[Bug 109923] Chromium shows blackscreen on sketchfab like sites (WebGL?) (rx460, 18.50-725072, 7/2/2019)
https://bugs.freedesktop.org/show_bug.cgi?id=109923
Bug ID: 109923
Summary: Chromium shows blackscreen on sketchfab like sites
(WebGL?) (rx460, 18.50-725072, 7/2/2019)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: DRM/AMDgpu-pro
Assignee: dri-devel@lists.freedesktop.org
Reporter: mihailov-...@mail.ru
Steps to Reproduce:
Open sketchfab.com, while loading chromium shows something, but then everything
gets black.
It is happening on 18.50-725072 amdgpu-pro drivers, while on 18.40-697810
chromium doesn't show blackscreen. I use Lubuntu 18.04.
Some outputs (there is one comment after dmesg):
$uname -a
Linux user 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64
x86_64 x86_64 GNU/Linux
$ dmesg | grep amdgpu
[6.246244] [drm] amdgpu kernel modesetting enabled.
[6.246246] [drm] amdgpu version: 18.50.1.418
[6.257297] fb: switching to amdgpudrmfb from VESA VGA
[6.257997] amdgpu :01:00.0: Invalid PCI ROM header signature: expecting
0xaa55, got 0x
[6.263289] amdgpu :01:00.0: VRAM: 2048M 0x00F4 -
0x00F47FFF (2048M used)
[6.263292] amdgpu :01:00.0: GART: 256M 0x00FF -
0x00FF0FFF
[6.267778] [drm] amdgpu: 2048M of VRAM memory ready
[6.267780] [drm] amdgpu: 13014M of GTT memory ready.
[6.633726] fbcon: amdgpudrmfb (fb0) is primary device
[6.694025] amdgpu :01:00.0: fb0: amdgpudrmfb frame buffer device
[6.711472] [drm] Initialized amdgpu 3.27.0 20150101 for :01:00.0 on
minor 0
[ 203.253903] amdgpu :01:00.0: GPU fault detected: 146 0x0378770c for
process chromium-browse pid 2365 thread chromium-browse pid 2365
[ 203.253910] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR
0x0011306F
[ 203.253912] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0807700C
[ 203.253915] amdgpu :01:00.0: VM fault (0x0c, vmid 4, pasid 32771) at
page 1126511, read from 'SDM0' (0x53444d30) (119)
[ 579.809297] amdgpu :01:00.0: GPU fault detected: 146 0x0378770c for
process chromium-browse pid 2365 thread chromium-browse pid 2365
[ 579.809305] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR
0x0011306F
[ 579.809307] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0E07700C
[ 579.809310] amdgpu :01:00.0: VM fault (0x0c, vmid 7, pasid 32771) at
page 1126511, read from 'SDM0' (0x53444d30) (119)
(The comment:)
The error messages after point [ 203.253903] are typical for 18.40-697810 too,
but chromium seems work not so bad. Render artifacts doesn't count.
(End of comment)
chrome://version tab:
Chromium72.0.3626.119 (Official Build) Built on Ubuntu , running on
Ubuntu 18.04 (64-bit)
Revision
9a65993e2cde1b5797ec98da4cd9abcea464cd7b-refs/branch-heads/3626@{#876}
OS Linux
JavaScript V8 7.2.502.26
Flash 32.0.0.142 /usr/lib/adobe-flashplugin/libpepflashplayer.so
User Agent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like
Gecko) Ubuntu Chromium/72.0.3626.119 Chrome/72.0.3626.119 Safari/537.36
Command Line/usr/lib/chromium-browser/chromium-browser
--ppapi-flash-path=/usr/lib/adobe-flashplugin/libpepflashplayer.so
--ppapi-flash-version=32.0.0.142 --enable-pinch
--enable-native-gpu-memory-buffers --enable-features=CheckerImaging
--flag-switches-begin --autoplay-policy=no-user-gesture-required
--enable-gpu-rasterization --enable-offline-auto-reload-visible-only
--disable-offline-auto-reload --enable-tcp-fastopen --enable-zero-copy
--ignore-gpu-blacklist --num-raster-threads=3
--enable-features=CheckerImaging,DrawOcclusion,ExpensiveBackgroundTimerThrottling,OptimizationHints,ParallelDownloading,UseSurfaceLayerForVideo
--disable-features=AutofillExpandedPopupViews,MemoryCoordinator,WebPayments,fill-on-account-select
--flag-switches-end
Executable Path /usr/lib/chromium-browser/chromium-browser
If it's not the right place for this bug please tell me where can I report it,
if you know.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #24 from Adrian Garay --- Since I didn't clearly specify above, my result was with amd-staging-drm-next, but the behavior is identical to the current 5.0 release. When the screen goes blank the machine stops responding, but it appears systemd still periodically logs work such as cron jobs. Laptop has to be hard powered down by holding the power switch. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #23 from Adrian Garay --- I am on firmware F.20 and the above does not work for me. I still see the scrambled line of garbage at boot, but instead of crashing my screen just goes blank. If I add modprobe.blacklist=amdgpu to the kernel I can boot, where I then SSH in and record the log file while running modprobe amdgpu from the laptop (attached.) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/11] drm/panel: simple: Add NewEast Optoelectronics CO., LTD WJFH116008A panel support
On Fri, Feb 22, 2019 at 10:37 AM Rob Herring wrote: > There is not any simple panel binding really. This originated I think > from a 'simple-panel' compatible that was originally attempted. What we > have is a collection of common properties for panels which panel > bindings can use. And we have some common panel docs too. I've been > meaning to clean-up and unify all this. I'm afraid I'm not right person to clean it up. My understanding of what different kind of panels and connectors need is pretty limited. Moreover I'm doing pinebook hacking in my spare time which is few hours a week and major panel/connector bindings clean up is not something I want to invest my time in. Since it seems to be a blocker I'll wait for someone to clean up panel/connector bindings and then respin the series. Meanwhile it'll live in my github. Thanks for review and sharing your ideas. Regards, Vasily ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #22 from Adrian Garay --- Created attachment 143560 --> https://bugs.freedesktop.org/attachment.cgi?id=143560=edit logged when modprobe amdgpu is run -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 John Doe (anode@gmail.com) changed: What|Removed |Added CC||anode@gmail.com --- Comment #3 from John Doe (anode@gmail.com) --- (In reply to Alex Deucher from comment #1) > This is more likely a mesa issue than a kernel issue. no, 4.14 kernel with latest mesa libs works very vell without any stucks but from 4.20.4 and in all latest kernels (including 5.0) OS freezes and stucks every 30s ... 1min for 30s when browsing youtube with HW acceleration enabled(uvd) or playing a game, RX550, Arch, vanilla kernel 365.021164] amdgpu: [powerplay] last message was failed ret is 0 [ 365.045198] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered [ 365.570667] amdgpu: [powerplay] failed to send message 133 ret is 0 [ 366.115228] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=9365, emitted seq=9365 [ 366.115377] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 [ 366.115388] [drm] Timeout, but no hardware hang detected. [ 366.689407] amdgpu: [powerplay] last message was failed ret is 0 [ 367.232287] amdgpu: [powerplay] failed to send message 306 ret is 0 [ 367.787043] amdgpu: [powerplay] last message was failed ret is 0 [ 368.320138] amdgpu: [powerplay] failed to send message 5e ret is 0 [ 369.367739] amdgpu: [powerplay] last message was failed ret is 0 [ 369.907559] amdgpu: [powerplay] failed to send message 145 ret is 0 [ 370.994478] amdgpu: [powerplay] last message was failed ret is 0 [ 371.538753] amdgpu: [powerplay] failed to send message 146 ret is 0 [ 372.075079] amdgpu: [powerplay] last message was failed ret is 0 [ 372.598565] amdgpu: [powerplay] failed to send message 148 ret is 0 [ 373.657188] amdgpu: [powerplay] last message was failed ret is 0 [ 374.198637] amdgpu: [powerplay] failed to send message 145 ret is 0 [ 375.075076] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered [ 375.284948] amdgpu: [powerplay] last message was failed ret is 0 [ 375.830347] amdgpu: [powerplay] failed to send message 146 ret is 0 [ 376.138428] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=10113, emitted seq=10113 [ 376.138783] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 [ 376.138797] [drm] IP block:sdma_v3_0 is hung! [ 376.138809] [drm] GPU recovery disabled. [ 376.394657] amdgpu: [powerplay] last message was failed ret is 0 [ 376.934375] amdgpu: [powerplay] failed to send message 16a ret is 0 [ 377.463230] amdgpu: [powerplay] last message was failed ret is 0 [ 377.977725] amdgpu: [powerplay] failed to send message 186 ret is 0 [ 378.518406] amdgpu: [powerplay] last message was failed ret is 0 [ 379.060098] amdgpu: [powerplay] failed to send message 54 ret is 0 [ 379.556880] amdgpu: [powerplay] last message was failed ret is 0 [ 380.075217] amdgpu: [powerplay] failed to send message 26b ret is 0 [ 380.605976] amdgpu: [powerplay] last message was failed ret is 0 [ 381.134301] amdgpu: [powerplay] failed to send message 13d ret is 0 [ 381.657486] amdgpu: [powerplay] last message was failed ret is 0 [ 382.204551] amdgpu: [powerplay] failed to send message 14f ret is 0 [ 382.741827] amdgpu: [powerplay] last message was failed ret is 0 [ 383.281165] amdgpu: [powerplay] failed to send message 151 ret is 0 [ 383.824923] amdgpu: [powerplay] last message was failed ret is 0 [ 384.362266] amdgpu: [powerplay] failed to send message 135 ret is 0 [ 384.903686] amdgpu: [powerplay] last message was failed ret is 0 [ 385.101515] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered [ 385.461515] amdgpu: [powerplay] failed to send message 190 ret is 0 [ 386.014015] amdgpu: [powerplay] last message was failed ret is 0 [ 386.164818] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=10761, emitted seq=10761 [ 386.164970] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 [ 386.164985] [drm] Timeout, but no hardware hang detected. -- You are receiving this mail because: You are
[radeon-alex:amd-staging-drm-next 673/688] htmldocs: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:537: warning: Function parameter or member 'start' not described in 'amdgpu_vm_pt_first_dfs'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: c9115f8904eef0f880d3b4f8306f553b1bb1c532 commit: 0629ed786b3faa5e968d81c22a388958801db25a [673/688] drm/amdgpu: free PDs/PTs on demand reproduce: make htmldocs All warnings (new ones prefixed by >>): include/linux/interrupt.h:268: warning: Function parameter or member 'is_managed' not described in 'irq_affinity_desc' block/blk-core.c:685: warning: Excess function parameter 'request_count' description in 'blk_attempt_plug_merge' block/blk-core.c:685: warning: Excess function parameter 'request_count' description in 'blk_attempt_plug_merge' include/linux/rcupdate_wait.h:1: warning: no structured comments found include/linux/rcutree.h:1: warning: no structured comments found kernel/rcu/tree.c:710: warning: Excess function parameter 'irq' description in 'rcu_nmi_exit' include/linux/gfp.h:1: warning: no structured comments found include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ibss' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.connect' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.keys' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ie' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ie_len' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ssid' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.default_key' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.default_mgmt_key' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.prev_bssid_valid' not described in 'wireless_dev' include/net/mac80211.h:2393: warning: Function parameter or member 'radiotap_timestamp.units_pos' not described in 'ieee80211_hw' include/net/mac80211.h:2393: warning: Function parameter or member 'radiotap_timestamp.accuracy' not described in 'ieee80211_hw' include/net/mac80211.h:1004: warning: Function parameter or member 'control.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.use_rts' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.use_cts_prot' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.short_preamble' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.skip_table' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.jiffies' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.vif' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.hw_key' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.flags' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.enqueue_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'ack' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.ampdu_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.antenna' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.tx_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or
[radeon-alex:amd-staging-drm-next 2/2] drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c:338:1: sparse: warning: no newline at end of file
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: c9115f8904eef0f880d3b4f8306f553b1bb1c532
commit: c9115f8904eef0f880d3b4f8306f553b1bb1c532 [2/2] drm/amdgpu: XGMI pstate
switch initial support
reproduce:
# apt-get install sparse
git checkout c9115f8904eef0f880d3b4f8306f553b1bb1c532
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c:338:1: sparse: warning: no newline
>> at end of file
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c:37:6: sparse: warning: symbol
'amdgpu_xgmi_hive_try_lock' was not declared. Should it be static?
vim +338 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
325
326 int amdgpu_xgmi_set_pstate(struct amdgpu_device *adev, int pstate)
327 {
328 int ret = 0;
329 struct amdgpu_hive_info *hive = amdgpu_get_xgmi_hive(adev, 0);
330
331 if (!hive)
332 return 0;
333
334 if (hive->pstate == pstate)
335 return 0;
336 /* Todo : sent the message to SMU for pstate change */
337 return ret;
> 338 }
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
On Thu, Mar 7, 2019 at 9:11 AM Eric Anholt wrote: > > Rob Herring writes: > > > On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote: > >> > >> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for > >> OpenGL vertex shader processing and PP is for fragment shader > >> processing. Each processor has its own MMU so prcessors work in > >> virtual address space. > >> - There's only one GP but multiple PP (max 4 for mali 400 and 8 > >> for mali 450) in the same mali 4xx GPU. All PPs are grouped > >> togather to handle a single fragment shader task divided by > >> FB output tiled pixels. Mali 400 user space driver is > >> responsible for assign target tiled pixels to each PP, but mali > >> 450 has a HW module called DLBU to dynamically balance each > >> PP's load. > >> - User space driver allocate buffer object and map into GPU > >> virtual address space, upload command stream and draw data with > >> CPU mmap of the buffer object, then submit task to GP/PP with > >> a register frame indicating where is the command stream and misc > >> settings. > >> - There's no command stream validation/relocation due to each user > >> process has its own GPU virtual address space. GP/PP's MMU switch > >> virtual address space before running two tasks from different > >> user process. Error or evil user space code just get MMU fault > >> or GP/PP error IRQ, then the HW/SW will be recovered. > >> - Use GEM+shmem for MM. Currently just alloc and pin memory when > >> gem object creation. GPU vm map of the buffer is also done in > >> the alloc stage in kernel space. We may delay the memory > >> allocation and real GPU vm map to command submission stage in the > >> furture as improvement. > >> - Use drm_sched for GPU task schedule. Each OpenGL context should > >> have a lima context object in the kernel to distinguish tasks > >> from different user. drm_sched gets task from each lima context > >> in a fair way. > >> > >> mesa driver can be found here before upstreamed: > >> https://gitlab.freedesktop.org/lima/mesa > >> > >> v7: > >> - remove lima_fence_ops with default value > >> - move fence slab create to device probe > >> - check pad ioctl args to be zero > >> - add comments for user/kernel interface > >> > >> v6: > >> - fix comments by checkpatch.pl > >> > >> v5: > >> - export gp/pp version to userspace > >> - rebase on drm-misc-next > >> > >> v4: > >> - use get param interface to get info > >> - separate context create/free ioctl > >> - remove unused max sched task param > >> - update copyright time > >> - use xarray instead of idr > >> - stop using drmP.h > >> > >> v3: > >> - fix comments from kbuild robot > >> - restrict supported arch to tested ones > >> > >> v2: > >> - fix syscall argument check > >> - fix job finish fence leak since kernel 5.0 > >> - use drm syncobj to replace native fence > >> - move buffer object GPU va map into kernel > >> - reserve syscall argument space for future info > >> - remove kernel gem modifier > >> - switch TTM back to GEM+shmem MM > >> - use time based io poll > >> - use whole register name > >> - adopt gem reservation obj integration > >> - use drm_timeout_abs_to_jiffies > >> > >> Cc: Eric Anholt > >> Cc: Rob Herring > >> Cc: Christian König > >> Cc: Daniel Vetter > >> Cc: Alex Deucher > >> Cc: Sam Ravnborg > >> Cc: Rob Clark > >> Signed-off-by: Andreas Baierl > >> Signed-off-by: Erico Nunes > >> Signed-off-by: Heiko Stuebner > >> Signed-off-by: Marek Vasut > >> Signed-off-by: Neil Armstrong > >> Signed-off-by: Simon Shields > >> Signed-off-by: Vasily Khoruzhick > >> Signed-off-by: Qiang Yu > >> --- > >> drivers/gpu/drm/Kconfig | 2 + > >> drivers/gpu/drm/Makefile | 1 + > >> drivers/gpu/drm/lima/Kconfig | 10 + > >> drivers/gpu/drm/lima/Makefile | 21 ++ > >> drivers/gpu/drm/lima/lima_bcast.c | 47 +++ > >> drivers/gpu/drm/lima/lima_bcast.h | 14 + > >> drivers/gpu/drm/lima/lima_ctx.c | 97 ++ > >> drivers/gpu/drm/lima/lima_ctx.h | 30 ++ > >> drivers/gpu/drm/lima/lima_device.c| 385 +++ > >> drivers/gpu/drm/lima/lima_device.h| 131 > >> drivers/gpu/drm/lima/lima_dlbu.c | 58 > >> drivers/gpu/drm/lima/lima_dlbu.h | 18 ++ > >> drivers/gpu/drm/lima/lima_drv.c | 376 +++ > >> drivers/gpu/drm/lima/lima_drv.h | 45 +++ > >> drivers/gpu/drm/lima/lima_gem.c | 381 +++ > >> drivers/gpu/drm/lima/lima_gem.h | 25 ++ > >> drivers/gpu/drm/lima/lima_gem_prime.c | 47 +++ > >> drivers/gpu/drm/lima/lima_gem_prime.h | 13 + > >> drivers/gpu/drm/lima/lima_gp.c| 283 + > >> drivers/gpu/drm/lima/lima_gp.h| 16 + > >> drivers/gpu/drm/lima/lima_l2_cache.c | 80 + > >> drivers/gpu/drm/lima/lima_l2_cache.h | 14 + > >> drivers/gpu/drm/lima/lima_mmu.c | 142 + > >>
[Bug 202799] New: amd/dc: right monitor sometimes never comes back up on dual-display setup after locking session
https://bugzilla.kernel.org/show_bug.cgi?id=202799 Bug ID: 202799 Summary: amd/dc: right monitor sometimes never comes back up on dual-display setup after locking session Product: Drivers Version: 2.5 Kernel Version: 5.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: li...@protonmail.com Regression: No Created attachment 281547 --> https://bugzilla.kernel.org/attachment.cgi?id=281547=edit xrandr --props output - linux 5.0 (4.20 also had the same issue) - xf86-video-amdgpu 18.1.0 - GNOME 3.30 Left screen is a Dell U2412M (1920x1200), right screen is a Dell P2715Q (4K monitor set at 2560x1440, primary). GPU is RX 580. Steps to reproduce: - Lock session, screens turn off - After a while, press a key to turn the screens back on again - When the left screen lights up first, the system only displays an image on the left screen. The right screen lights up afterwards but goes back to sleep because it's getting no signal, although xrandr still recognizes it. I need to manually turn off the right screen and back on again to get it to reconfigure. When using `amdgpu.dc=0`, this issue disappears. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] drm: Add library for shmem backed GEM objects
On Wed, Mar 6, 2019 at 6:50 PM Eric Anholt wrote: > > Rob Herring writes: > > > From: Noralf Trønnes > > > > This adds a library for shmem backed GEM objects. > > > > v7: > > - Use write-combine for mmap instead. This is the more common > > case. (robher) > > > > v6: > > - Fix uninitialized variable issue in an error path (anholt). > > - Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting > > of the pages (anholt). > > > > v5: > > - Drop drm_gem_shmem_prime_mmap() (Daniel Vetter) > > - drm_gem_shmem_mmap(): Subtract drm_vma_node_start() to get the real > > vma->vm_pgoff > > - drm_gem_shmem_fault(): Use vmf->pgoff now that vma->vm_pgoff is correct > > > > v4: > > - Drop cache modes (Thomas Hellstrom) > > - Add a GEM attached vtable > > > > v3: > > - Grammar (Sam Ravnborg) > > - s/drm_gem_shmem_put_pages_unlocked/drm_gem_shmem_put_pages_locked/ > > (Sam Ravnborg) > > - Add debug output in error path (Sam Ravnborg) > > > > Signed-off-by: Noralf Trønnes > > Signed-off-by: Eric Anholt > > Signed-off-by: Rob Herring > > --- > > I don't have a user to submit just yet, but we are using this for > > panfrost which can be seen here[1]. I expect we'll be ready to merge > > panfrost for 5.2. I need to add exporting drm_gem_shmem_create_with_handle() as well. I was thinking I was just using that in my rockchip conversion attempt, but I need it for panfrost too. > Excellent. I'm taking a look at this for v3d, and I see that on the > panfrost side you're allocating shmem->sgt and doing dma_map_sg() in > your MMU map code, with no error handling. And, on MMU unmap I see > dma_unmap_sg() unconditionally (won't that unbalance for a prime import > which will presumably do its own unmapping?), but it also looks like the > sgt is not freed. Indeed, I'll need to split those. Error handling? Panfrost doesn't do that. ;) > Can we do something nicer for handling the driver's desire for the sgt > to fill its PTEs, regardless of where the BO came from? Not sure I follow. You mean do something in shmem helpers? I'm assuming when we pin and dma map will evolve from at BO creation time to on demand. > I also hope we can plug this into vkms and turn on prime sharing for it. Doesn't seem too hard. I'd assume vkms would be okay with WC mappings as it looks like they are currently cacheable? We could add a dma attrs field to let users customize the mapping, but I'd rather avoid that if possible. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/msm/dpu: dont use encoder->crtc in atomic path
On 2019-03-04 10:09, Sean Paul wrote:
On Wed, Feb 13, 2019 at 05:19:13PM -0800, Jeykumar Sankaran wrote:
encoder->crtc is not really meaningful for atomic path. Use
crtc->encoder_mask to identify the crtc attached with
an encoder.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 45617b9..0a19124 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -961,6 +961,7 @@ static void dpu_encoder_virt_mode_set(struct
drm_encoder *drm_enc,
struct dpu_kms *dpu_kms;
struct list_head *connector_list;
struct drm_connector *conn = NULL, *conn_iter;
+ struct drm_crtc *drm_crtc;
struct dpu_rm_hw_iter pp_iter, ctl_iter;
struct msm_display_topology topology;
struct dpu_hw_ctl *hw_ctl[MAX_CHANNELS_PER_ENC] = { NULL };
@@ -992,10 +993,14 @@ static void dpu_encoder_virt_mode_set(struct
drm_encoder *drm_enc,
return;
}
+ drm_for_each_crtc(drm_crtc, drm_enc->dev)
+ if (drm_crtc->state->encoder_mask &
drm_encoder_mask(drm_enc))
+ break;
You should check whether you actually found the crtc, or are just using
the last
one in the list.
I see you have pulled in the this entire series on msm-next. If it is
the right
thing to do, I can address this comment in a separate patch on top
instead of
posting v2.
Thanks
Jeykumar S.
Sean
+
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
/* Reserve dynamic resources now. Indicating non-AtomicTest phase
*/
- ret = dpu_rm_reserve(_kms->rm, drm_enc, drm_enc->crtc->state,
+ ret = dpu_rm_reserve(_kms->rm, drm_enc, drm_crtc->state,
topology, false);
if (ret) {
DPU_ERROR_ENC(dpu_enc,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
On Thu, Mar 7, 2019 at 8:15 AM Dave Airlie wrote:
>
> > +#endif
> > diff --git a/include/uapi/drm/lima_drm.h b/include/uapi/drm/lima_drm.h
> > new file mode 100644
> > index ..05f8c910d7fb
> > --- /dev/null
> > +++ b/include/uapi/drm/lima_drm.h
> > @@ -0,0 +1,164 @@
> > +/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
> > +/* Copyright 2017-2018 Qiang Yu */
> > +
> > +#ifndef __LIMA_DRM_H__
> > +#define __LIMA_DRM_H__
> > +
> > +#include "drm.h"
> > +
> > +#if defined(__cplusplus)
> > +extern "C" {
> > +#endif
> > +
> > +enum drm_lima_param_gpu_id {
> > + DRM_LIMA_PARAM_GPU_ID_UNKNOWN,
> > + DRM_LIMA_PARAM_GPU_ID_MALI400,
> > + DRM_LIMA_PARAM_GPU_ID_MALI450,
> > +};
> > +
> > +enum drm_lima_param {
> > + DRM_LIMA_PARAM_GPU_ID,
> > + DRM_LIMA_PARAM_NUM_PP,
> > + DRM_LIMA_PARAM_GP_VERSION,
> > + DRM_LIMA_PARAM_PP_VERSION,
> > +};
> > +
> > +/**
> > + * get various information of the GPU
> > + */
> > +struct drm_lima_get_param {
> > + __u32 param; /* in, value in enum drm_lima_param */
> > + __u32 pad; /* pad, must be zero */
> > + __u64 value; /* out, parameter value */
> > +};
> > +
> > +/**
> > + * create a buffer for used by GPU
> > + */
> > +struct drm_lima_gem_create {
> > + __u32 size;/* in, buffer size */
> > + __u32 flags; /* in, currently no flags, must be zero */
> > + __u32 handle; /* out, GEM buffer handle */
> > + __u32 pad; /* pad, must be zero */
> > +};
> > +
> > +/**
> > + * get information of a buffer
> > + */
> > +struct drm_lima_gem_info {
> > + __u32 handle; /* in, GEM buffer handle */
> > + __u32 va; /* out, virtual address mapped into GPU MMU */
> > + __u64 offset; /* out, used to mmap this buffer to CPU */
> > +};
> > +
> > +#define LIMA_SUBMIT_BO_READ 0x01
> > +#define LIMA_SUBMIT_BO_WRITE 0x02
> > +
> > +/* buffer information used by one task */
> > +struct drm_lima_gem_submit_bo {
> > + __u32 handle; /* in, GEM buffer handle */
> > + __u32 flags; /* in, buffer read/write by GPU */
> > +};
> > +
> > +#define LIMA_GP_FRAME_REG_NUM 6
> > +
> > +/* frame used to setup GP for each task */
> > +struct drm_lima_gp_frame {
> > + __u32 frame[LIMA_GP_FRAME_REG_NUM];
> > +};
> > +
> > +#define LIMA_PP_FRAME_REG_NUM 23
> > +#define LIMA_PP_WB_REG_NUM 12
> > +
> > +/* frame used to setup mali400 GPU PP for each task */
> > +struct drm_lima_m400_pp_frame {
> > + __u32 frame[LIMA_PP_FRAME_REG_NUM];
> > + __u32 num_pp;
> > + __u32 wb[3 * LIMA_PP_WB_REG_NUM];
> > + __u32 plbu_array_address[4];
> > + __u32 fragment_stack_address[4];
> > +};
> > +
> > +/* frame used to setup mali450 GPU PP for each task */
> > +struct drm_lima_m450_pp_frame {
> > + __u32 frame[LIMA_PP_FRAME_REG_NUM];
> > + __u32 num_pp;
> > + __u32 wb[3 * LIMA_PP_WB_REG_NUM];
> > + __u32 use_dlbu;
> > + __u32 _pad;
> > + union {
> > + __u32 plbu_array_address[8];
> > + __u32 dlbu_regs[4];
> > + };
> > + __u32 fragment_stack_address[8];
> > +};
> > +
> > +#define LIMA_PIPE_GP 0x00
> > +#define LIMA_PIPE_PP 0x01
> > +
> > +#define LIMA_SUBMIT_FLAG_EXPLICIT_FENCE (1 << 0)
> > +
> > +/**
> > + * submit a task to GPU
> > + */
> > +struct drm_lima_gem_submit {
> > + __u32 ctx; /* in, context handle task is submitted to */
> > + __u32 pipe;/* in, which pipe to use, GP/PP */
> > + __u32 nr_bos; /* in, array length of bos field */
> > + __u32 frame_size; /* in, size of frame field */
> > + __u64 bos; /* in, array of drm_lima_gem_submit_bo */
> > + __u64 frame; /* in, GP/PP frame */
> > + __u32 flags; /* in, submit flags */
> > + __u32 out_sync;/* in, drm_syncobj handle used to wait task
> > finish after submission */
> > + __u32 in_sync[2]; /* in, drm_syncobj handle used to wait before
> > start this task */
> > +};
>
> This seems a bit limited, is there a reason it's two, at least in
> Vulkan drivers we'd want more than two I suspect (Vulkan may not work
> on this hw anyways), but it might be required in the future to make
> this extensible.
Mali4xx GPU does not support Vulkan, the reason I pick two is, one for
sync_file fd imported drm_syncobj, one for GP out_sync be able to pass
to PP in_sync directly when explicit fence without
drm_syncobj -> sync_file -> merge sync_file -> drm_syncobj
pass.
>
> At least a comment stating why 2 was picked is sufficient for current use
> cases.
>
OK, will add it.
Regards,
Qiang
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
On Thu, Mar 7, 2019 at 8:08 AM Dave Airlie wrote: > > On Thu, 7 Mar 2019 at 09:46, Rob Herring wrote: > > > > On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote: > > > > > > - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for > > > OpenGL vertex shader processing and PP is for fragment shader > > > processing. Each processor has its own MMU so prcessors work in > > > virtual address space. > > > - There's only one GP but multiple PP (max 4 for mali 400 and 8 > > > for mali 450) in the same mali 4xx GPU. All PPs are grouped > > > togather to handle a single fragment shader task divided by > > > FB output tiled pixels. Mali 400 user space driver is > > > responsible for assign target tiled pixels to each PP, but mali > > > 450 has a HW module called DLBU to dynamically balance each > > > PP's load. > > > - User space driver allocate buffer object and map into GPU > > > virtual address space, upload command stream and draw data with > > > CPU mmap of the buffer object, then submit task to GP/PP with > > > a register frame indicating where is the command stream and misc > > > settings. > > > - There's no command stream validation/relocation due to each user > > > process has its own GPU virtual address space. GP/PP's MMU switch > > > virtual address space before running two tasks from different > > > user process. Error or evil user space code just get MMU fault > > > or GP/PP error IRQ, then the HW/SW will be recovered. > > > - Use GEM+shmem for MM. Currently just alloc and pin memory when > > > gem object creation. GPU vm map of the buffer is also done in > > > the alloc stage in kernel space. We may delay the memory > > > allocation and real GPU vm map to command submission stage in the > > > furture as improvement. > > > - Use drm_sched for GPU task schedule. Each OpenGL context should > > > have a lima context object in the kernel to distinguish tasks > > > from different user. drm_sched gets task from each lima context > > > in a fair way. > > > > > > mesa driver can be found here before upstreamed: > > > https://gitlab.freedesktop.org/lima/mesa > > > > > > v7: > > > - remove lima_fence_ops with default value > > > - move fence slab create to device probe > > > - check pad ioctl args to be zero > > > - add comments for user/kernel interface > > > > > > v6: > > > - fix comments by checkpatch.pl > > > > > > v5: > > > - export gp/pp version to userspace > > > - rebase on drm-misc-next > > > > > > v4: > > > - use get param interface to get info > > > - separate context create/free ioctl > > > - remove unused max sched task param > > > - update copyright time > > > - use xarray instead of idr > > > - stop using drmP.h > > > > > > v3: > > > - fix comments from kbuild robot > > > - restrict supported arch to tested ones > > > > > > v2: > > > - fix syscall argument check > > > - fix job finish fence leak since kernel 5.0 > > > - use drm syncobj to replace native fence > > > - move buffer object GPU va map into kernel > > > - reserve syscall argument space for future info > > > - remove kernel gem modifier > > > - switch TTM back to GEM+shmem MM > > > - use time based io poll > > > - use whole register name > > > - adopt gem reservation obj integration > > > - use drm_timeout_abs_to_jiffies > > > > > > Cc: Eric Anholt > > > Cc: Rob Herring > > > Cc: Christian König > > > Cc: Daniel Vetter > > > Cc: Alex Deucher > > > Cc: Sam Ravnborg > > > Cc: Rob Clark > > > Signed-off-by: Andreas Baierl > > > Signed-off-by: Erico Nunes > > > Signed-off-by: Heiko Stuebner > > > Signed-off-by: Marek Vasut > > > Signed-off-by: Neil Armstrong > > > Signed-off-by: Simon Shields > > > Signed-off-by: Vasily Khoruzhick > > > Signed-off-by: Qiang Yu > > > --- > > > drivers/gpu/drm/Kconfig | 2 + > > > drivers/gpu/drm/Makefile | 1 + > > > drivers/gpu/drm/lima/Kconfig | 10 + > > > drivers/gpu/drm/lima/Makefile | 21 ++ > > > drivers/gpu/drm/lima/lima_bcast.c | 47 +++ > > > drivers/gpu/drm/lima/lima_bcast.h | 14 + > > > drivers/gpu/drm/lima/lima_ctx.c | 97 ++ > > > drivers/gpu/drm/lima/lima_ctx.h | 30 ++ > > > drivers/gpu/drm/lima/lima_device.c| 385 +++ > > > drivers/gpu/drm/lima/lima_device.h| 131 > > > drivers/gpu/drm/lima/lima_dlbu.c | 58 > > > drivers/gpu/drm/lima/lima_dlbu.h | 18 ++ > > > drivers/gpu/drm/lima/lima_drv.c | 376 +++ > > > drivers/gpu/drm/lima/lima_drv.h | 45 +++ > > > drivers/gpu/drm/lima/lima_gem.c | 381 +++ > > > drivers/gpu/drm/lima/lima_gem.h | 25 ++ > > > drivers/gpu/drm/lima/lima_gem_prime.c | 47 +++ > > > drivers/gpu/drm/lima/lima_gem_prime.h | 13 + > > > drivers/gpu/drm/lima/lima_gp.c| 283 + > > > drivers/gpu/drm/lima/lima_gp.h| 16 + > > > drivers/gpu/drm/lima/lima_l2_cache.c | 80 + >
[radeon-alex:amd-staging-drm-next 672/688] htmldocs: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:898: warning: Function parameter or member 'cursor' not described in 'amdgpu_vm_alloc_pts'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: c9115f8904eef0f880d3b4f8306f553b1bb1c532 commit: 73eaf1e03db0ef8fb44dcaa391cbcf1a219f299f [672/688] drm/amdgpu: allocate VM PDs/PTs on demand reproduce: make htmldocs All warnings (new ones prefixed by >>): kernel/rcu/tree.c:710: warning: Excess function parameter 'irq' description in 'rcu_nmi_exit' include/linux/gfp.h:1: warning: no structured comments found include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ibss' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.connect' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.keys' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ie' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ie_len' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ssid' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.default_key' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.default_mgmt_key' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.prev_bssid_valid' not described in 'wireless_dev' include/net/mac80211.h:2393: warning: Function parameter or member 'radiotap_timestamp.units_pos' not described in 'ieee80211_hw' include/net/mac80211.h:2393: warning: Function parameter or member 'radiotap_timestamp.accuracy' not described in 'ieee80211_hw' include/net/mac80211.h:1004: warning: Function parameter or member 'control.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.use_rts' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.use_cts_prot' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.short_preamble' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.skip_table' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.jiffies' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.vif' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.hw_key' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.flags' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.enqueue_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'ack' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.ampdu_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.antenna' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.tx_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.status_driver_data' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'driver_rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'pad' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'rate_driver_data' not described in 'ieee80211_tx_info' net/mac80211/sta_info.h:590: warning: Function
[PATCH] drm/msm/dsi: add protection against NULL dsi device
When panel probe happens after DSI probe, the DSI probe
is deferred as per current design. In the probe defer path
dsi device is destroyed. This NULL dsi device could be
deferenced by the panel probe in the mipi_dsi_attach path.
Check for NULL dsi device before accessing it.
Reported-by: Jeffrey Hugo
Tested-by: Jeffrey Hugo
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 80aa634..cc2569d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -769,7 +769,7 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 dma_base,
u32 len)
void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags)
{
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
- struct drm_device *dev = msm_dsi->dev;
+ struct drm_device *dev = msm_dsi ? msm_dsi->dev : NULL;
struct msm_drm_private *priv;
struct msm_kms *kms;
struct drm_encoder *encoder;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
Rob Herring writes: > On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote: >> >> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for >> OpenGL vertex shader processing and PP is for fragment shader >> processing. Each processor has its own MMU so prcessors work in >> virtual address space. >> - There's only one GP but multiple PP (max 4 for mali 400 and 8 >> for mali 450) in the same mali 4xx GPU. All PPs are grouped >> togather to handle a single fragment shader task divided by >> FB output tiled pixels. Mali 400 user space driver is >> responsible for assign target tiled pixels to each PP, but mali >> 450 has a HW module called DLBU to dynamically balance each >> PP's load. >> - User space driver allocate buffer object and map into GPU >> virtual address space, upload command stream and draw data with >> CPU mmap of the buffer object, then submit task to GP/PP with >> a register frame indicating where is the command stream and misc >> settings. >> - There's no command stream validation/relocation due to each user >> process has its own GPU virtual address space. GP/PP's MMU switch >> virtual address space before running two tasks from different >> user process. Error or evil user space code just get MMU fault >> or GP/PP error IRQ, then the HW/SW will be recovered. >> - Use GEM+shmem for MM. Currently just alloc and pin memory when >> gem object creation. GPU vm map of the buffer is also done in >> the alloc stage in kernel space. We may delay the memory >> allocation and real GPU vm map to command submission stage in the >> furture as improvement. >> - Use drm_sched for GPU task schedule. Each OpenGL context should >> have a lima context object in the kernel to distinguish tasks >> from different user. drm_sched gets task from each lima context >> in a fair way. >> >> mesa driver can be found here before upstreamed: >> https://gitlab.freedesktop.org/lima/mesa >> >> v7: >> - remove lima_fence_ops with default value >> - move fence slab create to device probe >> - check pad ioctl args to be zero >> - add comments for user/kernel interface >> >> v6: >> - fix comments by checkpatch.pl >> >> v5: >> - export gp/pp version to userspace >> - rebase on drm-misc-next >> >> v4: >> - use get param interface to get info >> - separate context create/free ioctl >> - remove unused max sched task param >> - update copyright time >> - use xarray instead of idr >> - stop using drmP.h >> >> v3: >> - fix comments from kbuild robot >> - restrict supported arch to tested ones >> >> v2: >> - fix syscall argument check >> - fix job finish fence leak since kernel 5.0 >> - use drm syncobj to replace native fence >> - move buffer object GPU va map into kernel >> - reserve syscall argument space for future info >> - remove kernel gem modifier >> - switch TTM back to GEM+shmem MM >> - use time based io poll >> - use whole register name >> - adopt gem reservation obj integration >> - use drm_timeout_abs_to_jiffies >> >> Cc: Eric Anholt >> Cc: Rob Herring >> Cc: Christian König >> Cc: Daniel Vetter >> Cc: Alex Deucher >> Cc: Sam Ravnborg >> Cc: Rob Clark >> Signed-off-by: Andreas Baierl >> Signed-off-by: Erico Nunes >> Signed-off-by: Heiko Stuebner >> Signed-off-by: Marek Vasut >> Signed-off-by: Neil Armstrong >> Signed-off-by: Simon Shields >> Signed-off-by: Vasily Khoruzhick >> Signed-off-by: Qiang Yu >> --- >> drivers/gpu/drm/Kconfig | 2 + >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/lima/Kconfig | 10 + >> drivers/gpu/drm/lima/Makefile | 21 ++ >> drivers/gpu/drm/lima/lima_bcast.c | 47 +++ >> drivers/gpu/drm/lima/lima_bcast.h | 14 + >> drivers/gpu/drm/lima/lima_ctx.c | 97 ++ >> drivers/gpu/drm/lima/lima_ctx.h | 30 ++ >> drivers/gpu/drm/lima/lima_device.c| 385 +++ >> drivers/gpu/drm/lima/lima_device.h| 131 >> drivers/gpu/drm/lima/lima_dlbu.c | 58 >> drivers/gpu/drm/lima/lima_dlbu.h | 18 ++ >> drivers/gpu/drm/lima/lima_drv.c | 376 +++ >> drivers/gpu/drm/lima/lima_drv.h | 45 +++ >> drivers/gpu/drm/lima/lima_gem.c | 381 +++ >> drivers/gpu/drm/lima/lima_gem.h | 25 ++ >> drivers/gpu/drm/lima/lima_gem_prime.c | 47 +++ >> drivers/gpu/drm/lima/lima_gem_prime.h | 13 + >> drivers/gpu/drm/lima/lima_gp.c| 283 + >> drivers/gpu/drm/lima/lima_gp.h| 16 + >> drivers/gpu/drm/lima/lima_l2_cache.c | 80 + >> drivers/gpu/drm/lima/lima_l2_cache.h | 14 + >> drivers/gpu/drm/lima/lima_mmu.c | 142 + >> drivers/gpu/drm/lima/lima_mmu.h | 16 + >> drivers/gpu/drm/lima/lima_object.c| 122 >> drivers/gpu/drm/lima/lima_object.h| 36 +++ >> drivers/gpu/drm/lima/lima_pmu.c | 60 >> drivers/gpu/drm/lima/lima_pmu.h | 12 + >> drivers/gpu/drm/lima/lima_pp.c| 427
Re: [PATCH v7] drm: Add library for shmem backed GEM objects
Rob Herring writes: > From: Noralf Trønnes > > This adds a library for shmem backed GEM objects. > > v7: > - Use write-combine for mmap instead. This is the more common > case. (robher) > > v6: > - Fix uninitialized variable issue in an error path (anholt). > - Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting > of the pages (anholt). > > v5: > - Drop drm_gem_shmem_prime_mmap() (Daniel Vetter) > - drm_gem_shmem_mmap(): Subtract drm_vma_node_start() to get the real > vma->vm_pgoff > - drm_gem_shmem_fault(): Use vmf->pgoff now that vma->vm_pgoff is correct > > v4: > - Drop cache modes (Thomas Hellstrom) > - Add a GEM attached vtable > > v3: > - Grammar (Sam Ravnborg) > - s/drm_gem_shmem_put_pages_unlocked/drm_gem_shmem_put_pages_locked/ > (Sam Ravnborg) > - Add debug output in error path (Sam Ravnborg) > > Signed-off-by: Noralf Trønnes > Signed-off-by: Eric Anholt > Signed-off-by: Rob Herring > --- > I don't have a user to submit just yet, but we are using this for > panfrost which can be seen here[1]. I expect we'll be ready to merge > panfrost for 5.2. Excellent. I'm taking a look at this for v3d, and I see that on the panfrost side you're allocating shmem->sgt and doing dma_map_sg() in your MMU map code, with no error handling. And, on MMU unmap I see dma_unmap_sg() unconditionally (won't that unbalance for a prime import which will presumably do its own unmapping?), but it also looks like the sgt is not freed. Can we do something nicer for handling the driver's desire for the sgt to fill its PTEs, regardless of where the BO came from? I also hope we can plug this into vkms and turn on prime sharing for it. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
> +#endif
> diff --git a/include/uapi/drm/lima_drm.h b/include/uapi/drm/lima_drm.h
> new file mode 100644
> index ..05f8c910d7fb
> --- /dev/null
> +++ b/include/uapi/drm/lima_drm.h
> @@ -0,0 +1,164 @@
> +/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
> +/* Copyright 2017-2018 Qiang Yu */
> +
> +#ifndef __LIMA_DRM_H__
> +#define __LIMA_DRM_H__
> +
> +#include "drm.h"
> +
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> +enum drm_lima_param_gpu_id {
> + DRM_LIMA_PARAM_GPU_ID_UNKNOWN,
> + DRM_LIMA_PARAM_GPU_ID_MALI400,
> + DRM_LIMA_PARAM_GPU_ID_MALI450,
> +};
> +
> +enum drm_lima_param {
> + DRM_LIMA_PARAM_GPU_ID,
> + DRM_LIMA_PARAM_NUM_PP,
> + DRM_LIMA_PARAM_GP_VERSION,
> + DRM_LIMA_PARAM_PP_VERSION,
> +};
> +
> +/**
> + * get various information of the GPU
> + */
> +struct drm_lima_get_param {
> + __u32 param; /* in, value in enum drm_lima_param */
> + __u32 pad; /* pad, must be zero */
> + __u64 value; /* out, parameter value */
> +};
> +
> +/**
> + * create a buffer for used by GPU
> + */
> +struct drm_lima_gem_create {
> + __u32 size;/* in, buffer size */
> + __u32 flags; /* in, currently no flags, must be zero */
> + __u32 handle; /* out, GEM buffer handle */
> + __u32 pad; /* pad, must be zero */
> +};
> +
> +/**
> + * get information of a buffer
> + */
> +struct drm_lima_gem_info {
> + __u32 handle; /* in, GEM buffer handle */
> + __u32 va; /* out, virtual address mapped into GPU MMU */
> + __u64 offset; /* out, used to mmap this buffer to CPU */
> +};
> +
> +#define LIMA_SUBMIT_BO_READ 0x01
> +#define LIMA_SUBMIT_BO_WRITE 0x02
> +
> +/* buffer information used by one task */
> +struct drm_lima_gem_submit_bo {
> + __u32 handle; /* in, GEM buffer handle */
> + __u32 flags; /* in, buffer read/write by GPU */
> +};
> +
> +#define LIMA_GP_FRAME_REG_NUM 6
> +
> +/* frame used to setup GP for each task */
> +struct drm_lima_gp_frame {
> + __u32 frame[LIMA_GP_FRAME_REG_NUM];
> +};
> +
> +#define LIMA_PP_FRAME_REG_NUM 23
> +#define LIMA_PP_WB_REG_NUM 12
> +
> +/* frame used to setup mali400 GPU PP for each task */
> +struct drm_lima_m400_pp_frame {
> + __u32 frame[LIMA_PP_FRAME_REG_NUM];
> + __u32 num_pp;
> + __u32 wb[3 * LIMA_PP_WB_REG_NUM];
> + __u32 plbu_array_address[4];
> + __u32 fragment_stack_address[4];
> +};
> +
> +/* frame used to setup mali450 GPU PP for each task */
> +struct drm_lima_m450_pp_frame {
> + __u32 frame[LIMA_PP_FRAME_REG_NUM];
> + __u32 num_pp;
> + __u32 wb[3 * LIMA_PP_WB_REG_NUM];
> + __u32 use_dlbu;
> + __u32 _pad;
> + union {
> + __u32 plbu_array_address[8];
> + __u32 dlbu_regs[4];
> + };
> + __u32 fragment_stack_address[8];
> +};
> +
> +#define LIMA_PIPE_GP 0x00
> +#define LIMA_PIPE_PP 0x01
> +
> +#define LIMA_SUBMIT_FLAG_EXPLICIT_FENCE (1 << 0)
> +
> +/**
> + * submit a task to GPU
> + */
> +struct drm_lima_gem_submit {
> + __u32 ctx; /* in, context handle task is submitted to */
> + __u32 pipe;/* in, which pipe to use, GP/PP */
> + __u32 nr_bos; /* in, array length of bos field */
> + __u32 frame_size; /* in, size of frame field */
> + __u64 bos; /* in, array of drm_lima_gem_submit_bo */
> + __u64 frame; /* in, GP/PP frame */
> + __u32 flags; /* in, submit flags */
> + __u32 out_sync;/* in, drm_syncobj handle used to wait task finish
> after submission */
> + __u32 in_sync[2]; /* in, drm_syncobj handle used to wait before
> start this task */
> +};
This seems a bit limited, is there a reason it's two, at least in
Vulkan drivers we'd want more than two I suspect (Vulkan may not work
on this hw anyways), but it might be required in the future to make
this extensible.
At least a comment stating why 2 was picked is sufficient for current use cases.
Thanks,
Dave
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
On Thu, 7 Mar 2019 at 09:46, Rob Herring wrote: > > On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote: > > > > - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for > > OpenGL vertex shader processing and PP is for fragment shader > > processing. Each processor has its own MMU so prcessors work in > > virtual address space. > > - There's only one GP but multiple PP (max 4 for mali 400 and 8 > > for mali 450) in the same mali 4xx GPU. All PPs are grouped > > togather to handle a single fragment shader task divided by > > FB output tiled pixels. Mali 400 user space driver is > > responsible for assign target tiled pixels to each PP, but mali > > 450 has a HW module called DLBU to dynamically balance each > > PP's load. > > - User space driver allocate buffer object and map into GPU > > virtual address space, upload command stream and draw data with > > CPU mmap of the buffer object, then submit task to GP/PP with > > a register frame indicating where is the command stream and misc > > settings. > > - There's no command stream validation/relocation due to each user > > process has its own GPU virtual address space. GP/PP's MMU switch > > virtual address space before running two tasks from different > > user process. Error or evil user space code just get MMU fault > > or GP/PP error IRQ, then the HW/SW will be recovered. > > - Use GEM+shmem for MM. Currently just alloc and pin memory when > > gem object creation. GPU vm map of the buffer is also done in > > the alloc stage in kernel space. We may delay the memory > > allocation and real GPU vm map to command submission stage in the > > furture as improvement. > > - Use drm_sched for GPU task schedule. Each OpenGL context should > > have a lima context object in the kernel to distinguish tasks > > from different user. drm_sched gets task from each lima context > > in a fair way. > > > > mesa driver can be found here before upstreamed: > > https://gitlab.freedesktop.org/lima/mesa > > > > v7: > > - remove lima_fence_ops with default value > > - move fence slab create to device probe > > - check pad ioctl args to be zero > > - add comments for user/kernel interface > > > > v6: > > - fix comments by checkpatch.pl > > > > v5: > > - export gp/pp version to userspace > > - rebase on drm-misc-next > > > > v4: > > - use get param interface to get info > > - separate context create/free ioctl > > - remove unused max sched task param > > - update copyright time > > - use xarray instead of idr > > - stop using drmP.h > > > > v3: > > - fix comments from kbuild robot > > - restrict supported arch to tested ones > > > > v2: > > - fix syscall argument check > > - fix job finish fence leak since kernel 5.0 > > - use drm syncobj to replace native fence > > - move buffer object GPU va map into kernel > > - reserve syscall argument space for future info > > - remove kernel gem modifier > > - switch TTM back to GEM+shmem MM > > - use time based io poll > > - use whole register name > > - adopt gem reservation obj integration > > - use drm_timeout_abs_to_jiffies > > > > Cc: Eric Anholt > > Cc: Rob Herring > > Cc: Christian König > > Cc: Daniel Vetter > > Cc: Alex Deucher > > Cc: Sam Ravnborg > > Cc: Rob Clark > > Signed-off-by: Andreas Baierl > > Signed-off-by: Erico Nunes > > Signed-off-by: Heiko Stuebner > > Signed-off-by: Marek Vasut > > Signed-off-by: Neil Armstrong > > Signed-off-by: Simon Shields > > Signed-off-by: Vasily Khoruzhick > > Signed-off-by: Qiang Yu > > --- > > drivers/gpu/drm/Kconfig | 2 + > > drivers/gpu/drm/Makefile | 1 + > > drivers/gpu/drm/lima/Kconfig | 10 + > > drivers/gpu/drm/lima/Makefile | 21 ++ > > drivers/gpu/drm/lima/lima_bcast.c | 47 +++ > > drivers/gpu/drm/lima/lima_bcast.h | 14 + > > drivers/gpu/drm/lima/lima_ctx.c | 97 ++ > > drivers/gpu/drm/lima/lima_ctx.h | 30 ++ > > drivers/gpu/drm/lima/lima_device.c| 385 +++ > > drivers/gpu/drm/lima/lima_device.h| 131 > > drivers/gpu/drm/lima/lima_dlbu.c | 58 > > drivers/gpu/drm/lima/lima_dlbu.h | 18 ++ > > drivers/gpu/drm/lima/lima_drv.c | 376 +++ > > drivers/gpu/drm/lima/lima_drv.h | 45 +++ > > drivers/gpu/drm/lima/lima_gem.c | 381 +++ > > drivers/gpu/drm/lima/lima_gem.h | 25 ++ > > drivers/gpu/drm/lima/lima_gem_prime.c | 47 +++ > > drivers/gpu/drm/lima/lima_gem_prime.h | 13 + > > drivers/gpu/drm/lima/lima_gp.c| 283 + > > drivers/gpu/drm/lima/lima_gp.h| 16 + > > drivers/gpu/drm/lima/lima_l2_cache.c | 80 + > > drivers/gpu/drm/lima/lima_l2_cache.h | 14 + > > drivers/gpu/drm/lima/lima_mmu.c | 142 + > > drivers/gpu/drm/lima/lima_mmu.h | 16 + > > drivers/gpu/drm/lima/lima_object.c| 122 > > drivers/gpu/drm/lima/lima_object.h| 36 +++ > >
Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote: > > - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for > OpenGL vertex shader processing and PP is for fragment shader > processing. Each processor has its own MMU so prcessors work in > virtual address space. > - There's only one GP but multiple PP (max 4 for mali 400 and 8 > for mali 450) in the same mali 4xx GPU. All PPs are grouped > togather to handle a single fragment shader task divided by > FB output tiled pixels. Mali 400 user space driver is > responsible for assign target tiled pixels to each PP, but mali > 450 has a HW module called DLBU to dynamically balance each > PP's load. > - User space driver allocate buffer object and map into GPU > virtual address space, upload command stream and draw data with > CPU mmap of the buffer object, then submit task to GP/PP with > a register frame indicating where is the command stream and misc > settings. > - There's no command stream validation/relocation due to each user > process has its own GPU virtual address space. GP/PP's MMU switch > virtual address space before running two tasks from different > user process. Error or evil user space code just get MMU fault > or GP/PP error IRQ, then the HW/SW will be recovered. > - Use GEM+shmem for MM. Currently just alloc and pin memory when > gem object creation. GPU vm map of the buffer is also done in > the alloc stage in kernel space. We may delay the memory > allocation and real GPU vm map to command submission stage in the > furture as improvement. > - Use drm_sched for GPU task schedule. Each OpenGL context should > have a lima context object in the kernel to distinguish tasks > from different user. drm_sched gets task from each lima context > in a fair way. > > mesa driver can be found here before upstreamed: > https://gitlab.freedesktop.org/lima/mesa > > v7: > - remove lima_fence_ops with default value > - move fence slab create to device probe > - check pad ioctl args to be zero > - add comments for user/kernel interface > > v6: > - fix comments by checkpatch.pl > > v5: > - export gp/pp version to userspace > - rebase on drm-misc-next > > v4: > - use get param interface to get info > - separate context create/free ioctl > - remove unused max sched task param > - update copyright time > - use xarray instead of idr > - stop using drmP.h > > v3: > - fix comments from kbuild robot > - restrict supported arch to tested ones > > v2: > - fix syscall argument check > - fix job finish fence leak since kernel 5.0 > - use drm syncobj to replace native fence > - move buffer object GPU va map into kernel > - reserve syscall argument space for future info > - remove kernel gem modifier > - switch TTM back to GEM+shmem MM > - use time based io poll > - use whole register name > - adopt gem reservation obj integration > - use drm_timeout_abs_to_jiffies > > Cc: Eric Anholt > Cc: Rob Herring > Cc: Christian König > Cc: Daniel Vetter > Cc: Alex Deucher > Cc: Sam Ravnborg > Cc: Rob Clark > Signed-off-by: Andreas Baierl > Signed-off-by: Erico Nunes > Signed-off-by: Heiko Stuebner > Signed-off-by: Marek Vasut > Signed-off-by: Neil Armstrong > Signed-off-by: Simon Shields > Signed-off-by: Vasily Khoruzhick > Signed-off-by: Qiang Yu > --- > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/lima/Kconfig | 10 + > drivers/gpu/drm/lima/Makefile | 21 ++ > drivers/gpu/drm/lima/lima_bcast.c | 47 +++ > drivers/gpu/drm/lima/lima_bcast.h | 14 + > drivers/gpu/drm/lima/lima_ctx.c | 97 ++ > drivers/gpu/drm/lima/lima_ctx.h | 30 ++ > drivers/gpu/drm/lima/lima_device.c| 385 +++ > drivers/gpu/drm/lima/lima_device.h| 131 > drivers/gpu/drm/lima/lima_dlbu.c | 58 > drivers/gpu/drm/lima/lima_dlbu.h | 18 ++ > drivers/gpu/drm/lima/lima_drv.c | 376 +++ > drivers/gpu/drm/lima/lima_drv.h | 45 +++ > drivers/gpu/drm/lima/lima_gem.c | 381 +++ > drivers/gpu/drm/lima/lima_gem.h | 25 ++ > drivers/gpu/drm/lima/lima_gem_prime.c | 47 +++ > drivers/gpu/drm/lima/lima_gem_prime.h | 13 + > drivers/gpu/drm/lima/lima_gp.c| 283 + > drivers/gpu/drm/lima/lima_gp.h| 16 + > drivers/gpu/drm/lima/lima_l2_cache.c | 80 + > drivers/gpu/drm/lima/lima_l2_cache.h | 14 + > drivers/gpu/drm/lima/lima_mmu.c | 142 + > drivers/gpu/drm/lima/lima_mmu.h | 16 + > drivers/gpu/drm/lima/lima_object.c| 122 > drivers/gpu/drm/lima/lima_object.h| 36 +++ > drivers/gpu/drm/lima/lima_pmu.c | 60 > drivers/gpu/drm/lima/lima_pmu.h | 12 + > drivers/gpu/drm/lima/lima_pp.c| 427 ++ > drivers/gpu/drm/lima/lima_pp.h| 19 ++ > drivers/gpu/drm/lima/lima_regs.h | 298 ++ >
[PATCH/RFC 07/15] dt-bindings: display: renesas: lvds: Add renesas, companion property
Add a new optional renesas,companion property to point to the companion LVDS encoder. This is used to support dual-link operation where the main LVDS encoder splits even-numbered and odd-numbered pixels between the two LVDS encoders. The new property doesn't control the mode of operation, it only describes the relationship between the master and companion LVDS encoders. Signed-off-by: Laurent Pinchart --- .../devicetree/bindings/display/bridge/renesas,lvds.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt index 900a884ad9f5..a720dbb5de69 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt @@ -45,6 +45,12 @@ OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. Each port shall have a single endpoint. +Optional properties: + +- renesas,companion : phandle to the companion LVDS encoder. This property is + valid for the first LVDS encoder D3 and E3 SoCs only, and points to the + second encoder to be used as a companion in dual-link mode. + Example: -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 12/15] drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode
In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
can't be used in that case, don't create an encoder and connector for
it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 6c91753af7bc..fe046d194944 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -16,6 +16,7 @@
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
#include "rcar_du_kms.h"
+#include "rcar_lvds.h"
/*
-
* Encoder
@@ -97,6 +98,17 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
}
}
+ /*
+* On Gen3 skip the LVDS1 output if the LVDS1 encoder is used as a
+* companion for LVDS0 in dual-link mode.
+*/
+ if (rcdu->info->gen >= 3 && output == RCAR_DU_OUTPUT_LVDS1) {
+ if (bridge && rcar_lvds_dual_link(bridge)) {
+ ret = -ENOLINK;
+ goto done;
+ }
+ }
+
ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
DRM_MODE_ENCODER_NONE, NULL);
if (ret < 0)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 3b7d50a8fb9b..7f9d43a1ee42 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -352,7 +352,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device
*rcdu,
}
ret = rcar_du_encoder_init(rcdu, output, entity);
- if (ret && ret != -EPROBE_DEFER)
+ if (ret && ret != -EPROBE_DEFER && ret != -ENOLINK)
dev_warn(rcdu->dev,
"failed to initialize encoder %pOF on output %u (%d),
skipping\n",
entity, output, ret);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 10/15] drm: rcar-du: lvds: Set LVEN and LVRES bits together on D3
On the D3 SoC the LVDS PHY must be enabled in the same register write
that enables the LVDS output. Skip writing the LVEN bit independently
on that platform, it will be set by the write that sets LVRES.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index b1abe737dc05..5ac92ee15be0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -475,9 +475,13 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
}
if (lvds->info->quirks & RCAR_LVDS_QUIRK_GEN3_LVEN) {
- /* Turn on the LVDS PHY. */
+ /*
+* Turn on the LVDS PHY. On D3, the LVEN and LVRES bit must be
+* set at the same time, so don't write the register yet.
+*/
lvdcr0 |= LVDCR0_LVEN;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+ if (!(lvds->info->quirks & RCAR_LVDS_QUIRK_PWD))
+ rcar_lvds_write(lvds, LVDCR0, lvdcr0);
}
if (!(lvds->info->quirks & RCAR_LVDS_QUIRK_EXT_PLL)) {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 06/15] drm: bridge: thc63: Report input bus mode through bridge timings
Set a drm_bridge_timings in the drm_bridge, and use it to report the
input bus mode (single-link or dual-link). The other fields of the
timings structure are kept to 0 as they do not apply to LVDS buses.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 46 ---
1 file changed, 35 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
index b083a740565c..206b0af5e154 100644
--- a/drivers/gpu/drm/bridge/thc63lvd1024.c
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -31,6 +31,8 @@ struct thc63_dev {
struct drm_bridge bridge;
struct drm_bridge *next;
+
+ struct drm_bridge_timings timings;
};
static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
@@ -48,15 +50,28 @@ static int thc63_attach(struct drm_bridge *bridge)
static enum drm_mode_status thc63_mode_valid(struct drm_bridge *bridge,
const struct drm_display_mode *mode)
{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ unsigned int min_freq;
+ unsigned int max_freq;
+
/*
-* The THC63LVD1024 clock frequency range is 8 to 135 MHz in single-in
-* mode. Note that the limits are different in dual-in, single-out mode,
-* and will need to be adjusted accordingly.
+* The THC63LVD1024 pixel rate range is 8 to 135 MHz in all modes but
+* dual-in, single-out where it is 40 to 150 MHz. As dual-in, dual-out
+* isn't supported by the driver yet, simply derive the limits from the
+* input mode.
*/
- if (mode->clock < 8000)
+ if (thc63->timings.dual_link) {
+ min_freq = 4;
+ max_freq = 15;
+ } else {
+ min_freq = 8000;
+ max_freq = 135000;
+ }
+
+ if (mode->clock < min_freq)
return MODE_CLOCK_LOW;
- if (mode->clock > 135000)
+ if (mode->clock > max_freq)
return MODE_CLOCK_HIGH;
return MODE_OK;
@@ -101,19 +116,19 @@ static const struct drm_bridge_funcs thc63_bridge_func = {
static int thc63_parse_dt(struct thc63_dev *thc63)
{
- struct device_node *thc63_out;
+ struct device_node *endpoint;
struct device_node *remote;
- thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
- THC63_RGB_OUT0, -1);
- if (!thc63_out) {
+ endpoint = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+THC63_RGB_OUT0, -1);
+ if (!endpoint) {
dev_err(thc63->dev, "Missing endpoint in port@%u\n",
THC63_RGB_OUT0);
return -ENODEV;
}
- remote = of_graph_get_remote_port_parent(thc63_out);
- of_node_put(thc63_out);
+ remote = of_graph_get_remote_port_parent(endpoint);
+ of_node_put(endpoint);
if (!remote) {
dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
THC63_RGB_OUT0);
@@ -132,6 +147,14 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
if (!thc63->next)
return -EPROBE_DEFER;
+ endpoint = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+THC63_LVDS_IN1, -1);
+ of_node_put(endpoint);
+
+ thc63->timings.dual_link = endpoint != NULL;
+ dev_dbg(thc63->dev, "operating in %s-link mode\n",
+ thc63->timings.dual_link ? "dual" : "single");
+
return 0;
}
@@ -188,6 +211,7 @@ static int thc63_probe(struct platform_device *pdev)
thc63->bridge.driver_private = thc63;
thc63->bridge.of_node = pdev->dev.of_node;
thc63->bridge.funcs = _bridge_func;
+ thc63->bridge.timings = >timings;
drm_bridge_add(>bridge);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 02/15] drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags
The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and
DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the
new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and
new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them
through the code.
This effectively changes the value of the .sampling_edge bridge timings
field in the dumb-vga-dac driver. This is safe to do as no driver
consumes these values yet.
Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 ++---
drivers/gpu/drm/bridge/tc358767.c | 4 ++--
drivers/gpu/drm/drm_modes.c | 12 +-
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +-
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
drivers/gpu/drm/mxsfb/mxsfb_crtc.c| 6 ++---
.../gpu/drm/omapdrm/displays/encoder-tfp410.c | 5 ++--
.../displays/panel-lgphilips-lb035q02.c | 5 ++--
.../omapdrm/displays/panel-nec-nl8048hl11.c | 5 ++--
.../displays/panel-sharp-ls037v7dw01.c| 5 ++--
.../omapdrm/displays/panel-sony-acx565akm.c | 5 ++--
.../omapdrm/displays/panel-tpo-td028ttec1.c | 5 ++--
.../omapdrm/displays/panel-tpo-td043mtea1.c | 5 ++--
drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/sdi.c | 4 ++--
drivers/gpu/drm/omapdrm/omap_encoder.c| 8 +++
drivers/gpu/drm/panel/panel-arm-versatile.c | 4 ++--
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 4 ++--
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 2 +-
drivers/gpu/drm/panel/panel-simple.c | 24 +--
drivers/gpu/drm/panel/panel-tpo-tpg110.c | 10
drivers/gpu/drm/pl111/pl111_display.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c| 4 ++--
drivers/gpu/drm/tve200/tve200_display.c | 3 ++-
include/drm/drm_bridge.h | 9 +++
25 files changed, 77 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index 0805801f4e94..94ed450e308d 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -234,7 +234,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
*/
static const struct drm_bridge_timings default_dac_timings = {
/* Timing specifications, datasheet page 7 */
- .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
.setup_time_ps = 500,
.hold_time_ps = 1500,
};
@@ -245,7 +245,7 @@ static const struct drm_bridge_timings default_dac_timings
= {
*/
static const struct drm_bridge_timings ti_ths8134_dac_timings = {
/* From timing diagram, datasheet page 9 */
- .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
/* From datasheet, page 12 */
.setup_time_ps = 3000,
/* I guess this means latched input */
@@ -258,7 +258,7 @@ static const struct drm_bridge_timings
ti_ths8134_dac_timings = {
*/
static const struct drm_bridge_timings ti_ths8135_dac_timings = {
/* From timing diagram, datasheet page 14 */
- .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
/* From datasheet, page 16 */
.setup_time_ps = 2000,
.hold_time_ps = 500,
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 888980d4bc74..e570c9dee180 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1222,8 +1222,8 @@ static int tc_bridge_attach(struct drm_bridge *bridge)
_format, 1);
tc->connector.display_info.bus_flags =
DRM_BUS_FLAG_DE_HIGH |
- DRM_BUS_FLAG_PIXDATA_NEGEDGE |
- DRM_BUS_FLAG_SYNC_NEGEDGE;
+ DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE |
+ DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE;
drm_connector_attach_encoder(>connector, tc->bridge.encoder);
return 0;
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 869ac6f4671e..56f92a0bba62 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -655,22 +655,22 @@ EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
* @bus_flags: information about pixelclk, sync and DE polarity will be stored
* here
*
- * Sets DRM_BUS_FLAG_DE_(LOW|HIGH), DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and
- * DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in @bus_flags according to DISPLAY_FLAGS
+ * Sets DRM_BUS_FLAG_DE_(LOW|HIGH), DRM_BUS_FLAG_PIXDATA_DRIVE_(POS|NEG)EDGE
+ * and DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in @bus_flags according to
DISPLAY_FLAGS
* found in @vm
*/
void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags)
{
*bus_flags = 0;
if (vm->flags &
[PATCH/RFC 04/15] drm: bridge: Add dual_link field to the drm_bridge_timings structure
Extend the drm_bridge_timings structure with a new dual_link field to
indicate that the bridge's input bus carries data on two separate
physical links. The first use case is LVDS dual-link mode where even-
and odd-numbered pixels are transferred on separate LVDS links.
Signed-off-by: Laurent Pinchart
---
include/drm/drm_bridge.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index d4428913a4e1..aea1fcfd92a7 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -265,6 +265,14 @@ struct drm_bridge_timings {
* input signal after the clock edge.
*/
u32 hold_time_ps;
+ /**
+* @dual_link:
+*
+* True if the bus operates in dual-link mode. The exact meaning is
+* dependent on the bus type. For LVDS buses, this indicates that even-
+* and odd-numbered pixels are received on separate links.
+*/
+ bool dual_link;
};
/**
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 03/15] drm/bridge: use bus flags in bridge timings
From: Stefan Agner
The DRM bus flags convey additional information on pixel data on
the bus. All current available bus flags might be of interest for
a bridge. Remove the sampling_edge field and use bus_flags.
In the case at hand a dumb VGA bridge needs a specific data enable
polarity (DRM_BUS_FLAG_DE_LOW).
Signed-off-by: Stefan Agner
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +++---
include/drm/drm_bridge.h | 12 +---
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index 94ed450e308d..e64736c39a9f 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -234,7 +234,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
*/
static const struct drm_bridge_timings default_dac_timings = {
/* Timing specifications, datasheet page 7 */
- .sampling_edge = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+ .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
.setup_time_ps = 500,
.hold_time_ps = 1500,
};
@@ -245,7 +245,7 @@ static const struct drm_bridge_timings default_dac_timings
= {
*/
static const struct drm_bridge_timings ti_ths8134_dac_timings = {
/* From timing diagram, datasheet page 9 */
- .sampling_edge = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+ .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
/* From datasheet, page 12 */
.setup_time_ps = 3000,
/* I guess this means latched input */
@@ -258,7 +258,7 @@ static const struct drm_bridge_timings
ti_ths8134_dac_timings = {
*/
static const struct drm_bridge_timings ti_ths8135_dac_timings = {
/* From timing diagram, datasheet page 14 */
- .sampling_edge = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+ .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
/* From datasheet, page 16 */
.setup_time_ps = 2000,
.hold_time_ps = 500,
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 5e5129206f40..d4428913a4e1 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -244,15 +244,13 @@ struct drm_bridge_funcs {
*/
struct drm_bridge_timings {
/**
-* @sampling_edge:
+* @input_bus_flags:
*
-* Tells whether the bridge samples the digital input signals from the
-* display engine on the positive or negative edge of the clock. This
-* should use the DRM_BUS_FLAG_PIXDATA_SAMPLE_[POS|NEG]EDGE and
-* DRM_BUS_FLAG_SYNC_SAMPLE_[POS|NEG]EDGE bitwise flags from the DRM
-* connector (bit 2, 3, 6 and 7 valid).
+* Tells what additional settings for the pixel data on the bus
+* this bridge requires (like pixel signal polarity). See also
+* _display_info->bus_flags.
*/
- u32 sampling_edge;
+ u32 input_bus_flags;
/**
* @setup_time_ps:
*
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 13/15] arm64: dts: renesas: r8a7799[05]: Point LVDS0 to its companion LVDS1
Add the new renesas,companion property to the LVDS0 node to point to the
companion LVDS encoder LVDS1.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 ++
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index b2f606e286ce..90c5ce8ab7e1 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -1678,6 +1678,8 @@
resets = < 727>;
status = "disabled";
+ renesas,companion = <>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 8530d9fc1371..81762884a2dc 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -1038,6 +1038,8 @@
resets = < 727>;
status = "disabled";
+ renesas,companion = <>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 11/15] drm: rcar-du: lvds: Add support for dual-link mode
In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
sends odd-numbered pixels to the LVDS1 encoder for transmission on a
separate link.
To implement support for this mode of operation, determine if the LVDS
connection operates in dual-link mode by querying the next device in the
pipeline, locate the companion encoder, and control it directly through
its bridge operations.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 104
drivers/gpu/drm/rcar-du/rcar_lvds.h | 5 ++
2 files changed, 96 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 5ac92ee15be0..90d33514bb3e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -66,6 +66,9 @@ struct rcar_lvds {
struct drm_display_mode display_mode;
enum rcar_lvds_mode mode;
+
+ struct drm_bridge *companion;
+ bool dual_link;
};
#define bridge_to_rcar_lvds(bridge) \
@@ -400,11 +403,6 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
const struct drm_display_mode *mode = >display_mode;
- /*
-* FIXME: We should really retrieve the CRTC through the state, but how
-* do we get a state pointer?
-*/
- struct drm_crtc *crtc = lvds->bridge.encoder->crtc;
u32 lvdhcr;
u32 lvdcr0;
int ret;
@@ -413,6 +411,10 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
if (ret < 0)
return;
+ /* Enable the companion LVDS encoder in dual-link mode. */
+ if (lvds->dual_link && lvds->companion)
+ lvds->companion->funcs->enable(lvds->companion);
+
/*
* Hardcode the channels and control signals routing for now.
*
@@ -435,17 +437,33 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
rcar_lvds_write(lvds, LVDCHCR, lvdhcr);
if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) {
- /* Disable dual-link mode. */
- rcar_lvds_write(lvds, LVDSTRIPE, 0);
+ /*
+* Configure vertical stripe based on the mode of operation of
+* the connected device.
+*/
+ rcar_lvds_write(lvds, LVDSTRIPE,
+ lvds->dual_link ? LVDSTRIPE_ST_ON : 0);
}
- /* PLL clock configuration. */
- lvds->info->pll_setup(lvds, mode->clock * 1000);
+ /*
+* PLL clock configuration on all instances but the companion in
+* dual-link mode.
+*/
+ if (!lvds->dual_link || lvds->companion)
+ lvds->info->pll_setup(lvds, mode->clock * 1000);
/* Set the LVDS mode and select the input. */
lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
- if (drm_crtc_index(crtc) == 2)
- lvdcr0 |= LVDCR0_DUSEL;
+
+ if (lvds->bridge.encoder) {
+ /*
+* FIXME: We should really retrieve the CRTC through the state,
+* but how do we get a state pointer?
+*/
+ if (drm_crtc_index(lvds->bridge.encoder->crtc) == 2)
+ lvdcr0 |= LVDCR0_DUSEL;
+ }
+
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
/* Turn all the channels on. */
@@ -512,6 +530,10 @@ static void rcar_lvds_disable(struct drm_bridge *bridge)
rcar_lvds_write(lvds, LVDCR1, 0);
rcar_lvds_write(lvds, LVDPLLCR, 0);
+ /* Disable the companion LVDS encoder in dual-link mode. */
+ if (lvds->dual_link && lvds->companion)
+ lvds->companion->funcs->disable(lvds->companion);
+
clk_disable_unprepare(lvds->clocks.mod);
}
@@ -628,10 +650,54 @@ static const struct drm_bridge_funcs rcar_lvds_bridge_ops
= {
.mode_set = rcar_lvds_mode_set,
};
+bool rcar_lvds_dual_link(struct drm_bridge *bridge)
+{
+ struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
+
+ return lvds->dual_link;
+}
+EXPORT_SYMBOL_GPL(rcar_lvds_dual_link);
+
/*
-
* Probe & Remove
*/
+static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)
+{
+ const struct of_device_id *match;
+ struct device_node *companion;
+ struct device *dev = lvds->dev;
+ int ret = 0;
+
+ /* Locate the companion LVDS encoder for dual-link operation, if any. */
+ companion = of_parse_phandle(dev->of_node, "renesas,companion", 0);
+ if (!companion)
+ return -ENODEV;
+
+ /*
+* Sanity check: the companion encoder must have the same compatible
+* string.
+*/
+ match = of_match_device(dev->driver->of_match_table, dev);
+ if (!of_device_is_compatible(companion, match->compatible)) {
+ ret = -ENODEV;
+
[PATCH/RFC 14/15] [HACK] arm64: dts: renesas: draak: Enable LVDS dual-link operation
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
---
.../arm64/boot/dts/renesas/r8a77995-draak.dts | 21 +--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 89df9bc844c0..f48dbe35c4b1 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -77,11 +77,18 @@
port@0 {
reg = <0>;
- thc63lvd1024_in: endpoint {
+ thc63lvd1024_in0: endpoint {
remote-endpoint = <_out>;
};
};
+ port@1 {
+ reg = <1>;
+ thc63lvd1024_in1: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
port@2 {
reg = <2>;
thc63lvd1024_out: endpoint {
@@ -349,17 +356,27 @@
ports {
port@1 {
lvds0_out: endpoint {
- remote-endpoint = <_in>;
+ remote-endpoint = <_in0>;
};
};
};
};
{
+ status = "okay";
+
clocks = < CPG_MOD 727>,
<_clk>,
<_clk>;
clock-names = "fck", "dclkin.0", "extal";
+
+ ports {
+ port@1 {
+ lvds1_out: endpoint {
+ remote-endpoint = <_in1>;
+ };
+ };
+ };
};
{
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 15/15] [HACK] arm64: dts: renesas: ebisu: Enable LVDS dual-link operation
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 21 +--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 62bdddcbbae7..4b9f3305b666 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -83,11 +83,18 @@
port@0 {
reg = <0>;
- thc63lvd1024_in: endpoint {
+ thc63lvd1024_in0: endpoint {
remote-endpoint = <_out>;
};
};
+ port@1 {
+ reg = <1>;
+ thc63lvd1024_in1: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
port@2 {
reg = <2>;
thc63lvd1024_out: endpoint {
@@ -436,17 +443,27 @@
ports {
port@1 {
lvds0_out: endpoint {
- remote-endpoint = <_in>;
+ remote-endpoint = <_in0>;
};
};
};
};
{
+ status = "okay";
+
clocks = < CPG_MOD 727>,
<_clk>,
<_clk>;
clock-names = "fck", "dclkin.0", "extal";
+
+ ports {
+ port@1 {
+ lvds1_out: endpoint {
+ remote-endpoint = <_in1>;
+ };
+ };
+ };
};
{
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 08/15] drm: rcar-du: lvds: Remove LVDS double-enable checks
The DRM core and DU driver guarantee that the LVDS bridge will not be
double-enabled or double-disabled. Remove the corresponding unnecessary
checks.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 7ef97b2a6eda..cd202157264a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -63,7 +63,6 @@ struct rcar_lvds {
struct clk *extal; /* External clock */
struct clk *dotclkin[2];/* External DU clocks */
} clocks;
- bool enabled;
struct drm_display_mode display_mode;
enum rcar_lvds_mode mode;
@@ -368,15 +367,12 @@ int rcar_lvds_clk_enable(struct drm_bridge *bridge,
unsigned long freq)
dev_dbg(lvds->dev, "enabling LVDS PLL, freq=%luHz\n", freq);
- WARN_ON(lvds->enabled);
-
ret = clk_prepare_enable(lvds->clocks.mod);
if (ret < 0)
return ret;
__rcar_lvds_pll_setup_d3_e3(lvds, freq, true);
- lvds->enabled = true;
return 0;
}
EXPORT_SYMBOL_GPL(rcar_lvds_clk_enable);
@@ -390,13 +386,9 @@ void rcar_lvds_clk_disable(struct drm_bridge *bridge)
dev_dbg(lvds->dev, "disabling LVDS PLL\n");
- WARN_ON(!lvds->enabled);
-
rcar_lvds_write(lvds, LVDPLLCR, 0);
clk_disable_unprepare(lvds->clocks.mod);
-
- lvds->enabled = false;
}
EXPORT_SYMBOL_GPL(rcar_lvds_clk_disable);
@@ -417,8 +409,6 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
u32 lvdcr0;
int ret;
- WARN_ON(lvds->enabled);
-
ret = clk_prepare_enable(lvds->clocks.mod);
if (ret < 0)
return;
@@ -503,16 +493,12 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
drm_panel_prepare(lvds->panel);
drm_panel_enable(lvds->panel);
}
-
- lvds->enabled = true;
}
static void rcar_lvds_disable(struct drm_bridge *bridge)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
- WARN_ON(!lvds->enabled);
-
if (lvds->panel) {
drm_panel_disable(lvds->panel);
drm_panel_unprepare(lvds->panel);
@@ -523,8 +509,6 @@ static void rcar_lvds_disable(struct drm_bridge *bridge)
rcar_lvds_write(lvds, LVDPLLCR, 0);
clk_disable_unprepare(lvds->clocks.mod);
-
- lvds->enabled = false;
}
static bool rcar_lvds_mode_fixup(struct drm_bridge *bridge,
@@ -583,8 +567,6 @@ static void rcar_lvds_mode_set(struct drm_bridge *bridge,
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
- WARN_ON(lvds->enabled);
-
lvds->display_mode = *adjusted_mode;
rcar_lvds_get_lvds_mode(lvds);
@@ -784,7 +766,6 @@ static int rcar_lvds_probe(struct platform_device *pdev)
lvds->dev = >dev;
lvds->info = of_device_get_match_data(>dev);
- lvds->enabled = false;
ret = rcar_lvds_parse_dt(lvds);
if (ret < 0)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 09/15] drm: rcar-du: lvds: Adjust operating frequency for D3 and E3
The D3 and E3 SoCs have different pixel clock frequency limits for the
LVDS encoder than the other SoCs in the Gen3 family. Adjust the mode
fixup implementation accordingly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index cd202157264a..b1abe737dc05 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -515,11 +515,16 @@ static bool rcar_lvds_mode_fixup(struct drm_bridge
*bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
+ int min_freq;
+
/*
* The internal LVDS encoder has a restricted clock frequency operating
-* range (31MHz to 148.5MHz). Clamp the clock accordingly.
+* range, from 5MHz to 148.5MHz on D3 and E3, and from 31MHz to
+* 148.5MHz on all other platforms. Clamp the clock accordingly.
*/
- adjusted_mode->clock = clamp(adjusted_mode->clock, 31000, 148500);
+ min_freq = lvds->info->quirks & RCAR_LVDS_QUIRK_EXT_PLL ? 5000 : 31000;
+ adjusted_mode->clock = clamp(adjusted_mode->clock, min_freq, 148500);
return true;
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 05/15] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation
The THC63LVD1024 LVDS decoder can operate in two modes, single-link or dual-link. In dual-link mode both input ports are used to carry even- and odd-numbered pixels separately. Document this in the DT bindings, along with the related rules governing port and usage. Signed-off-by: Laurent Pinchart --- .../bindings/display/bridge/thine,thc63lvd1024.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt index 37f0c04d5a28..4ff6eb9bbc19 100644 --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt @@ -28,6 +28,13 @@ Optional video port nodes: - port@1: Second LVDS input port - port@3: Second digital CMOS/TTL parallel output +The device can operate in single-link mode or dual-link mode. In single-link +mode, all pixels are received on port@0, and port@1 shall not contain any +endpoint. In dual-link mode, even-numbered pixels are received on port@0 and +odd-numbered pixels on port@1, and both port@0 and port@1 shall contain +endpoints. + + Example: -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 01/15] drm: Clarify definition of the DRM_BUS_FLAG_(PIXDATA|SYNC)_* macros
The DRM_BUS_FLAG_PIXDATA_POSEDGE and DRM_BUS_FLAG_PIXDATA_NEGEDGE macros
and their DRM_BUS_FLAG_SYNC_* counterparts define on which pixel clock
edge data and sync signals are driven. They are however used in some
drivers to define on which pixel clock edge data and sync signals are
sampled, which should usually (but not always) be the opposite edge of
the driving edge. This creates confusion.
Create four new macros for both PIXDATA and SYNC that explicitly state
the driving and sampling edge in their name to remove the confusion. The
driving macros are defined as the opposite of the sampling macros to
made code simpler based on the assumption that the driving and sampling
edges are opposite.
Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij
---
include/drm/drm_connector.h | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 8fe22abb1e10..411c0eb4c00e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -330,19 +330,47 @@ struct drm_display_info {
#define DRM_BUS_FLAG_DE_LOW(1<<0)
#define DRM_BUS_FLAG_DE_HIGH (1<<1)
-/* drive data on pos. edge */
+
+/*
+ * Don't use those two flags directly, use the DRM_BUS_FLAG_PIXDATA_DRIVE_*
+ * and DRM_BUS_FLAG_PIXDATA_SAMPLE_* variants to qualify the flags explicitly.
+ * The DRM_BUS_FLAG_PIXDATA_SAMPLE_* flags are defined as the opposite of the
+ * DRM_BUS_FLAG_PIXDATA_DRIVE_* flags to make code simpler, as signals are
+ * usually to be sampled on the opposite edge of the driving edge.
+ */
#define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2)
-/* drive data on neg. edge */
#define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3)
+
+/* Drive data on rising edge */
+#define DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE DRM_BUS_FLAG_PIXDATA_POSEDGE
+/* Drive data on falling edge */
+#define DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE DRM_BUS_FLAG_PIXDATA_NEGEDGE
+/* Sample data on rising edge */
+#define DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGEDRM_BUS_FLAG_PIXDATA_NEGEDGE
+/* Sample data on falling edge */
+#define DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGEDRM_BUS_FLAG_PIXDATA_POSEDGE
+
/* data is transmitted MSB to LSB on the bus */
#define DRM_BUS_FLAG_DATA_MSB_TO_LSB (1<<4)
/* data is transmitted LSB to MSB on the bus */
#define DRM_BUS_FLAG_DATA_LSB_TO_MSB (1<<5)
-/* drive sync on pos. edge */
+
+/*
+ * Similarly to the DRM_BUS_FLAG_PIXDATA_* flags, don't use these two flags
+ * directly, use one of the DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_* instead.
+ */
#define DRM_BUS_FLAG_SYNC_POSEDGE (1<<6)
-/* drive sync on neg. edge */
#define DRM_BUS_FLAG_SYNC_NEGEDGE (1<<7)
+/* Drive sync on rising edge */
+#define DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE
DRM_BUS_FLAG_SYNC_POSEDGE
+/* Drive sync on falling edge */
+#define DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE
DRM_BUS_FLAG_SYNC_NEGEDGE
+/* Sample sync on rising edge */
+#define DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE DRM_BUS_FLAG_SYNC_NEGEDGE
+/* Sample sync on falling edge */
+#define DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE DRM_BUS_FLAG_SYNC_POSEDGE
+
/**
* @bus_flags: Additional information (like pixel signal polarity) for
* the pixel data on the bus, using DRM_BUS_FLAGS\_ defines.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 00/15] R-Car DU: LVDS dual-link mode support
Hello everybody, This patch series implements support for LVDS dual-link mode in the R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024 LVDS decoder driver. I decided to tag it with RFC as it includes an extension to the drm_bridge API. LVDS dual-link is a mode of operation where two individual LVDS links are operated together to carry even- and odd-numbered pixels separately. This doubles the possible bandwidth of the video transmission. Both the transmitter and the receiver need to support this mode of operation. The R-Car D3 and E3 SoCs include two independent LVDS encoders that can be grouped together to operate in dual-link mode. When used separately, the LVDS encoders are connected to two different CRTCs and transmit independent video streams. When used in dual-link mode, the first LVDS encoder is connected to the first CRTC, and split even- and odd-numbered pixels. It transmits half of the pixels on its LVDS output, and sends the other half to the second LVDS encoder for transmittion over the second LVDS link. The second LVDS encoder thus operates under control of the first one, and isn't connected directly to a CRTC. On the receiving side, the THC63LVD1024 LVDS-to-parallel bridge has two LVDS inputs and two parallel outputs. It can operate in four different modes: - Single-in, single-out: The first LVDS input receives the video stream, and the bridge outputs it on the first parallel output. The second LVDS input and the second parallel output are not used. - Single-in, dual-out: The first LVDS input receives the video stream, and the bridge splits even- and odd-numbered pixels and outputs them on the first and second parallel outputs. The second LVDS input is not used. - Dual-in, single-out: The two LVDS inputs are used in dual-link mode, and the bridge combines the even- and odd-numbered pixels and outputs them on the first parallel output. The second parallel output is not used. - Dual-in, dual-out: The two LVDS inputs are used in dual-link mode, and the bridge outputs the even- and odd-numbered pixels on the first parallel output. The operating mode is selected by two input pins of the bridge, which are connected to DIP switches on the development boards I use. The mode is thus fixed from a Linux point of view. The first three patches are borrowed from the omapdrm pending rework. They clarify the DRM bus flags and extend the drm_bridge_timings to report input bus flags instead of just the input sampling edge. They have been extensively reviewed, there's no need to comment on them here. Patch 04/15 adds a new dual_link boolen field to the drm_bridge_timings structure to let bridges report their LVDS mode of operation. Patch 05/15 clarifies the THC63LVD1024 DT bindings to document dual-link operation, and patch 06/15 implements dual-link support in the thc64lvd1024 bridge driver by setting the drm_bridge_timings dual_link field according to the mode selected through DT. Patch 07/15 extends the R-Car LVDS DT bindings to specify the companion LVDS encoder for dual-link operation. Patches 08/15 to 10/15 then clean up the LVDS encoder driver and fix a couple of issues related to the D3 and E3 SoCs. Patch 11/15 implements dual-link support in the LVDS encoder driver, which involves retrieving the operation mode from the LVDS receiver, locating the companion LVDS encoder, and configuring both encoders when dual-link operation is desired. The API towards the DU driver is also extended to report the mode of operation. Patch 12/15 implements dual-link mode support in the DU driver. There is no specific configuration to be performed there, as dual-link is fully implemented in the LVDS encoder driver, but the DU driver has to skip creation of the DRM encoder and connector related to the second LVDS encoder when dual-link is used, as the second LVDS encoder operates as a slave of the first one, transparently from a CRTC (and thus userspace) perspective. Patch 13/15 specifies the companion LVDS encoder in the D3 and E3 DT bindings. This by itself doesn't enable dual-link mode, the LVDS0 encoder is still connected to the HDMI output through LVDS receiver, and the LVDS1 encoder is not used. Patches 14/15 and 15/15, not intended to be merged, enable dual-link operation for the D3 and E3 boards for testing and require flipping DIP switches on the boards. The patches are based on top of my drm/du/next branch, and are available for convenience at git://linuxtv.org/pinchartl/media.git drm/du/lvds/dual-link They have been tested successfully on the D3 Draak board. I expect them to work on E3 as well, but I don't have access to an Ebisu board to test this. Laurent Pinchart (14): drm: Clarify definition of the DRM_BUS_FLAG_(PIXDATA|SYNC)_* macros drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags drm: bridge: Add dual_link field to the drm_bridge_timings structure dt-bindings: display: bridge: thc63lvd1024: Document dual-link
[PATCH v7] drm: Add library for shmem backed GEM objects
From: Noralf Trønnes
This adds a library for shmem backed GEM objects.
v7:
- Use write-combine for mmap instead. This is the more common
case. (robher)
v6:
- Fix uninitialized variable issue in an error path (anholt).
- Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting
of the pages (anholt).
v5:
- Drop drm_gem_shmem_prime_mmap() (Daniel Vetter)
- drm_gem_shmem_mmap(): Subtract drm_vma_node_start() to get the real
vma->vm_pgoff
- drm_gem_shmem_fault(): Use vmf->pgoff now that vma->vm_pgoff is correct
v4:
- Drop cache modes (Thomas Hellstrom)
- Add a GEM attached vtable
v3:
- Grammar (Sam Ravnborg)
- s/drm_gem_shmem_put_pages_unlocked/drm_gem_shmem_put_pages_locked/
(Sam Ravnborg)
- Add debug output in error path (Sam Ravnborg)
Signed-off-by: Noralf Trønnes
Signed-off-by: Eric Anholt
Signed-off-by: Rob Herring
---
I don't have a user to submit just yet, but we are using this for
panfrost which can be seen here[1]. I expect we'll be ready to merge
panfrost for 5.2.
Rob
[1]
https://gitlab.freedesktop.org/panfrost/linux/blob/panfrost-5.0-rc4/drivers/gpu/drm/panfrost/panfrost_gem.c
Documentation/gpu/drm-kms-helpers.rst | 12 +
drivers/gpu/drm/Kconfig| 6 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_gem_shmem_helper.c | 560 +
include/drm/drm_gem_shmem_helper.h | 153 +++
5 files changed, 732 insertions(+)
create mode 100644 drivers/gpu/drm/drm_gem_shmem_helper.c
create mode 100644 include/drm/drm_gem_shmem_helper.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index b422eb8edf16..44e47ddc21d6 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -347,3 +347,15 @@ Legacy CRTC/Modeset Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
:export:
+
+SHMEM GEM Helper Reference
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_shmem_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
+ :export:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4385f00e1d05..0dedbc040c77 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -177,6 +177,12 @@ config DRM_KMS_CMA_HELPER
help
Choose this if you need the KMS CMA helper functions
+config DRM_GEM_SHMEM_HELPER
+ bool
+ depends on DRM
+ help
+ Choose this if you need the GEM shmem helper functions
+
config DRM_VM
bool
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index ce8d1d384319..203b311f12ae 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -25,6 +25,7 @@ drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
+drm-$(CONFIG_DRM_GEM_SHMEM_HELPER) += drm_gem_shmem_helper.o
drm-$(CONFIG_PCI) += ati_pcigart.o
drm-$(CONFIG_DRM_PANEL) += drm_panel.o
drm-$(CONFIG_OF) += drm_of.o
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
new file mode 100644
index ..3394768e067c
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -0,0 +1,560 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018 Noralf Trønnes
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * DOC: overview
+ *
+ * This library provides helpers for GEM objects backed by shmem buffers
+ * allocated using anonymous pageable memory.
+ */
+
+static const struct drm_gem_object_funcs drm_gem_shmem_funcs = {
+ .free = drm_gem_shmem_free_object,
+ .print_info = drm_gem_shmem_print_info,
+ .pin = drm_gem_shmem_pin,
+ .unpin = drm_gem_shmem_unpin,
+ .get_sg_table = drm_gem_shmem_get_sg_table,
+ .vmap = drm_gem_shmem_vmap,
+ .vunmap = drm_gem_shmem_vunmap,
+ .vm_ops = _gem_shmem_vm_ops,
+};
+
+/**
+ * drm_gem_shmem_create - Allocate an object with the given size
+ * @dev: DRM device
+ * @size: Size of the object to allocate
+ *
+ * This function creates a shmem GEM object.
+ *
+ * Returns:
+ * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
+ * error code on failure.
+ */
+struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
size_t size)
+{
+ struct drm_gem_shmem_object *shmem;
+ struct drm_gem_object *obj;
+ int ret;
+
+ size = PAGE_ALIGN(size);
+
+ if (dev->driver->gem_create_object)
+ obj = dev->driver->gem_create_object(dev, size);
+ else
+ obj = kzalloc(sizeof(*shmem), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ if
Re: [PATCH 16/17] drm/vkms: Convert to using __drm_atomic_helper_crtc_reset() for reset.
On 03/01, Maarten Lankhorst wrote:
> Convert vkms to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding destroy_state(),
> call it directly for freeing the old state.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 33 +---
> 1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 8a9aeb0a9ea8..550888e72c96 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -83,26 +83,6 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev,
> unsigned int pipe,
> return true;
> }
>
> -static void vkms_atomic_crtc_reset(struct drm_crtc *crtc)
> -{
> - struct vkms_crtc_state *vkms_state = NULL;
> -
> - if (crtc->state) {
> - vkms_state = to_vkms_crtc_state(crtc->state);
> - __drm_atomic_helper_crtc_destroy_state(crtc->state);
> - kfree(vkms_state);
> - crtc->state = NULL;
> - }
> -
> - vkms_state = kzalloc(sizeof(*vkms_state), GFP_KERNEL);
> - if (!vkms_state)
> - return;
> - INIT_WORK(_state->crc_work, vkms_crc_work_handle);
> -
> - crtc->state = _state->base;
> - crtc->state->crtc = crtc;
> -}
> -
> static struct drm_crtc_state *
> vkms_atomic_crtc_duplicate_state(struct drm_crtc *crtc)
> {
> @@ -135,6 +115,19 @@ static void vkms_atomic_crtc_destroy_state(struct
> drm_crtc *crtc,
> }
> }
>
> +static void vkms_atomic_crtc_reset(struct drm_crtc *crtc)
> +{
> + struct vkms_crtc_state *vkms_state =
> + kzalloc(sizeof(*vkms_state), GFP_KERNEL);
> +
> + if (crtc->state)
> + vkms_atomic_crtc_destroy_state(crtc, crtc->state);
> +
> + __drm_atomic_helper_crtc_reset(crtc, _state->base);
> + if (vkms_state)
> + INIT_WORK(_state->crc_work, vkms_crc_work_handle);
> +}
> +
> static const struct drm_crtc_funcs vkms_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> .destroy= drm_crtc_cleanup,
> --
> 2.20.1
>
Hi Maarten,
First of all, thanks for the patch :)
I tested it on my VM with the IGT test, and everything looks fine.
Reviewed-by: Rodrigo Siqueira
--
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On 3/6/19 1:03 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:18 AM Andrew F. Davis wrote:
>>
>> On 3/5/19 2:54 PM, John Stultz wrote:
>>> From: "Andrew F. Davis"
>>>
>>> This framework allows a unified userspace interface for dma-buf
>>> exporters, allowing userland to allocate specific types of
>>> memory for use in dma-buf sharing.
>>>
>>> Each heap is given its own device node, which a user can
>>> allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
>>>
>>> This code is an evoluiton of the Android ION implementation,
>>> and a big thanks is due to its authors/maintainers over time
>>> for their effort:
>>> Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
>>> Laura Abbott, and many other contributors!
>>>
>>> Cc: Laura Abbott
>>> Cc: Benjamin Gaignard
>>> Cc: Greg KH
>>> Cc: Sumit Semwal
>>> Cc: Liam Mark
>>> Cc: Brian Starkey
>>> Cc: Andrew F. Davis
>>> Cc: Chenbo Feng
>>> Cc: Alistair Strachan
>>> Cc: dri-devel@lists.freedesktop.org
>>> Signed-off-by: Andrew F. Davis
>>> [jstultz: reworded commit message, and lots of cleanups]
>>> Signed-off-by: John Stultz
>>> ---
>>> v2:
>>> * Folded down fixes I had previously shared in implementing
>>> heaps
>>> * Make flags a u64 (Suggested by Laura)
>>> * Add PAGE_ALIGN() fix to the core alloc funciton
>>> * IOCTL fixups suggested by Brian
>>> * Added fixes suggested by Benjamin
>>> * Removed core stats mgmt, as that should be implemented by
>>> per-heap code
>>> * Changed alloc to return a dma-buf fd, rather then a buffer
>>> (as it simplifies error handling)
>>> ---
>>> MAINTAINERS | 16
>>> drivers/dma-buf/Kconfig | 8 ++
>>> drivers/dma-buf/Makefile | 1 +
>>> drivers/dma-buf/dma-heap.c| 191
>>> ++
>>> include/linux/dma-heap.h | 65 ++
>>> include/uapi/linux/dma-heap.h | 52
>>> 6 files changed, 333 insertions(+)
>>> create mode 100644 drivers/dma-buf/dma-heap.c
>>> create mode 100644 include/linux/dma-heap.h
>>> create mode 100644 include/uapi/linux/dma-heap.h
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index ac2e518..a661e19 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -4621,6 +4621,22 @@ F: include/linux/*fence.h
>>> F: Documentation/driver-api/dma-buf.rst
>>> T: git git://anongit.freedesktop.org/drm/drm-misc
>>>
>>> +DMA-BUF HEAPS FRAMEWORK
>>> +M: Laura Abbott
>>> +R: Liam Mark
>>> +R: Brian Starkey
>>> +R: "Andrew F. Davis"
>>
>> Quotes not needed in maintainers file.
>
> Whatever you say, "Andrew F. Davis", or whomever you really are! ;)
>
<_<
>_>
>
>>> +
>>> + if (heap_allocation.fd ||
>>> + heap_allocation.reserved0 ||
>>> + heap_allocation.reserved1 ||
>>> + heap_allocation.reserved2) {
>>
>> Seems too many reserved, I can understand one, but if we ever needed all
>> of these we would be better off just adding another alloc ioctl.
>
> Well, we have to have one u32 for padding. And I figured if we needed
> anything more then a u32, then we're in for 2 more.
>
> And I think the potential of the alignment and heap-private flags, I
> worry we might want to have something, but I guess we could just add
> a new ioctl and keep the support for the old one if folks prefer.
>
>>> +int dma_heap_add(struct dma_heap *heap)
>>> +{
>>> + struct device *dev_ret;
>>> + int ret;
>>> +
>>> + if (!heap->name || !strcmp(heap->name, "")) {
>>> + pr_err("dma_heap: Cannot add heap without a name\n");
>>
>> As these names end up as the dev name in the file system we may want to
>> check for invalid names, there is probably a helper for that somewhere.
>
> Hrm. I'll have to look.
>
>>> +struct dma_heap {
>>> + const char *name;
>>> + struct dma_heap_ops *ops;
>>> + unsigned int minor;
>>> + dev_t heap_devt;
>>> + struct cdev heap_cdev;
>>> +};
>>
>> Still not sure about this, all of the members in this struct are
>> strictly internally used by the framework. The users of this framework
>> should not have access to them and only need to deal with an opaque
>> pointer for tracking themselves (can store it in a private struct of
>> their own then container_of to get back out their struct).
>>
>> Anyway, not a big deal, and if it really bugs me enough I can always go
>> fix it later, it's all kernel internal so not a blocker here. :)
>
> I guess I'd just move the include/linux/dma-heap.h to
> drivers/dma-buf/heaps/ and keep it localized there.
> But whichever. Feel free to also send a patch and I can fold it down.
>
The dma-heap.h needs to stay where it is, I was thinking just move
struct dma_heap to inside drivers/dma-buf/dma-heap.c. I wouldn't worry
about changing anything right now though, I'll post a patch you can
squash in later one we confirm this whole dma-heap thing will get deemed
acceptable in the first place.
Thanks,
Andrew
> thanks
> -john
>
[PATCH] drm/i915/ddi: Fix default eDP detection on port A
We rely on VBT DDI port info for eDP detection on GEN9 platforms and
above. This breaks GEN9 platforms which don't have VBT because port A
eDP now defaults to false. Fix this by defaulting to true when VBT is
missing.
Fixes: commit a98d9c1d7e9b ("drm/i915/ddi: Rely on VBT DDI port info for eDP
detection")
Signed-off-by: Thomas Preston
---
drivers/gpu/drm/i915/intel_bios.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 1faa494e2bc9..efbbfb64b55f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1629,6 +1629,7 @@ init_vbt_missing_defaults(struct drm_i915_private
*dev_priv)
info->supports_dvi = (port != PORT_A && port != PORT_E);
info->supports_hdmi = info->supports_dvi;
info->supports_dp = (port != PORT_E);
+ info->supports_edp = (port == PORT_A);
}
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109331] Empire Total War - Graphical Corruption
https://bugs.freedesktop.org/show_bug.cgi?id=109331 andrew.m.mcma...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from andrew.m.mcma...@gmail.com --- My system has changed somewhat since writing this bug report. As all Feral games on STEAM officially support either STEAMOS or Ubuntu; I thought I'd check out xubuntu 18.04 LTS - specifically: https://pastebin.com/f8cTGLSY The same glitch appears with the current Mesa drivers provided by the distribution (18.2.8) But using oibaf's ppa: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers Mesa related packages are updated to: Mesa 19.1.0-devel (git-54522d0 2019-03-06 bionic-oibaf-ppa) And I can no longer reproduce the issue! https://i.imgur.com/VhIylSp.jpg As I've made no other changes other than switching Mesa packages I can only assume that this has been fixed by an update/commit recently. Many thanks to everyone who works on Mesa. In just a few years (since I last tried Debian) my R9 285 has gone from having no support whatever in Linux to being very capable indeed to the point where I no longer require Windows: https://imgur.com/a/keUM4VS https://imgur.com/a/awddkUg -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On Wed, Mar 6, 2019 at 10:18 AM Andrew F. Davis wrote:
>
> On 3/5/19 2:54 PM, John Stultz wrote:
> > From: "Andrew F. Davis"
> >
> > This framework allows a unified userspace interface for dma-buf
> > exporters, allowing userland to allocate specific types of
> > memory for use in dma-buf sharing.
> >
> > Each heap is given its own device node, which a user can
> > allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
> >
> > This code is an evoluiton of the Android ION implementation,
> > and a big thanks is due to its authors/maintainers over time
> > for their effort:
> > Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
> > Laura Abbott, and many other contributors!
> >
> > Cc: Laura Abbott
> > Cc: Benjamin Gaignard
> > Cc: Greg KH
> > Cc: Sumit Semwal
> > Cc: Liam Mark
> > Cc: Brian Starkey
> > Cc: Andrew F. Davis
> > Cc: Chenbo Feng
> > Cc: Alistair Strachan
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Andrew F. Davis
> > [jstultz: reworded commit message, and lots of cleanups]
> > Signed-off-by: John Stultz
> > ---
> > v2:
> > * Folded down fixes I had previously shared in implementing
> > heaps
> > * Make flags a u64 (Suggested by Laura)
> > * Add PAGE_ALIGN() fix to the core alloc funciton
> > * IOCTL fixups suggested by Brian
> > * Added fixes suggested by Benjamin
> > * Removed core stats mgmt, as that should be implemented by
> > per-heap code
> > * Changed alloc to return a dma-buf fd, rather then a buffer
> > (as it simplifies error handling)
> > ---
> > MAINTAINERS | 16
> > drivers/dma-buf/Kconfig | 8 ++
> > drivers/dma-buf/Makefile | 1 +
> > drivers/dma-buf/dma-heap.c| 191
> > ++
> > include/linux/dma-heap.h | 65 ++
> > include/uapi/linux/dma-heap.h | 52
> > 6 files changed, 333 insertions(+)
> > create mode 100644 drivers/dma-buf/dma-heap.c
> > create mode 100644 include/linux/dma-heap.h
> > create mode 100644 include/uapi/linux/dma-heap.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ac2e518..a661e19 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4621,6 +4621,22 @@ F: include/linux/*fence.h
> > F: Documentation/driver-api/dma-buf.rst
> > T: git git://anongit.freedesktop.org/drm/drm-misc
> >
> > +DMA-BUF HEAPS FRAMEWORK
> > +M: Laura Abbott
> > +R: Liam Mark
> > +R: Brian Starkey
> > +R: "Andrew F. Davis"
>
> Quotes not needed in maintainers file.
Whatever you say, "Andrew F. Davis", or whomever you really are! ;)
> > +
> > + if (heap_allocation.fd ||
> > + heap_allocation.reserved0 ||
> > + heap_allocation.reserved1 ||
> > + heap_allocation.reserved2) {
>
> Seems too many reserved, I can understand one, but if we ever needed all
> of these we would be better off just adding another alloc ioctl.
Well, we have to have one u32 for padding. And I figured if we needed
anything more then a u32, then we're in for 2 more.
And I think the potential of the alignment and heap-private flags, I
worry we might want to have something, but I guess we could just add
a new ioctl and keep the support for the old one if folks prefer.
> > +int dma_heap_add(struct dma_heap *heap)
> > +{
> > + struct device *dev_ret;
> > + int ret;
> > +
> > + if (!heap->name || !strcmp(heap->name, "")) {
> > + pr_err("dma_heap: Cannot add heap without a name\n");
>
> As these names end up as the dev name in the file system we may want to
> check for invalid names, there is probably a helper for that somewhere.
Hrm. I'll have to look.
> > +struct dma_heap {
> > + const char *name;
> > + struct dma_heap_ops *ops;
> > + unsigned int minor;
> > + dev_t heap_devt;
> > + struct cdev heap_cdev;
> > +};
>
> Still not sure about this, all of the members in this struct are
> strictly internally used by the framework. The users of this framework
> should not have access to them and only need to deal with an opaque
> pointer for tracking themselves (can store it in a private struct of
> their own then container_of to get back out their struct).
>
> Anyway, not a big deal, and if it really bugs me enough I can always go
> fix it later, it's all kernel internal so not a blocker here. :)
I guess I'd just move the include/linux/dma-heap.h to
drivers/dma-buf/heaps/ and keep it localized there.
But whichever. Feel free to also send a patch and I can fold it down.
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/5] drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow
On Mon, Mar 4, 2019 at 9:24 PM Maxime Ripard wrote:
>
> On Sun, Mar 03, 2019 at 11:05:23PM +0530, Jagan Teki wrote:
> > Loop N1 instruction delay for burst mode devices are computed
> > based on horizontal sync and porch timing values.
> >
> > The current driver is using u16 type for computing this hsync_porch
> > value, which would failed to fit within the u16 type for large sync
> > and porch timings devices. This would result in hsync_porch overflow
> > and eventually computed wrong instruction delay value.
> >
> > Example, timings, where it produces the overflow
> > {
> > .hdisplay = 1080,
> > .hsync_start= 1080 + 408,
> > .hsync_end = 1080 + 408 + 4,
> > .htotal = 1080 + 408 + 4 + 38,
> > }
> >
> > It reproduces the desired delay value 65487 but the correct working
> > value should be 7.
> >
> > So, Fix it by computing hsync_porch value separately with u32 type.
> >
> > Fixes: 1c1a7aa3663c ("drm/sun4i: dsi: Add burst support")
> > Signed-off-by: Jagan Teki
> > Tested-by: Merlijn Wajer
> > ---
> > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > index 6ff585055a07..465e7fc57899 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -457,8 +457,9 @@ static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi
> > *dsi,
> > u16 delay = 50 - 1;
> >
> > if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> > - delay = (mode->htotal - mode->hdisplay) * 150;
> > - delay /= (mode->clock / 1000) * 8;
> > + u32 hsync_porch = (mode->htotal - mode->hdisplay);
> > +
> > + delay = ((hsync_porch * 150) / ((mode->clock / 1000) * 8));
>
> shouldn't we keep the multiplication by 150 in the u32 assignation?
Yes, ie true. will move it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: rcar-du: Support panels connected directly to the DPAD outputs
The R-Car DU driver assumes that a bridge is always connected to the DU
output. This is valid for the LVDS and HDMI outputs, but the DPAD
outputs can be connected directly to a panel, in which case no bridge is
available.
To support this use case, detect whether the entities connected to the
DU DPAD outputs are encoders or panels based on the number of ports of
their DT node, and retrieve the corresponding type of DRM objects. For
panels, additionally create panel bridge instances.
Signed-off-by: Laurent Pinchart
Tested-by: Kevin Key
Reviewed-by: Kieran Bingham
Reviewed-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 ---
1 file changed, 48 insertions(+), 6 deletions(-)
Changes since v1:
- Fix of_node_put() call in rcar_du_encoder_count_ports(), release the
reference to ports, not to node
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 8ee4e762f4e5..6c91753af7bc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -28,13 +28,33 @@ static const struct drm_encoder_funcs encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
+static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
+{
+ struct device_node *ports;
+ struct device_node *port;
+ unsigned int num_ports = 0;
+
+ ports = of_get_child_by_name(node, "ports");
+ if (!ports)
+ ports = of_node_get(node);
+
+ for_each_child_of_node(ports, port) {
+ if (of_node_name_eq(port, "port"))
+ num_ports++;
+ }
+
+ of_node_put(ports);
+
+ return num_ports;
+}
+
int rcar_du_encoder_init(struct rcar_du_device *rcdu,
enum rcar_du_output output,
struct device_node *enc_node)
{
struct rcar_du_encoder *renc;
struct drm_encoder *encoder;
- struct drm_bridge *bridge = NULL;
+ struct drm_bridge *bridge;
int ret;
renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
@@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
enc_node, output);
- /* Locate the DRM bridge from the encoder DT node. */
- bridge = of_drm_find_bridge(enc_node);
- if (!bridge) {
- ret = -EPROBE_DEFER;
- goto done;
+ /*
+* Locate the DRM bridge from the DT node. For the DPAD outputs, if the
+* DT node has a single port, assume that it describes a panel and
+* create a panel bridge.
+*/
+ if ((output == RCAR_DU_OUTPUT_DPAD0 ||
+output == RCAR_DU_OUTPUT_DPAD1) &&
+ rcar_du_encoder_count_ports(enc_node) == 1) {
+ struct drm_panel *panel = of_drm_find_panel(enc_node);
+
+ if (IS_ERR(panel)) {
+ ret = PTR_ERR(panel);
+ goto done;
+ }
+
+ bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
+ DRM_MODE_CONNECTOR_DPI);
+ if (IS_ERR(bridge)) {
+ ret = PTR_ERR(bridge);
+ goto done;
+ }
+ } else {
+ bridge = of_drm_find_bridge(enc_node);
+ if (!bridge) {
+ ret = -EPROBE_DEFER;
+ goto done;
+ }
}
ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test
On 3/6/19 12:19 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:15 AM Andrew F. Davis wrote:
>>
>> On 3/6/19 10:14 AM, Benjamin Gaignard wrote:
>>> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
Add very trivial allocation test for dma-heaps.
TODO: Need to actually do some validation on
the returned dma-buf.
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Greg KH
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Brian Starkey
Cc: Andrew F. Davis
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2: Switched to use reworked dma-heap apis
---
tools/testing/selftests/dmabuf-heaps/Makefile | 11 +++
tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 96
++
2 files changed, 107 insertions(+)
create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
b/tools/testing/selftests/dmabuf-heaps/Makefile
new file mode 100644
index 000..c414ad3
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
+#LDLIBS += -lrt -lpthread -lm
+
+# these are all "safe" tests that don't modify
+# system time or require escalated privileges
+TEST_GEN_PROGS = dmabuf-heap
+
+
+include ../lib.mk
+
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
new file mode 100644
index 000..06837a4
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../../../../include/uapi/linux/dma-heap.h"
+
+#define DEVPATH "/dev/dma_heap"
+
+int dmabuf_heap_open(char *name)
+{
+ int ret, fd;
+ char buf[256];
+
+ ret = sprintf(buf, "%s/%s", DEVPATH, name);
+ if (ret < 0) {
+ printf("sprintf failed!\n");
+ return ret;
+ }
+
+ fd = open(buf, O_RDWR);
+ if (fd < 0)
+ printf("open %s failed!\n", buf);
+ return fd;
+}
+
+int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags, int
*dmabuf_fd)
+{
+ struct dma_heap_allocation_data data = {
+ .len = len,
+ .flags = flags,
+ };
+ int ret;
+
+ if (dmabuf_fd == NULL)
+ return -EINVAL;
+
+ ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, );
+ if (ret < 0)
+ return ret;
+ *dmabuf_fd = (int)data.fd;
+ return ret;
+}
+
+#define ONE_MEG (1024*1024)
+
+void do_test(char *heap_name)
+{
+ int heap_fd = -1, dmabuf_fd = -1;
+ int ret;
+
+ printf("Testing heap: %s\n", heap_name);
+
+ heap_fd = dmabuf_heap_open(heap_name);
+ if (heap_fd < 0)
+ return;
+
+ printf("Allocating 1 MEG\n");
+ ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, _fd);
+ if (ret)
+ goto out;
+
+ /* DO SOMETHING WITH THE DMABUF HERE? */
>>>
>>> You can do a call to mmap and write a pattern in the buffer.
>>>
>>
>> mmap is optional for DMA-BUFs, only attach/map are required. To test
>> those we would need a dummy device, so a test kernel module may be
>> needed to really exercise this.
>>
>> I have one I use for ION buffer testing, it consumes a DMA-BUF passed
>> from userspace, attach/maps it to a dummy device then return the
>> physical address of the first page of the buffer for validation. Might
>> be a good test, but dummy devices don't always have the proper dma
>> attributes set like a real device does, so it may also fail for some
>> otherwise valid buffers.
>
> Cool! Do you mind sharing that? I might try to rework and integrate it
> into this patchset?
>
Sure, top two patches here:
> https://git.ti.com/ti-analog-linux-kernel/afd-analog/commits/dma-buf-to-phys
Andrew
> thanks
> -john
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109834] No x86 libraries in new amdgpu-pro drivers
https://bugs.freedesktop.org/show_bug.cgi?id=109834 Andre Klapper changed: What|Removed |Added Priority|high|medium -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/19] media: vsp1: dl: Support one-shot entries in the display list
Hi Brian,
On Wed, Mar 06, 2019 at 11:05:05AM +, Brian Starkey wrote:
> On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> > On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> >> On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> >>> On Fri, Feb 22, 2019 at 02:30:03PM +, Brian Starkey wrote:
> On Thu, Feb 21, 2019 at 12:32:00PM +0200, Laurent Pinchart wrote:
> > One-shot entries are used as an alternative to committing a complete new
> > display list when a couple of registers need to be written for one frame
> > and then reset to another value for all subsequent frames. This will be
> > used to implement writeback support that will need to enable writeback
> > for the duration of a single frame.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> > drivers/media/platform/vsp1/vsp1_dl.c | 78 +++
> > drivers/media/platform/vsp1/vsp1_dl.h | 3 ++
> > 2 files changed, 81 insertions(+)
> >
> > diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> > b/drivers/media/platform/vsp1/vsp1_dl.c
> > index 886b3a69d329..7b4d252bfde7 100644
> > --- a/drivers/media/platform/vsp1/vsp1_dl.c
> > +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> > @@ -115,6 +115,12 @@ struct vsp1_dl_body {
> >
> > unsigned int num_entries;
> > unsigned int max_entries;
> > +
> > + unsigned int num_patches;
> > + struct {
> > + struct vsp1_dl_entry *entry;
> > + u32 data;
> > + } patches[2];
> > };
> >
> > /**
> > @@ -361,6 +367,7 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
> > return;
> >
> > dlb->num_entries = 0;
> > + dlb->num_patches = 0;
> >
> > spin_lock_irqsave(>pool->lock, flags);
> > list_add_tail(>free, >pool->free);
> > @@ -388,6 +395,47 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb,
> > u32 reg, u32 data)
> > dlb->num_entries++;
> > }
> >
> > +/**
> > + * vsp1_dl_body_write_oneshot - Write a register to a display list
> > body for a
> > + * single frame
> > + * @dlb: The body
> > + * @reg: The register address
> > + * @value: The register value
> > + * @reset_value: The value to reset the register to at the next vblank
> > + *
> > + * Display lists in continuous mode are re-used by the hardware for
> > successive
> > + * frames until a new display list is committed. Changing the VSP
> > configuration
> > + * normally requires creating and committing a new display list. This
> > function
> > + * offers an alternative race-free way by writing a @value to the
> > @register in
> > + * the display list body for a single frame, specifying in
> > @reset_value the
> > + * value to reset the register to one vblank after the display list is
> > + * committed.
> > + *
> > + * The maximum number of one-shot entries is limited to 2 per display
> > list body,
> > + * and one-shot entries are counted in the total number of entries
> > specified
> > + * when the body is allocated by vsp1_dl_body_alloc().
> > + */
> > +void vsp1_dl_body_write_oneshot(struct vsp1_dl_body *dlb, u32 reg, u32
> > value,
> > + u32 reset_value)
> > +{
> > + if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
> > + "DLB size exceeded (max %u)", dlb->max_entries))
> > + return;
> > +
> > + if (WARN_ONCE(dlb->num_patches >= ARRAY_SIZE(dlb->patches),
> > + "DLB patches size exceeded (max %zu)",
> > + ARRAY_SIZE(dlb->patches)))
> > + return;
> > +
> > + dlb->patches[dlb->num_patches].entry =
> > >entries[dlb->num_entries];
> > + dlb->patches[dlb->num_patches].data = reset_value;
> > + dlb->num_patches++;
> > +
> > + dlb->entries[dlb->num_entries].addr = reg;
> > + dlb->entries[dlb->num_entries].data = value;
> > + dlb->num_entries++;
> > +}
> > +
> > /*
> > -
> > * Display List Extended Command Management
> > */
> > @@ -652,6 +700,7 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list
> > *dl)
> > * has at least one body, thus we reinitialise the entries list.
> > */
> > dl->body0->num_entries = 0;
> > + dl->body0->num_patches = 0;
> >
> > list_add_tail(>list, >dlm->free);
> > }
> > @@ -930,6 +979,35 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl,
> > unsigned int dl_flags)
> > * Display List Manager
Re: [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test
On Wed, Mar 6, 2019 at 10:15 AM Andrew F. Davis wrote:
>
> On 3/6/19 10:14 AM, Benjamin Gaignard wrote:
> > Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
> >>
> >> Add very trivial allocation test for dma-heaps.
> >>
> >> TODO: Need to actually do some validation on
> >> the returned dma-buf.
> >>
> >> Cc: Laura Abbott
> >> Cc: Benjamin Gaignard
> >> Cc: Greg KH
> >> Cc: Sumit Semwal
> >> Cc: Liam Mark
> >> Cc: Brian Starkey
> >> Cc: Andrew F. Davis
> >> Cc: Chenbo Feng
> >> Cc: Alistair Strachan
> >> Cc: dri-devel@lists.freedesktop.org
> >> Signed-off-by: John Stultz
> >> ---
> >> v2: Switched to use reworked dma-heap apis
> >> ---
> >> tools/testing/selftests/dmabuf-heaps/Makefile | 11 +++
> >> tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 96
> >> ++
> >> 2 files changed, 107 insertions(+)
> >> create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
> >> create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> >>
> >> diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
> >> b/tools/testing/selftests/dmabuf-heaps/Makefile
> >> new file mode 100644
> >> index 000..c414ad3
> >> --- /dev/null
> >> +++ b/tools/testing/selftests/dmabuf-heaps/Makefile
> >> @@ -0,0 +1,11 @@
> >> +# SPDX-License-Identifier: GPL-2.0
> >> +CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
> >> +#LDLIBS += -lrt -lpthread -lm
> >> +
> >> +# these are all "safe" tests that don't modify
> >> +# system time or require escalated privileges
> >> +TEST_GEN_PROGS = dmabuf-heap
> >> +
> >> +
> >> +include ../lib.mk
> >> +
> >> diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> >> b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> >> new file mode 100644
> >> index 000..06837a4
> >> --- /dev/null
> >> +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> >> @@ -0,0 +1,96 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "../../../../include/uapi/linux/dma-heap.h"
> >> +
> >> +#define DEVPATH "/dev/dma_heap"
> >> +
> >> +int dmabuf_heap_open(char *name)
> >> +{
> >> + int ret, fd;
> >> + char buf[256];
> >> +
> >> + ret = sprintf(buf, "%s/%s", DEVPATH, name);
> >> + if (ret < 0) {
> >> + printf("sprintf failed!\n");
> >> + return ret;
> >> + }
> >> +
> >> + fd = open(buf, O_RDWR);
> >> + if (fd < 0)
> >> + printf("open %s failed!\n", buf);
> >> + return fd;
> >> +}
> >> +
> >> +int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags, int
> >> *dmabuf_fd)
> >> +{
> >> + struct dma_heap_allocation_data data = {
> >> + .len = len,
> >> + .flags = flags,
> >> + };
> >> + int ret;
> >> +
> >> + if (dmabuf_fd == NULL)
> >> + return -EINVAL;
> >> +
> >> + ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, );
> >> + if (ret < 0)
> >> + return ret;
> >> + *dmabuf_fd = (int)data.fd;
> >> + return ret;
> >> +}
> >> +
> >> +#define ONE_MEG (1024*1024)
> >> +
> >> +void do_test(char *heap_name)
> >> +{
> >> + int heap_fd = -1, dmabuf_fd = -1;
> >> + int ret;
> >> +
> >> + printf("Testing heap: %s\n", heap_name);
> >> +
> >> + heap_fd = dmabuf_heap_open(heap_name);
> >> + if (heap_fd < 0)
> >> + return;
> >> +
> >> + printf("Allocating 1 MEG\n");
> >> + ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, _fd);
> >> + if (ret)
> >> + goto out;
> >> +
> >> + /* DO SOMETHING WITH THE DMABUF HERE? */
> >
> > You can do a call to mmap and write a pattern in the buffer.
> >
>
> mmap is optional for DMA-BUFs, only attach/map are required. To test
> those we would need a dummy device, so a test kernel module may be
> needed to really exercise this.
>
> I have one I use for ION buffer testing, it consumes a DMA-BUF passed
> from userspace, attach/maps it to a dummy device then return the
> physical address of the first page of the buffer for validation. Might
> be a good test, but dummy devices don't always have the proper dma
> attributes set like a real device does, so it may also fail for some
> otherwise valid buffers.
Cool! Do you mind sharing that? I might try to rework and integrate it
into this patchset?
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=109695 --- Comment #10 from Dylan Baker --- We're getting down to just a few bugs blocking 19.0, so I'm pinging those bugs to see what the progress is? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109834] No x86 libraries in new amdgpu-pro drivers
https://bugs.freedesktop.org/show_bug.cgi?id=109834 --- Comment #2 from pearlydragon --- Open drivers doesnt contained icd and loader. Or I find source ,but it compile in 10GB - I have only 4GB in root. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/19] media: vsp1: dl: Support one-shot entries in the display list
Hi Liviu,
On Wed, Mar 06, 2019 at 02:20:51PM +, Liviu Dudau wrote:
> On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> > On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> >> On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> >>> On Fri, Feb 22, 2019 at 02:30:03PM +, Brian Starkey wrote:
> On Thu, Feb 21, 2019 at 12:32:00PM +0200, Laurent Pinchart wrote:
> > One-shot entries are used as an alternative to committing a complete new
> > display list when a couple of registers need to be written for one frame
> > and then reset to another value for all subsequent frames. This will be
> > used to implement writeback support that will need to enable writeback
> > for the duration of a single frame.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> > drivers/media/platform/vsp1/vsp1_dl.c | 78 +++
> > drivers/media/platform/vsp1/vsp1_dl.h | 3 ++
> > 2 files changed, 81 insertions(+)
> >
> > diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> > b/drivers/media/platform/vsp1/vsp1_dl.c
> > index 886b3a69d329..7b4d252bfde7 100644
> > --- a/drivers/media/platform/vsp1/vsp1_dl.c
> > +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> > @@ -115,6 +115,12 @@ struct vsp1_dl_body {
> >
> > unsigned int num_entries;
> > unsigned int max_entries;
> > +
> > + unsigned int num_patches;
> > + struct {
> > + struct vsp1_dl_entry *entry;
> > + u32 data;
> > + } patches[2];
> > };
> >
> > /**
> > @@ -361,6 +367,7 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
> > return;
> >
> > dlb->num_entries = 0;
> > + dlb->num_patches = 0;
> >
> > spin_lock_irqsave(>pool->lock, flags);
> > list_add_tail(>free, >pool->free);
> > @@ -388,6 +395,47 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb,
> > u32 reg, u32 data)
> > dlb->num_entries++;
> > }
> >
> > +/**
> > + * vsp1_dl_body_write_oneshot - Write a register to a display list
> > body for a
> > + * single frame
> > + * @dlb: The body
> > + * @reg: The register address
> > + * @value: The register value
> > + * @reset_value: The value to reset the register to at the next vblank
> > + *
> > + * Display lists in continuous mode are re-used by the hardware for
> > successive
> > + * frames until a new display list is committed. Changing the VSP
> > configuration
> > + * normally requires creating and committing a new display list. This
> > function
> > + * offers an alternative race-free way by writing a @value to the
> > @register in
> > + * the display list body for a single frame, specifying in
> > @reset_value the
> > + * value to reset the register to one vblank after the display list is
> > + * committed.
> > + *
> > + * The maximum number of one-shot entries is limited to 2 per display
> > list body,
> > + * and one-shot entries are counted in the total number of entries
> > specified
> > + * when the body is allocated by vsp1_dl_body_alloc().
> > + */
> > +void vsp1_dl_body_write_oneshot(struct vsp1_dl_body *dlb, u32 reg, u32
> > value,
> > + u32 reset_value)
> > +{
> > + if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
> > + "DLB size exceeded (max %u)", dlb->max_entries))
> > + return;
> > +
> > + if (WARN_ONCE(dlb->num_patches >= ARRAY_SIZE(dlb->patches),
> > + "DLB patches size exceeded (max %zu)",
> > + ARRAY_SIZE(dlb->patches)))
> > + return;
> > +
> > + dlb->patches[dlb->num_patches].entry =
> > >entries[dlb->num_entries];
> > + dlb->patches[dlb->num_patches].data = reset_value;
> > + dlb->num_patches++;
> > +
> > + dlb->entries[dlb->num_entries].addr = reg;
> > + dlb->entries[dlb->num_entries].data = value;
> > + dlb->num_entries++;
> > +}
> > +
> > /*
> > -
> > * Display List Extended Command Management
> > */
> > @@ -652,6 +700,7 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list
> > *dl)
> > * has at least one body, thus we reinitialise the entries list.
> > */
> > dl->body0->num_entries = 0;
> > + dl->body0->num_patches = 0;
> >
> > list_add_tail(>list, >dlm->free);
> > }
> > @@ -930,6 +979,35 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl,
> > unsigned int dl_flags)
> > * Display List Manager
>
[Bug 109493] [CI][DRMTIP] igt@gem_cpu_reloc@forked - fail - igt_skip: Assertion `!test_child' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=109493 --- Comment #7 from CI Bug Log --- The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109493] [CI][DRMTIP] igt@gem_cpu_reloc@forked - fail - igt_skip: Assertion `!test_child' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=109493 Martin Peres changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Martin Peres --- (In reply to Chris Wilson from comment #5) > commit 4049adf01014af077df2174def4fadf7cecb066e (HEAD, upstream/master) > Author: Chris Wilson > Date: Wed Jan 30 16:18:58 2019 + > > i915/gem_cpu_reloc: Do the can-store-dword check at start > > igt doesn't handle skipping from inside igt_fork very gracefully and > crashes instead of reporting the lack of requirements. One solution > would be to fix igt, but far easier is to just move the requirement > checking around to do it before we even fork. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109493 > Signed-off-by: Chris Wilson > Reviewed-by: Tvrtko Ursulin Thanks, it definitely did the trick as it was seen twice every single run between drmtip_197 and 203, and nothing for 34 runs :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/7] drm/edid: Allow to ignore the audio EDID data
Maxime Ripard writes: > [ Unknown signature status ] > On Tue, Mar 05, 2019 at 01:47:38PM -0800, Eric Anholt wrote: >> Maxime Ripard writes: >> >> > [ Unknown signature status ] >> > On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote: >> >> On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote: >> >> > >> >> > Maxime Ripard writes: >> >> > >> >> > > In some cases, in order to accomodate with displays with poor EDIDs, >> >> > > we >> >> > > need to ignore that the monitor alledgedly supports audio output and >> >> > > disable the audio output. >> >> > > >> >> > > Signed-off-by: Maxime Ripard >> >> > > --- >> >> > > drivers/gpu/drm/drm_edid.c | 8 >> >> > > 1 file changed, 8 insertions(+) >> >> > > >> >> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c >> >> > > index 990b1909f9d7..c0258b011bb2 100644 >> >> > > --- a/drivers/gpu/drm/drm_edid.c >> >> > > +++ b/drivers/gpu/drm/drm_edid.c >> >> > > @@ -4190,6 +4190,11 @@ bool drm_detect_hdmi_monitor(struct edid *edid) >> >> > > } >> >> > > EXPORT_SYMBOL(drm_detect_hdmi_monitor); >> >> > > >> >> > > +static bool ignore_edid_audio = false; >> >> > > +module_param(ignore_edid_audio, bool, 0644); >> >> > > +MODULE_PARM_DESC(ignore_edid_audio, >> >> > > + "Ignore the EDID and always consider that a monitor >> >> > > doesn't have audio capabilities"); >> >> > > + >> >> > > /** >> >> > > * drm_detect_monitor_audio - check monitor audio capability >> >> > > * @edid: EDID block to scan >> >> > > @@ -4209,6 +4214,9 @@ bool drm_detect_monitor_audio(struct edid *edid) >> >> > > bool has_audio = false; >> >> > > int start_offset, end_offset; >> >> > > >> >> > > + if (ignore_edid_audio) >> >> > > + goto end; >> >> > > + >> >> > > edid_ext = drm_find_cea_extension(edid); >> >> > > if (!edid_ext) >> >> > > goto end; >> >> > >> >> > It looks like the motivation for the original flag on Raspberry Pi was >> >> > "I've got a non-audio monitor, but the system comes up trying to play >> >> > audio to HDMI instead of the analog jack". Do we have some way for DRM >> >> > to communicate to ALSA that this is not the right place to try to play >> >> > audio by default? >> >> >> >> Apparently not. We have users using debug knobs in our drivers to >> >> disable display audio because ALSA defaults to that rather than other >> >> audio. >> > >> > I guess one way to do this would be to register the card only when an >> > audio-capable monitor is connected instead of doing this at probe >> > time. I'm not sure how convenient it is for userspace though. >> >> Oh, right, the HDMI encoder passes the ELD to ALSA, and userspace gets >> to use that. So, open source is already doing the right thing, and the >> problem was that the old driver talking to the firmware wouldn't, thus >> the need for a flag. > > I started to look into this, and while on my laptop, the ELD seems to > be exposed as part of /proc/asound/card0/eld*, there's no such file on > the RPi with a 5.0 kernel (and an HDMI monitor with audio support, > obviously). Is it something that used to work at some point? I don't know, personally. Sounds like it's worth investigating. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
Qiang Yu writes: > - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for > OpenGL vertex shader processing and PP is for fragment shader > processing. Each processor has its own MMU so prcessors work in > virtual address space. > - There's only one GP but multiple PP (max 4 for mali 400 and 8 > for mali 450) in the same mali 4xx GPU. All PPs are grouped > togather to handle a single fragment shader task divided by > FB output tiled pixels. Mali 400 user space driver is > responsible for assign target tiled pixels to each PP, but mali > 450 has a HW module called DLBU to dynamically balance each > PP's load. > - User space driver allocate buffer object and map into GPU > virtual address space, upload command stream and draw data with > CPU mmap of the buffer object, then submit task to GP/PP with > a register frame indicating where is the command stream and misc > settings. > - There's no command stream validation/relocation due to each user > process has its own GPU virtual address space. GP/PP's MMU switch > virtual address space before running two tasks from different > user process. Error or evil user space code just get MMU fault > or GP/PP error IRQ, then the HW/SW will be recovered. > - Use GEM+shmem for MM. Currently just alloc and pin memory when > gem object creation. GPU vm map of the buffer is also done in > the alloc stage in kernel space. We may delay the memory > allocation and real GPU vm map to command submission stage in the > furture as improvement. > - Use drm_sched for GPU task schedule. Each OpenGL context should > have a lima context object in the kernel to distinguish tasks > from different user. drm_sched gets task from each lima context > in a fair way. > > mesa driver can be found here before upstreamed: > https://gitlab.freedesktop.org/lima/mesa > > v7: > - remove lima_fence_ops with default value > - move fence slab create to device probe > - check pad ioctl args to be zero > - add comments for user/kernel interface Thanks for adding the comments! That helps a lot. I feel pretty good about the ABI at this point. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Use 16bpp by default for the fbdev buffer
Maxime Ripard writes: > The preferred bpp for the fbdev emulation buffer has been 32 so far, which > means that by default we will allocate an 8MB buffer with a 1920x1080 > resolution. > > Worse this memory will be allocated from the CMA pool, and will never be > freed even if we don't use the fbdev emulation. Therefore, reducing it is a > big deal, and switching to 16bpp by default will gain us around 4MB at > 1920x1080, while keeping decent color depth. And users still have the > option to switch to 32bpp using the kernel command line. Reviewed-by: Eric Anholt This matches the defaults used by the bcm2708 fbdev driver that we're trying to get people to switch off of. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201273] Fatal error during GPU init amdgpu RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201273 --- Comment #36 from quirin.blae...@freenet.de --- Bug is still alive. v5.0 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test
On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
wrote:
> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
> > +
> > + printf("Allocating 1 MEG\n");
> > + ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, _fd);
> > + if (ret)
> > + goto out;
> > +
> > + /* DO SOMETHING WITH THE DMABUF HERE? */
>
> You can do a call to mmap and write a pattern in the buffer.
Yea. I can also do some invalid allocations to make sure things fail properly.
But I was talking a bit w/ Sumit about the lack of any general dmabuf
tests, and am curious if we need to have a importer device driver that
can validate its a real dmabuf and exercise more of the dmabuf ops.
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On Wed, Mar 6, 2019 at 8:12 AM Benjamin Gaignard wrote: > Le mar. 5 mars 2019 à 21:54, John Stultz a écrit : > > +/** > > + * DOC: DMABUF Heaps Userspace API > > + * > > + */ > > + > > +/* Currently no flags */ > > +#define DMA_HEAP_VALID_FLAGS (0) > > I think here you need to allow flags like O_RDWR or O_CLOEXEC else > mmap will fail. > Hm. So I meant for these to be just the bitmask of valid flags for the allocate IOCTL (used to make sure no one is passing junk flags accidentally), rather then valid flags for the heap open call. But this probably suggests I should call it something like DMA_HEAP_ALLOC_VALID_FLAGS instead? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109922] Failed to get GBM bo for flip to new front.
https://bugs.freedesktop.org/show_bug.cgi?id=109922 Michel Dänzer changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #1 from Michel Dänzer --- This is https://gitlab.freedesktop.org/xorg/xserver/issues/68 . -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109922] Failed to get GBM bo for flip to new front.
https://bugs.freedesktop.org/show_bug.cgi?id=109922 Bug ID: 109922 Summary: Failed to get GBM bo for flip to new front. Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: pmenzel+bugs.freedesktop@molgen.mpg.de Created attachment 143553 --> https://bugs.freedesktop.org/attachment.cgi?id=143553=edit Xorg.0.log Using the modesetting driver with AMD hardware, the X.Org Server reports a lot of the messages below. [ 139.113] (EE) modeset(0): Failed to get GBM bo for flip to new front. [ 139.113] (EE) modeset(0): present flip failed This happened with Linux 4.19.19 and 4.20.13. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test
On 3/6/19 10:14 AM, Benjamin Gaignard wrote:
> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>>
>> Add very trivial allocation test for dma-heaps.
>>
>> TODO: Need to actually do some validation on
>> the returned dma-buf.
>>
>> Cc: Laura Abbott
>> Cc: Benjamin Gaignard
>> Cc: Greg KH
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian Starkey
>> Cc: Andrew F. Davis
>> Cc: Chenbo Feng
>> Cc: Alistair Strachan
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: John Stultz
>> ---
>> v2: Switched to use reworked dma-heap apis
>> ---
>> tools/testing/selftests/dmabuf-heaps/Makefile | 11 +++
>> tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 96
>> ++
>> 2 files changed, 107 insertions(+)
>> create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
>> create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>>
>> diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
>> b/tools/testing/selftests/dmabuf-heaps/Makefile
>> new file mode 100644
>> index 000..c414ad3
>> --- /dev/null
>> +++ b/tools/testing/selftests/dmabuf-heaps/Makefile
>> @@ -0,0 +1,11 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
>> +#LDLIBS += -lrt -lpthread -lm
>> +
>> +# these are all "safe" tests that don't modify
>> +# system time or require escalated privileges
>> +TEST_GEN_PROGS = dmabuf-heap
>> +
>> +
>> +include ../lib.mk
>> +
>> diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>> b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>> new file mode 100644
>> index 000..06837a4
>> --- /dev/null
>> +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>> @@ -0,0 +1,96 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "../../../../include/uapi/linux/dma-heap.h"
>> +
>> +#define DEVPATH "/dev/dma_heap"
>> +
>> +int dmabuf_heap_open(char *name)
>> +{
>> + int ret, fd;
>> + char buf[256];
>> +
>> + ret = sprintf(buf, "%s/%s", DEVPATH, name);
>> + if (ret < 0) {
>> + printf("sprintf failed!\n");
>> + return ret;
>> + }
>> +
>> + fd = open(buf, O_RDWR);
>> + if (fd < 0)
>> + printf("open %s failed!\n", buf);
>> + return fd;
>> +}
>> +
>> +int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags, int
>> *dmabuf_fd)
>> +{
>> + struct dma_heap_allocation_data data = {
>> + .len = len,
>> + .flags = flags,
>> + };
>> + int ret;
>> +
>> + if (dmabuf_fd == NULL)
>> + return -EINVAL;
>> +
>> + ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, );
>> + if (ret < 0)
>> + return ret;
>> + *dmabuf_fd = (int)data.fd;
>> + return ret;
>> +}
>> +
>> +#define ONE_MEG (1024*1024)
>> +
>> +void do_test(char *heap_name)
>> +{
>> + int heap_fd = -1, dmabuf_fd = -1;
>> + int ret;
>> +
>> + printf("Testing heap: %s\n", heap_name);
>> +
>> + heap_fd = dmabuf_heap_open(heap_name);
>> + if (heap_fd < 0)
>> + return;
>> +
>> + printf("Allocating 1 MEG\n");
>> + ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, _fd);
>> + if (ret)
>> + goto out;
>> +
>> + /* DO SOMETHING WITH THE DMABUF HERE? */
>
> You can do a call to mmap and write a pattern in the buffer.
>
mmap is optional for DMA-BUFs, only attach/map are required. To test
those we would need a dummy device, so a test kernel module may be
needed to really exercise this.
I have one I use for ION buffer testing, it consumes a DMA-BUF passed
from userspace, attach/maps it to a dummy device then return the
physical address of the first page of the buffer for validation. Might
be a good test, but dummy devices don't always have the proper dma
attributes set like a real device does, so it may also fail for some
otherwise valid buffers.
Andrew
> Benjamin
>> +
>> +out:
>> + if (dmabuf_fd >= 0)
>> + close(dmabuf_fd);
>> + if (heap_fd >= 0)
>> + close(heap_fd);
>> +}
>> +
>> +
>> +int main(void)
>> +{
>> + DIR *d;
>> + struct dirent *dir;
>> +
>> + d = opendir(DEVPATH);
>> + if (!d) {
>> + printf("No %s directory?\n", DEVPATH);
>> + return -1;
>> + }
>> +
>> + while ((dir = readdir(d)) != NULL)
>> + do_test(dir->d_name);
>> +
>> +
>> + return 0;
>> +}
>> --
>> 2.7.4
>>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On 3/5/19 2:54 PM, John Stultz wrote:
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of
> memory for use in dma-buf sharing.
>
> Each heap is given its own device node, which a user can
> allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
>
> This code is an evoluiton of the Android ION implementation,
> and a big thanks is due to its authors/maintainers over time
> for their effort:
> Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
> Laura Abbott, and many other contributors!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Greg KH
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Brian Starkey
> Cc: Andrew F. Davis
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Andrew F. Davis
> [jstultz: reworded commit message, and lots of cleanups]
> Signed-off-by: John Stultz
> ---
> v2:
> * Folded down fixes I had previously shared in implementing
> heaps
> * Make flags a u64 (Suggested by Laura)
> * Add PAGE_ALIGN() fix to the core alloc funciton
> * IOCTL fixups suggested by Brian
> * Added fixes suggested by Benjamin
> * Removed core stats mgmt, as that should be implemented by
> per-heap code
> * Changed alloc to return a dma-buf fd, rather then a buffer
> (as it simplifies error handling)
> ---
> MAINTAINERS | 16
> drivers/dma-buf/Kconfig | 8 ++
> drivers/dma-buf/Makefile | 1 +
> drivers/dma-buf/dma-heap.c| 191
> ++
> include/linux/dma-heap.h | 65 ++
> include/uapi/linux/dma-heap.h | 52
> 6 files changed, 333 insertions(+)
> create mode 100644 drivers/dma-buf/dma-heap.c
> create mode 100644 include/linux/dma-heap.h
> create mode 100644 include/uapi/linux/dma-heap.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ac2e518..a661e19 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4621,6 +4621,22 @@ F: include/linux/*fence.h
> F: Documentation/driver-api/dma-buf.rst
> T: git git://anongit.freedesktop.org/drm/drm-misc
>
> +DMA-BUF HEAPS FRAMEWORK
> +M: Laura Abbott
> +R: Liam Mark
> +R: Brian Starkey
> +R: "Andrew F. Davis"
Quotes not needed in maintainers file.
> +R: John Stultz
> +S: Maintained
> +L: linux-me...@vger.kernel.org
> +L: dri-devel@lists.freedesktop.org
> +L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
> +F: include/uapi/linux/dma-heap.h
> +F: include/linux/dma-heap.h
> +F: drivers/dma-buf/dma-heap.c
> +F: drivers/dma-buf/heaps/*
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
> M: Vinod Koul
> L: dmaeng...@vger.kernel.org
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index 2e5a0fa..09c61db 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -39,4 +39,12 @@ config UDMABUF
> A driver to let userspace turn memfd regions into dma-bufs.
> Qemu can use this to create host dmabufs for guest framebuffers.
>
> +menuconfig DMABUF_HEAPS
> + bool "DMA-BUF Userland Memory Heaps"
> + select DMA_SHARED_BUFFER
> + help
> + Choose this option to enable the DMA-BUF userland memory heaps,
> + this allows userspace to allocate dma-bufs that can be shared between
> + drivers.
> +
> endmenu
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index 0913a6c..b0332f1 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1,4 +1,5 @@
> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
> +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
> obj-$(CONFIG_SYNC_FILE) += sync_file.o
> obj-$(CONFIG_SW_SYNC)+= sw_sync.o sync_debug.o
> obj-$(CONFIG_UDMABUF)+= udmabuf.o
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> new file mode 100644
> index 000..14b3975
> --- /dev/null
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Framework for userspace DMA-BUF allocations
> + *
> + * Copyright (C) 2011 Google, Inc.
> + * Copyright (C) 2019 Linaro Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define DEVNAME "dma_heap"
> +
> +#define NUM_HEAP_MINORS 128
> +static DEFINE_IDR(dma_heap_idr);
> +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */
> +
> +dev_t dma_heap_devt;
> +struct class *dma_heap_class;
> +struct list_head dma_heap_list;
> +struct dentry *dma_heap_debug_root;
> +
> +static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> + unsigned int flags)
> +{
> + len = PAGE_ALIGN(len);
> + if (!len)
> + return -EINVAL;
> +
> +
Re: [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>
> Add very trivial allocation test for dma-heaps.
>
> TODO: Need to actually do some validation on
> the returned dma-buf.
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Greg KH
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Brian Starkey
> Cc: Andrew F. Davis
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> v2: Switched to use reworked dma-heap apis
> ---
> tools/testing/selftests/dmabuf-heaps/Makefile | 11 +++
> tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 96
> ++
> 2 files changed, 107 insertions(+)
> create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
> create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>
> diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
> b/tools/testing/selftests/dmabuf-heaps/Makefile
> new file mode 100644
> index 000..c414ad3
> --- /dev/null
> +++ b/tools/testing/selftests/dmabuf-heaps/Makefile
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0
> +CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
> +#LDLIBS += -lrt -lpthread -lm
> +
> +# these are all "safe" tests that don't modify
> +# system time or require escalated privileges
> +TEST_GEN_PROGS = dmabuf-heap
> +
> +
> +include ../lib.mk
> +
> diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> new file mode 100644
> index 000..06837a4
> --- /dev/null
> +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> @@ -0,0 +1,96 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../../../../include/uapi/linux/dma-heap.h"
> +
> +#define DEVPATH "/dev/dma_heap"
> +
> +int dmabuf_heap_open(char *name)
> +{
> + int ret, fd;
> + char buf[256];
> +
> + ret = sprintf(buf, "%s/%s", DEVPATH, name);
> + if (ret < 0) {
> + printf("sprintf failed!\n");
> + return ret;
> + }
> +
> + fd = open(buf, O_RDWR);
> + if (fd < 0)
> + printf("open %s failed!\n", buf);
> + return fd;
> +}
> +
> +int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags, int *dmabuf_fd)
> +{
> + struct dma_heap_allocation_data data = {
> + .len = len,
> + .flags = flags,
> + };
> + int ret;
> +
> + if (dmabuf_fd == NULL)
> + return -EINVAL;
> +
> + ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, );
> + if (ret < 0)
> + return ret;
> + *dmabuf_fd = (int)data.fd;
> + return ret;
> +}
> +
> +#define ONE_MEG (1024*1024)
> +
> +void do_test(char *heap_name)
> +{
> + int heap_fd = -1, dmabuf_fd = -1;
> + int ret;
> +
> + printf("Testing heap: %s\n", heap_name);
> +
> + heap_fd = dmabuf_heap_open(heap_name);
> + if (heap_fd < 0)
> + return;
> +
> + printf("Allocating 1 MEG\n");
> + ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, _fd);
> + if (ret)
> + goto out;
> +
> + /* DO SOMETHING WITH THE DMABUF HERE? */
You can do a call to mmap and write a pattern in the buffer.
Benjamin
> +
> +out:
> + if (dmabuf_fd >= 0)
> + close(dmabuf_fd);
> + if (heap_fd >= 0)
> + close(heap_fd);
> +}
> +
> +
> +int main(void)
> +{
> + DIR *d;
> + struct dirent *dir;
> +
> + d = opendir(DEVPATH);
> + if (!d) {
> + printf("No %s directory?\n", DEVPATH);
> + return -1;
> + }
> +
> + while ((dir = readdir(d)) != NULL)
> + do_test(dir->d_name);
> +
> +
> + return 0;
> +}
> --
> 2.7.4
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of
> memory for use in dma-buf sharing.
>
> Each heap is given its own device node, which a user can
> allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
>
> This code is an evoluiton of the Android ION implementation,
> and a big thanks is due to its authors/maintainers over time
> for their effort:
> Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
> Laura Abbott, and many other contributors!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Greg KH
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Brian Starkey
> Cc: Andrew F. Davis
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Andrew F. Davis
> [jstultz: reworded commit message, and lots of cleanups]
> Signed-off-by: John Stultz
> ---
> v2:
> * Folded down fixes I had previously shared in implementing
> heaps
> * Make flags a u64 (Suggested by Laura)
> * Add PAGE_ALIGN() fix to the core alloc funciton
> * IOCTL fixups suggested by Brian
> * Added fixes suggested by Benjamin
> * Removed core stats mgmt, as that should be implemented by
> per-heap code
> * Changed alloc to return a dma-buf fd, rather then a buffer
> (as it simplifies error handling)
> ---
> MAINTAINERS | 16
> drivers/dma-buf/Kconfig | 8 ++
> drivers/dma-buf/Makefile | 1 +
> drivers/dma-buf/dma-heap.c| 191
> ++
> include/linux/dma-heap.h | 65 ++
> include/uapi/linux/dma-heap.h | 52
> 6 files changed, 333 insertions(+)
> create mode 100644 drivers/dma-buf/dma-heap.c
> create mode 100644 include/linux/dma-heap.h
> create mode 100644 include/uapi/linux/dma-heap.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ac2e518..a661e19 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4621,6 +4621,22 @@ F: include/linux/*fence.h
> F: Documentation/driver-api/dma-buf.rst
> T: git git://anongit.freedesktop.org/drm/drm-misc
>
> +DMA-BUF HEAPS FRAMEWORK
> +M: Laura Abbott
> +R: Liam Mark
> +R: Brian Starkey
> +R: "Andrew F. Davis"
> +R: John Stultz
> +S: Maintained
> +L: linux-me...@vger.kernel.org
> +L: dri-devel@lists.freedesktop.org
> +L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
> +F: include/uapi/linux/dma-heap.h
> +F: include/linux/dma-heap.h
> +F: drivers/dma-buf/dma-heap.c
> +F: drivers/dma-buf/heaps/*
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
> M: Vinod Koul
> L: dmaeng...@vger.kernel.org
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index 2e5a0fa..09c61db 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -39,4 +39,12 @@ config UDMABUF
> A driver to let userspace turn memfd regions into dma-bufs.
> Qemu can use this to create host dmabufs for guest framebuffers.
>
> +menuconfig DMABUF_HEAPS
> + bool "DMA-BUF Userland Memory Heaps"
> + select DMA_SHARED_BUFFER
> + help
> + Choose this option to enable the DMA-BUF userland memory heaps,
> + this allows userspace to allocate dma-bufs that can be shared
> between
> + drivers.
> +
> endmenu
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index 0913a6c..b0332f1 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1,4 +1,5 @@
> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
> +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
> obj-$(CONFIG_SYNC_FILE)+= sync_file.o
> obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
> obj-$(CONFIG_UDMABUF) += udmabuf.o
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> new file mode 100644
> index 000..14b3975
> --- /dev/null
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Framework for userspace DMA-BUF allocations
> + *
> + * Copyright (C) 2011 Google, Inc.
> + * Copyright (C) 2019 Linaro Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define DEVNAME "dma_heap"
> +
> +#define NUM_HEAP_MINORS 128
> +static DEFINE_IDR(dma_heap_idr);
> +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */
> +
> +dev_t dma_heap_devt;
> +struct class *dma_heap_class;
> +struct list_head dma_heap_list;
> +struct dentry *dma_heap_debug_root;
> +
> +static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> +unsigned int flags)
> +{
> + len = PAGE_ALIGN(len);
> + if (!len)
> +
Re: [RFC][PATCH 4/5 v2] dma-buf: heaps: Add CMA heap to dmabuf heapss
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>
> This adds a CMA heap, which allows userspace to allocate
> a dma-buf of contiguous memory out of a CMA region.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original author and maintainters:
> Benjamin Gaignard, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Greg KH
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Brian Starkey
> Cc: Andrew F. Davis
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> v2:
> * Switch allocate to return dmabuf fd
> * Simplify init code
> * Checkpatch fixups
> ---
> drivers/dma-buf/heaps/Kconfig| 8 ++
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/cma_heap.c | 164
> +++
> 3 files changed, 173 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/cma_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index 2050527..a5eef06 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
> help
> Choose this option to enable the system dmabuf heap. The system heap
> is backed by pages from the buddy allocator. If in doubt, say Y.
> +
> +config DMABUF_HEAPS_CMA
> + bool "DMA-BUF CMA Heap"
> + depends on DMABUF_HEAPS && DMA_CMA
> + help
> + Choose this option to enable dma-buf CMA heap. This heap is backed
> + by the Contiguous Memory Allocator (CMA). If your system has these
> + regions, you should say Y here.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index d1808ec..6e54cde 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-y += heap-helpers.o
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> new file mode 100644
> index 000..33c18ec
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -0,0 +1,164 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF CMA heap exporter
> + *
> + * Copyright (C) 2012, 2019 Linaro Ltd.
> + * Author: for ST-Ericsson.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "heap-helpers.h"
> +
> +struct cma_heap {
> + struct dma_heap heap;
> + struct cma *cma;
> +};
> +
> +
> +#define to_cma_heap(x) container_of(x, struct cma_heap, heap)
Even if I had write this macro years ago, now I would prefer to have a
static inline function
to be able to check the types.
with that:
Reviewed-by: Benjamin Gaignard
> +
> +
> +static void cma_heap_free(struct heap_helper_buffer *buffer)
> +{
> + struct cma_heap *cma_heap = to_cma_heap(buffer->heap_buffer.heap);
> + struct page *pages = buffer->priv_virt;
> + unsigned long nr_pages;
> +
> + nr_pages = PAGE_ALIGN(buffer->heap_buffer.size) >> PAGE_SHIFT;
> +
> + /* release memory */
> + cma_release(cma_heap->cma, pages, nr_pages);
> + /* release sg table */
> + sg_free_table(buffer->sg_table);
> + kfree(buffer->sg_table);
> + kfree(buffer);
> +}
> +
> +/* dmabuf heap CMA operations functions */
> +static int cma_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long flags)
> +{
> + struct cma_heap *cma_heap = to_cma_heap(heap);
> + struct heap_helper_buffer *helper_buffer;
> + struct sg_table *table;
> + struct page *pages;
> + size_t size = PAGE_ALIGN(len);
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> + unsigned long align = get_order(size);
> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct dma_buf *dmabuf;
> + int ret = -ENOMEM;
> +
> + if (align > CONFIG_CMA_ALIGNMENT)
> + align = CONFIG_CMA_ALIGNMENT;
> +
> + helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
> + if (!helper_buffer)
> + return -ENOMEM;
> +
> + INIT_HEAP_HELPER_BUFFER(helper_buffer, cma_heap_free);
> + helper_buffer->heap_buffer.flags = flags;
> + helper_buffer->heap_buffer.heap = heap;
> + helper_buffer->heap_buffer.size = len;
> +
> +
> + pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
> + if (!pages)
> + goto free_buf;
> +
> + if (PageHighMem(pages)) {
> + unsigned long nr_clear_pages = nr_pages;
> + struct page *page = pages;
> +
> + while (nr_clear_pages > 0) {
> + void *vaddr =
Re: [RFC][PATCH 3/5 v2] dma-buf: heaps: Add system heap to dmabuf heaps
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>
> This patch adds system heap to the dma-buf heaps framework.
>
> This allows applications to get a page-allocator backed dma-buf
> for non-contiguous memory.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original authors and maintainters:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Greg KH
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Brian Starkey
> Cc: Andrew F. Davis
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> v2:
> * Switch allocate to return dmabuf fd
> * Simplify init code
> * Checkpatch fixups
> * Droped dead system-contig code
just few blank lines to remove.
Reveiwed-by: Benjamin Gaignard
> ---
> drivers/dma-buf/Kconfig | 2 +
> drivers/dma-buf/heaps/Kconfig | 6 ++
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/system_heap.c | 132
>
> 4 files changed, 141 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/Kconfig
> create mode 100644 drivers/dma-buf/heaps/system_heap.c
>
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index 09c61db..63c139d 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -47,4 +47,6 @@ menuconfig DMABUF_HEAPS
> this allows userspace to allocate dma-bufs that can be shared
> between
> drivers.
>
> +source "drivers/dma-buf/heaps/Kconfig"
> +
> endmenu
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> new file mode 100644
> index 000..2050527
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -0,0 +1,6 @@
> +config DMABUF_HEAPS_SYSTEM
> + bool "DMA-BUF System Heap"
> + depends on DMABUF_HEAPS
> + help
> + Choose this option to enable the system dmabuf heap. The system heap
> + is backed by pages from the buddy allocator. If in doubt, say Y.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index de49898..d1808ec 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -1,2 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-y += heap-helpers.o
> +obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
> diff --git a/drivers/dma-buf/heaps/system_heap.c
> b/drivers/dma-buf/heaps/system_heap.c
> new file mode 100644
> index 000..e001661
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF System heap exporter
> + *
> + * Copyright (C) 2011 Google, Inc.
> + * Copyright (C) 2019 Linaro Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "heap-helpers.h"
> +
> +
remove blank line
> +struct system_heap {
> + struct dma_heap heap;
> +};
> +
> +
remove blank line
> +static void system_heap_free(struct heap_helper_buffer *buffer)
> +{
> + int i;
> + struct scatterlist *sg;
> + struct sg_table *table = buffer->sg_table;
> +
> + for_each_sg(table->sgl, sg, table->nents, i)
> + __free_page(sg_page(sg));
> +
> + sg_free_table(table);
> + kfree(table);
> + kfree(buffer);
> +}
> +
> +static int system_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long flags)
> +{
> + struct heap_helper_buffer *helper_buffer;
> + struct sg_table *table;
> + struct scatterlist *sg;
> + int i, j;
> + int npages = PAGE_ALIGN(len) / PAGE_SIZE;
> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct dma_buf *dmabuf;
> + int ret = -ENOMEM;
> +
> + helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
> + if (!helper_buffer)
> + return -ENOMEM;
> +
> + INIT_HEAP_HELPER_BUFFER(helper_buffer, system_heap_free);
> + helper_buffer->heap_buffer.flags = flags;
> + helper_buffer->heap_buffer.heap = heap;
> + helper_buffer->heap_buffer.size = len;
> +
> + table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> + if (!table)
> + goto err0;
> +
> + i = sg_alloc_table(table, npages, GFP_KERNEL);
> + if (i)
> + goto err1;
> + for_each_sg(table->sgl, sg, table->nents, i) {
> + struct page *page;
> +
> + page = alloc_page(GFP_KERNEL);
> + if (!page)
> + goto err2;
> + sg_set_page(sg, page, PAGE_SIZE, 0);
> + }
> +
> + /* create the dmabuf */
> + exp_info.ops = _helper_ops;
> + exp_info.size = len;
> + exp_info.flags = O_RDWR;
> + exp_info.priv = _buffer->heap_buffer;
[Bug 109887] vega56 undervolting/overclocking voltage issues
https://bugs.freedesktop.org/show_bug.cgi?id=109887 --- Comment #4 from kgkggl+bugs.freedesktop@gmail.com --- (In reply to fin4478 from comment #3) > You need to have a kernel command line parameter and c is used to commit > changes. See: https://wiki.archlinux.org/index.php/AMDGPU#Overclocking Yes, I use "c" to commit changes, the GPU frequency can always be modified, but the voltage does not take effect. I use parameters: # echo s 1 974 825 > /sys/class/drm/card0/device/pp_od_clk_voltage # echo s 2 1096 850 > /sys/class/drm/card0/device/pp_od_clk_voltage # echo s 3 1218 875 > /sys/class/drm/card0/device/pp_od_clk_voltage # echo s 4 1340 900 > /sys/class/drm/card0/device/pp_od_clk_voltage # echo s 5 1462 925 > /sys/class/drm/card0/device/pp_od_clk_voltage # echo s 6 1584 950 > /sys/class/drm/card0/device/pp_od_clk_voltage # echo s 7 1584 950 > /sys/class/drm/card0/device/pp_od_clk_voltage # echo c > /sys/class/drm/card0/device/pp_od_clk_voltage -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] tests/amdgpu: add deadlock test for sdma
On 3/6/19 1:37 AM, Cui, Flora wrote:
> deadlock test for sdma will cause gpu recoverty.
> disable the test for now until GPU reset recovery could survive at least
> 1000 times test.
Can you specify what issues you see and on what ASIC ?
Andrey
>
> v2: add modprobe parameter
>
> Change-Id: I9adac63c62db22107345eddb30e7d81a1bda838c
> Signed-off-by: Flora Cui
> ---
> tests/amdgpu/amdgpu_test.c| 4 ++
> tests/amdgpu/deadlock_tests.c | 103
> +-
> 2 files changed, 106 insertions(+), 1 deletion(-)
>
> diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
> index ebf4409..38b8a68 100644
> --- a/tests/amdgpu/amdgpu_test.c
> +++ b/tests/amdgpu/amdgpu_test.c
> @@ -426,6 +426,10 @@ static void amdgpu_disable_suites()
> "compute ring block test (set
> amdgpu.lockup_timeout=50)", CU_FALSE))
> fprintf(stderr, "test deactivation failed - %s\n",
> CU_get_error_msg());
>
> + if (amdgpu_set_test_active(DEADLOCK_TESTS_STR,
> + "sdma ring block test (set
> amdgpu.lockup_timeout=50)", CU_FALSE))
> + fprintf(stderr, "test deactivation failed - %s\n",
> CU_get_error_msg());
> +
> if (amdgpu_set_test_active(BO_TESTS_STR, "Metadata", CU_FALSE))
> fprintf(stderr, "test deactivation failed - %s\n",
> CU_get_error_msg());
>
> diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
> index a6c2635..91368c1 100644
> --- a/tests/amdgpu/deadlock_tests.c
> +++ b/tests/amdgpu/deadlock_tests.c
> @@ -96,6 +96,9 @@
>
> #define mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR
> 0x54f
>
> +#define SDMA_PKT_HEADER_OP(x)(x & 0xff)
> +#define SDMA_OP_POLL_REGMEM 8
> +
> static amdgpu_device_handle device_handle;
> static uint32_t major_version;
> static uint32_t minor_version;
> @@ -110,6 +113,7 @@ static void amdgpu_deadlock_gfx(void);
> static void amdgpu_deadlock_compute(void);
> static void amdgpu_illegal_reg_access();
> static void amdgpu_illegal_mem_access();
> +static void amdgpu_deadlock_sdma(void);
>
> CU_BOOL suite_deadlock_tests_enable(void)
> {
> @@ -171,6 +175,7 @@ int suite_deadlock_tests_clean(void)
> CU_TestInfo deadlock_tests[] = {
> { "gfx ring block test (set amdgpu.lockup_timeout=50)",
> amdgpu_deadlock_gfx },
> { "compute ring block test (set amdgpu.lockup_timeout=50)",
> amdgpu_deadlock_compute },
> + { "sdma ring block test (set amdgpu.lockup_timeout=50)",
> amdgpu_deadlock_sdma },
> { "illegal reg access test", amdgpu_illegal_reg_access },
> { "illegal mem access test (set amdgpu.vm_fault_stop=2)",
> amdgpu_illegal_mem_access },
> CU_TEST_INFO_NULL,
> @@ -260,7 +265,6 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
> ibs_request.ibs = _info;
> ibs_request.resources = bo_list;
> ibs_request.fence_info.handle = NULL;
> -
> for (i = 0; i < 200; i++) {
> r = amdgpu_cs_submit(context_handle, 0,_request, 1);
> CU_ASSERT_EQUAL((r == 0 || r == -ECANCELED), 1);
> @@ -291,6 +295,103 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
> CU_ASSERT_EQUAL(r, 0);
> }
>
> +static void amdgpu_deadlock_sdma(void)
> +{
> + amdgpu_context_handle context_handle;
> + amdgpu_bo_handle ib_result_handle;
> + void *ib_result_cpu;
> + uint64_t ib_result_mc_address;
> + struct amdgpu_cs_request ibs_request;
> + struct amdgpu_cs_ib_info ib_info;
> + struct amdgpu_cs_fence fence_status;
> + uint32_t expired;
> + int i, r;
> + amdgpu_bo_list_handle bo_list;
> + amdgpu_va_handle va_handle;
> + struct drm_amdgpu_info_hw_ip info;
> + uint32_t ring_id;
> +
> + r = amdgpu_query_hw_ip_info(device_handle, AMDGPU_HW_IP_DMA, 0, );
> + CU_ASSERT_EQUAL(r, 0);
> +
> + r = amdgpu_cs_ctx_create(device_handle, _handle);
> + CU_ASSERT_EQUAL(r, 0);
> +
> + for (ring_id = 0; (1 << ring_id) & info.available_rings; ring_id++) {
> + r = pthread_create(_thread, NULL, write_mem_address,
> NULL);
> + CU_ASSERT_EQUAL(r, 0);
> +
> + r = amdgpu_bo_alloc_and_map_raw(device_handle, 4096, 4096,
> + AMDGPU_GEM_DOMAIN_GTT, 0, use_uc_mtype ?
> AMDGPU_VM_MTYPE_UC : 0,
> + _result_handle,
> _result_cpu,
> +
> _result_mc_address, _handle);
> + CU_ASSERT_EQUAL(r, 0);
> +
> + r = amdgpu_get_bo_list(device_handle, ib_result_handle, NULL,
> +_list);
> + CU_ASSERT_EQUAL(r, 0);
> +
> + ptr = ib_result_cpu;
> + i = 0;
> +
> + ptr[i++] = SDMA_PKT_HEADER_OP(SDMA_OP_POLL_REGMEM) |
> + (0 << 26) | /* WAIT_REG_MEM */
> +
Re: [PATCH v2 0/5] drm/bridge: sii902x: HDMI-audio support and some fixes
Hi Jyri,
I also implemented HDMI audio support for sii902x to enable audio on a
STM32 board. As you submitted your patches first, I will align on it.
I had a first look at the current patch and I have some comments below.
I will review more in details and make some tests, asap.
I agree with Laurent and Andrzej regarding the missing audio connection
in DT. I would expect a subnode in DT describing the connection between
the HDMI codec and the CPU DAI.
Typically:
port@1 {
reg = <1>;
codec_endpoint: endpoint {
remote-endpoint = <_dai_endpoint>;
};
};
Then the hdmi codec get_dai_id callback can be implemented to check the
endpoint used for audio.
mclk and i2s-fifo-routing properties are defined as optional properties
in bindings.
However, these properties are required to initialize to the audio codec
in the code.
- master clock:
The i2s link of sii902x can be used without master clock. So the master
clock property has to be made actually optional. Probably, error code
-ENOENT should be checked on devm_clk_get() call, to ignore mclk if the
property is not defined.
- i2s-fifo-routing:
fifo mapping maybe set by default, according to i2s_fifo_defaults array
if the property is not set.
Best regards
Olivier
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Use 16bpp by default for the fbdev buffer
On Wed, 2019-03-06 at 15:02 +0100, Maxime Ripard wrote: > The preferred bpp for the fbdev emulation buffer has been 32 so far, which > means that by default we will allocate an 8MB buffer with a 1920x1080 > resolution. > > Worse this memory will be allocated from the CMA pool, and will never be > freed even if we don't use the fbdev emulation. Therefore, reducing it is a > big deal, and switching to 16bpp by default will gain us around 4MB at > 1920x1080, while keeping decent color depth. And users still have the > option to switch to 32bpp using the kernel command line. > > Signed-off-by: Maxime Ripard Reviewed-by: Paul Kocialkowski Cheers, Paul > --- > drivers/gpu/drm/vc4/vc4_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c > index 52576dee809e..c38cf64837e1 100644 > --- a/drivers/gpu/drm/vc4/vc4_drv.c > +++ b/drivers/gpu/drm/vc4/vc4_drv.c > @@ -286,7 +286,7 @@ static int vc4_drm_bind(struct device *dev) > > vc4_kms_load(drm); > > - drm_fbdev_generic_setup(drm, 32); > + drm_fbdev_generic_setup(drm, 16); > > return 0; > -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos/mixer: fix MIXER shadow registry synchronisation code
MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
to update internal state (shadow registers).
Apparently the driver implements it incorrectly. The rule should be
as follows:
- do not request updating registers until previous request was finished,
ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0.
- before setting registers synchronisation on VSYNC should be turned off,
ie. MXR_STATUS_SYNC_ENABLE should be reset,
- after finishing MXR_STATUS_SYNC_ENABLE should be set again.
The patch hopefully implements it correctly.
Below sample kernel log from page fault caused by the bug:
[ 25.670038] exynos-sysmmu 1465.sysmmu: 1445.mixer: PAGE FAULT
occurred at 0x2247b800
[ 25.677888] [ cut here ]
[ 25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
[ 25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 25.693778] Modules linked in:
[ 25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted
5.0.0-rc7-01157-g5f86b1566bdd #136
[ 25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264
[ 25.716470] LR is at lock_is_held_type+0x44/0x64
Reported-by: Marian Mihailescu
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 107 +++---
1 file changed, 63 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 0573eab0e190..42ce01c226ef 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -20,6 +20,7 @@
#include "regs-vp.h"
#include
+#include
#include
#include
#include
@@ -352,15 +353,59 @@ static void mixer_cfg_vp_blend(struct mixer_context *ctx,
unsigned int alpha)
mixer_reg_write(ctx, MXR_VIDEO_CFG, val);
}
-static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
+static bool mixer_is_synced(struct mixer_context *ctx)
{
- /* block update on vsync */
- mixer_reg_writemask(ctx, MXR_STATUS, enable ?
- MXR_STATUS_SYNC_ENABLE : 0, MXR_STATUS_SYNC_ENABLE);
+ u32 base, shadow;
+ if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
+ ctx->mxr_ver == MXR_VER_128_0_0_184)
+ return !(mixer_reg_read(ctx, MXR_CFG) &
+MXR_CFG_LAYER_UPDATE_COUNT_MASK);
+
+ if (test_bit(MXR_BIT_VP_ENABLED, >flags) &&
+ vp_reg_read(ctx, VP_SHADOW_UPDATE))
+ return false;
+
+ base = mixer_reg_read(ctx, MXR_CFG);
+ shadow = mixer_reg_read(ctx, MXR_CFG_S);
+ if (base != shadow)
+ return false;
+
+ base = mixer_reg_read(ctx, MXR_GRAPHIC_BASE(0));
+ shadow = mixer_reg_read(ctx, MXR_GRAPHIC_BASE_S(0));
+ if (base != shadow)
+ return false;
+
+ base = mixer_reg_read(ctx, MXR_GRAPHIC_BASE(1));
+ shadow = mixer_reg_read(ctx, MXR_GRAPHIC_BASE_S(1));
+ if (base != shadow)
+ return false;
+
+ return true;
+}
+
+static int mixer_wait_for_sync(struct mixer_context *ctx)
+{
+ ktime_t timeout = ktime_add_us(ktime_get(), 10);
+
+ while (!mixer_is_synced(ctx)) {
+ usleep_range(1000, 2000);
+ if (ktime_compare(ktime_get(), timeout) > 0)
+ return -ETIMEDOUT;
+ }
+ return 0;
+}
+
+static void mixer_disable_sync(struct mixer_context *ctx)
+{
+ mixer_reg_writemask(ctx, MXR_STATUS, 0, MXR_STATUS_SYNC_ENABLE);
+}
+
+static void mixer_enable_sync(struct mixer_context *ctx)
+{
+ mixer_reg_writemask(ctx, MXR_STATUS, ~0, MXR_STATUS_SYNC_ENABLE);
if (test_bit(MXR_BIT_VP_ENABLED, >flags))
- vp_reg_write(ctx, VP_SHADOW_UPDATE, enable ?
- VP_SHADOW_UPDATE_ENABLE : 0);
+ vp_reg_write(ctx, VP_SHADOW_UPDATE, VP_SHADOW_UPDATE_ENABLE);
}
static void mixer_cfg_scan(struct mixer_context *ctx, int width, int height)
@@ -498,7 +543,6 @@ static void vp_video_buffer(struct mixer_context *ctx,
spin_lock_irqsave(>reg_slock, flags);
- vp_reg_write(ctx, VP_SHADOW_UPDATE, 1);
/* interlace or progressive scan mode */
val = (test_bit(MXR_BIT_INTERLACE, >flags) ? ~0 : 0);
vp_reg_writemask(ctx, VP_MODE, val, VP_MODE_LINE_SKIP);
@@ -553,11 +597,6 @@ static void vp_video_buffer(struct mixer_context *ctx,
vp_regs_dump(ctx);
}
-static void mixer_layer_update(struct mixer_context *ctx)
-{
- mixer_reg_writemask(ctx, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
-}
-
static void mixer_graph_buffer(struct mixer_context *ctx,
struct exynos_drm_plane *plane)
{
@@ -640,11 +679,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
mixer_cfg_layer(ctx, win, priority, true);
mixer_cfg_gfx_blend(ctx, win, pixel_alpha, state->base.alpha);
- /* layer update mandatory for mixer 16.0.33.0 */
-
[Bug 109834] No x86 libraries in new amdgpu-pro drivers
https://bugs.freedesktop.org/show_bug.cgi?id=109834 --- Comment #1 from fin4...@hotmail.com --- AMD has open source drivers for gaming. Amdgpu-pro is for CAD software etc. Steam games are for Debian based distributions, see system requirements. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: randr: Virtual monitor not present with MST display
On 2019-03-06 1:41 p.m., Paul Menzel wrote: > On 03/05/19 20:07, Alex Deucher wrote: >> On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote: > >>> Using the MST display Dell UP3214Q (two panels) with an AMD system, >>> the virtual monitor object is not created. GDM and Xfce consider both >>> panels as separate screens (`xrandr --listmonitors`). >>> >>> [0.00] Linux version 4.20.13.mx64.248 >>> (r...@holidayincambodia.molgen.mpg.de) (gcc version 7.3.0 (GCC)) #1 SMP Wed >>> Feb 27 14:10:55 CET 2019 >>> >>> [ 79.494297] [drm] DM_MST: stopping TM on aconnector: a8109331 >>> [id: 56] >>> [ 79.494362] [drm] DM_MST: Disabling connector: 776ea22b [id: 63] >>> [master: a8109331] >>> [ 79.494406] [drm] DM_MST: Disabling connector: 057ebdbb [id: 67] >>> [master: a8109331] >>> [ 79.781882] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last >>> cmd=0x201f0500 >>> [ 86.028806] [drm] DM_MST: starting TM on aconnector: a8109331 >>> [id: 56] >>> [ 86.053072] [drm] DM_MST: added connector: 1c9b49ed [id: 71] >>> [master: a8109331] >>> [ 86.108540] [drm] SADs count is: -2, don't need to read it >>> [ 86.386661] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >>> create stream for sink! >>> [ 87.237878] [drm] DM_MST: added connector: c3ffcbbb [id: 80] >>> [master: a8109331] >>> [ 87.293028] [drm] SADs count is: -2, don't need to read it >>> [ 206.993344] [drm] DM_MST: stopping TM on aconnector: a8109331 >>> [id: 56] >>> [ 206.993423] [drm] DM_MST: Disabling connector: 1c9b49ed [id: 71] >>> [master: a8109331] >>> [ 206.993456] [drm] DM_MST: Disabling connector: c3ffcbbb [id: 80] >>> [master: a8109331] >>> [ 207.548051] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >>> create stream for sink! >>> [ 207.603193] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >>> create stream for sink! >>> [ 207.762388] traps: xfdesktop[2225] general protection fault >>> ip:7f588981226c sp:7ffee65af370 error:0 in >>> libgobject-2.0.so.0.5800.1[7f58897da000+56000] >>> [ 210.320612] [drm] DM_MST: starting TM on aconnector: b456cd59 >>> [id: 62] >>> [ 210.343497] [drm] DM_MST: added connector: 735839d5 [id: 73] >>> [master: b456cd59] >>> [ 210.399168] [drm] SADs count is: -2, don't need to read it >>> [ 210.404454] [drm] DM_MST: added connector: cccb0c2d [id: 88] >>> [master: b456cd59] >>> [ 210.675589] [drm] SADs count is: -2, don't need to read it > > I didn’t provide the output of xrandr in my previous message. > > $ xrandr --listmonitors > Monitors: 2 > 0: +DisplayPort-9 1920/698x2160/392+0+0 DisplayPort-9 > 1: +DisplayPort-10 1920/698x2160/392+1920+0 DisplayPort-10 > > Please find the X.Org X Server log attached. > >>> With an Intel system, the monitor object is shown. > > To clarify, the modesetting driver is used with the Intel hardware. Does this work better with the modesetting driver on the AMD system? -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109887] vega56 undervolting/overclocking voltage issues
https://bugs.freedesktop.org/show_bug.cgi?id=109887 --- Comment #3 from fin4...@hotmail.com --- You need to have a kernel command line parameter and c is used to commit changes. See: https://wiki.archlinux.org/index.php/AMDGPU#Overclocking -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/vkms: Add overlay plane support
On Tuesday, 2019-03-05 21:54:47 +0530, Mamta Shukla wrote:
> Add overlay plane support in vkms aligned with cursor and primary
> plane with module option 'enable_overlay' to enable/disable overlay
> plane while testing.
>
> This currently passes plane-position-covered-pipe-A-plane subtest
> from IGT kms_plane test.
>
> Signed-off-by: Mamta Shukla
> ---
> change in v2:
> -Fix warning: return makes pointer from integer without a cast using
> ERR_PTR
>
> drivers/gpu/drm/vkms/vkms_crc.c | 36 +++
> drivers/gpu/drm/vkms/vkms_drv.c | 4
> drivers/gpu/drm/vkms/vkms_drv.h | 8 +++
> drivers/gpu/drm/vkms/vkms_plane.c | 36 ++-
> 4 files changed, 79 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index 4dd6c155363d..ac3ed863cf34 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -109,6 +109,25 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> }
> }
>
> +static void compose_overlay(struct vkms_crc_data *overlay_crc,
> + struct vkms_crc_data *primary_crc, void *vaddr_out)
> {
> + struct drm_gem_object *overlay_obj;
> + struct vkms_gem_object *overlay_vkms_obj;
> +
> + overlay_obj = drm_gem_fb_get_obj(_crc->fb, 0);
> + overlay_vkms_obj = drm_gem_to_vkms_gem(overlay_obj);
> + mutex_lock(_vkms_obj->pages_lock);
> + if(!overlay_vkms_obj->vaddr){
> + DRM_WARN("overlay palne vaddr is NULL");
s/palne/plane/
> + goto out;
> + }
> +
> + blend(vaddr_out, overlay_vkms_obj->vaddr, primary_crc, overlay_crc);
> +
> +out:
> + mutex_unlock(_vkms_obj->pages_lock);
> +}
> +
> static void compose_cursor(struct vkms_crc_data *cursor_crc,
> struct vkms_crc_data *primary_crc, void *vaddr_out)
> {
> @@ -131,7 +150,8 @@ static void compose_cursor(struct vkms_crc_data
> *cursor_crc,
> }
>
> static uint32_t _vkms_get_crc(struct vkms_crc_data *primary_crc,
> - struct vkms_crc_data *cursor_crc)
> + struct vkms_crc_data *cursor_crc,
> + struct vkms_crc_data *overlay_crc)
> {
> struct drm_framebuffer *fb = _crc->fb;
> struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> @@ -154,6 +174,8 @@ static uint32_t _vkms_get_crc(struct vkms_crc_data
> *primary_crc,
> memcpy(vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
> mutex_unlock(_obj->pages_lock);
>
> + if (overlay_crc)
> + compose_overlay(overlay_crc, primary_crc, vaddr_out);
> if (cursor_crc)
> compose_cursor(cursor_crc, primary_crc, vaddr_out);
>
> @@ -184,6 +206,7 @@ void vkms_crc_work_handle(struct work_struct *work)
> output);
> struct vkms_crc_data *primary_crc = NULL;
> struct vkms_crc_data *cursor_crc = NULL;
> + struct vkms_crc_data *overlay_crc = NULL;
> struct drm_plane *plane;
> u32 crc32 = 0;
> u64 frame_start, frame_end;
> @@ -210,12 +233,17 @@ void vkms_crc_work_handle(struct work_struct *work)
>
> if (plane->type == DRM_PLANE_TYPE_PRIMARY)
> primary_crc = crc_data;
> - else
> +
> + if (plane->type == DRM_PLANE_TYPE_CURSOR)
> cursor_crc = crc_data;
> +
> + if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> + overlay_crc = crc_data;
Maybe turn that into a switch() ?
> }
>
> - if (primary_crc)
> - crc32 = _vkms_get_crc(primary_crc, cursor_crc);
> + if (primary_crc){
> + crc32 = _vkms_get_crc(primary_crc, cursor_crc, overlay_crc);
> + }
>
> frame_end = drm_crtc_accurate_vblank_count(crtc);
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 738dd6206d85..b08ad6f95675 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -29,6 +29,10 @@ bool enable_cursor;
> module_param_named(enable_cursor, enable_cursor, bool, 0444);
> MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>
> +bool enable_overlay;
> +module_param_named(enable_overlay, enable_overlay, bool, 0444);
> +MODULE_PARM_DESC(enable_overlay, "Enable/Disable overlay support");
> +
> static const struct file_operations vkms_driver_fops = {
> .owner = THIS_MODULE,
> .open = drm_open,
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 81f1cfbeb936..81dceadfde62 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -20,6 +20,8 @@
>
> extern bool enable_cursor;
>
> +extern bool enable_overlay;
> +
> static const u32 vkms_formats[] = {
> DRM_FORMAT_XRGB,
> };
> @@ -28,6 +30,10 @@ static const u32
Re: [PATCH v5 07/19] media: vsp1: dl: Support one-shot entries in the display list
On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> > On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> > > On Fri, Feb 22, 2019 at 02:30:03PM +, Brian Starkey wrote:
> > >> On Thu, Feb 21, 2019 at 12:32:00PM +0200, Laurent Pinchart wrote:
> > >>> One-shot entries are used as an alternative to committing a complete new
> > >>> display list when a couple of registers need to be written for one frame
> > >>> and then reset to another value for all subsequent frames. This will be
> > >>> used to implement writeback support that will need to enable writeback
> > >>> for the duration of a single frame.
> > >>>
> > >>> Signed-off-by: Laurent Pinchart
> > >>>
> > >>> ---
> > >>> drivers/media/platform/vsp1/vsp1_dl.c | 78 +++
> > >>> drivers/media/platform/vsp1/vsp1_dl.h | 3 ++
> > >>> 2 files changed, 81 insertions(+)
> > >>>
> > >>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> b/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> index 886b3a69d329..7b4d252bfde7 100644
> > >>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> @@ -115,6 +115,12 @@ struct vsp1_dl_body {
> > >>>
> > >>> unsigned int num_entries;
> > >>> unsigned int max_entries;
> > >>> +
> > >>> + unsigned int num_patches;
> > >>> + struct {
> > >>> + struct vsp1_dl_entry *entry;
> > >>> + u32 data;
> > >>> + } patches[2];
> > >>> };
> > >>>
> > >>> /**
> > >>> @@ -361,6 +367,7 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
> > >>> return;
> > >>>
> > >>> dlb->num_entries = 0;
> > >>> + dlb->num_patches = 0;
> > >>>
> > >>> spin_lock_irqsave(>pool->lock, flags);
> > >>> list_add_tail(>free, >pool->free);
> > >>> @@ -388,6 +395,47 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb,
> > >>> u32 reg, u32 data)
> > >>> dlb->num_entries++;
> > >>> }
> > >>>
> > >>> +/**
> > >>> + * vsp1_dl_body_write_oneshot - Write a register to a display list
> > >>> body for a
> > >>> + * single frame
> > >>> + * @dlb: The body
> > >>> + * @reg: The register address
> > >>> + * @value: The register value
> > >>> + * @reset_value: The value to reset the register to at the next vblank
> > >>> + *
> > >>> + * Display lists in continuous mode are re-used by the hardware for
> > >>> successive
> > >>> + * frames until a new display list is committed. Changing the VSP
> > >>> configuration
> > >>> + * normally requires creating and committing a new display list. This
> > >>> function
> > >>> + * offers an alternative race-free way by writing a @value to the
> > >>> @register in
> > >>> + * the display list body for a single frame, specifying in
> > >>> @reset_value the
> > >>> + * value to reset the register to one vblank after the display list is
> > >>> + * committed.
> > >>> + *
> > >>> + * The maximum number of one-shot entries is limited to 2 per display
> > >>> list body,
> > >>> + * and one-shot entries are counted in the total number of entries
> > >>> specified
> > >>> + * when the body is allocated by vsp1_dl_body_alloc().
> > >>> + */
> > >>> +void vsp1_dl_body_write_oneshot(struct vsp1_dl_body *dlb, u32 reg, u32
> > >>> value,
> > >>> + u32 reset_value)
> > >>> +{
> > >>> + if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
> > >>> + "DLB size exceeded (max %u)", dlb->max_entries))
> > >>> + return;
> > >>> +
> > >>> + if (WARN_ONCE(dlb->num_patches >= ARRAY_SIZE(dlb->patches),
> > >>> + "DLB patches size exceeded (max %zu)",
> > >>> + ARRAY_SIZE(dlb->patches)))
> > >>> + return;
> > >>> +
> > >>> + dlb->patches[dlb->num_patches].entry =
> > >>> >entries[dlb->num_entries];
> > >>> + dlb->patches[dlb->num_patches].data = reset_value;
> > >>> + dlb->num_patches++;
> > >>> +
> > >>> + dlb->entries[dlb->num_entries].addr = reg;
> > >>> + dlb->entries[dlb->num_entries].data = value;
> > >>> + dlb->num_entries++;
> > >>> +}
> > >>> +
> > >>> /*
> > >>> -
> > >>> * Display List Extended Command Management
> > >>> */
> > >>> @@ -652,6 +700,7 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list
> > >>> *dl)
> > >>> * has at least one body, thus we reinitialise the entries list.
> > >>> */
> > >>> dl->body0->num_entries = 0;
> > >>> + dl->body0->num_patches = 0;
> > >>>
> > >>> list_add_tail(>list, >dlm->free);
> > >>> }
> > >>> @@ -930,6 +979,35 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl,
> > >>> unsigned int dl_flags)
> > >>> * Display List Manager
> > >>> */
> > >>>
> > >>> +/**
> > >>> + *
Re: [PATCH v5 0/3] drm/vc4: Add a load tracker
On Wed, Feb 20, 2019 at 09:56:39AM -0800, Eric Anholt wrote: > Paul Kocialkowski writes: > > > Hi, > > > > Here is a fourth iteration of the VC4 load tracking series, which was > > initially developed by Boris Brezillon and that I have now taken over. > > > > This new iteration takes in account comments from v3 and comes with a > > new approach for avoiding underrun reports when reconfiguring the > > pipeline. It is now based on detection instead of delaying the underrun > > interrupt unmasking. > > > > It can be tested with a dedicated IGT GPU Tools series: > > VC4 load tracker testing > > Series is: > > Reviewed-by: Eric Anholt > > Thanks for persisting on this! Applied all three patches to drm-misc-next. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [v2] gpu: host1x: avoid IOMMU_API build error
On 6.3.2019 15.57, Arnd Bergmann wrote:
When the iommu API is disabled, the host1x driver fails to build:
drivers/gpu/host1x/hw/channel_hw.c: In function 'host1x_channel_set_streamid':
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit declaration of
function 'dev_iommu_fwspec_get'; did you mean 'iommu_fwspec_free'?
[-Werror=implicit-function-declaration]
struct iommu_fwspec *spec = dev_iommu_fwspec_get(channel->dev->parent);
^~~~
iommu_fwspec_free
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: initialization of 'struct
iommu_fwspec *' from 'int' makes pointer from integer without a cast
[-Werror=int-conversion]
drivers/gpu/host1x/hw/channel_hw.c:119:23: error: 'struct iommu_fwspec' has no
member named 'ids'
u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
^~
cc1: all warnings being treated as errors
As Mikko explains, we should program SMMU bypass (0x7f) if that
happens.
Fixes: de5469c21ff9 ("gpu: host1x: Program the channel stream ID")
Suggested-by: Mikko Perttunen
Signed-off-by: Arnd Bergmann
v2: fall back to 0x7f sid
---
drivers/gpu/host1x/hw/channel_hw.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/hw/channel_hw.c
b/drivers/gpu/host1x/hw/channel_hw.c
index 27101c04a827..0c0eb43abf65 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -115,8 +115,12 @@ static inline void synchronize_syncpt_base(struct
host1x_job *job)
static void host1x_channel_set_streamid(struct host1x_channel *channel)
{
#if HOST1X_HW >= 6
+ u32 sid = 0x7f;
+#ifdef CONFIG_IOMMU_API
struct iommu_fwspec *spec = dev_iommu_fwspec_get(channel->dev->parent);
- u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
+ if (spec)
+ sid = spec->ids[0] & 0x;
+#endif
host1x_ch_writel(channel, sid, HOST1X_CHANNEL_SMMU_STREAMID);
#endif
Reviewed-by: Mikko Perttunen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Use 16bpp by default for the fbdev buffer
The preferred bpp for the fbdev emulation buffer has been 32 so far, which means that by default we will allocate an 8MB buffer with a 1920x1080 resolution. Worse this memory will be allocated from the CMA pool, and will never be freed even if we don't use the fbdev emulation. Therefore, reducing it is a big deal, and switching to 16bpp by default will gain us around 4MB at 1920x1080, while keeping decent color depth. And users still have the option to switch to 32bpp using the kernel command line. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 52576dee809e..c38cf64837e1 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -286,7 +286,7 @@ static int vc4_drm_bind(struct device *dev) vc4_kms_load(drm); - drm_fbdev_generic_setup(drm, 32); + drm_fbdev_generic_setup(drm, 16); return 0; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [v2] gpu: host1x: avoid IOMMU_API build error
When the iommu API is disabled, the host1x driver fails to build:
drivers/gpu/host1x/hw/channel_hw.c: In function 'host1x_channel_set_streamid':
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit declaration of
function 'dev_iommu_fwspec_get'; did you mean 'iommu_fwspec_free'?
[-Werror=implicit-function-declaration]
struct iommu_fwspec *spec = dev_iommu_fwspec_get(channel->dev->parent);
^~~~
iommu_fwspec_free
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: initialization of 'struct
iommu_fwspec *' from 'int' makes pointer from integer without a cast
[-Werror=int-conversion]
drivers/gpu/host1x/hw/channel_hw.c:119:23: error: 'struct iommu_fwspec' has no
member named 'ids'
u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
^~
cc1: all warnings being treated as errors
As Mikko explains, we should program SMMU bypass (0x7f) if that
happens.
Fixes: de5469c21ff9 ("gpu: host1x: Program the channel stream ID")
Suggested-by: Mikko Perttunen
Signed-off-by: Arnd Bergmann
v2: fall back to 0x7f sid
---
drivers/gpu/host1x/hw/channel_hw.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/hw/channel_hw.c
b/drivers/gpu/host1x/hw/channel_hw.c
index 27101c04a827..0c0eb43abf65 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -115,8 +115,12 @@ static inline void synchronize_syncpt_base(struct
host1x_job *job)
static void host1x_channel_set_streamid(struct host1x_channel *channel)
{
#if HOST1X_HW >= 6
+ u32 sid = 0x7f;
+#ifdef CONFIG_IOMMU_API
struct iommu_fwspec *spec = dev_iommu_fwspec_get(channel->dev->parent);
- u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
+ if (spec)
+ sid = spec->ids[0] & 0x;
+#endif
host1x_ch_writel(channel, sid, HOST1X_CHANNEL_SMMU_STREAMID);
#endif
--
2.20.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] phy: Add driver for mixel dphy found on imx8
Hi, On Fri, Feb 08, 2019 at 11:55:41AM +, Robert Chiras wrote: > Hi Guido > > On Vi, 2019-02-08 at 12:40 +0100, Guido Günther wrote: > > Hi Robert, > > On Wed, Feb 06, 2019 at 03:28:07PM +, Robert Chiras wrote: > > > > > > Hi Guido, > > > > > > Thanks for picking this up. It's interesting to see that a lot has > > > changed in the PHY API and the phy can be now configured through > > > the > > > API instead of exported function as I did in the NXP tree. > > > > > > I was going through your implementation and I noticed you also > > > added > > > the phy_ref clock to this driver too. This is good, since the DPHY > > > needs this clock, but I have a question related to the other > > > clocks: > > > According to the Northwest Logic reference manual (the DSI host > > > that > > > uses this DPHY), the host relies on the TX clock in order to > > > configure > > > the DPHY. Is this driver relying on it's user to also enable the TX > > > clock? > > Yes, I think that would be best. In fact due to lack of reference > > manuals for nwl and mixel I didn't even know exactly which clocks > > needed > > to be on already so I currently set for enabling this after the nwl > > clocks. Are these manuals available publicly somewhere, I couldn't > > find > > them? > > That's OK, I guess. Regarding the manuals: we have them from the vendor > so I can't share them. Too bad. Any contact I could ping there would also be nice? > > > > > > > > > Also: did you test this driver? Because I have a version of the > > > patches > > > from NXP tree rebased on top of latest linux-next and I have a > > > working > > Hmm...could you (maybe off list) send the boot output with DEBUG 1 > > at the top of the driver and drm.debug=0x2f on the kernel command > > line? > > Maybe I can spot something. > > Eventually I got it working. On i.MX8MQ there is a System Reset > Controller that controls the clocks on each individual block. For some > reason, before asserting the MIPI clock domain in this SRC, a delay is > needed (right now, the hack is a sleep). Probably there is a component > that is not ready yet. Right now I am trying to figure out which one is > it and how can I wait for it. > > > > > > > > > version of eLCDIF with Raydium RM67191 DSI panel on mScale850D > > > (i.MX8MQ). And I tried using this driver but there is no signal on > > > the > > > screen, even through the register values are all identical. Next, > > > I'll > > > try to debug why isn't this working on my setup. > > I'm testing this on the Librem 5 devkit with a rockchip panel atm > > using > > DCSS not eLCDIF though. My plan is to move to the NXP evk in the not > > so > > far future to make this easier to reproduce. > > Good to know. Currently I am working on the eLCDIF pipeline on 850D to > make it ready for upstream. Since you took my DPHY driver and submitted > upstream in a better shape, I will make use of it. Cool. I have an initial version of nwl mostly in shape now too (hope to send it out in a couple of days). eLCDIF will be handy to test the whole stack on 5.x. Cheers, -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109921] [CI][Runner] Do not mistake KERN_NOTICE for a WARNING
https://bugs.freedesktop.org/show_bug.cgi?id=109921 Martin Peres changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |arkadiusz.hi...@intel.com |.org| --- Comment #1 from Martin Peres --- Assigning Arek, as he already started working on this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109921] [CI][Runner] Do not mistake KERN_NOTICE for a WARNING
https://bugs.freedesktop.org/show_bug.cgi?id=109921 Bug ID: 109921 Summary: [CI][Runner] Do not mistake KERN_NOTICE for a WARNING Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: martin.pe...@free.fr Original bug: https://bugs.freedesktop.org/show_bug.cgi?id=107956 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [TWO BUGs] etnaviv crashes overnight
Hi Russell,
Am Mittwoch, den 06.03.2019, 13:20 + schrieb Russell King - ARM Linux admin:
> On Tue, Feb 26, 2019 at 11:02:48AM +0100, Lucas Stach wrote:
> > Hi Russell,
> >
> > Am Dienstag, den 26.02.2019, 09:24 + schrieb Russell King - ARM Linux
> > admin:
> > > I'm not sure when this happened, only that it happened sometime
> > > overnight. It was left running an Xfce desktop having only logged in,
> > > but with the monitor disconnected. Fedora 23 plus xf86-video-armada.
> > >
> > > I don't have any more information than that and the kernel messages
> > > below.
> >
> > Thanks for the report! Both of those issues are caused by the GPU
> > scheduler failing to put the scheduler fence callback execution into a
> > work item, like it normally does, in the dying sched_entity cleanup.
> > This causes multiple code paths which expect to be called from a clean
> > process context to be called from the same IRQ context with a number of
> > locks potentially already held.
> >
> > It will take me some time to work through the corners of this code, but
> > I should have a patch fixing this later today.
>
> Hi Lucas,
>
> Did you get a chance to patch this bug?
I have the following patch, but it didn't get close to the amount of
testing required for such a change yet. Maybe you can run it and see if
something falls out?
Regards,
Lucas
>8-
From badd5fa28e2e9369bcd765f110bc6b8756207bcf Mon Sep 17 00:00:00 2001
From: Lucas Stach
Date: Wed, 27 Feb 2019 18:11:48 +0100
Subject: [PATCH] drm/scheduler: put killed job cleanup to worker
drm_sched_entity_kill_jobs_cb() is called right from the last scheduled
job finished fence signaling. As this might happen from IRQ context we
now end up calling the GPU driver free_job callback in IRQ context, while
all other paths call it from normal process context.
Etnaviv in particular calls core kernel functions that are only valid to
be called from process context when freeing the job. Other drivers might
have similar issues, but I did not validate this. Fix this by punting
the cleanup work into a work item, so the driver expectations are met.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/scheduler/sched_entity.c | 30 ++--
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 3e22a54a99c2..dde875c6ca50 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -188,19 +188,10 @@ long drm_sched_entity_flush(struct drm_sched_entity
*entity, long timeout)
}
EXPORT_SYMBOL(drm_sched_entity_flush);
-/**
- * drm_sched_entity_kill_jobs - helper for drm_sched_entity_kill_jobs
- *
- * @f: signaled fence
- * @cb: our callback structure
- *
- * Signal the scheduler finished fence when the entity in question is killed.
- */
-static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
- struct dma_fence_cb *cb)
+static void drm_sched_entity_kill_work(struct work_struct *work)
{
- struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
-finish_cb);
+ struct drm_sched_job *job = container_of(work, struct drm_sched_job,
+finish_work);
drm_sched_fence_finished(job->s_fence);
WARN_ON(job->s_fence->parent);
@@ -208,6 +199,15 @@ static void drm_sched_entity_kill_jobs_cb(struct dma_fence
*f,
job->sched->ops->free_job(job);
}
+static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
+ struct dma_fence_cb *cb)
+{
+ struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
+finish_cb);
+
+ schedule_work(>finish_work);
+}
+
/**
* drm_sched_entity_kill_jobs - Make sure all remaining jobs are killed
*
@@ -227,6 +227,12 @@ static void drm_sched_entity_kill_jobs(struct
drm_sched_entity *entity)
drm_sched_fence_scheduled(s_fence);
dma_fence_set_error(_fence->finished, -ESRCH);
+ /*
+* Replace regular finish work function with one that just
+* kills the job.
+*/
+ job->finish_work.func = drm_sched_entity_kill_work;
+
/*
* When pipe is hanged by older entity, new entity might
* not even have chance to submit it's first job to HW
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Support panels connected directly to the DPAD outputs
Hi Laurent!
On Wed, Mar 06, 2019 at 03:13:55PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Wed, Mar 06, 2019 at 11:03:32AM +0100, Jacopo Mondi wrote:
> > On Sat, Mar 02, 2019 at 06:17:25PM +0200, Laurent Pinchart wrote:
> > > The R-Car DU driver assumes that a bridge is always connected to the DU
> > > output. This is valid for the LVDS and HDMI outputs, but the DPAD
> > > outputs can be connected directly to a panel, in which case no bridge is
> > > available.
> > >
> > > To support this use case, detect whether the entities connected to the
> > > DU DPAD outputs are encoders or panels based on the number of ports of
> > > their DT node, and retrieve the corresponding type of DRM objects. For
> > > panels, additionally create panel bridge instances.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 ---
> > > 1 file changed, 48 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > > index 8ee4e762f4e5..595ecfa1ff0e 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > > @@ -28,13 +28,33 @@ static const struct drm_encoder_funcs encoder_funcs =
> > > {
> > > .destroy = drm_encoder_cleanup,
> > > };
> > >
> > > +static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
> > > +{
> > > + struct device_node *ports;
> > > + struct device_node *port;
> > > + unsigned int num_ports = 0;
> > > +
> > > + ports = of_get_child_by_name(node, "ports");
> > > + if (!ports)
> > > + ports = of_node_get(node);
> > > +
> > > + for_each_child_of_node(ports, port) {
> > > + if (of_node_name_eq(port, "port"))
> > > + num_ports++;
> > > + }
> > > +
> > > + of_node_put(node);
> > > +
> > > + return num_ports;
> > > +}
> > > +
> > > int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > >enum rcar_du_output output,
> > >struct device_node *enc_node)
> > > {
> >
> > You received a Tested-by, so I might surely be mistaken, but the
> > caller of this function skips all remote nodes with a single port,
> > doesn't it?
> > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/rcar-du/rcar_du_kms.c#L308
> >
> > I don't have any DTS with a panel connected to the DPAD output so, as
> > a test, I removed all endpoints except endpoint@0 from the 'hdmi0' device
> > node, and the 'rcar_du_encoder_init()' function never gets called and DU
> > probing fails with:
> > rcar-du feb0.display: no encoder found for endpoint
> > /soc/display@feb0/ports/port@1/endpoint, skipping
> >
> > What am I missing?
>
> You're missing drm-next :-)
>
> https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/rcar-du/rcar_du_kms.c#n331
Oh, I see!
Thanks, with this clarified, please add
Reviewed-by: Jacopo Mondi
Thanks
j
>
> > > struct rcar_du_encoder *renc;
> > > struct drm_encoder *encoder;
> > > - struct drm_bridge *bridge = NULL;
> > > + struct drm_bridge *bridge;
> > > int ret;
> > >
> > > renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> > > @@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > > dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> > > enc_node, output);
> > >
> > > - /* Locate the DRM bridge from the encoder DT node. */
> > > - bridge = of_drm_find_bridge(enc_node);
> > > - if (!bridge) {
> > > - ret = -EPROBE_DEFER;
> > > - goto done;
> > > + /*
> > > + * Locate the DRM bridge from the DT node. For the DPAD outputs, if the
> > > + * DT node has a single port, consider it describes a panel and create a
> > > + * panel bridge.
> > > + */
> > > + if ((output == RCAR_DU_OUTPUT_DPAD0 ||
> > > + output == RCAR_DU_OUTPUT_DPAD1) &&
> > > + rcar_du_encoder_count_ports(enc_node) == 1) {
> >
> > Could this be cached?
>
> How so ? This function is run once per enc_node, so the cache wouldn't
> be used again, would it ?
>
> > > + struct drm_panel *panel = of_drm_find_panel(enc_node);
> > > +
> > > + if (IS_ERR(panel)) {
> > > + ret = PTR_ERR(panel);
> > > + goto done;
> > > + }
> > > +
> > > + bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
> > > +DRM_MODE_CONNECTOR_DPI);
> > > + if (IS_ERR(bridge)) {
> > > + ret = PTR_ERR(bridge);
> > > + goto done;
> > > + }
> > > + } else {
> > > + bridge = of_drm_find_bridge(enc_node);
> > > + if (!bridge) {
> > > + ret = -EPROBE_DEFER;
> > > + goto done;
> > > + }
> > > }
> > >
> > > ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
>
> --
> Regards,
>
> Laurent Pinchart
signature.asc
Description: PGP signature
Re: [PATCH 2/7] drm/edid: Allow to ignore the audio EDID data
On Tue, Mar 05, 2019 at 01:47:38PM -0800, Eric Anholt wrote: > Maxime Ripard writes: > > > [ Unknown signature status ] > > On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote: > >> On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote: > >> > > >> > Maxime Ripard writes: > >> > > >> > > In some cases, in order to accomodate with displays with poor EDIDs, we > >> > > need to ignore that the monitor alledgedly supports audio output and > >> > > disable the audio output. > >> > > > >> > > Signed-off-by: Maxime Ripard > >> > > --- > >> > > drivers/gpu/drm/drm_edid.c | 8 > >> > > 1 file changed, 8 insertions(+) > >> > > > >> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > >> > > index 990b1909f9d7..c0258b011bb2 100644 > >> > > --- a/drivers/gpu/drm/drm_edid.c > >> > > +++ b/drivers/gpu/drm/drm_edid.c > >> > > @@ -4190,6 +4190,11 @@ bool drm_detect_hdmi_monitor(struct edid *edid) > >> > > } > >> > > EXPORT_SYMBOL(drm_detect_hdmi_monitor); > >> > > > >> > > +static bool ignore_edid_audio = false; > >> > > +module_param(ignore_edid_audio, bool, 0644); > >> > > +MODULE_PARM_DESC(ignore_edid_audio, > >> > > + "Ignore the EDID and always consider that a monitor > >> > > doesn't have audio capabilities"); > >> > > + > >> > > /** > >> > > * drm_detect_monitor_audio - check monitor audio capability > >> > > * @edid: EDID block to scan > >> > > @@ -4209,6 +4214,9 @@ bool drm_detect_monitor_audio(struct edid *edid) > >> > > bool has_audio = false; > >> > > int start_offset, end_offset; > >> > > > >> > > + if (ignore_edid_audio) > >> > > + goto end; > >> > > + > >> > > edid_ext = drm_find_cea_extension(edid); > >> > > if (!edid_ext) > >> > > goto end; > >> > > >> > It looks like the motivation for the original flag on Raspberry Pi was > >> > "I've got a non-audio monitor, but the system comes up trying to play > >> > audio to HDMI instead of the analog jack". Do we have some way for DRM > >> > to communicate to ALSA that this is not the right place to try to play > >> > audio by default? > >> > >> Apparently not. We have users using debug knobs in our drivers to > >> disable display audio because ALSA defaults to that rather than other > >> audio. > > > > I guess one way to do this would be to register the card only when an > > audio-capable monitor is connected instead of doing this at probe > > time. I'm not sure how convenient it is for userspace though. > > Oh, right, the HDMI encoder passes the ELD to ALSA, and userspace gets > to use that. So, open source is already doing the right thing, and the > problem was that the old driver talking to the firmware wouldn't, thus > the need for a flag. I started to look into this, and while on my laptop, the ELD seems to be exposed as part of /proc/asound/card0/eld*, there's no such file on the RPi with a 5.0 kernel (and an HDMI monitor with audio support, obviously). Is it something that used to work at some point? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [TWO BUGs] etnaviv crashes overnight
On Tue, Feb 26, 2019 at 11:02:48AM +0100, Lucas Stach wrote:
> Hi Russell,
>
> Am Dienstag, den 26.02.2019, 09:24 + schrieb Russell King - ARM Linux
> admin:
> > I'm not sure when this happened, only that it happened sometime
> > overnight. It was left running an Xfce desktop having only logged in,
> > but with the monitor disconnected. Fedora 23 plus xf86-video-armada.
> >
> > I don't have any more information than that and the kernel messages
> > below.
>
> Thanks for the report! Both of those issues are caused by the GPU
> scheduler failing to put the scheduler fence callback execution into a
> work item, like it normally does, in the dying sched_entity cleanup.
> This causes multiple code paths which expect to be called from a clean
> process context to be called from the same IRQ context with a number of
> locks potentially already held.
>
> It will take me some time to work through the corners of this code, but
> I should have a patch fixing this later today.
Hi Lucas,
Did you get a chance to patch this bug?
Thanks.
>
> Regards,
> Lucas
>
> > [51328.909729]
> > [51328.915044] WARNING: possible recursive locking detected
> > [51328.920361] 4.20.0+ #307 Not tainted
> > [51328.923939]
> > [51328.929254] Xorg/5379 is trying to acquire lock:
> > [51328.933874] cd12d5e4 (&(>lock)->rlock){-.-.}, at:
> > dma_fence_signal+0x9c/0x1d4
> > [51328.941638]
> > [51328.941638] but task is already holding lock:
> > [51328.947474] cd12d6a4 (&(>lock)->rlock){-.-.}, at:
> > dma_fence_signal+0x9c/0x1d4
> > [51328.955226]
> > [51328.955226] other info that might help us debug this:
> > [51328.961756] Possible unsafe locking scenario:
> > [51328.961756]
> > [51328.967678]CPU0
> > [51328.970127]
> > [51328.976761] lock(&(>lock)->rlock);
> > [51328.980948]
> > [51328.980948] *** DEADLOCK ***
> > [51328.980948]
> > [51328.986871] May be due to missing lock nesting notation
> > [51328.986871]
> > [51328.993663] 4 locks held by Xorg/5379:
> > [51328.997414] #0: d8c6bdd0 (reservation_ww_class_acquire){+.+.}, at:
> > drm_ioctl_kernel+0x90/0xc8
> > [51329.006040] #1: d879e2ac (>lock){+.+.}, at:
> > etnaviv_cmdbuf_init+0x5c/0x16c [etnaviv]
> > [51329.014784] #2: d900dd88 (&(>fence_spinlock)->rlock){-.-.}, at:
> > dma_fence_signal+0x9c/0x1d4
> > [51329.023668] #3: cd12d6a4 (&(>lock)->rlock){-.-.}, at:
> > dma_fence_signal+0x9c/0x1d4
> > [51329.031854]
> > [51329.031854] stack backtrace:
> > [51329.036218] CPU: 0 PID: 5379 Comm: Xorg Not tainted 4.20.0+ #307
> > [51329.042227] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > [51329.048772] [] (unwind_backtrace) from []
> > (show_stack+0x10/0x14)
> > [51329.056527] [] (show_stack) from []
> > (dump_stack+0x9c/0xd4)
> > [51329.063763] [] (dump_stack) from []
> > (__lock_acquire+0x1270/0x19b8)
> > [51329.071689] [] (__lock_acquire) from []
> > (lock_acquire+0xc4/0x1dc)
> > [51329.079529] [] (lock_acquire) from []
> > (_raw_spin_lock_irqsave+0x44/0x58)
> > [51329.087975] [] (_raw_spin_lock_irqsave) from []
> > (dma_fence_signal+0x9c/0x1d4)
> > [51329.096872] [] (dma_fence_signal) from []
> > (drm_sched_entity_kill_jobs_cb+0x14/0x78 [gpu_sched])
> > [51329.107327] [] (drm_sched_entity_kill_jobs_cb [gpu_sched])
> > from [] (dma_fence_signal+0xe0/0x1d4)
> > [51329.117866] [] (dma_fence_signal) from []
> > (drm_sched_process_job+0x60/0x1a4 [gpu_sched])
> > [51329.127710] [] (drm_sched_process_job [gpu_sched]) from
> > [] (dma_fence_signal+0xe0/0x1d4)
> > [51329.137569] [] (dma_fence_signal) from []
> > (irq_handler+0xc8/0x1d8 [etnaviv])
> > [51329.146389] [] (irq_handler [etnaviv]) from []
> > (__handle_irq_event_percpu+0x98/0x378)
> > [51329.155966] [] (__handle_irq_event_percpu) from []
> > (handle_irq_event_percpu+0x1c/0x58)
> > [51329.165629] [] (handle_irq_event_percpu) from []
> > (handle_irq_event+0x38/0x5c)
> > [51329.174511] [] (handle_irq_event) from []
> > (handle_fasteoi_irq+0x94/0x124)
> > [51329.183044] [] (handle_fasteoi_irq) from []
> > (generic_handle_irq+0x18/0x28)
> > [51329.191665] [] (generic_handle_irq) from []
> > (__handle_domain_irq+0x54/0xb0)
> > [51329.200374] [] (__handle_domain_irq) from []
> > (gic_handle_irq+0x48/0x98)
> > [51329.208735] [] (gic_handle_irq) from []
> > (__irq_svc+0x70/0x98)
> > [51329.216221] Exception stack(0xd8c6bc28 to 0xd8c6bc70)
> > [51329.221279] bc20: 0001 0011 d8c6bc78 c2005940
> > d879e2ac
> > [51329.229462] bc40: c0c2c580 600b0013 c0b98568
> > c13bb508 d8c6bc78
> > [51329.237643] bc60: c0085804 c0087860 800b0013
> > [51329.242704] [] (__irq_svc) from []
> > (lock_acquire+0xdc/0x1dc)
> > [51329.250111] [] (lock_acquire) from []
> > (__mutex_lock+0x50/0x8b8)
> > [51329.25] [] (__mutex_lock) from []
> > (mutex_lock_nested+0x1c/0x24)
> > [51329.265812] [] (mutex_lock_nested) from []
>
Re: [PATCH] drm: rcar-du: Support panels connected directly to the DPAD outputs
Hi Jacopo,
On Wed, Mar 06, 2019 at 11:03:32AM +0100, Jacopo Mondi wrote:
> On Sat, Mar 02, 2019 at 06:17:25PM +0200, Laurent Pinchart wrote:
> > The R-Car DU driver assumes that a bridge is always connected to the DU
> > output. This is valid for the LVDS and HDMI outputs, but the DPAD
> > outputs can be connected directly to a panel, in which case no bridge is
> > available.
> >
> > To support this use case, detect whether the entities connected to the
> > DU DPAD outputs are encoders or panels based on the number of ports of
> > their DT node, and retrieve the corresponding type of DRM objects. For
> > panels, additionally create panel bridge instances.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 ---
> > 1 file changed, 48 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > index 8ee4e762f4e5..595ecfa1ff0e 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > @@ -28,13 +28,33 @@ static const struct drm_encoder_funcs encoder_funcs = {
> > .destroy = drm_encoder_cleanup,
> > };
> >
> > +static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
> > +{
> > + struct device_node *ports;
> > + struct device_node *port;
> > + unsigned int num_ports = 0;
> > +
> > + ports = of_get_child_by_name(node, "ports");
> > + if (!ports)
> > + ports = of_node_get(node);
> > +
> > + for_each_child_of_node(ports, port) {
> > + if (of_node_name_eq(port, "port"))
> > + num_ports++;
> > + }
> > +
> > + of_node_put(node);
> > +
> > + return num_ports;
> > +}
> > +
> > int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > enum rcar_du_output output,
> > struct device_node *enc_node)
> > {
>
> You received a Tested-by, so I might surely be mistaken, but the
> caller of this function skips all remote nodes with a single port,
> doesn't it?
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/rcar-du/rcar_du_kms.c#L308
>
> I don't have any DTS with a panel connected to the DPAD output so, as
> a test, I removed all endpoints except endpoint@0 from the 'hdmi0' device
> node, and the 'rcar_du_encoder_init()' function never gets called and DU
> probing fails with:
> rcar-du feb0.display: no encoder found for endpoint
> /soc/display@feb0/ports/port@1/endpoint, skipping
>
> What am I missing?
You're missing drm-next :-)
https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/rcar-du/rcar_du_kms.c#n331
> > struct rcar_du_encoder *renc;
> > struct drm_encoder *encoder;
> > - struct drm_bridge *bridge = NULL;
> > + struct drm_bridge *bridge;
> > int ret;
> >
> > renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> > @@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> > enc_node, output);
> >
> > - /* Locate the DRM bridge from the encoder DT node. */
> > - bridge = of_drm_find_bridge(enc_node);
> > - if (!bridge) {
> > - ret = -EPROBE_DEFER;
> > - goto done;
> > + /*
> > +* Locate the DRM bridge from the DT node. For the DPAD outputs, if the
> > +* DT node has a single port, consider it describes a panel and create a
> > +* panel bridge.
> > +*/
> > + if ((output == RCAR_DU_OUTPUT_DPAD0 ||
> > +output == RCAR_DU_OUTPUT_DPAD1) &&
> > + rcar_du_encoder_count_ports(enc_node) == 1) {
>
> Could this be cached?
How so ? This function is run once per enc_node, so the cache wouldn't
be used again, would it ?
> > + struct drm_panel *panel = of_drm_find_panel(enc_node);
> > +
> > + if (IS_ERR(panel)) {
> > + ret = PTR_ERR(panel);
> > + goto done;
> > + }
> > +
> > + bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
> > + DRM_MODE_CONNECTOR_DPI);
> > + if (IS_ERR(bridge)) {
> > + ret = PTR_ERR(bridge);
> > + goto done;
> > + }
> > + } else {
> > + bridge = of_drm_find_bridge(enc_node);
> > + if (!bridge) {
> > + ret = -EPROBE_DEFER;
> > + goto done;
> > + }
> > }
> >
> > ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Support panels connected directly to the DPAD outputs
Hi Kieran,
On Wed, Mar 06, 2019 at 10:07:12AM +, Kieran Bingham wrote:
> On 02/03/2019 16:17, Laurent Pinchart wrote:
> > The R-Car DU driver assumes that a bridge is always connected to the DU
> > output. This is valid for the LVDS and HDMI outputs, but the DPAD
> > outputs can be connected directly to a panel, in which case no bridge is
> > available.
> >
> > To support this use case, detect whether the entities connected to the
> > DU DPAD outputs are encoders or panels based on the number of ports of
> > their DT node, and retrieve the corresponding type of DRM objects. For
> > panels, additionally create panel bridge instances.
> >
> > Signed-off-by: Laurent Pinchart
>
> Except for some minor wording on the comment, which I'll let you handle,
>
> Reviewed-by: Kieran Bingham
>
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 ---
> > 1 file changed, 48 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > index 8ee4e762f4e5..595ecfa1ff0e 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > @@ -28,13 +28,33 @@ static const struct drm_encoder_funcs encoder_funcs = {
> > .destroy = drm_encoder_cleanup,
> > };
> >
> > +static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
> > +{
> > + struct device_node *ports;
> > + struct device_node *port;
> > + unsigned int num_ports = 0;
> > +
> > + ports = of_get_child_by_name(node, "ports");
> > + if (!ports)
> > + ports = of_node_get(node);
> > +
> > + for_each_child_of_node(ports, port) {
> > + if (of_node_name_eq(port, "port"))
> > + num_ports++;
> > + }
> > +
> > + of_node_put(node);
> > +
> > + return num_ports;
> > +}
> > +
> > int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > enum rcar_du_output output,
> > struct device_node *enc_node)
> > {
> > struct rcar_du_encoder *renc;
> > struct drm_encoder *encoder;
> > - struct drm_bridge *bridge = NULL;
> > + struct drm_bridge *bridge;
> > int ret;
> >
> > renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> > @@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> > enc_node, output);
> >
> > - /* Locate the DRM bridge from the encoder DT node. */
> > - bridge = of_drm_find_bridge(enc_node);
> > - if (!bridge) {
> > - ret = -EPROBE_DEFER;
> > - goto done;
> > + /*
> > +* Locate the DRM bridge from the DT node. For the DPAD outputs, if the
> > +* DT node has a single port, consider it describes a panel and create a
>
>
> consider it as describing? (if it's an assumption that has been made)
>
> consider if it describes? (if it's conditional)
>
> I'm not sure I fully understand the intent of the sentence to correct it
> - but it needs a little tweak. The use of the word 'consider' makes me
> assume that it might not need a panel bridge, and some further decision
> needs to be made, but the code looks like it assumes one port means
> there should be a panel - and a bridge will be added.
Should I write it as "assume that it ..." ? I considered "consider" as
being less conditional than "assume", but I'll trust your judgement on
that.
> > +* panel bridge.
> > +*/
> > + if ((output == RCAR_DU_OUTPUT_DPAD0 ||
> > +output == RCAR_DU_OUTPUT_DPAD1) &&
> > + rcar_du_encoder_count_ports(enc_node) == 1) {
> > + struct drm_panel *panel = of_drm_find_panel(enc_node);
> > +
> > + if (IS_ERR(panel)) {
> > + ret = PTR_ERR(panel);
> > + goto done;
> > + }
> > +
> > + bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
> > + DRM_MODE_CONNECTOR_DPI);
> > + if (IS_ERR(bridge)) {
> > + ret = PTR_ERR(bridge);
> > + goto done;
> > + }
> > + } else {
> > + bridge = of_drm_find_bridge(enc_node);
> > + if (!bridge) {
> > + ret = -EPROBE_DEFER;
> > + goto done;
> > + }
> > }
> >
> > ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: randr: Virtual monitor not present with MST display
Dear Alex, On 03/05/19 20:07, Alex Deucher wrote: > On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote: >> Using the MST display Dell UP3214Q (two panels) with an AMD system, >> the virtual monitor object is not created. GDM and Xfce consider both >> panels as separate screens (`xrandr --listmonitors`). >> >> [0.00] Linux version 4.20.13.mx64.248 >> (r...@holidayincambodia.molgen.mpg.de) (gcc version 7.3.0 (GCC)) #1 SMP Wed >> Feb 27 14:10:55 CET 2019 >> >> [ 79.494297] [drm] DM_MST: stopping TM on aconnector: a8109331 >> [id: 56] >> [ 79.494362] [drm] DM_MST: Disabling connector: 776ea22b [id: 63] >> [master: a8109331] >> [ 79.494406] [drm] DM_MST: Disabling connector: 057ebdbb [id: 67] >> [master: a8109331] >> [ 79.781882] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last >> cmd=0x201f0500 >> [ 86.028806] [drm] DM_MST: starting TM on aconnector: a8109331 >> [id: 56] >> [ 86.053072] [drm] DM_MST: added connector: 1c9b49ed [id: 71] >> [master: a8109331] >> [ 86.108540] [drm] SADs count is: -2, don't need to read it >> [ 86.386661] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >> create stream for sink! >> [ 87.237878] [drm] DM_MST: added connector: c3ffcbbb [id: 80] >> [master: a8109331] >> [ 87.293028] [drm] SADs count is: -2, don't need to read it >> [ 206.993344] [drm] DM_MST: stopping TM on aconnector: a8109331 >> [id: 56] >> [ 206.993423] [drm] DM_MST: Disabling connector: 1c9b49ed [id: 71] >> [master: a8109331] >> [ 206.993456] [drm] DM_MST: Disabling connector: c3ffcbbb [id: 80] >> [master: a8109331] >> [ 207.548051] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >> create stream for sink! >> [ 207.603193] [drm:create_stream_for_sink [amdgpu]] *ERROR* Failed to >> create stream for sink! >> [ 207.762388] traps: xfdesktop[2225] general protection fault >> ip:7f588981226c sp:7ffee65af370 error:0 in >> libgobject-2.0.so.0.5800.1[7f58897da000+56000] >> [ 210.320612] [drm] DM_MST: starting TM on aconnector: b456cd59 >> [id: 62] >> [ 210.343497] [drm] DM_MST: added connector: 735839d5 [id: 73] >> [master: b456cd59] >> [ 210.399168] [drm] SADs count is: -2, don't need to read it >> [ 210.404454] [drm] DM_MST: added connector: cccb0c2d [id: 88] >> [master: b456cd59] >> [ 210.675589] [drm] SADs count is: -2, don't need to read it I didn’t provide the output of xrandr in my previous message. $ xrandr --listmonitors Monitors: 2 0: +DisplayPort-9 1920/698x2160/392+0+0 DisplayPort-9 1: +DisplayPort-10 1920/698x2160/392+1920+0 DisplayPort-10 Please find the X.Org X Server log attached. >> With an Intel system, the monitor object is shown. To clarify, the modesetting driver is used with the Intel hardware. >> $ xrandr --listmonitors >> Monitors: 1 >> 0: +Auto-Monitor-1 3840/698x2160/392+0+0 DP-1-9 DP-1-8 >> >> Do you have an idea, what the AMD drivers does differently, and how >> to fix this? > > + dri-devel > > My understanding is that this is handled at the Desktop level rather > than the driver. X exposes the tile info via randr 1.5 and the > desktop environment should handle it as a single monitor. Mutter > handles this in GNOME for example. > > https://cgit.freedesktop.org/xorg/xserver/commit/?id=7e1f86d42b54fb7f6492875e47a718eaeca3069b > https://lists.x.org/archives/xorg-announce/2015-May/002605.html > https://mail.gnome.org/archives/desktop-devel-list/2015-November/msg00018.html As it works with the modesetting driver, it looks to me like Xfce supports it, and it’s a driver issue. The Linux error messages also do not look promising. Any idea, if they are related? Lastly, shouldn’t at least the output of `xrandr` be correct, if everything is set up correctly? Kind regards, Paul [57.665] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [57.665] Build Operating System: Linux 4.19.19.mx64.244 x86_64 [57.665] Current Operating System: Linux inbetweenmove.molgen.mpg.de 4.19.19.mx64.244 #1 SMP Tue Feb 5 13:01:13 CET 2019 x86_64 [57.665] Kernel command line: BOOT_IMAGE=/boot/bzImage-4.19.19.mx64.244 crashkernel=256M root=LABEL=root ro console=ttyS1,115200n8 console=tty0 init=/bin/systemd audit=0 [57.665] Build Date: 27 February 2019 12:32:24PM [57.665] [57.665] Current version of pixman: 0.38.0 [57.665] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [57.665] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [57.665] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar 6 13:24:58 2019 [57.665] (==) Using config directory: "/etc/X11/xorg.conf.d" [57.665] (==) Using system
[Bug 108898] (Recoverable) GPU hangs with GfxBench Manhattan GL tests
https://bugs.freedesktop.org/show_bug.cgi?id=108898 --- Comment #2 from Eero Tamminen --- Hangs are still happening with the latest Mesa (43f40dc7cb234e) and drm-tip kernel (v5.0) git versions in Manhattan test offscreen versions. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/19] media: vsp1: dl: Support one-shot entries in the display list
Hi,
On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> > On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> > > On Fri, Feb 22, 2019 at 02:30:03PM +, Brian Starkey wrote:
> > >> On Thu, Feb 21, 2019 at 12:32:00PM +0200, Laurent Pinchart wrote:
> > >>> One-shot entries are used as an alternative to committing a complete new
> > >>> display list when a couple of registers need to be written for one frame
> > >>> and then reset to another value for all subsequent frames. This will be
> > >>> used to implement writeback support that will need to enable writeback
> > >>> for the duration of a single frame.
> > >>>
> > >>> Signed-off-by: Laurent Pinchart
> > >>>
> > >>> ---
> > >>> drivers/media/platform/vsp1/vsp1_dl.c | 78 +++
> > >>> drivers/media/platform/vsp1/vsp1_dl.h | 3 ++
> > >>> 2 files changed, 81 insertions(+)
> > >>>
> > >>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> b/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> index 886b3a69d329..7b4d252bfde7 100644
> > >>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> > >>> @@ -115,6 +115,12 @@ struct vsp1_dl_body {
> > >>>
> > >>> unsigned int num_entries;
> > >>> unsigned int max_entries;
> > >>> +
> > >>> + unsigned int num_patches;
> > >>> + struct {
> > >>> + struct vsp1_dl_entry *entry;
> > >>> + u32 data;
> > >>> + } patches[2];
> > >>> };
> > >>>
> > >>> /**
> > >>> @@ -361,6 +367,7 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
> > >>> return;
> > >>>
> > >>> dlb->num_entries = 0;
> > >>> + dlb->num_patches = 0;
> > >>>
> > >>> spin_lock_irqsave(>pool->lock, flags);
> > >>> list_add_tail(>free, >pool->free);
> > >>> @@ -388,6 +395,47 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb,
> > >>> u32 reg, u32 data)
> > >>> dlb->num_entries++;
> > >>> }
> > >>>
> > >>> +/**
> > >>> + * vsp1_dl_body_write_oneshot - Write a register to a display list
> > >>> body for a
> > >>> + * single frame
> > >>> + * @dlb: The body
> > >>> + * @reg: The register address
> > >>> + * @value: The register value
> > >>> + * @reset_value: The value to reset the register to at the next vblank
> > >>> + *
> > >>> + * Display lists in continuous mode are re-used by the hardware for
> > >>> successive
> > >>> + * frames until a new display list is committed. Changing the VSP
> > >>> configuration
> > >>> + * normally requires creating and committing a new display list. This
> > >>> function
> > >>> + * offers an alternative race-free way by writing a @value to the
> > >>> @register in
> > >>> + * the display list body for a single frame, specifying in
> > >>> @reset_value the
> > >>> + * value to reset the register to one vblank after the display list is
> > >>> + * committed.
> > >>> + *
> > >>> + * The maximum number of one-shot entries is limited to 2 per display
> > >>> list body,
> > >>> + * and one-shot entries are counted in the total number of entries
> > >>> specified
> > >>> + * when the body is allocated by vsp1_dl_body_alloc().
> > >>> + */
> > >>> +void vsp1_dl_body_write_oneshot(struct vsp1_dl_body *dlb, u32 reg, u32
> > >>> value,
> > >>> + u32 reset_value)
> > >>> +{
> > >>> + if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
> > >>> + "DLB size exceeded (max %u)", dlb->max_entries))
> > >>> + return;
> > >>> +
> > >>> + if (WARN_ONCE(dlb->num_patches >= ARRAY_SIZE(dlb->patches),
> > >>> + "DLB patches size exceeded (max %zu)",
> > >>> + ARRAY_SIZE(dlb->patches)))
> > >>> + return;
> > >>> +
> > >>> + dlb->patches[dlb->num_patches].entry =
> > >>> >entries[dlb->num_entries];
> > >>> + dlb->patches[dlb->num_patches].data = reset_value;
> > >>> + dlb->num_patches++;
> > >>> +
> > >>> + dlb->entries[dlb->num_entries].addr = reg;
> > >>> + dlb->entries[dlb->num_entries].data = value;
> > >>> + dlb->num_entries++;
> > >>> +}
> > >>> +
> > >>> /*
> > >>> -
> > >>> * Display List Extended Command Management
> > >>> */
> > >>> @@ -652,6 +700,7 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list
> > >>> *dl)
> > >>> * has at least one body, thus we reinitialise the entries list.
> > >>> */
> > >>> dl->body0->num_entries = 0;
> > >>> + dl->body0->num_patches = 0;
> > >>>
> > >>> list_add_tail(>list, >dlm->free);
> > >>> }
> > >>> @@ -930,6 +979,35 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl,
> > >>> unsigned int dl_flags)
> > >>> * Display List Manager
> > >>> */
> > >>>
> > >>> +/**
> > >>> + *
[Bug 109850] there is a problem in frame buffer console.
https://bugs.freedesktop.org/show_bug.cgi?id=109850 Andre Klapper changed: What|Removed |Added Blocks|| Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id= [Bug ] X server crash whenever 2 xvideo windows are being used simultaneously -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next-fixes
Hi Dave, Daniel, A few extra patches for the 5.1 merge window. Thanks! Maxime drm-misc-next-fixes-2019-03-06: - Properly mark the ptr_to_compat argument with the __user tag - Merge __drm_atomic_helper_disable_all into drm_atomic_helper_disable_all The following changes since commit 6649a95d35d850e417f125821a803ca7889c713c: drm/komeda: fix build with drm_modeset_helper.h update (2019-02-11 10:36:00 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2019-03-06 for you to fetch changes up to e552f0851070fe4975d610a99910be4e9bf5d7bd: drm: add __user attribute to ptr_to_compat() (2019-03-04 09:55:31 -0500) - Properly mark the ptr_to_compat argument with the __user tag - Merge __drm_atomic_helper_disable_all into drm_atomic_helper_disable_all Ben Dooks (1): drm: add __user attribute to ptr_to_compat() Sean Paul (1): drm: Merge __drm_atomic_helper_disable_all() into drm_atomic_helper_disable_all() drivers/gpu/drm/drm_atomic_helper.c | 119 +--- drivers/gpu/drm/drm_ioc32.c | 6 +- 2 files changed, 59 insertions(+), 66 deletions(-) -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109863] Testing purpose
https://bugs.freedesktop.org/show_bug.cgi?id=109863 Andre Klapper changed: What|Removed |Added Component|/dev/null |Two Alias|osamamumta...@gmal.com | Product|a big freedesktop.org fly |Spam |ribbon | -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Support panels connected directly to the DPAD outputs
Hi Laurent,
On Sat, Mar 02, 2019 at 06:17:25PM +0200, Laurent Pinchart wrote:
> The R-Car DU driver assumes that a bridge is always connected to the DU
> output. This is valid for the LVDS and HDMI outputs, but the DPAD
> outputs can be connected directly to a panel, in which case no bridge is
> available.
>
> To support this use case, detect whether the entities connected to the
> DU DPAD outputs are encoders or panels based on the number of ports of
> their DT node, and retrieve the corresponding type of DRM objects. For
> panels, additionally create panel bridge instances.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 54 ---
> 1 file changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index 8ee4e762f4e5..595ecfa1ff0e 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -28,13 +28,33 @@ static const struct drm_encoder_funcs encoder_funcs = {
> .destroy = drm_encoder_cleanup,
> };
>
> +static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
> +{
> + struct device_node *ports;
> + struct device_node *port;
> + unsigned int num_ports = 0;
> +
> + ports = of_get_child_by_name(node, "ports");
> + if (!ports)
> + ports = of_node_get(node);
> +
> + for_each_child_of_node(ports, port) {
> + if (of_node_name_eq(port, "port"))
> + num_ports++;
> + }
> +
> + of_node_put(node);
> +
> + return num_ports;
> +}
> +
> int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>enum rcar_du_output output,
>struct device_node *enc_node)
> {
You received a Tested-by, so I might surely be mistaken, but the
caller of this function skips all remote nodes with a single port,
doesn't it?
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/rcar-du/rcar_du_kms.c#L308
I don't have any DTS with a panel connected to the DPAD output so, as
a test, I removed all endpoints except endpoint@0 from the 'hdmi0' device
node, and the 'rcar_du_encoder_init()' function never gets called and DU
probing fails with:
rcar-du feb0.display: no encoder found for endpoint
/soc/display@feb0/ports/port@1/endpoint, skipping
What am I missing?
Thanks
j
> struct rcar_du_encoder *renc;
> struct drm_encoder *encoder;
> - struct drm_bridge *bridge = NULL;
> + struct drm_bridge *bridge;
> int ret;
>
> renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> @@ -48,11 +68,33 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> enc_node, output);
>
> - /* Locate the DRM bridge from the encoder DT node. */
> - bridge = of_drm_find_bridge(enc_node);
> - if (!bridge) {
> - ret = -EPROBE_DEFER;
> - goto done;
> + /*
> + * Locate the DRM bridge from the DT node. For the DPAD outputs, if the
> + * DT node has a single port, consider it describes a panel and create a
> + * panel bridge.
> + */
> + if ((output == RCAR_DU_OUTPUT_DPAD0 ||
> + output == RCAR_DU_OUTPUT_DPAD1) &&
> + rcar_du_encoder_count_ports(enc_node) == 1) {
Could this be cached?
> + struct drm_panel *panel = of_drm_find_panel(enc_node);
> +
> + if (IS_ERR(panel)) {
> + ret = PTR_ERR(panel);
> + goto done;
> + }
> +
> + bridge = devm_drm_panel_bridge_add(rcdu->dev, panel,
> +DRM_MODE_CONNECTOR_DPI);
> + if (IS_ERR(bridge)) {
> + ret = PTR_ERR(bridge);
> + goto done;
> + }
> + } else {
> + bridge = of_drm_find_bridge(enc_node);
> + if (!bridge) {
> + ret = -EPROBE_DEFER;
> + goto done;
> + }
> }
>
> ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
> --
> Regards,
>
> Laurent Pinchart
>
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V6 8/8] drm/mediatek: fix the rate of parent for hdmi phy in MT2701
Hi, Wangyan:
On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> From: chunhui dai
>
> We should not change the rate of parent for hdmi phy when
> doing round_rate for this clock. The parent clock of hdmi
> phy must be the same as it. We change it when doing set_rate
> only.
>
> Signed-off-by: chunhui dai
> Signed-off-by: wangyan wang
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 ---
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 11 +++
> drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
> 4 files changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index 370309d684ec..ca8bc1489f37 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
> .owner = THIS_MODULE,
> };
>
> -long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> - unsigned long *parent_rate)
> -{
> - struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> -
> - hdmi_phy->pll_rate = rate;
> - if (rate <= 7425)
> - *parent_rate = rate;
> - else
> - *parent_rate = rate / 2;
> -
> - return rate;
> -}
> -
> u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
> {
> return readl(hdmi_phy->regs + offset);
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index 446e2acd1926..c6061ad15ff0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -50,9 +50,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy,
> u32 offset,
> void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> u32 val, u32 mask);
> struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
> -long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> - unsigned long *parent_rate);
> -
> extern struct platform_driver mtk_hdmi_phy_driver;
> extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
> extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index 88dd9e812ca0..33893a180c2e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -152,6 +152,17 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
> unsigned long rate,
> RG_HDMITX_DRV_IBIAS_MASK);
> return 0;
> }
> +
> +static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> +
> + hdmi_phy->pll_rate = rate;
I think you don't need to save the rate into pll_rate here, pll_rate
would be set in set_rate() or recalc_rate().
Regards,
CK
> +
> + return rate;
> +}
> +
> static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
> {
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> index 63dde42521b8..3a339f516613 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> @@ -285,6 +285,20 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
> unsigned long rate,
> return 0;
> }
>
> +static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> +
> + hdmi_phy->pll_rate = rate;
> + if (rate <= 7425)
> + *parent_rate = rate;
> + else
> + *parent_rate = rate / 2;
> +
> + return rate;
> +}
> +
> static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
> {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
