[Bug 107377] [CI][DRMTIP] igt@gem_gpgpu_fill - fail - Test assertion failure function gen7_render_flush, Failed assertion: ret == 0, Last errno: 5, Input/output error
https://bugs.freedesktop.org/show_bug.cgi?id=107377 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Lakshmi --- Closing this bug, this issue not seen since 1 month. -- 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: [ANNOUNCE] libdrm 2.4.94
Le vendredi 24 août 2018, 00:37:51 CEST Kristian H. Kristensen a écrit : > https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2 -> Forbidden You don't have permission to access /libdrm/libdrm-2.4.94.tar.bz2 on this server. > PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2.sig -> Not Found The requested URL /libdrm/libdrm-2.4.94.tar.bz2.sig was not found on this server. - Laurent Carlier http://www.archlinux.org signature.asc Description: This is a digitally signed message part. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[no subject]
Hi Linus, Just a couple of fixes PRs for rc1, One MAINTAINERS address change, two panels fixes, and set of amdgpu fixes (build fixes, display fixes and some others). Thanks Dave. drm-next-2018-08-24: amdgpu and panel/misc fixes. The following changes since commit 3d63a3c14741ed015948943076f3c6a2f2cd7b27: Merge tag 'drm-msm-next-2018-08-10' of git://people.freedesktop.org/~robclark/linux into drm-next (2018-08-17 10:46:51 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-08-24 for you to fetch changes up to 3e20e97c2d55fb18e4b06d16478edc757483b7db: Merge tag 'drm-misc-next-fixes-2018-08-23-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-08-24 13:41:03 +1000) amdgpu and panel/misc fixes. Alex Deucher (1): drm/amdgpu/display: disable eDP fast boot optimization on DCE8 Christian König (3): drm/amdgpu: fix incorrect use of fcheck drm/amdgpu: fix incorrect use of drm_file->pid drm/amdgpu: fix amdgpu_amdkfd_remove_eviction_fence v3 Dave Airlie (3): Merge tag 'drm-misc-next-fixes-2018-08-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge branch 'drm-next-4.19' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge tag 'drm-misc-next-fixes-2018-08-23-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Dmytro Laktyushkin (3): drm/amd/display: fix dp_ss_control vbios flag parsing drm/amd/display: make dp_ss_off optional drm/amd/display: fix dentist did ranges Evan Quan (1): drm/amdgpu: set correct base for THM/NBIF/MP1 IP Kai-Heng Feng (1): drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80 Leo (Sunpeng) Li (2): Revert "drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0 with CONFIG_X86" drm/amd/display: Don't build DCN1 when kcov is enabled Samson Tam (1): drm/amd/display: Do not retain link settings Sean Paul (2): drm/panel: simple: tv123wam: Add unprepare delay MAINTAINERS: drm-misc: Change seanpaul's email address Yintian Tao (2): drm/amdgpu: access register without KIQ drm/powerplay: enable dpm under pass-through MAINTAINERS| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 103 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 21 ++--- drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c | 3 + drivers/gpu/drm/amd/amdgpu/vi.c| 4 +- drivers/gpu/drm/amd/display/Kconfig| 6 ++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +- drivers/gpu/drm/amd/display/dc/Makefile| 2 +- .../amd/display/dc/bios/command_table_helper2.c| 2 +- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 21 - drivers/gpu/drm/amd/display/dc/core/dc_debug.c | 2 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 6 +- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 12 +-- drivers/gpu/drm/amd/display/dc/dc.h| 2 +- .../gpu/drm/amd/display/dc/dce/dce_clock_source.c | 6 +- .../gpu/drm/amd/display/dc/dce/dce_clock_source.h | 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c| 18 ++-- drivers/gpu/drm/amd/display/dc/dce/dce_clocks.h| 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c | 6 +- .../drm/amd/display/dc/dce/dce_stream_encoder.c| 20 ++-- .../amd/display/dc/dce110/dce110_hw_sequencer.c| 10 +- drivers/gpu/drm/amd/display/dc/gpio/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/gpio/hw_factory.c | 4 +- drivers/gpu/drm/amd/display/dc/gpio/hw_translate.c | 4 +- drivers/gpu/drm/amd/display/dc/i2caux/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/i2caux/i2caux.c | 4 +- drivers/gpu/drm/amd/display/dc/inc/core_types.h| 7 +- drivers/gpu/drm/amd/display/dc/irq/Makefile| 2 +- drivers/gpu/drm/amd/display/dc/irq/irq_service.c | 2 +- drivers/gpu/drm/amd/display/dc/os_types.h | 2 +- .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 4 +- drivers/gpu/drm/drm_edid.c | 3 + drivers/gpu/drm/panel/panel-simple.c | 3 + 35 files changed, 161 insertions(+), 142 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107627] Freedesktop runtime version 18.08 Mesa cached shaders result in crashes
https://bugs.freedesktop.org/show_bug.cgi?id=107627 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Timothy Arceri --- I've skimmed over the linked report and I've got no idea why you think this is a Mesa bug. Help me help you, a proper bug report should contain all the information I need to start looking into the issue. -- 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 107668] Blank screen since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 and RX380 on HDMI Ultrawidescreen Monitor
https://bugs.freedesktop.org/show_bug.cgi?id=107668 --- Comment #1 from Naheem Zaffar --- Created attachment 141266 --> https://bugs.freedesktop.org/attachment.cgi?id=141266=edit Dmesg output with amdgpu.dc=0 Taken when booting with Vanilla Mainline kernel 4.19.0-0.rc0.git8.1.vanilla.knurd.1.fc28.x86_64 with argument amdgpu.dc=0 -- 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 107668] Blank screen since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 and RX380 on HDMI Ultrawidescreen Monitor
https://bugs.freedesktop.org/show_bug.cgi?id=107668 Bug ID: 107668 Summary: Blank screen since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 and RX380 on HDMI Ultrawidescreen Monitor 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: naheemzaf...@gmail.com Created attachment 141265 --> https://bugs.freedesktop.org/attachment.cgi?id=141265=edit Dmesg from boot with Kernel 4.19 prerelease I have already reported this on Redhat Bugzilla, so if more information is needed, that may be a good place to look at comments: https://bugzilla.redhat.com/show_bug.cgi?id=1594488 Since the change to using dc in the kernel I am getting a blank screen with trying to boot my ultrawidescreen monitor. As a workaround I can use amdgpu.dc=0, but this hits al earlier big where at native resolution the display output is garbled (links in Redhat Bugzilla attach to another big report, youtube video of the same). I am attaching dmesg output from 4.19.0-0.rc0.git8.1.vanilla.knurd.1.fc28.x86_64 with and without amdgpu.dc=0 I have noticed a couple of entries in the dmesg without the amdgpu.dc=0: kernel: [drm] add ip block number 4 with amdgpu.dc=0 it is: kernel: [drm] add ip block number 4 The other ip address block entries are identical. with amdgpu.dc=0 I get this section: Aug 22 23:46:22 kernel: [drm] PCIE GART of 256M enabled (table at 0x00F40090). Aug 22 23:46:22 kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Aug 22 23:46:22 kernel: [drm] Driver supports precise vblank timestamp query. Aug 22 23:46:22 kernel: [drm] AMDGPU Display Connectors Aug 22 23:46:22 kernel: [drm] Connector 0: Aug 22 23:46:22 kernel: [drm] DP-1 Aug 22 23:46:22 kernel: [drm] HPD5 Aug 22 23:46:22 kernel: [drm] DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b 0x486b Aug 22 23:46:22 kernel: [drm] Encoders: Aug 22 23:46:22 kernel: [drm] DFP1: INTERNAL_UNIPHY1 Aug 22 23:46:22 kernel: [drm] Connector 1: Aug 22 23:46:22 kernel: [drm] HDMI-A-1 Aug 22 23:46:22 kernel: [drm] HPD3 Aug 22 23:46:22 kernel: [drm] DDC: 0x4874 0x4874 0x4875 0x4875 0x4876 0x4876 0x4877 0x4877 Aug 22 23:46:22 kernel: [drm] Encoders: Aug 22 23:46:22 kernel: [drm] DFP2: INTERNAL_UNIPHY1 Aug 22 23:46:22 kernel: [drm] Connector 2: Aug 22 23:46:22 kernel: [drm] DVI-D-1 Aug 22 23:46:22 kernel: [drm] HPD4 Aug 22 23:46:22 kernel: [drm] DDC: 0x4878 0x4878 0x4879 0x4879 0x487a 0x487a 0x487b 0x487b Aug 22 23:46:22 kernel: [drm] Encoders: Aug 22 23:46:22 kernel: [drm] DFP3: INTERNAL_UNIPHY Aug 22 23:46:22 kernel: [drm] Chained IB support enabled! but without amdgpu.dc=0 only the first and last line of that section appear. Later down without the amdgpu.dc=0 I also get the following message: kernel: [drm] Cannot find any crtc or sizes This may also be similar to bug https://bugs.freedesktop.org/show_bug.cgi?id=105880 but that is for laptop panels on LVDS while this issue is with a discrete RX460 graphics card on HDMI -- 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 107545] radeon - ring 0 stalled - GPU lockup - SI
https://bugs.freedesktop.org/show_bug.cgi?id=107545 --- Comment #8 from Christopher --- Created attachment 141264 --> https://bugs.freedesktop.org/attachment.cgi?id=141264=edit dmsg output running on xorg -- 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 1/1] drm/ttm: Set memory as decrypted for ttm framebuffer mappings
On 08/23/2018 01:47 AM, Christian König wrote: Am 22.08.2018 um 22:57 schrieb Jiandi An: On 08/22/2018 02:09 PM, Christian König wrote: Am 22.08.2018 um 20:57 schrieb Jiandi An: Framebuffer memory needs to be accessed decrypted. Ensure the memory encryption mask is not set for the ttm framebuffer mappings. NAK, the memory not only needs to be decrypted while CPU accessed but all the time. ttm_page_alloc.c and ttm_page_alloc_dma.c should already take care of that while mapping the pages. Regards, Christian. The path where the issue comes in is booting guest with AMD SEV enabled while using virtio-vga device. The ttm->pages doesn't go through ttm_populate_and_map_pages(). And that is the point where you need to jump in and fix the problem. When a driver implements the populate() and unpopulate() callbacks themselves it needs to take care of all that handling. Thanks for the suggestion and guidance. So you want me to register the callbacks something like virtio_gpu_ttm_populate() and virtio_gpu_ttm_unpopulate() in the virtio_gpu_bo_driver, and perform mapping by calling ttm_bo_kmap()? Then bring setting memory decrypted/encryped by calling set_memory_decrypted()/set_memory_encrypted() outside of ttm_bo_kmap(), do it within virtio_gpu_ttm_populate() and virtio_gpu_ttm_unpopulate() callbacks? Then get rid of the separate call of virtio_gpu_vmap_fb() the virtio_gpu driver does? In the kernel path, the virtio_gpu driver calls virtio_gpu_alloc_object() and goes down to ttm to allocate pages in ttm_pool_populate(). Driver in guest then does virtio_gpu_vmap_fb() which goes down to ttm_bo_kmap_ttm() and does a vmap() for GVA to GPA for those pages. If SEV is enabled, decryption should be set in this GVA to GPA mapping. That assumption is what is incorrect here. TTM can't work with encrypted pages, so you need to set the pages as decrypted directly after calling ttm_pool_populate(). And obviously set it to encrypted again before calling ttm_pool_unpopulate(). Probably best if we add that to ttm_tt_populate()/ttm_tt_unpopulate(). Here when you say ttm_tt_populate() and ttm_tt_unpopulate() you mean the virtio_gpu_ttm_populate() and virtio_gpu_ttm_unpopulate() that I register in virtio_gpu_bo_driver right? Regards, Christian. Guest then sends object attach command to host via virtio_gpu_object_attach() which stuffs the pages' physical addresses (guest physical address) in a scatter list and send them to host QEMU. Host QEMU maps those guest pages GPA to HPA and access via HVA while guest write stuff in those pages via GVA. virtio_gpu_alloc_object() virtio_gpu_object_create() sturct virtio_gpu_object bo kzalloc() ttm_bo_init() ... ttm_tt_create() bo->ttm = bdev->driver->ttm_tt_create() virtio_gpu_ttm_tt_create() ... ttm_tt_populate() ttm_pool_populate() ttm_get_pages(ttm->pages, ttm->num_pages) virtio_gpu_vmap_fb() virtio_gpu_object_kmap(obj, NULL) ttm_bo_kmap ttm_mem_io_reserve() ttm_bo_kmap_ttm() vmap() struct virtio_gpu_object bo->vmap = ttm_kmap_obj_virtual(>kmap, _iomem); virtio_gpu_object_attach() <<== Sending attach backing command virtio_gpu_object_get_sg_table() if (bo->tbo.ttm->state == tt_unpopulated) virtio_gpu_object bo.ttm->bdev->driver->ttm_tt_populate(bo->tbo.ttm, ); bo->pages = kmalloc(sizeof(struct sg_table), GFP_KERNEL); sg_alloc_table_from_pages(bo->tbo.ttm->pages) //Getfrom ttm->pages and put in sg __sg_alloc_table_from_pages() There is a separate userspace path for example when displace manager kicks in, virtio_gpu_alloc_object() followed by virtio_gpu_object_attach() are called through the ioctl virtio_gpu_resource_create_ioctl(). The mapping of the pages created in this page are handled in the do_page_fault() path in ttm_bo_vm_ops's ttm_bo_vm_fault() handler. do_page_fault() handle_mm_fault() __do_page_fault() ttm_bo_vm_fault() ttm_bo_reserve() __ttm_bo_reserve() ttm_mem_io_reserve_vm() ttm_mem_io_reserve() bdev->driver->io_mem_reserve() virtio_gpu_ttm_io_mem_reserve() mem->bus.is_iomem = false mem->mem_type == TTM_PL_TT I originally handled setting pages decrypted for the kernel path for GVA to GPA mapping in guest in virtio_gpu_vmap_fb() at the virtio_gpu driver layer. But for the user space path virtio_gpu_vmap_fb() is not called. Mapping is handled in the page_fault handler. So I moved it to the ttm layer. What layer do you recommend as more appropriate to handle setting memory decrypted for GVA to GPA mapping for thos ttm->pages? Thanks
[Bug 107545] radeon - ring 0 stalled - GPU lockup - SI
https://bugs.freedesktop.org/show_bug.cgi?id=107545 --- Comment #7 from Christopher --- Hello, I am getting similar issues with regards to fence wait timeouts. However I have narrowed it further to it ONLY happening when gnome is running on xorg. I have over the past month or so rebuilt my system from the ground up. I am NOT using a distro that holds peoples hands with package managers and bloated useless kernel modules. I use instructions from linuxfromscratch.org to build the entire system from the latest stable sourcecode. After I first boot into gnome, with it running on xorg, as soon as I have logged in and click on activities on the gnome menu and select terminal, then the little circle starts twirling, and after a few seconds the screen flashes, and it momentarily goes to the grey login background, then flashes to what can only be described as a mini pixal dump, then after a while it flashes back to the login screen again and you need to login again. At this point, if you click on the drop down list to see the types of login session available, gnome on xorg is missing from the list. At this stage I login and going back and activating gnome terminal is successfull, however the dmesg log shows that it has ring stalled errors, and the dreaded parser error that has been mentioned here. If I start gnome on wayland, and then proceed to click on activities and then on terminal to bring up gnome terminal, even though the circle twirls for a long time after, the terminal window opens almost immediately and the output of dmesg is free of the ring timeouts. Running xorg by itself using twm with clock and xterm also produces a clean dmesg log. Please find the results attached for both boot tests. By the way this is on one of the latest versions of the 4.18 kernel series available on kernel.org. The version of Mesa used is: mesa-18.1.5 -- 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 107545] radeon - ring 0 stalled - GPU lockup - SI
https://bugs.freedesktop.org/show_bug.cgi?id=107545 --- Comment #6 from Christopher --- Created attachment 141263 --> https://bugs.freedesktop.org/attachment.cgi?id=141263=edit dmsg output running on wayland -- 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
[ANNOUNCE] libdrm 2.4.94
Benjamin Gaignard (2): tests/modetest: Add atomic support tests/util: Add support for stm module Christian König (7): amdgpu: stop using the hash table for fd_tab amdgpu: add handle table implementation v2 amdgpu: use handle table for KMS handles amdgpu: use handle table for flink names amdgpu: remove the hash table implementation amdgpu: always add all BOs to handle table amdgpu: fix off by one in handle_table_insert Junwei Zhang (5): amdgpu: add bo from user memory to handle table amdgpu: add a function to find bo by cpu mapping (v2) tests/amdgpu: add test for finding bo by CPU mapping amdgpu: free flink bo in bo import amdgpu: add a function to create amdgpu bo internally (v4) Kristian H. Kristensen (1): Bump to version 2.4.94 Likun Gao (1): amdgpu: Disable deadlock test suite for RV Michel Dänzer (2): amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping amdgpu: Eliminate void* arithmetic in amdgpu_find_bo_by_cpu_mapping Mike Lothian (1): libdrm: Fix amdgpu build failure Rob Clark (2): freedreno: don't leak stateobj rb refs freedreno: fix use-after-free with stateobj rb's Rodrigo Vivi (1): intel: Add a new CFL PCI ID. Tanmay Shah (1): libdrm: add msm drm uapi header git tag: libdrm-2.4.94 https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2 MD5: d48759b2c276382f9085799a08a153f5 libdrm-2.4.94.tar.bz2 SHA1: 740c5c19b5e451102d0f5b360dae3016b3e72eab libdrm-2.4.94.tar.bz2 SHA256: 31d9831e6eaa5b16fb560e5578b3428ce6aa024ff6c66882631005cc9624680f libdrm-2.4.94.tar.bz2 SHA512: ac6b37fd3b88f5b7660dc630ec0a22b05d24138d0985c93c45363b938f5ee72cfe8bb198d94765090c3a5c158c06f3be14b849fd00b8d865c04d4132e28f6920 libdrm-2.4.94.tar.bz2 PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2.sig https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.gz MD5: 1d2e80ffe5b69c31c8465966e5cc7ce4 libdrm-2.4.94.tar.gz SHA1: 05433abd64c692250a52694f1af74f161323a698 libdrm-2.4.94.tar.gz SHA256: c438b0e2a8e0c9e6a1d92f4c235176e545d81f4edb9a14bc606bb5ede6668d8e libdrm-2.4.94.tar.gz SHA512: 99cc4eba5e9fc44886c515484821e6d509d202ee269d292e0d9b426bb92a53f6fc7095174d12652b377cd12036e4138ebc324df9e36e5edde5da31d476fa4ebe libdrm-2.4.94.tar.gz PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.gz.sig ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Fix nouveau_connector_ddc_detect()
It looks like that when we moved over to using
drm_connector_for_each_possible_encoder() in nouveau, that one rather
important part of this function got dropped by accident:
/* Right v here */
for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) {
int id = connector->encoder_ids[i];
if (id == 0)
break;
Since it's rather difficult to notice: the conditional in this loop is
actually:
nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER
Meaning that all early breaks result in nv_encoder keeping it's value,
otherwise nv_encoder = NULL. Ugh.
Since this got dropped, nouveau_connector_ddc_detect() now returns an
encoder for every single connector, regardless of whether or not it's
detected:
[ 1780.056185] nouveau :01:00.0: DRM: DDC responded, but no EDID for
DP-2
So: fix this to ensure we only return an encoder if we actually found
one, and clean up the rest of the function while we're at it since it's
nearly impossible to read properly.
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
Fixes: ddba766dd07e ("drm/nouveau: Use
drm_connector_for_each_possible_encoder()")
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 51 -
1 file changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 3b288be9c3f7..51b6f762f1e1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -414,9 +414,9 @@ nouveau_connector_ddc_detect(struct drm_connector
*connector)
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_gpio *gpio = nvxx_gpio(>client.device);
- struct nouveau_encoder *nv_encoder = NULL;
+ struct nouveau_encoder *nv_encoder = NULL, *found = NULL;
struct drm_encoder *encoder;
- int i, panel = -ENODEV;
+ int i, ret, panel = -ENODEV;
/* eDP panels need powering on by us (if the VBIOS doesn't default it
* to on) before doing any AUX channel transactions. LVDS panel power
@@ -433,37 +433,46 @@ nouveau_connector_ddc_detect(struct drm_connector
*connector)
drm_connector_for_each_possible_encoder(connector, encoder, i) {
nv_encoder = nouveau_encoder(encoder);
- if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
- int ret = nouveau_dp_detect(nv_encoder);
+ switch (nv_encoder->dcb->type) {
+ case DCB_OUTPUT_DP:
+ ret = nouveau_dp_detect(nv_encoder);
if (ret == NOUVEAU_DP_MST)
return NULL;
- if (ret == NOUVEAU_DP_SST)
- break;
- } else
- if ((vga_switcheroo_handler_flags() &
-VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
- nv_encoder->dcb->type == DCB_OUTPUT_LVDS &&
- nv_encoder->i2c) {
- int ret;
+ else if (ret == NOUVEAU_DP_SST)
+ found = nv_encoder;
+
+ break;
+ case DCB_OUTPUT_LVDS:
+ /* Can we actually probe this LVDS display? */
+ if (!((vga_switcheroo_handler_flags() &
+ VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
+ nv_encoder->i2c))
+ continue;
+
vga_switcheroo_lock_ddc(dev->pdev);
- ret = nvkm_probe_i2c(nv_encoder->i2c, 0x50);
- vga_switcheroo_unlock_ddc(dev->pdev);
- if (ret)
- break;
- } else
- if (nv_encoder->i2c) {
if (nvkm_probe_i2c(nv_encoder->i2c, 0x50))
- break;
+ found = nv_encoder;
+ vga_switcheroo_unlock_ddc(dev->pdev);
+
+ break;
+ default:
+ if (nv_encoder->i2c &&
+ nvkm_probe_i2c(nv_encoder->i2c, 0x50))
+ found = nv_encoder;
+
+ break;
}
+ if (found)
+ break;
}
/* eDP panel not detected, restore panel power GPIO to previous
* state to avoid confusing the SOR for other output types.
*/
- if (!nv_encoder && panel == 0)
+ if (!found && panel == 0)
nvkm_gpio_set(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff, panel);
- return nv_encoder;
+ return found;
}
static struct nouveau_encoder *
--
2.17.1
___
dri-devel mailing list
[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off
https://bugs.freedesktop.org/show_bug.cgi?id=105046 --- Comment #17 from Michael Zapf --- Just installed openSUSE with kernel 4.18; the issue seems to be fixed! Let me check with my office PC (in about a week) before declaring it resolved. -- 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] mach64: detect the dot clock divider correctly on sparc
On Sun, 19 Aug 2018, Ville Syrjälä wrote:
> On Fri, Aug 17, 2018 at 03:19:37PM -0400, Mikulas Patocka wrote:
> > On Sun Ultra 5, it happens that the dot clock is not set up properly for
> > some videomodes. For example, if we set the videomode "r1024x768x60" in
> > the firmware, Linux would incorrectly set a videomode with refresh rate
> > 180Hz when booting (suprisingly, my LCD monitor can display it, although
> > display quality is very low).
> >
> > The reason is this: Older mach64 cards set the divider in the register
> > VCLK_POST_DIV. The register has four 2-bit fields (the field that is
> > actually used is specified in the lowest two bits of the register
> > CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards,
> > there's another bit added - the top four bits of PLL_EXT_CNTL extend the
> > divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12".
> > The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets
> > them, so it can work regardless if the card supports them. However, the
> > sparc64 firmware may set these extended dividers during boot - and the
> > mach64 driver detects incorrect dot clock in this case.
> >
> > This patch makes the driver read the additional divider bit from
> > PLL_EXT_CNTL and calculate the initial refresh rate properly.
> >
> > Signed-off-by: Mikulas Patocka
> > Cc: sta...@vger.kernel.org
> >
> > ---
> > drivers/video/fbdev/aty/atyfb.h |3 ++-
> > drivers/video/fbdev/aty/atyfb_base.c |7 ---
> > drivers/video/fbdev/aty/mach64_ct.c | 10 +-
> > 3 files changed, 11 insertions(+), 9 deletions(-)
> >
> > Index: linux-stable/drivers/video/fbdev/aty/atyfb.h
> > ===
> > --- linux-stable.orig/drivers/video/fbdev/aty/atyfb.h 2018-08-13
> > 21:12:11.0 +0200
> > +++ linux-stable/drivers/video/fbdev/aty/atyfb.h2018-08-13
> > 21:17:14.0 +0200
> > @@ -333,6 +333,8 @@ extern const struct aty_pll_ops aty_pll_
> > extern void aty_set_pll_ct(const struct fb_info *info, const union aty_pll
> > *pll);
> > extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
> >
> > +extern const u8 aty_postdividers[8];
> > +
> >
> > /*
> > * Hardware cursor support
> > @@ -359,7 +361,6 @@ static inline void wait_for_idle(struct
> >
> > extern void aty_reset_engine(const struct atyfb_par *par);
> > extern void aty_init_engine(struct atyfb_par *par, struct fb_info *info);
> > -extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
> >
> > void atyfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);
> > void atyfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
> > Index: linux-stable/drivers/video/fbdev/aty/atyfb_base.c
> > ===
> > --- linux-stable.orig/drivers/video/fbdev/aty/atyfb_base.c 2018-08-13
> > 21:12:11.0 +0200
> > +++ linux-stable/drivers/video/fbdev/aty/atyfb_base.c 2018-08-13
> > 21:22:23.0 +0200
> > @@ -3087,17 +3087,18 @@ static int atyfb_setup_sparc(struct pci_
> > /*
> > * PLL Reference Divider M:
> > */
> > - M = pll_regs[2];
> > + M = pll_regs[PLL_REF_DIV];
> >
> > /*
> > * PLL Feedback Divider N (Dependent on CLOCK_CNTL):
> > */
> > - N = pll_regs[7 + (clock_cntl & 3)];
> > + N = pll_regs[VCLK0_FB_DIV + (clock_cntl & 3)];
> >
> > /*
> > * PLL Post Divider P (Dependent on CLOCK_CNTL):
> > */
> > - P = 1 << (pll_regs[6] >> ((clock_cntl & 3) << 1));
> > + P = aty_postdividers[((pll_regs[VCLK_POST_DIV] >> ((clock_cntl
> > & 3) << 1)) & 3) |
> > +((pll_regs[PLL_EXT_CNTL] >> (2 +
> > (clock_cntl & 3))) & 4)];
> >
> > /*
> > * PLL Divider Q:
> > Index: linux-stable/drivers/video/fbdev/aty/mach64_ct.c
> > ===
> > --- linux-stable.orig/drivers/video/fbdev/aty/mach64_ct.c 2018-08-13
> > 21:12:11.0 +0200
> > +++ linux-stable/drivers/video/fbdev/aty/mach64_ct.c2018-08-13
> > 21:35:32.0 +0200
> > @@ -115,7 +115,7 @@ static void aty_st_pll_ct(int offset, u8
> > */
> >
> > #define Maximum_DSP_PRECISION 7
> > -static u8 postdividers[] = {1,2,4,8,3};
> > +const u8 aty_postdividers[8] = {1,2,4,8,3,5,6,12};
>
> Not sure about the '5'. That setting is marked as reserved in my docs.
> So I guess it doesn't really matter what number we put there.
I downloaded documentation here:
http://ftp.nluug.nl/ftp/pub/NetBSD/misc/cegger/hw_manuals/ati/mach64_and_ragepro/
The RAGE XL/XC Register Reference Guide - at page 4-77 it says "select
alternate post dividers", but doesn't say what they are.
At page 4-89 it lists post dividers
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 1:49 PM, Laurent Pinchart wrote: > On Thursday, 23 August 2018 20:48:40 EEST John Stultz wrote: >> On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter wrote: >> > On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote: >> >> Possibly slightly out of topic, but we're in 2018, is there any plan to >> >> make SurfaceFlinger move away from FBDEV ? >> > >> > Is surfaceflinger really using direct fbdev still (maybe for boot-up)? Or >> > is this just an artifact of the mali blob hwcomposer backend? >> >> Mostly its due to the simple fbdev being a legacy solution on android >> that works out of the box. >> I do suspect the android devs hope to retire it, which is why I'm >> working on getting things going w/ the drm_hwcomposer right now so we >> can get away from the fbdev. > > That would be good news. Are there many Android components other than vendor- > specific hwcomposer implementations that still use fbdev ? So yea, I can't really speak about what the various vendors are doing, as I don't really know, but I'm aware there are still a few (in some cases major) vendors who still use fbdev on their shipping devices with their custom hwcomposer code. Other then that, to my knowledge AOSP only has a default fallback hwcomposer that uses fbdev, which is what we've used here as we didn't want to take the vendor's proprietary hwcomposer blob. But again, moving to the drm_hwcomposer is the shiny bright future, as soon as a few remaining issues are sorted upstream. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next-fixes for -rc1 part 2
Hi Dave, One more patch snuck in between my PR and today. drm-misc-next-fixes-2018-08-23-1: - Add quirk to Lenovo B50-80 to use 6 bpc instead of 8 (Feng) Cc: Kai-Heng Feng Cheers, Sean The following changes since commit 4acd8d01a2393f2145ad1db10b2d5c764582a98d: MAINTAINERS: drm-misc: Change seanpaul's email address (2018-08-16 11:48:24 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-08-23-1 for you to fetch changes up to 25da75043f8690fd083878447c91f289dfb63b87: drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80 (2018-08-23 10:25:39 +0200) - Add quirk to Lenovo B50-80 to use 6 bpc instead of 8 (Feng) Cc: Kai-Heng Feng Kai-Heng Feng (1): drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80 drivers/gpu/drm/drm_edid.c | 3 +++ 1 file changed, 3 insertions(+) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
Hi John, On Thursday, 23 August 2018 20:48:40 EEST John Stultz wrote: > On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter wrote: > > On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote: > >> On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote: > >>> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: > Hey Noralf, all, > > I've been digging for a bit on the regression that this patch has > > tripped on the HiKey board as reported here: > https://lkml.org/lkml/2018/8/16/81 > > The first issue was that the kirin driver was setting > mode_config.max_width/height = 2048, which was causing errors as the > the requested resolution was 1920x2160 (due to surfaceflinger > requesting y*2 for page flipping). > >>> > >>> Hey Noralf, > >>> > >>> Sorry, I know your probably sick of me. But I just wanted to circle > >>> > >>> around on this little bit. So part of the issue I found earlier, was > >>> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support > >>> Surfaceflinger's request for page flipping. > >> > >> Possibly slightly out of topic, but we're in 2018, is there any plan to > >> make SurfaceFlinger move away from FBDEV ? > > > > Is surfaceflinger really using direct fbdev still (maybe for boot-up)? Or > > is this just an artifact of the mali blob hwcomposer backend? > > Mostly its due to the simple fbdev being a legacy solution on android > that works out of the box. > I do suspect the android devs hope to retire it, which is why I'm > working on getting things going w/ the drm_hwcomposer right now so we > can get away from the fbdev. That would be good news. Are there many Android components other than vendor- specific hwcomposer implementations that still use fbdev ? > But in the meantime, keeping the fbdev method running is important so we > have a functioning device for testing AOSP w/ mainline. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107666] st_sampler_view.c:546 assert
https://bugs.freedesktop.org/show_bug.cgi?id=107666 Bug ID: 107666 Summary: st_sampler_view.c:546 assert Product: Mesa Version: 18.2 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: mar...@serafean.cz QA Contact: dri-devel@lists.freedesktop.org mesa 18.2.0_rc4 lspci: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] glxinfo: Device: AMD CAYMAN (DRM 2.50.0 / 4.17.14-gentoo, LLVM 6.0.1) (0x6719) Version: 18.2.0 Using Kodi to watch tv using the HTSP plugin, using VDPAU for decoding: kodi.bin: ../mesa-18.2.0-rc4/src/mesa/state_tracker/st_sampler_view.c:546: st_get_texture_sampler_view_from_stobj: Assertion `stObj->level_override || last_level(stObj) == view->u.tex.last_level' failed. VAAPI decoding works. -- 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 07/23] drm/dsc: Define Display Stream Compression PPS infoframe
Thanks for the review.
And yes it just removes the bitfields in PPS since the packing of the
bitfields and memory allocations are heavily dependent on HW.
So we cant have them in DRM level.
I will make sure to add this in version history and also add
Suggested-by: jani.nik...@linux.intel.com
Manasi
On Thu, Aug 23, 2018 at 03:40:12PM -0400, Harry Wentland wrote:
> On 2018-07-31 05:07 PM, Manasi Navare wrote:
> > This patch defines a new header file for all the DSC 1.2 structures
> > and creates a structure for PPS infoframe which will be used to send
> > picture parameter set secondary data packet for display stream compression.
> > All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> > from VESA.
> >
> > Cc: Gaurav K Singh
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Harry Wentland
> > Signed-off-by: Manasi Navare
>
> Looks like this version basically removes the bitfield definitions and adds
> those
> in the comments, compared to the review in May.
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> > include/drm/drm_dsc.h | 365
> > ++
> > 1 file changed, 365 insertions(+)
> > create mode 100644 include/drm/drm_dsc.h
> >
> > diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> > new file mode 100644
> > index 000..678e8e6
> > --- /dev/null
> > +++ b/include/drm/drm_dsc.h
> > @@ -0,0 +1,365 @@
> > +/*
> > + * Copyright (C) 2018 Intel Corp.
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included
> > in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + *
> > + * Authors:
> > + * Manasi Navare
> > + */
> > +
> > +#ifndef DRM_DSC_H_
> > +#define DRM_DSC_H_
> > +
> > +#include
> > +
> > +/* VESA Display Stream Compression DSC 1.2 constants */
> > +#define DSC_NUM_BUF_RANGES 15
> > +
> > +/**
> > + * struct picture_parameter_set - Represents 128 bytes of Picture
> > Parameter Set
> > + *
> > + * The VESA DSC standard defines picture parameter set (PPS) which display
> > + * stream compression encoders must communicate to decoders.
> > + * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The
> > fields in
> > + * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
> > + * The PPS fields that span over more than a byte should be stored in Big
> > Endian
> > + * format.
> > + */
> > +struct picture_parameter_set {
> > + /**
> > +* @dsc_version:
> > +* PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
> > +* PPS0[7:4] - dsc_version_major: Contains major version of DSC
> > +*/
> > + u8 dsc_version;
> > + /**
> > +* @pps_identifier:
> > +* PPS1[7:0] - Application specific identifier that can be
> > +* used to differentiate between different PPS tables.
> > +*/
> > + u8 pps_identifier;
> > + /**
> > +* @pps_reserved:
> > +* PPS2[7:0]- RESERVED Byte
> > +*/
> > + u8 pps_reserved;
> > + /**
> > +* @pps_3:
> > +* PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
> > +* generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
> > +* 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> > +* 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> > +* PPS3[7:4] - bits_per_component: Bits per component for the original
> > +* pixels of the encoded picture.
> > +* 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
> > +* 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
> > +* allowed only when dsc_minor_version = 0x2)
> > +*/
> > + u8 pps_3;
> > + /**
> > +* @pps_4:
> > +* PPS4[1:0] -These are the most significant 2 bits of
> > +* compressed BPP bits_per_pixel[9:0] syntax element.
> > +* PPS4[2] - vbr_enable: 0 = VBR disabled, 1 = VBR enabled
> > +* PPS4[3] - simple_422:
Re: [PATCH v2 07/23] drm/dsc: Define Display Stream Compression PPS infoframe
On Fri, Aug 17, 2018 at 12:31:51PM -0700, Srivatsa, Anusha wrote:
> This patch needs to now incorporate the newly added slice_row_per_frame
> parameter in PPS_16.
Nope, the slice_row_per_frame and slice_per_line are only required to configure
PPS
on the source side. They are not DSC spec related PPS parameters.
Manasi
>
> Anusha
>
> >-Original Message-
> >From: Navare, Manasi D
> >Sent: Tuesday, July 31, 2018 2:07 PM
> >To: intel-...@lists.freedesktop.org
> >Cc: Navare, Manasi D ; Singh, Gaurav K
> >; dri-devel@lists.freedesktop.org; Jani Nikula
> >; Ville Syrjala ;
> >Srivatsa, Anusha ; Harry Wentland
> >
> >Subject: [PATCH v2 07/23] drm/dsc: Define Display Stream Compression PPS
> >infoframe
> >
> >This patch defines a new header file for all the DSC 1.2 structures and
> >creates a
> >structure for PPS infoframe which will be used to send picture parameter set
> >secondary data packet for display stream compression.
> >All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> >from
> >VESA.
> >
> >Cc: Gaurav K Singh
> >Cc: dri-devel@lists.freedesktop.org
> >Cc: Jani Nikula
> >Cc: Ville Syrjala
> >Cc: Anusha Srivatsa
> >Cc: Harry Wentland
> >Signed-off-by: Manasi Navare
> >---
> > include/drm/drm_dsc.h | 365
> >++
> > 1 file changed, 365 insertions(+)
> > create mode 100644 include/drm/drm_dsc.h
> >
> >diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h new file mode
> >100644 index 000..678e8e6
> >--- /dev/null
> >+++ b/include/drm/drm_dsc.h
> >@@ -0,0 +1,365 @@
> >+/*
> >+ * Copyright (C) 2018 Intel Corp.
> >+ *
> >+ * Permission is hereby granted, free of charge, to any person
> >+obtaining a
> >+ * copy of this software and associated documentation files (the
> >+"Software"),
> >+ * to deal in the Software without restriction, including without
> >+limitation
> >+ * the rights to use, copy, modify, merge, publish, distribute,
> >+sublicense,
> >+ * and/or sell copies of the Software, and to permit persons to whom
> >+the
> >+ * Software is furnished to do so, subject to the following conditions:
> >+ *
> >+ * The above copyright notice and this permission notice shall be
> >+included in
> >+ * all copies or substantial portions of the Software.
> >+ *
> >+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> >+EXPRESS OR
> >+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> >+MERCHANTABILITY,
> >+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> >EVENT
> >+SHALL
> >+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> >+DAMAGES OR
> >+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> >+OTHERWISE,
> >+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> >USE
> >+OR
> >+ * OTHER DEALINGS IN THE SOFTWARE.
> >+ *
> >+ * Authors:
> >+ * Manasi Navare */
> >+
> >+#ifndef DRM_DSC_H_
> >+#define DRM_DSC_H_
> >+
> >+#include
> >+
> >+/* VESA Display Stream Compression DSC 1.2 constants */
> >+#define DSC_NUM_BUF_RANGES 15
> >+
> >+/**
> >+ * struct picture_parameter_set - Represents 128 bytes of Picture
> >+Parameter Set
> >+ *
> >+ * The VESA DSC standard defines picture parameter set (PPS) which
> >+display
> >+ * stream compression encoders must communicate to decoders.
> >+ * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The
> >+fields in
> >+ * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
> >+ * The PPS fields that span over more than a byte should be stored in
> >+Big Endian
> >+ * format.
> >+ */
> >+struct picture_parameter_set {
> >+/**
> >+ * @dsc_version:
> >+ * PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
> >+ * PPS0[7:4] - dsc_version_major: Contains major version of DSC
> >+ */
> >+u8 dsc_version;
> >+/**
> >+ * @pps_identifier:
> >+ * PPS1[7:0] - Application specific identifier that can be
> >+ * used to differentiate between different PPS tables.
> >+ */
> >+u8 pps_identifier;
> >+/**
> >+ * @pps_reserved:
> >+ * PPS2[7:0]- RESERVED Byte
> >+ */
> >+u8 pps_reserved;
> >+/**
> >+ * @pps_3:
> >+ * PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
> >+ * generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
> >+ * 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> >+ * 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> >+ * PPS3[7:4] - bits_per_component: Bits per component for the original
> >+ * pixels of the encoded picture.
> >+ * 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
> >+ * 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
> >+ * allowed only when dsc_minor_version = 0x2)
> >+ */
> >+u8 pps_3;
> >+/**
> >+ * @pps_4:
> >+ * PPS4[1:0] -These are the most significant 2 bits of
> >+ * compressed BPP bits_per_pixel[9:0] syntax element.
> >+ *
Re: [PATCH v2 08/23] drm/dsc: Define VESA Display Stream Compression Capabilities
On 2018-07-31 05:07 PM, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This defines all the DSC parameters as per the VESA DSC spec
> that will be required for DSC encoder/decoder
>
> v4 (From Manasi)
> * Add the DSC_MUX_WORD_SIZE constants (Manasi)
>
> v3 (From Manasi)
> * Remove the duplicate define (Suggested By:Harry Wentland)
>
> v2: Define this struct in DRM (From Manasi)
> * Changed the data types to u8/u16 instead of unsigned longs (Manasi)
> * Remove driver specific fields (Manasi)
> * Move this struct definition to DRM (Manasi)
> * Define DSC 1.2 parameters (Manasi)
> * Use DSC_NUM_BUF_RANGES (Manasi)
> * Call it drm_dsc_config (Manasi)
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Harry Wentland
> Signed-off-by: Manasi Navare
> Signed-off-by: Gaurav K Singh
Acked-by: Harry Wentland
Harry
> ---
> include/drm/drm_dsc.h | 110
> ++
> 1 file changed, 110 insertions(+)
>
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> index 678e8e6..eda323d 100644
> --- a/include/drm/drm_dsc.h
> +++ b/include/drm/drm_dsc.h
> @@ -30,6 +30,116 @@
>
> /* VESA Display Stream Compression DSC 1.2 constants */
> #define DSC_NUM_BUF_RANGES 15
> +#define DSC_MUX_WORD_SIZE_8_10_BPC 48
> +#define DSC_MUX_WORD_SIZE_12_BPC 64
> +
> +/* Configuration for a single Rate Control model range */
> +struct dsc_rc_range_parameters {
> + /* Min Quantization Parameters allowed for this range */
> + u8 range_min_qp;
> + /* Max Quantization Parameters allowed for this range */
> + u8 range_max_qp;
> + /* Bits/group offset to apply to target for this group */
> + u8 range_bpg_offset;
> +};
> +
> +struct drm_dsc_config {
> + /* Bits / component for previous reconstructed line buffer */
> + u8 line_buf_depth;
> + /* Bits per component to code (must be 8, 10, or 12) */
> + u8 bits_per_component;
> + /*
> + * Flag indicating to do RGB - YCoCg conversion
> + * and back (should be 1 for RGB input)
> + */
> + bool convert_rgb;
> + u8 slice_count;
> + /* Slice Width */
> + u16 slice_width;
> + /* Slice Height */
> + u16 slice_height;
> + /*
> + * 4:2:2 enable mode (from PPS, 4:2:2 conversion happens
> + * outside of DSC encode/decode algorithm)
> + */
> + bool enable422;
> + /* Picture Width */
> + u16 pic_width;
> + /* Picture Height */
> + u16 pic_height;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_high;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_low;
> + /* Bits/pixel target << 4 (ie., 4 fractional bits) */
> + u16 bits_per_pixel;
> + /*
> + * Factor to determine if an edge is present based
> + * on the bits produced
> + */
> + u8 rc_edge_factor;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit1;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit0;
> + /* Number of pixels to delay the initial transmission */
> + u16 initial_xmit_delay;
> + /* Number of pixels to delay the VLD on the decoder,not including SSM */
> + u16 initial_dec_delay;
> + /* Block prediction enable */
> + bool block_pred_enable;
> + /* Bits/group offset to use for first line of the slice */
> + u8 first_line_bpg_offset;
> + /* Value to use for RC model offset at slice start */
> + u16 initial_offset;
> + /* Thresholds defining each of the buffer ranges */
> + u16 rc_buf_thresh[DSC_NUM_BUF_RANGES - 1];
> + /* Parameters for each of the RC ranges */
> + struct dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
> + /* Total size of RC model */
> + u16 rc_model_size;
> + /* Minimum QP where flatness information is sent */
> + u8 flatness_min_qp;
> + /* Maximum QP where flatness information is sent */
> + u8 flatness_max_qp;
> + /* Initial value for scale factor */
> + u8 initial_scale_value;
> + /* Decrement scale factor every scale_decrement_interval groups */
> + u16 scale_decrement_interval;
> + /* Increment scale factor every scale_increment_interval groups */
> + u16 scale_increment_interval;
> + /* Non-first line BPG offset to use */
> + u16 nfl_bpg_offset;
> + /* BPG offset used to enforce slice bit */
> + u16 slice_bpg_offset;
> + /* Final RC linear transformation offset value */
> + u16 final_offset;
> + /* Enable on-off VBR (ie., disable stuffing bits) */
> + bool vbr_enable;
> + /* Mux word size (in bits) for SSM mode */
> + u8 mux_word_size;
> + /*
> + * The (max) size in bytes of the "chunks" that are
> + * used in slice multiplexing
> + */
> + u16 slice_chunk_size;
> + /* Rate
Re: [PATCH v2 10/23] drm/dsc: Add helpers for DSC picture parameter set infoframes
On 2018-07-31 05:07 PM, Manasi Navare wrote:
> According to Display Stream compression spec 1.2, the picture
> parameter set metadata is sent from source to sink device
> using the DP Secondary data packet. An infoframe is formed
> for the PPS SDP header and PPS SDP payload bytes.
> This patch adds helpers to fill the PPS SDP header
> and PPS SDP payload according to the DSC 1.2 specification.
>
> v5:
> Do not use bitfields for DRM structs (Jani N)
> v4:
> * Use DSC constants for params that dont change across
> configurations
> v3:
> * Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst
> (Daniel Vetter)
>
> v2:
> * Add EXPORT_SYMBOL for the drm functions (Manasi)
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Harry Wentland
> Signed-off-by: Manasi Navare
Acked-by: Harry Wentland
Harry
> ---
> Documentation/gpu/drm-kms-helpers.rst | 12 ++
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_dsc.c | 221
> ++
> include/drm/drm_dsc.h | 22
> 4 files changed, 256 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/drm_dsc.c
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index f9cfcdc..50bb717 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -223,6 +223,18 @@ MIPI DSI Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
> :export:
>
> +Display Stream Compression Helper Functions Reference
> +=
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> + :doc: dsc helpers
> +
> +.. kernel-doc:: include/drm/drm_dsc.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> + :export:
> +
> Output Probing Helper Functions Reference
> =
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index a6771ce..961e511 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -31,7 +31,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>
> -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
> drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> drm_simple_kms_helper.o drm_modeset_helper.o \
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> new file mode 100644
> index 000..99a8794
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -0,0 +1,221 @@
> +/*
> + *Copyright © 2018 Intel Corp
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that
> copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission. The copyright holders make no representations
> + * about the suitability of this software for any purpose. It is provided
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
> USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> PERFORMANCE
> + * OF THIS SOFTWARE.
> + *
> + * Author:
> + * Manasi Navare
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * DOC: dsc helpers
> + *
> + * These functions contain some common logic and helpers to deal with VESA
> + * Display Stream Compression standard required for DSC on Display Port/eDP
> or
> + * MIPI display interfaces.
> + */
> +
> +/**
> + * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
> + * for DisplayPort as per the DP 1.4 spec.
> + * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
> + */
> +void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
> +{
> + memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
> +
> + pps_sdp->pps_header.HB1 = DP_SDP_PPS;
> + pps_sdp->pps_header.HB2 =
Re: [PATCH v2 07/23] drm/dsc: Define Display Stream Compression PPS infoframe
On 2018-07-31 05:07 PM, Manasi Navare wrote:
> This patch defines a new header file for all the DSC 1.2 structures
> and creates a structure for PPS infoframe which will be used to send
> picture parameter set secondary data packet for display stream compression.
> All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> from VESA.
>
> Cc: Gaurav K Singh
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Harry Wentland
> Signed-off-by: Manasi Navare
Looks like this version basically removes the bitfield definitions and adds
those
in the comments, compared to the review in May.
Reviewed-by: Harry Wentland
Harry
> ---
> include/drm/drm_dsc.h | 365
> ++
> 1 file changed, 365 insertions(+)
> create mode 100644 include/drm/drm_dsc.h
>
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> new file mode 100644
> index 000..678e8e6
> --- /dev/null
> +++ b/include/drm/drm_dsc.h
> @@ -0,0 +1,365 @@
> +/*
> + * Copyright (C) 2018 Intel Corp.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + * Manasi Navare
> + */
> +
> +#ifndef DRM_DSC_H_
> +#define DRM_DSC_H_
> +
> +#include
> +
> +/* VESA Display Stream Compression DSC 1.2 constants */
> +#define DSC_NUM_BUF_RANGES 15
> +
> +/**
> + * struct picture_parameter_set - Represents 128 bytes of Picture Parameter
> Set
> + *
> + * The VESA DSC standard defines picture parameter set (PPS) which display
> + * stream compression encoders must communicate to decoders.
> + * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The fields
> in
> + * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
> + * The PPS fields that span over more than a byte should be stored in Big
> Endian
> + * format.
> + */
> +struct picture_parameter_set {
> + /**
> + * @dsc_version:
> + * PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
> + * PPS0[7:4] - dsc_version_major: Contains major version of DSC
> + */
> + u8 dsc_version;
> + /**
> + * @pps_identifier:
> + * PPS1[7:0] - Application specific identifier that can be
> + * used to differentiate between different PPS tables.
> + */
> + u8 pps_identifier;
> + /**
> + * @pps_reserved:
> + * PPS2[7:0]- RESERVED Byte
> + */
> + u8 pps_reserved;
> + /**
> + * @pps_3:
> + * PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
> + * generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
> + * 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> + * 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> + * PPS3[7:4] - bits_per_component: Bits per component for the original
> + * pixels of the encoded picture.
> + * 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
> + * 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
> + * allowed only when dsc_minor_version = 0x2)
> + */
> + u8 pps_3;
> + /**
> + * @pps_4:
> + * PPS4[1:0] -These are the most significant 2 bits of
> + * compressed BPP bits_per_pixel[9:0] syntax element.
> + * PPS4[2] - vbr_enable: 0 = VBR disabled, 1 = VBR enabled
> + * PPS4[3] - simple_422: Indicates if decoder drops samples to
> + * reconstruct the 4:2:2 picture.
> + * PPS4[4] - Convert_rgb: Indicates if DSC color space conversion is
> + * active.
> + * PPS4[5] - blobk_pred_enable: Indicates if BP is used to code any
> + * groups in picture
> + * PPS4[7:6] - Reseved bits
> + */
> + u8 pps_4;
> + /**
> + * @bits_per_pixel_low:
> + * PPS5[7:0] - This indicates the lower significant 8 bits of
> + * the compressed BPP bits_per_pixel[9:0] element.
> + */
> + u8
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #29 from Andrey Grodzovsky --- (In reply to Jan Jurzitza from comment #28) > (In reply to Andrey Grodzovsky from comment #25) > > Still same issue happening here on both projects built from git. One issue > here which doesn't seem completely related: > Aug 23 20:41:20 archlinux kernel: [ cut here ] > Aug 23 20:41:20 archlinux kernel: CPU update of VM recommended only for > large BAR system > Aug 23 20:41:20 archlinux kernel: WARNING: CPU: 5 PID: 1092 at > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:2606 amdgpu_vm_init+0x477/0x490 > [amdgpu] > Aug 23 20:41:20 archlinux kernel: Modules linked in: bnep nct6775 hwmon_vid > joydev btusb btrtl btbcm btintel bluetooth snd_usb_audio snd_usbmidi_lib > snd_rawmidi input_leds snd_seq_device ecdh_generic mousedev nls_iso8859_1 > nls_cp437 vfat fat btrfs zstd_compress libcrc32c zstd_decompress xxhash xor > arc4 amdkfd amd_iommu_v2 amdgpu iwlmvm mac80211 edac_mce_amd led_class > kvm_amd iwlwifi snd_hda_codec_realtek chash gpu_sched kvm snd_hda_codec_hdmi > snd_hda_codec_generic ttm snd_hda_intel drm_kms_helper irqbypass > snd_hda_codec cfg80211 morus1280_avx2 drm morus1280_sse2 morus1280_glue > morus640_sse2 morus640_glue snd_hda_core aegis256_aesni aegis128l_aesni > aegis128_aesni igb snd_hwdep crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel snd_pcm pcbc snd_timer agpgart evdev ccp sp5100_tco > aesni_intel snd syscopyarea i2c_algo_bit sysfillrect > Aug 23 20:41:20 archlinux kernel: aes_x86_64 wmi_bmof mac_hid crypto_simd > sysimgblt raid6_pq cryptd glue_helper fb_sys_fops soundcore k10temp > i2c_piix4 dca rfkill rng_core wmi button acpi_cpufreq sch_fq_codel > vboxnetflt(O) vboxnetadp(O) pci_stub vboxpci(O) vboxdrv(O) sg crypto_user > ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto sr_mod > cdrom sd_mod uas usb_storage hid_uclogic hid_generic usbhid hid ahci libahci > xhci_pci libata crc32c_intel xhci_hcd usbcore scsi_mod usb_common > Aug 23 20:41:20 archlinux kernel: CPU: 5 PID: 1092 Comm: Xorg.wrap Tainted: > G O 4.18.0-rc1-5024f8dfe478 #1 > Aug 23 20:41:20 archlinux kernel: Hardware name: To Be Filled By O.E.M. To > Be Filled By O.E.M./X370 Gaming-ITX/ac, BIOS P3.40 11/07/2017 > Aug 23 20:41:20 archlinux kernel: RIP: 0010:amdgpu_vm_init+0x477/0x490 > [amdgpu] > Aug 23 20:41:20 archlinux kernel: Code: b8 08 d8 ff ff e8 79 89 7c e8 e9 ee > fe ff ff 41 89 ef e9 e6 fe ff ff 48 c7 c7 08 65 f0 c0 c6 05 41 af 2b 00 01 > e8 a3 8f 37 e8 <0f> 0b 0f b6 8b 60 01 00 00 e9 b4 fc ff ff e8 26 8d 37 e8 66 > 0f 1f > Aug 23 20:41:20 archlinux kernel: RSP: 0018:acc2c8df7b60 EFLAGS: 00010286 > Aug 23 20:41:20 archlinux kernel: RAX: RBX: > 9b10f7bf9000 RCX: 0006 > Aug 23 20:41:20 archlinux kernel: RDX: 0007 RSI: > 0002 RDI: 9b10fe7564d0 > Aug 23 20:41:20 archlinux kernel: RBP: 9b10f564 R08: > 001856da5330 R09: 0036 > Aug 23 20:41:20 archlinux kernel: R10: 0424 R11: > 0006ad48 R12: 9b10f7bf90b8 > Aug 23 20:41:20 archlinux kernel: R13: 000a R14: > R15: > Aug 23 20:41:20 archlinux kernel: FS: 7fcf6cc95500() > GS:9b10fe74() knlGS: > Aug 23 20:41:20 archlinux kernel: CS: 0010 DS: ES: CR0: > 80050033 > Aug 23 20:41:20 archlinux kernel: CR2: 7fcf6cb1d960 CR3: > 0007e119 CR4: 003406e0 > Aug 23 20:41:20 archlinux kernel: Call Trace: > Aug 23 20:41:20 archlinux kernel: ? ida_simple_get+0x91/0xf0 > Aug 23 20:41:20 archlinux kernel: amdgpu_driver_open_kms+0x83/0x1d0 [amdgpu] > Aug 23 20:41:20 archlinux kernel: drm_open+0x20b/0x440 [drm] > Aug 23 20:41:20 archlinux kernel: drm_stub_open+0xaf/0xf0 [drm] > Aug 23 20:41:20 archlinux kernel: chrdev_open+0xa3/0x1b0 > Aug 23 20:41:20 archlinux kernel: ? cdev_put.part.3+0x20/0x20 > Aug 23 20:41:20 archlinux kernel: do_dentry_open+0x1ab/0x2d0 > Aug 23 20:41:20 archlinux kernel: path_openat+0x31b/0x1440 > Aug 23 20:41:20 archlinux kernel: ? alloc_set_pte+0x1fd/0x4e0 > Aug 23 20:41:20 archlinux kernel: do_filp_open+0x93/0x100 > Aug 23 20:41:20 archlinux kernel: ? __check_object_size+0x9c/0x171 > Aug 23 20:41:20 archlinux kernel: do_sys_open+0x186/0x210 > Aug 23 20:41:20 archlinux kernel: do_syscall_64+0x4e/0x100 > Aug 23 20:41:20 archlinux kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 > Aug 23 20:41:20 archlinux kernel: RIP: 0033:0x7fcf6cbbc452 > Aug 23 20:41:20 archlinux kernel: Code: 25 00 00 41 00 3d 00 00 41 00 74 4c > 48 8d 05 f5 70 0d 00 8b 00 85 c0 75 6d 89 f2 b8 01 01 00 00 48 89 fe bf 9c > ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a2 00 00 00 48 8b 4c 24 28 64 48 33 > 0c 25 > Aug 23 20:41:20 archlinux kernel: RSP: 002b:7ffe9a15b0a0 EFLAGS: > 0246 ORIG_RAX: 0101 > Aug 23 20:41:20 archlinux kernel: RAX: ffda RBX: > RCX:
[Bug 104284] [IGT] some gem_exec_fence Failed assertion: __gem_execbuf(fd, execbuf) == 0
https://bugs.freedesktop.org/show_bug.cgi?id=104284 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #18 from Lakshmi --- No failures noticed for gem_exec_fence tests. Closing the defect as fixed. -- 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 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #28 from Jan Jurzitza --- (In reply to Andrey Grodzovsky from comment #25) Still same issue happening here on both projects built from git. One issue here which doesn't seem completely related: Aug 23 20:41:20 archlinux kernel: [ cut here ] Aug 23 20:41:20 archlinux kernel: CPU update of VM recommended only for large BAR system Aug 23 20:41:20 archlinux kernel: WARNING: CPU: 5 PID: 1092 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:2606 amdgpu_vm_init+0x477/0x490 [amdgpu] Aug 23 20:41:20 archlinux kernel: Modules linked in: bnep nct6775 hwmon_vid joydev btusb btrtl btbcm btintel bluetooth snd_usb_audio snd_usbmidi_lib snd_rawmidi input_leds snd_seq_device ecdh_generic mousedev nls_iso8859_1 nls_cp437 vfat fat btrfs zstd_compress libcrc32c zstd_decompress xxhash xor arc4 amdkfd amd_iommu_v2 amdgpu iwlmvm mac80211 edac_mce_amd led_class kvm_amd iwlwifi snd_hda_codec_realtek chash gpu_sched kvm snd_hda_codec_hdmi snd_hda_codec_generic ttm snd_hda_intel drm_kms_helper irqbypass snd_hda_codec cfg80211 morus1280_avx2 drm morus1280_sse2 morus1280_glue morus640_sse2 morus640_glue snd_hda_core aegis256_aesni aegis128l_aesni aegis128_aesni igb snd_hwdep crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_pcm pcbc snd_timer agpgart evdev ccp sp5100_tco aesni_intel snd syscopyarea i2c_algo_bit sysfillrect Aug 23 20:41:20 archlinux kernel: aes_x86_64 wmi_bmof mac_hid crypto_simd sysimgblt raid6_pq cryptd glue_helper fb_sys_fops soundcore k10temp i2c_piix4 dca rfkill rng_core wmi button acpi_cpufreq sch_fq_codel vboxnetflt(O) vboxnetadp(O) pci_stub vboxpci(O) vboxdrv(O) sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto sr_mod cdrom sd_mod uas usb_storage hid_uclogic hid_generic usbhid hid ahci libahci xhci_pci libata crc32c_intel xhci_hcd usbcore scsi_mod usb_common Aug 23 20:41:20 archlinux kernel: CPU: 5 PID: 1092 Comm: Xorg.wrap Tainted: G O 4.18.0-rc1-5024f8dfe478 #1 Aug 23 20:41:20 archlinux kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X370 Gaming-ITX/ac, BIOS P3.40 11/07/2017 Aug 23 20:41:20 archlinux kernel: RIP: 0010:amdgpu_vm_init+0x477/0x490 [amdgpu] Aug 23 20:41:20 archlinux kernel: Code: b8 08 d8 ff ff e8 79 89 7c e8 e9 ee fe ff ff 41 89 ef e9 e6 fe ff ff 48 c7 c7 08 65 f0 c0 c6 05 41 af 2b 00 01 e8 a3 8f 37 e8 <0f> 0b 0f b6 8b 60 01 00 00 e9 b4 fc ff ff e8 26 8d 37 e8 66 0f 1f Aug 23 20:41:20 archlinux kernel: RSP: 0018:acc2c8df7b60 EFLAGS: 00010286 Aug 23 20:41:20 archlinux kernel: RAX: RBX: 9b10f7bf9000 RCX: 0006 Aug 23 20:41:20 archlinux kernel: RDX: 0007 RSI: 0002 RDI: 9b10fe7564d0 Aug 23 20:41:20 archlinux kernel: RBP: 9b10f564 R08: 001856da5330 R09: 0036 Aug 23 20:41:20 archlinux kernel: R10: 0424 R11: 0006ad48 R12: 9b10f7bf90b8 Aug 23 20:41:20 archlinux kernel: R13: 000a R14: R15: Aug 23 20:41:20 archlinux kernel: FS: 7fcf6cc95500() GS:9b10fe74() knlGS: Aug 23 20:41:20 archlinux kernel: CS: 0010 DS: ES: CR0: 80050033 Aug 23 20:41:20 archlinux kernel: CR2: 7fcf6cb1d960 CR3: 0007e119 CR4: 003406e0 Aug 23 20:41:20 archlinux kernel: Call Trace: Aug 23 20:41:20 archlinux kernel: ? ida_simple_get+0x91/0xf0 Aug 23 20:41:20 archlinux kernel: amdgpu_driver_open_kms+0x83/0x1d0 [amdgpu] Aug 23 20:41:20 archlinux kernel: drm_open+0x20b/0x440 [drm] Aug 23 20:41:20 archlinux kernel: drm_stub_open+0xaf/0xf0 [drm] Aug 23 20:41:20 archlinux kernel: chrdev_open+0xa3/0x1b0 Aug 23 20:41:20 archlinux kernel: ? cdev_put.part.3+0x20/0x20 Aug 23 20:41:20 archlinux kernel: do_dentry_open+0x1ab/0x2d0 Aug 23 20:41:20 archlinux kernel: path_openat+0x31b/0x1440 Aug 23 20:41:20 archlinux kernel: ? alloc_set_pte+0x1fd/0x4e0 Aug 23 20:41:20 archlinux kernel: do_filp_open+0x93/0x100 Aug 23 20:41:20 archlinux kernel: ? __check_object_size+0x9c/0x171 Aug 23 20:41:20 archlinux kernel: do_sys_open+0x186/0x210 Aug 23 20:41:20 archlinux kernel: do_syscall_64+0x4e/0x100 Aug 23 20:41:20 archlinux kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Aug 23 20:41:20 archlinux kernel: RIP: 0033:0x7fcf6cbbc452 Aug 23 20:41:20 archlinux kernel: Code: 25 00 00 41 00 3d 00 00 41 00 74 4c 48 8d 05 f5 70 0d 00 8b 00 85 c0 75 6d 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a2 00 00 00 48 8b 4c 24 28 64 48 33 0c 25 Aug 23 20:41:20 archlinux kernel: RSP: 002b:7ffe9a15b0a0 EFLAGS: 0246 ORIG_RAX: 0101 Aug 23 20:41:20 archlinux kernel: RAX: ffda RBX: RCX: 7fcf6cbbc452 Aug 23 20:41:20 archlinux kernel: RDX: 0002 RSI: 7ffe9a15b180 RDI: ff9c Aug 23 20:41:20 archlinux kernel: RBP: 7ffe9a15b130 R08: R09: Aug 23
[Bug 107572] Unrecoverable GPU hang with IP block:gfx_v8_0 is hung
https://bugs.freedesktop.org/show_bug.cgi?id=107572 --- Comment #18 from madc...@atlas.cz --- Created attachment 141261 --> https://bugs.freedesktop.org/attachment.cgi?id=141261=edit dmesg log of the crash in Unigine Superposition -- 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 107572] Unrecoverable GPU hang with IP block:gfx_v8_0 is hung
https://bugs.freedesktop.org/show_bug.cgi?id=107572 --- Comment #17 from madc...@atlas.cz --- I just ran a few tests with git/svn versions of LLVM 8.0 and mesa 18.3 and the problem is still there. I attached a dmesg log of the crash in Unigine Superposition. Just FTR the crash with LLVM 8.0/mesa 18.3 happens only on the Extreme settings, High settings survive without a hitch. -- 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 (repost) 5/5] drm/amdgpu: add DisplayPort CEC-Tunneling-over-AUX support
On 2018-08-17 10:11 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
>
> Signed-off-by: Hans Verkuil
> Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++--
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 ++
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 34f34823bab5..77898c95bef6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -898,6 +898,7 @@ amdgpu_dm_update_connector_after_detect(struct
> amdgpu_dm_connector *aconnector)
> aconnector->dc_sink = sink;
> if (sink->dc_edid.length == 0) {
> aconnector->edid = NULL;
> + drm_dp_cec_unset_edid(>dm_dp_aux.aux);
> } else {
> aconnector->edid =
> (struct edid *) sink->dc_edid.raw_edid;
> @@ -905,10 +906,13 @@ amdgpu_dm_update_connector_after_detect(struct
> amdgpu_dm_connector *aconnector)
>
> drm_connector_update_edid_property(connector,
> aconnector->edid);
> + drm_dp_cec_set_edid(>dm_dp_aux.aux,
> + aconnector->edid);
> }
> amdgpu_dm_add_sink_to_freesync_module(connector,
> aconnector->edid);
>
> } else {
> + drm_dp_cec_unset_edid(>dm_dp_aux.aux);
> amdgpu_dm_remove_sink_from_freesync_module(connector);
> drm_connector_update_edid_property(connector, NULL);
> aconnector->num_modes = 0;
> @@ -1059,12 +1063,16 @@ static void handle_hpd_rx_irq(void *param)
> drm_kms_helper_hotplug_event(dev);
> }
> }
> +
> if ((dc_link->cur_link_settings.lane_count != LANE_COUNT_UNKNOWN) ||
> - (dc_link->type == dc_connection_mst_branch))
> + (dc_link->type == dc_connection_mst_branch)) {
> dm_handle_hpd_rx_irq(aconnector);
> + }
These lines don't really add anything functional.
Either way, this patch is
Reviewed-by: Harry Wentland
Harry
>
> - if (dc_link->type != dc_connection_mst_branch)
> + if (dc_link->type != dc_connection_mst_branch) {
> + drm_dp_cec_irq(>dm_dp_aux.aux);
> mutex_unlock(>hpd_lock);
> + }
> }
>
> static void register_hpd_handlers(struct amdgpu_device *adev)
> @@ -2732,6 +2740,7 @@ static void amdgpu_dm_connector_destroy(struct
> drm_connector *connector)
> dm->backlight_dev = NULL;
> }
> #endif
> + drm_dp_cec_unregister_connector(>dm_dp_aux.aux);
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
> kfree(connector);
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 9a300732ba37..18a3a6e5ffa0 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -496,6 +496,8 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
> aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
>
> drm_dp_aux_register(>dm_dp_aux.aux);
> + drm_dp_cec_register_connector(>dm_dp_aux.aux,
> + aconnector->base.name, dm->adev->dev);
> aconnector->mst_mgr.cbs = _mst_cbs;
> drm_dp_mst_topology_mgr_init(
> >mst_mgr,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 11:16 PM Zhenyu Wang wrote: > > yeah, that's the clear way to fix this imo. We only depend on guest > life cycle to access guest memory properly. Here's proposed fix, will > verify and integrate it later. Thanks, this looks sane to me, Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Thu, Aug 23, 2018 at 08:25:46PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 23, 2018 at 06:19:31PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote:
> > > On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> > > > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> > > > wrote:
> > > > > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> > > > >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe
> > > > >> wrote:
> > > > >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> > > > >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe
> > > > >> > > wrote:
> > > > >> > > > The previous patch added tile_w and tile_h, which represent the
> > > > >> > > > horizontal and vertical sizes of a tile.
> > > > >> > > >
> > > > >> > > > This one uses that to plumb through drm core in order to be
> > > > >> > > > able to
> > > > >> > > > handle linear tile formats without the need for drivers to
> > > > >> > > > roll up
> > > > >> > > > their own implementation.
> > > > >> > > >
> > > > >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind
> > > > >> > > > which
> > > > >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in
> > > > >> > > > average 2
> > > > >> > > > bytes per pixel and where tiles are laid out in a linear
> > > > >> > > > manner.
> > > > >> > > >
> > > > >> > > > Now what are the restrictions:
> > > > >> > > >
> > > > >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width
> > > > >> > > > in
> > > > >> > > > pixels. Due to this the places where the pitch is checked/used
> > > > >> > > > need to
> > > > >> > > > be updated to take into consideration the tile_w, tile_h and
> > > > >> > > > tile_size.
> > > > >> > > > tile_size = cpp * tile_w * tile_h
> > > > >> > > >
> > > > >> > > > 2. When doing source cropping plane_src_x/y need to be a
> > > > >> > > > multiple of
> > > > >> > > > tile_w/tile_h and we need to take into consideration the
> > > > >> > > > tile_w/tile_h
> > > > >> > > > when computing the start address.
> > > > >> > > >
> > > > >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so
> > > > >> > > > if I
> > > > >> > > > didn't miss anything nothing should change.
> > > > >> > > >
> > > > >> > > > Regarding multi-planar linear tile formats, I'm not sure how
> > > > >> > > > those
> > > > >> > > > should be handle I kind of assumed that tile_h/tile_w will
> > > > >> > > > have to be
> > > > >> > > > divided by horizontal/subsampling. Anyway, I think it's best
> > > > >> > > > to just
> > > > >> > > > put an warning in there and handle it when someone tries to add
> > > > >> > > > support for them.
> > > > >> > > >
> > > > >> > > > Signed-off-by: Alexandru Gheorghe
> > > > >> > > >
> > > > >> > > > ---
> > > > >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > > >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > > >> > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > > >> > > >
> > > > >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > > >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > > >> > > > include/drm/drm_fourcc.h | 2 +
> > > > >> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > > >> > > >
> > > > >> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > >> > > > b/drivers/gpu/drm/drm_atomic.c
> > > > >> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > > >> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > >> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > >> > > > @@ -1087,6 +1087,14 @@ static int
> > > > >> > > > drm_atomic_plane_check(struct drm_plane *plane,
> > > > >> > > > return -ENOSPC;
> > > > >> > > > }
> > > > >> > > >
> > > > >> > > > + /* Make sure source coordinates are a multiple of tile
> > > > >> > > > sizes */
> > > > >> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > > >> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > > >> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source
> > > > >> > > > coordinates do not meet tile restrictions",
> > > > >> > > > +plane->base.id, plane->name);
> > > > >> > > > + return -EINVAL;
> > > > >> > > > + }
> > > > >> > >
> > > > >> > > Feels rather wrong to me to put such hardware specific
> > > > >> > > limitations into
> > > > >> > > the core.
> > > > >> >
> > > > >> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr
> > > > >> > wouldn't
> > > > >> > work.
> > > > >>
> > > > >> If that guy is supposed to give you a tile aligned address then it
> > > > >> could
> > > > >> just do that and leave it up to the driver to deal with the
> > > > >> remainder of
> > > > >> the coordinates?
> > >
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter wrote: > On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote: >> Hi John, >> >> On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote: >> > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: >> > > Hey Noralf, all, >> > > >> > > I've been digging for a bit on the regression that this patch has >> > > >> > > tripped on the HiKey board as reported here: >> > > https://lkml.org/lkml/2018/8/16/81 >> > > >> > > The first issue was that the kirin driver was setting >> > > mode_config.max_width/height = 2048, which was causing errors as the >> > > the requested resolution was 1920x2160 (due to surfaceflinger >> > > requesting y*2 for page flipping). >> > >> > Hey Noralf, >> > Sorry, I know your probably sick of me. But I just wanted to circle >> > around on this little bit. So part of the issue I found earlier, was >> > that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support >> > Surfaceflinger's request for page flipping. >> >> Possibly slightly out of topic, but we're in 2018, is there any plan to make >> SurfaceFlinger move away from FBDEV ? > > Is surfaceflinger really using direct fbdev still (maybe for boot-up)? Or > is this just an artifact of the mali blob hwcomposer backend? Mostly its due to the simple fbdev being a legacy solution on android that works out of the box. I do suspect the android devs hope to retire it, which is why I'm working on getting things going w/ the drm_hwcomposer right now so we can get away from the fbdev. But in the meantime, keeping the fbdev method running is important so we have a functioning device for testing AOSP w/ mainline. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > The previous patch added tile_w and tile_h, which represent the
> > horizontal and vertical sizes of a tile.
> >
> > This one uses that to plumb through drm core in order to be able to
> > handle linear tile formats without the need for drivers to roll up
> > their own implementation.
> >
> > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > bytes per pixel and where tiles are laid out in a linear manner.
> >
> > Now what are the restrictions:
> >
> > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > pixels. Due to this the places where the pitch is checked/used need to
> > be updated to take into consideration the tile_w, tile_h and
> > tile_size.
> > tile_size = cpp * tile_w * tile_h
> >
> > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > when computing the start address.
> >
> > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > didn't miss anything nothing should change.
> >
> > Regarding multi-planar linear tile formats, I'm not sure how those
> > should be handle I kind of assumed that tile_h/tile_w will have to be
> > divided by horizontal/subsampling. Anyway, I think it's best to just
> > put an warning in there and handle it when someone tries to add
> > support for them.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_atomic.c | 8 +++
> > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > drivers/gpu/drm/drm_fourcc.c | 52
> > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > include/drm/drm_fourcc.h | 2 +
> > 6 files changed, 94 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 3eb061e11e2e..7a3e893a4cd1 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> > *plane,
> > return -ENOSPC;
> > }
> >
> > + /* Make sure source coordinates are a multiple of tile sizes */
> > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> > tile restrictions",
> > +plane->base.id, plane->name);
> > + return -EINVAL;
> > + }
> > +
> > if (plane_switching_crtc(state->state, plane, state)) {
> > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
> > plane->base.id, plane->name);
> > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > index 47e0e2f6642d..4d8052adce67 100644
> > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> > *fb,
> > struct drm_gem_cma_object *obj;
> > dma_addr_t paddr;
> > u8 h_div = 1, v_div = 1;
> > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> >
> > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > if (!obj)
> > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > drm_framebuffer *fb,
> > v_div = fb->format->vsub;
> > }
> >
> > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> > - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> > + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> > + / h_div;
> > + /*
> > +* For tile formats pitches are expected to cover at least
> > +* width * tile_h pixels
> > +*/
> > + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
> >
> > return paddr;
> > }
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index f55cd93ba2d0..d6c9c5aa4036 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t
> > format, int plane)
> > return height / info->vsub;
> > }
> > EXPORT_SYMBOL(drm_format_plane_height);
> > +
> > +/**
> > + * drm_format_tile_width - width of a tile for tile formats, should be 1
> > for all
> > + * non-tiled formats.
> > + * @format: pixel format
> > + * @plane: plane index
> > + *
> > + * Returns:
> > + * The width of a tile, depending on the plane index and horizontal
> > sub-sampling
> > + */
> >
Re: [Intel-gfx] [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 10:24 AM, Ville Syrjälä wrote: > On Wed, Aug 22, 2018 at 09:14:08PM -0700, John Stultz wrote: >> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: >> > Hey Noralf, all, >> > I've been digging for a bit on the regression that this patch has >> > tripped on the HiKey board as reported here: >> > https://lkml.org/lkml/2018/8/16/81 >> > >> > The first issue was that the kirin driver was setting >> > mode_config.max_width/height = 2048, which was causing errors as the >> > the requested resolution was 1920x2160 (due to surfaceflinger >> > requesting y*2 for page flipping). >> >> Hey Noralf, >> Sorry, I know your probably sick of me. But I just wanted to circle >> around on this little bit. So part of the issue I found earlier, was >> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support >> Surfaceflinger's request for page flipping. This is what makes the Y >> resolution 2160, which runs afoul of the new max_height check of 2048 >> in the generic code. >> >> I was checking with Xinliang, who know the kirin display hardware, >> about the max_height being set to 2048 to ensure bumping it up wasn't >> a problem, but he said 2048x2048 was unfortunately not arbitrary, and >> that was the hard limit of the display hardware. However, with >> overalloc, the 1920x2160 res fbdev should still be ok, as only >> 1920x1080 is actually displayed at one time. > > I recently tried to clarify that max_width/height are simply the max > framebuffer dimensions supported by the driver. So it's perfectly legal > for a driver to declare max_height as something big that can't be > scanned out in its entirety by a single plane. For i915 I'm currently > working on bumping these limits to 32k-1 regardless of the hardware > scanout limitations. > > So if you're already running with a framebuffer height >2048 and it > works then it would seem to me that you could just bump this limit in > the driver. Ok. I'm fine with this as long as its not going to cause further trouble. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 12:46 AM, Laurent Pinchart wrote: > Hi John, > > On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote: >> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: >> > Hey Noralf, all, >> > >> > I've been digging for a bit on the regression that this patch has >> > >> > tripped on the HiKey board as reported here: >> > https://lkml.org/lkml/2018/8/16/81 >> > >> > The first issue was that the kirin driver was setting >> > mode_config.max_width/height = 2048, which was causing errors as the >> > the requested resolution was 1920x2160 (due to surfaceflinger >> > requesting y*2 for page flipping). >> >> Hey Noralf, >> Sorry, I know your probably sick of me. But I just wanted to circle >> around on this little bit. So part of the issue I found earlier, was >> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support >> Surfaceflinger's request for page flipping. > > Possibly slightly out of topic, but we're in 2018, is there any plan to make > SurfaceFlinger move away from FBDEV ? Yes. That is actually work-in-progress for both HiKey and HiKey960, switching to use the drm_hwcomposer once we can get upstream project into a sane state. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/vkms: Add support for vkms work without vblank
Currently, vkms needs VBlank to work well. This patch adds another
operation model that make vkms works without VBlank support. In this
scenario, vblank signaling is faked by calling drm_send_vblank_event()
in vkms_crtc_atomic_flush(); this approach works due to the
drm_vblank_get() == 0 verification.
Changes since V1:
Daniel Vetter:
- Change module parameter name from disablevblank to virtual_hw
- Improve parameter description
- Improve commit message
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_crtc.c | 10 ++
drivers/gpu/drm/vkms/vkms_drv.c | 13 +++--
drivers/gpu/drm/vkms/vkms_drv.h | 1 +
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index bfe6e0312cc4..001fa5c1d326 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -145,12 +145,22 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
+ struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
+
+ if (vkms_out->disable_vblank)
+ return;
+
drm_crtc_vblank_on(crtc);
}
static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
+ struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
+
+ if (vkms_out->disable_vblank)
+ return;
+
drm_crtc_vblank_off(crtc);
}
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 5d78bd97e69c..0b6569ee9dcc 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -21,6 +21,11 @@
static struct vkms_device *vkms_device;
+static bool virtual_hw;
+module_param_named(virtual_hw, virtual_hw, bool, 0444);
+MODULE_PARM_DESC(virtual_hw,
+"Enable virtual hardware mode (disables vblanks and
immediately completes flips)");
+
static const struct file_operations vkms_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -105,9 +110,13 @@ static int __init vkms_init(void)
goto out_fini;
}
- vkms_device->drm.irq_enabled = true;
+ vkms_device->output.disable_vblank = virtual_hw;
+ vkms_device->drm.irq_enabled = !virtual_hw;
+
+ if (virtual_hw)
+ DRM_INFO("Virtual Hardware mode enabled");
- ret = drm_vblank_init(_device->drm, 1);
+ ret = (virtual_hw) ? 0 : drm_vblank_init(_device->drm, 1);
if (ret) {
DRM_ERROR("Failed to vblank\n");
goto out_fini;
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index f156c930366a..9ee862e6f7e5 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -52,6 +52,7 @@ struct vkms_output {
struct drm_encoder encoder;
struct drm_connector connector;
struct hrtimer vblank_hrtimer;
+ bool disable_vblank;
ktime_t period_ns;
struct drm_pending_vblank_event *event;
bool crc_enabled;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Visibility of issues fd.o admins are faced with (Was: Re: RFC: Migration to Gitlab)
[Changing subject/recipients, to avoid hijacking the thread] Hi Dan, On Wed, 22 Aug 2018 at 17:29, Daniel Stone wrote: > > Hi, > > On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote: > > On 22 August 2018 at 12:44, Daniel Vetter wrote: > > > I think it's time to brainstorm a bit about the gitlab migration. Basic > > > reasons: > > > > > > - fd.o admins want to deprecate shell accounts and hand-rolled > > > infrastructure, because it's a pain to keep secure > > > > > > - gitlab will allow us to add committers on our own, greatly > > > simplifying that process (and offloading that task from fd.o admins). > > > > Random thought - I really wish the admins spoke early and louder about > > issues. > > From infra to manpower and adhoc tool maintenance. > > I thought I mostly had it covered, but fair enough. What knowledge are > you missing and how should it best be delivered? > > One first-order issue is that as documented at > https://www.freedesktop.org/wiki/AccountRequests/ creating accounts > requires manual admin intervention. You can also search the > 'freedesktop.org' product on Bugzilla to see the amount of time we > spend shuffling around GPG & SSH keys, which is about the worst > possible use of my time. Many other people have had access to drive > the ancient shell-script frontend to LDAP before, but for some reason > they mostly aren't very enthusiastic about doing it all the time. > > In the mesa-dev@ thread about Mesa's migration, which is linked from > my blog post, I went into quite a lot of detail about why Jenkins was > not suitable to roll out across fd.o globally. That knowledge was > gained from trial & error, which was a lot of time burnt. The end > result is that we don't have any CI, except if people hang > Travis/AppVeyor off GitHub mirrors. > > You've personally seen what's involved in setting up Git repository > hooks so we can build docs. We can't give access to let people work on > those, without giving them direct access to the literal Git repository > itself on disk. The hooks mostly involve bespoke sets of rsync jobs > and hand-managed SSH credentials and external services to build docs > and so on and so forth. None of this is accessible to a newcomer who > wants to make a non-code contribution: you have to find someone with > access to the repo to go bash some shell scripts directly and hope you > didn't screw it up. None of this is auditable, so if the repo > mysteriously gets wiped, then hopefully there are some backups > somewhere. But there definitely aren't any logs. Luckily we prevent > most people from having access to most repositories via a mandatory > 'shell' which only allows people to push Git; this was written by hand > by us 12 years ago. > > What else? Our fork of Patchwork was until recently based on an > ancient fork of Django, in a bespoke unreproducible production > environment. Bugzilla is patched for spam and templates (making > upgrades complex), yet we still have a surprising amount of spam pass > through. There's no way to delete spam, but you have to manually move > every bug to the 'spam' group, then go through and delete the user > which involves copying & pasting the email and a few clicks per user. > Mailman is patched to support Recaptcha, bringing more upgrade fun. > ikiwiki breaks all the time because it's designed to have the > public-access web server on the same host as the writeable Git > repositories. > > Our servers are several years old and approaching life expiry, and we > have no more spare disk. You can see in #freedesktop IRC the constant > network connectivity issues people have to PSU almost every day. Our > attempts to root-cause and solve those have got nowhere. > > I could go on, but the 'moved elsewhere' list in > https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/2 > indicates that we do have problems to solve, and that changing > peoples' SSH keys for them isn't the best way for us to be spending > the extremely limited time that we do have. > Starting with the most important - regardless of what may come as nitpicking, I do admire the time, patience and effort that you've been putting in fd.o. Based on your blog-post, there are many issues beyond users usability (think people using cgit/annongit, pw failing to parse email, etc). And yes, I've read it a couple of times as it came out. You mentioned many of those, so let me respin that a bit: - old hacky/adhoc scripts - throw those over a git repo - annoying and/or admin requiring workflow - throw some suggestions about tools in ^^ - ageing servers - increasing maintenance People working on graphics [more or less familiar with some issues] may not be the best admin/tools engineers out there. Hence publicity, be that via blog post/XDC talk/other, is very important IMHO. Don't recall a blog or XDC (lighting) talk over the last 5 years - and seemingly during that time, more issues have been pilling up. I believe that people would have responded to such
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Thu, Aug 23, 2018 at 06:19:31PM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote:
> > On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> > > wrote:
> > > > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> > > >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe
> > > >> wrote:
> > > >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> > > >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > >> > > > The previous patch added tile_w and tile_h, which represent the
> > > >> > > > horizontal and vertical sizes of a tile.
> > > >> > > >
> > > >> > > > This one uses that to plumb through drm core in order to be able
> > > >> > > > to
> > > >> > > > handle linear tile formats without the need for drivers to roll
> > > >> > > > up
> > > >> > > > their own implementation.
> > > >> > > >
> > > >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind
> > > >> > > > which
> > > >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in
> > > >> > > > average 2
> > > >> > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > >> > > >
> > > >> > > > Now what are the restrictions:
> > > >> > > >
> > > >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > >> > > > pixels. Due to this the places where the pitch is checked/used
> > > >> > > > need to
> > > >> > > > be updated to take into consideration the tile_w, tile_h and
> > > >> > > > tile_size.
> > > >> > > > tile_size = cpp * tile_w * tile_h
> > > >> > > >
> > > >> > > > 2. When doing source cropping plane_src_x/y need to be a
> > > >> > > > multiple of
> > > >> > > > tile_w/tile_h and we need to take into consideration the
> > > >> > > > tile_w/tile_h
> > > >> > > > when computing the start address.
> > > >> > > >
> > > >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if
> > > >> > > > I
> > > >> > > > didn't miss anything nothing should change.
> > > >> > > >
> > > >> > > > Regarding multi-planar linear tile formats, I'm not sure how
> > > >> > > > those
> > > >> > > > should be handle I kind of assumed that tile_h/tile_w will have
> > > >> > > > to be
> > > >> > > > divided by horizontal/subsampling. Anyway, I think it's best to
> > > >> > > > just
> > > >> > > > put an warning in there and handle it when someone tries to add
> > > >> > > > support for them.
> > > >> > > >
> > > >> > > > Signed-off-by: Alexandru Gheorghe
> > > >> > > >
> > > >> > > > ---
> > > >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > >> > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > >> > > >
> > > >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > >> > > > include/drm/drm_fourcc.h | 2 +
> > > >> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > >> > > >
> > > >> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > >> > > > b/drivers/gpu/drm/drm_atomic.c
> > > >> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > >> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > >> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > >> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > >> > > > drm_plane *plane,
> > > >> > > > return -ENOSPC;
> > > >> > > > }
> > > >> > > >
> > > >> > > > + /* Make sure source coordinates are a multiple of tile
> > > >> > > > sizes */
> > > >> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > >> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > >> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source
> > > >> > > > coordinates do not meet tile restrictions",
> > > >> > > > +plane->base.id, plane->name);
> > > >> > > > + return -EINVAL;
> > > >> > > > + }
> > > >> > >
> > > >> > > Feels rather wrong to me to put such hardware specific limitations
> > > >> > > into
> > > >> > > the core.
> > > >> >
> > > >> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
> > > >> > work.
> > > >>
> > > >> If that guy is supposed to give you a tile aligned address then it
> > > >> could
> > > >> just do that and leave it up to the driver to deal with the remainder
> > > >> of
> > > >> the coordinates?
> > > >>
> > > >> >
> > > >> > An alternative, would be to include it in the driver and put an WARN
> > > >> > in drm_fb_cma_get_gem_addr in case someone else uses it with a
> > > >> > src_x/src_y tile multiples.
> > > >> >
> > > >> > What do you think about that ?
> > > >> >
> > > >> > >
> > > >> > > > +
> > > >> > > >
Re: [Intel-gfx] [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Wed, Aug 22, 2018 at 09:14:08PM -0700, John Stultz wrote: > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: > > Hey Noralf, all, > > I've been digging for a bit on the regression that this patch has > > tripped on the HiKey board as reported here: > > https://lkml.org/lkml/2018/8/16/81 > > > > The first issue was that the kirin driver was setting > > mode_config.max_width/height = 2048, which was causing errors as the > > the requested resolution was 1920x2160 (due to surfaceflinger > > requesting y*2 for page flipping). > > Hey Noralf, > Sorry, I know your probably sick of me. But I just wanted to circle > around on this little bit. So part of the issue I found earlier, was > that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support > Surfaceflinger's request for page flipping. This is what makes the Y > resolution 2160, which runs afoul of the new max_height check of 2048 > in the generic code. > > I was checking with Xinliang, who know the kirin display hardware, > about the max_height being set to 2048 to ensure bumping it up wasn't > a problem, but he said 2048x2048 was unfortunately not arbitrary, and > that was the hard limit of the display hardware. However, with > overalloc, the 1920x2160 res fbdev should still be ok, as only > 1920x1080 is actually displayed at one time. I recently tried to clarify that max_width/height are simply the max framebuffer dimensions supported by the driver. So it's perfectly legal for a driver to declare max_height as something big that can't be scanned out in its entirety by a single plane. For i915 I'm currently working on bumping these limits to 32k-1 regardless of the hardware scanout limitations. So if you're already running with a framebuffer height >2048 and it works then it would seem to me that you could just bump this limit in the driver. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> > wrote:
> > > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> > >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe
> > >> wrote:
> > >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> > >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > >> > > > The previous patch added tile_w and tile_h, which represent the
> > >> > > > horizontal and vertical sizes of a tile.
> > >> > > >
> > >> > > > This one uses that to plumb through drm core in order to be able to
> > >> > > > handle linear tile formats without the need for drivers to roll up
> > >> > > > their own implementation.
> > >> > > >
> > >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind
> > >> > > > which
> > >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in
> > >> > > > average 2
> > >> > > > bytes per pixel and where tiles are laid out in a linear manner.
> > >> > > >
> > >> > > > Now what are the restrictions:
> > >> > > >
> > >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > >> > > > pixels. Due to this the places where the pitch is checked/used
> > >> > > > need to
> > >> > > > be updated to take into consideration the tile_w, tile_h and
> > >> > > > tile_size.
> > >> > > > tile_size = cpp * tile_w * tile_h
> > >> > > >
> > >> > > > 2. When doing source cropping plane_src_x/y need to be a multiple
> > >> > > > of
> > >> > > > tile_w/tile_h and we need to take into consideration the
> > >> > > > tile_w/tile_h
> > >> > > > when computing the start address.
> > >> > > >
> > >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > >> > > > didn't miss anything nothing should change.
> > >> > > >
> > >> > > > Regarding multi-planar linear tile formats, I'm not sure how those
> > >> > > > should be handle I kind of assumed that tile_h/tile_w will have to
> > >> > > > be
> > >> > > > divided by horizontal/subsampling. Anyway, I think it's best to
> > >> > > > just
> > >> > > > put an warning in there and handle it when someone tries to add
> > >> > > > support for them.
> > >> > > >
> > >> > > > Signed-off-by: Alexandru Gheorghe
> > >> > > >
> > >> > > > ---
> > >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > >> > > > drivers/gpu/drm/drm_fourcc.c | 52
> > >> > > >
> > >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > >> > > > include/drm/drm_fourcc.h | 2 +
> > >> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > >> > > >
> > >> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > >> > > > b/drivers/gpu/drm/drm_atomic.c
> > >> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > >> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > >> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > >> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > >> > > > drm_plane *plane,
> > >> > > > return -ENOSPC;
> > >> > > > }
> > >> > > >
> > >> > > > + /* Make sure source coordinates are a multiple of tile
> > >> > > > sizes */
> > >> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > >> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > >> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates
> > >> > > > do not meet tile restrictions",
> > >> > > > +plane->base.id, plane->name);
> > >> > > > + return -EINVAL;
> > >> > > > + }
> > >> > >
> > >> > > Feels rather wrong to me to put such hardware specific limitations
> > >> > > into
> > >> > > the core.
> > >> >
> > >> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
> > >> > work.
> > >>
> > >> If that guy is supposed to give you a tile aligned address then it could
> > >> just do that and leave it up to the driver to deal with the remainder of
> > >> the coordinates?
> > >>
> > >> >
> > >> > An alternative, would be to include it in the driver and put an WARN
> > >> > in drm_fb_cma_get_gem_addr in case someone else uses it with a
> > >> > src_x/src_y tile multiples.
> > >> >
> > >> > What do you think about that ?
> > >> >
> > >> > >
> > >> > > > +
> > >> > > > if (plane_switching_crtc(state->state, plane, state)) {
> > >> > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> > >> > > > directly\n",
> > >> > > > plane->base.id, plane->name);
> > >> > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > >> > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > >> > >
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 6:49 PM, Noralf Trønnes wrote:
>
> Den 23.08.2018 09.37, skrev Daniel Vetter:
>>
>> On Wed, Aug 22, 2018 at 11:21:11PM -0700, John Stultz wrote:
>>>
>>> On Wed, Aug 22, 2018 at 10:51 PM, Daniel Vetter wrote:
On Thu, Aug 23, 2018 at 6:14 AM, John Stultz
wrote:
>
> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz
> wrote:
>>
>> Hey Noralf, all,
>>I've been digging for a bit on the regression that this patch has
>> tripped on the HiKey board as reported here:
>> https://lkml.org/lkml/2018/8/16/81
>>
>> The first issue was that the kirin driver was setting
>> mode_config.max_width/height = 2048, which was causing errors as the
>> the requested resolution was 1920x2160 (due to surfaceflinger
>> requesting y*2 for page flipping).
>
> Hey Noralf,
>Sorry, I know your probably sick of me. But I just wanted to circle
> around on this little bit. So part of the issue I found earlier, was
> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support
> Surfaceflinger's request for page flipping. This is what makes the Y
> resolution 2160, which runs afoul of the new max_height check of 2048
> in the generic code.
>
> I was checking with Xinliang, who know the kirin display hardware,
> about the max_height being set to 2048 to ensure bumping it up wasn't
> a problem, but he said 2048x2048 was unfortunately not arbitrary, and
> that was the hard limit of the display hardware. However, with
> overalloc, the 1920x2160 res fbdev should still be ok, as only
> 1920x1080 is actually displayed at one time.
>
> So it seems like we might need to multiply the max_height by the
> overalloc factor when we are checking it in
> drm_internal_framebuffer_create?
>
> Does that approach sound sane, or would folks prefer something
> different?
I guess we could simply not check against the height limit when
allocating framebuffers. But we've done that for userspace buffers
since forever (they just allocate 2 buffers for page-flipping), so I
have no idea what would all break if we'd suddenly lift this
restriction. And whether we'd lift it for fbdev only or for everyone
doesn't really make much of a difference, since either this works, or
it doesn't (across all chips).
>>>
>>> That feels a bit more risky then what I was thinking. What about
>>> something like (apologies, whitespace corrupted)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index fe7e545..0424a71 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -1810,6 +1810,7 @@ static int drm_fb_helper_single_fb_probe(struct
>>> drm_fb_helper *fb_helper,
>>> int i;
>>> struct drm_fb_helper_surface_size sizes;
>>> int gamma_size = 0;
>>> + struct drm_mode_config *config;
>>>
>>> memset(, 0, sizeof(struct drm_fb_helper_surface_size));
>>> sizes.surface_depth = 24;
>>> @@ -1910,6 +1911,11 @@ static int drm_fb_helper_single_fb_probe(struct
>>> drm_fb_helper *fb_helper,
>>> sizes.surface_height *= drm_fbdev_overalloc;
>>> sizes.surface_height /= 100;
>>>
>>> + config = _helper->client.dev->mode_config;
>>> + config->max_height *= drm_fbdev_overalloc;
>>> + config->max_height /= 100;
>>> +
>>> +
>>> /* push down into drivers */
>>> ret = (*fb_helper->funcs->fb_probe)(fb_helper, );
>>> if (ret < 0)
>>>
>>>
>>> That way it only effects the fbdev + overalloc case?
>>
>> Still changes it for everyone, not just fbdev, if you enable overalloc.
>> You'd need to reset.
>>
>> Another, cleaner way to fix this would be to overallocate the buffer, but
>> have the drm_framebuffer limited. But that means we need to change the
>> fbdev scrolling logic. And the entire interface between fbdev helpers and
>> drivers needs a rework, since atm the driver allocates the drm_framebuffer
>> for you. That's what userspace can/will do in this case I guess. Has all
>> the issues of scrolling by moving the drm_fb without hw knowledge.
>>
>> I guess maybe just dropping the max_height check in fbdev is ok, if we put
>> a really big comment/FIXME there. Or maybe make it conditional on
>> fbdev_overalloc being at the default value, that'd probably be better
>> even.
>
>
> Maybe something like this could work:
>
> int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper,
> struct drm_fb_helper_surface_size *sizes)
> {
> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
> sizes->surface_width, sizes->surface_height,
> sizes->surface_bpp);
>
> format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> sizes->surface_depth);
>
> if (drm_fbdev_overalloc > 100 &&
> sizes->surface_height >
>
Re: [PATCH 0/2] Add R-Car V3H (R8A77980) support to the R-Car LVDS driver
On 06/05/2018 11:25 PM, Sergei Shtylyov wrote: > Here's the set of 2 patches against the 'drm-next' branch of the 'drm.git' > repo. > The purpose of these patches is to add the R-Car V3H (R8A77980) support to the > R-Car LVDS driver. > > [1/2] dt-bindings: display: renesas: lvds: document R8A77980 bindings > [2/2] drm: rcar-du: lvds: add R8A77980 support Laurent, I'm not seeing these patches merged... they are 2.5 months old without a comment! :-( MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
Den 23.08.2018 09.37, skrev Daniel Vetter:
On Wed, Aug 22, 2018 at 11:21:11PM -0700, John Stultz wrote:
On Wed, Aug 22, 2018 at 10:51 PM, Daniel Vetter wrote:
On Thu, Aug 23, 2018 at 6:14 AM, John Stultz wrote:
On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote:
Hey Noralf, all,
I've been digging for a bit on the regression that this patch has
tripped on the HiKey board as reported here:
https://lkml.org/lkml/2018/8/16/81
The first issue was that the kirin driver was setting
mode_config.max_width/height = 2048, which was causing errors as the
the requested resolution was 1920x2160 (due to surfaceflinger
requesting y*2 for page flipping).
Hey Noralf,
Sorry, I know your probably sick of me. But I just wanted to circle
around on this little bit. So part of the issue I found earlier, was
that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support
Surfaceflinger's request for page flipping. This is what makes the Y
resolution 2160, which runs afoul of the new max_height check of 2048
in the generic code.
I was checking with Xinliang, who know the kirin display hardware,
about the max_height being set to 2048 to ensure bumping it up wasn't
a problem, but he said 2048x2048 was unfortunately not arbitrary, and
that was the hard limit of the display hardware. However, with
overalloc, the 1920x2160 res fbdev should still be ok, as only
1920x1080 is actually displayed at one time.
So it seems like we might need to multiply the max_height by the
overalloc factor when we are checking it in
drm_internal_framebuffer_create?
Does that approach sound sane, or would folks prefer something different?
I guess we could simply not check against the height limit when
allocating framebuffers. But we've done that for userspace buffers
since forever (they just allocate 2 buffers for page-flipping), so I
have no idea what would all break if we'd suddenly lift this
restriction. And whether we'd lift it for fbdev only or for everyone
doesn't really make much of a difference, since either this works, or
it doesn't (across all chips).
That feels a bit more risky then what I was thinking. What about
something like (apologies, whitespace corrupted)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index fe7e545..0424a71 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1810,6 +1810,7 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
int i;
struct drm_fb_helper_surface_size sizes;
int gamma_size = 0;
+ struct drm_mode_config *config;
memset(, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
@@ -1910,6 +1911,11 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
sizes.surface_height *= drm_fbdev_overalloc;
sizes.surface_height /= 100;
+ config = _helper->client.dev->mode_config;
+ config->max_height *= drm_fbdev_overalloc;
+ config->max_height /= 100;
+
+
/* push down into drivers */
ret = (*fb_helper->funcs->fb_probe)(fb_helper, );
if (ret < 0)
That way it only effects the fbdev + overalloc case?
Still changes it for everyone, not just fbdev, if you enable overalloc.
You'd need to reset.
Another, cleaner way to fix this would be to overallocate the buffer, but
have the drm_framebuffer limited. But that means we need to change the
fbdev scrolling logic. And the entire interface between fbdev helpers and
drivers needs a rework, since atm the driver allocates the drm_framebuffer
for you. That's what userspace can/will do in this case I guess. Has all
the issues of scrolling by moving the drm_fb without hw knowledge.
I guess maybe just dropping the max_height check in fbdev is ok, if we put
a really big comment/FIXME there. Or maybe make it conditional on
fbdev_overalloc being at the default value, that'd probably be better
even.
Maybe something like this could work:
int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper,
struct drm_fb_helper_surface_size *sizes)
{
DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
sizes->surface_width, sizes->surface_height,
sizes->surface_bpp);
format = drm_mode_legacy_fb_format(sizes->surface_bpp,
sizes->surface_depth);
if (drm_fbdev_overalloc > 100 &&
sizes->surface_height >
fb_helper->client.dev->mode_config.max_height) {
u32 divisor = drm_fbdev_overalloc / 100;
buffer = drm_client_buffer_create(client, sizes->surface_width,
sizes->surface_height, format);
if (IS_ERR(buffer))
return PTR_ERR(buffer);
ret = drm_client_buffer_addfb(buffer, sizes->surface_width,
sizes->surface_height / divisor, format);
if (ret) {
drm_client_buffer_delete(buffer);
return ret;
}
buffer->fb->height =
[PATCH] etnaviv: setup missing dma_mask
As for today etnaviv device doesn't setup dma_mask.
The etnaviv device is a virtual device not represented in DT
so missing dma_mask isn't setup by generic plaform code
(by of_dma_configure function).
Missing dma_mask causes fails in some dma cache ops functions.
For example it causes fails on map_* operations in generic
dma_noncoherent_ops and dma_direct_ops.
We faced with this behaviour after switching ARC to generic
dma_noncoherent cache ops using.
So fix this by setting dma_mask via dma_coerce_mask_and_coherent()
Reviewed-by: Christoph Hellwig
Signed-off-by: Eugeniy Paltsev
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 540b59fb4103..69d80937e021 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -593,7 +593,7 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct component_match *match = NULL;
- dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
+ dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
if (!dev->platform_data) {
struct device_node *core_node;
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/nouveau: Check backlight IDs are >= 0, not > 0
On Thu, 2018-08-23 at 14:00 +0200, Karol Herbst wrote:
> Patches 1-5 are Reviewed-by: Karol Herbst
>
> I think it might be worth to test those patches on a system without
> any backlight devices just to verify we don't break things, but the
> code looked good already, so maybe we don't really need to test.
Did! The P50 lets you switch between dedicated GPU mode and hybrid GPU mode, and
it switches backlight control between the intel and nvidia GPUs. Seemed to work
just fine for me
>
> On Thu, Aug 23, 2018 at 3:21 AM, Lyude Paul wrote:
> > Remember, ida IDs start at 0, not 1!
> >
> > Signed-off-by: Lyude Paul
> > Cc: sta...@vger.kernel.org
> > Cc: Jeffery Miller
> > Cc: Karol Herbst
> > ---
> > drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > index 408b955e5c39..6dd72bc32897 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > @@ -116,7 +116,7 @@ nv40_backlight_init(struct drm_connector *connector)
> >_bl_ops, );
> >
> > if (IS_ERR(bd)) {
> > - if (bl_connector.id > 0)
> > + if (bl_connector.id >= 0)
> > ida_simple_remove(_ida, bl_connector.id);
> > return PTR_ERR(bd);
> > }
> > @@ -249,7 +249,7 @@ nv50_backlight_init(struct drm_connector *connector)
> >nv_encoder, ops, );
> >
> > if (IS_ERR(bd)) {
> > - if (bl_connector.id > 0)
> > + if (bl_connector.id >= 0)
> > ida_simple_remove(_ida, bl_connector.id);
> > return PTR_ERR(bd);
> > }
> > --
> > 2.17.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/msm/A6x: Add devfreq support in A6x
On Thu, Aug 23, 2018 at 02:48:31PM +0530, Sharat Masetty wrote:
> Implement routines to estimate GPU busy time and fetching the
> current frequency for the polling interval. This is required by
> the devfreq framework which recommends a frequency change if needed.
> The driver code then tries to set this new frequency on the GPU by
> sending an Out Of Band(OOB) request.
"sending an Out of Band (OOB) request _to the GMU_". Otherwise it is a little
confusing as to who is doing what.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 46
> +++
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 ++
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 ++
> 4 files changed, 72 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index f6634c0..92ff48b 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -67,8 +67,10 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
> A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
> }
>
> -static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> +static int __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> {
> + int ret;
Should be a u32 since we are doing a gmu_read().
> +
> gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
>
> gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
> @@ -84,7 +86,41 @@ static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
> index)
> a6xx_gmu_set_oob(gmu, GMU_OOB_DCVS_SET);
> a6xx_gmu_clear_oob(gmu, GMU_OOB_DCVS_SET);
>
> - return gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
> + ret = gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
> + if (!ret)
> + gmu->cur_freq = gmu->gpu_freqs[index];
> +
'ret' from the register read won't be an appropriate Unix error message so it
should be translated - otherwise it will be confusing because
'a6xx_gmu_set_freq' otherwise returns 0 or valid error messages.
> + return ret;
> +}
> +
> +int a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> + struct a6xx_gmu *gmu = _gpu->gmu;
> + u32 perf_index = 0;
> +
> + if (freq == gmu->cur_freq)
> + return 0;
> +
> + //TODO: Use a hashmap instead? This gets called potentially every ~10 ms
Please don't use C++ style comments. A TODO is okay, but I would prefer if you
solved this question. I'm not sure if walking a short list of 10 items is a big
concern if it happens every 10ms or so.
> + for (perf_index = 0; perf_index < gmu->nr_gpu_freqs; perf_index++)
> + if (freq == gmu->gpu_freqs[perf_index])
> + break;
Are you positive we don't need to worry about rounding here - will devfreq
*always* give you an exact frequency value? I know the clock subsystem allows
for rounding. You might want to double check just to be sure that we don't need
to worry about that here.
In particular, I would be concerned about the userspace governor for devfreq
where the user can set anything they want. I'm not 100% sure that gets vetted
against the OPP table before we get to this point.
> + if (perf_index == gmu->nr_gpu_freqs)
> + return -EINVAL;
Related to the previous comment slightly, if devfreq wants to set a frequency of
a hundred million HZ is it an error or should we just clamp to the highest
available frequency and call it good?
> + return __a6xx_gmu_set_freq(gmu, perf_index);
> +}
> +
> +unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> + struct a6xx_gmu *gmu = _gpu->gmu;
> +
> + return gmu->cur_freq;
> }
>
> static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
> @@ -629,8 +665,8 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
> if (!ret)
> ret = a6xx_hfi_start(gmu, GMU_COLD_BOOT);
>
> - /* Set the GPU back to the highest power frequency */
> - a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
> + /* Save the current frequency for devfreq */
> + gmu->cur_freq = gmu->gpu_freqs[gmu->nr_gpu_freqs - 1];
I'm not sure I understand this change - don't we need to set the frequency
GPU immediately out of reset even if DCVS is expected to change it soon?
>
> out:
> if (ret)
> @@ -671,7 +707,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> ret = a6xx_hfi_start(gmu, status);
>
> /* Set the GPU to the highest power frequency */
> - a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
> + __a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
>
> out:
> /* Make sure to turn off the boot OOB request on error */
> diff --git
Re: [PATCH 4/5] drm/msm: re-factor devfreq code
On Thu, Aug 23, 2018 at 02:48:30PM +0530, Sharat Masetty wrote:
> devfreq framework requires the drivers to provide busy time estimations.
It would help if you added an article to this sentence, i.e: "The devfreq
framework..."
> The GPU driver relies on the hardware performance counteres for the busy time
> estimations, but different hardware revisions have counters which can be
> sourced from different clocks. So the busy time estimation will be target
> dependent. Additionally on targets where the clocks are completely controlled
> by the on chip microcontroller, fetching and setting the current GPU frequency
> will be different. This patch aims to embrace these differences by
> re-factoring
> the devfreq code a bit.
Other than that, the code looks good. A bit of churn, but for a good cause.
Reviewed-by: Jordan Crouse
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 +---
> drivers/gpu/drm/msm/msm_gpu.c | 49
> ---
> drivers/gpu/drm/msm/msm_gpu.h | 5 +++-
> 3 files changed, 44 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 897f3e2..043e680 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -1369,12 +1369,20 @@ static struct msm_ringbuffer *a5xx_active_ring(struct
> msm_gpu *gpu)
> return a5xx_gpu->cur_ring;
> }
>
> -static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t *value)
> +static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
> {
> - *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
> - REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
> + u64 busy_cycles;
> + unsigned long busy_time;
>
> - return 0;
> + busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
> + REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
> +
> + busy_time = (busy_cycles - gpu->devfreq.busy_cycles) /
> + (clk_get_rate(gpu->core_clk) / 100);
> +
> + gpu->devfreq.busy_cycles = busy_cycles;
> +
> + return busy_time;
> }
>
> static const struct adreno_gpu_funcs funcs = {
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 83fd602..32269ef 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -36,12 +36,16 @@ static int msm_devfreq_target(struct device *dev,
> unsigned long *freq,
> struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> struct dev_pm_opp *opp;
>
> - opp = dev_pm_opp_find_freq_ceil(dev, freq);
> + opp = devfreq_recommended_opp(dev, freq, flags);
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
>
> - if (!IS_ERR(opp)) {
> + if (gpu->funcs->gpu_set_freq)
> + gpu->funcs->gpu_set_freq(gpu, (u64)*freq);
> + else
> clk_set_rate(gpu->core_clk, *freq);
> - dev_pm_opp_put(opp);
> - }
> +
> + dev_pm_opp_put(opp);
>
> return 0;
> }
> @@ -50,16 +54,14 @@ static int msm_devfreq_get_dev_status(struct device *dev,
> struct devfreq_dev_status *status)
> {
> struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> - u64 cycles;
> ktime_t time;
>
> - status->current_frequency = (unsigned long) clk_get_rate(gpu->core_clk);
> - gpu->funcs->gpu_busy(gpu, );
> -
> - status->busy_time = (cycles - gpu->devfreq.busy_cycles) /
> - (status->current_frequency / 100);
> + if (gpu->funcs->gpu_get_freq)
> + status->current_frequency = gpu->funcs->gpu_get_freq(gpu);
> + else
> + status->current_frequency = clk_get_rate(gpu->core_clk);
>
> - gpu->devfreq.busy_cycles = cycles;
> + status->busy_time = gpu->funcs->gpu_busy(gpu);
>
> time = ktime_get();
> status->total_time = ktime_us_delta(time, gpu->devfreq.time);
> @@ -72,7 +74,10 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
> unsigned long *freq)
> {
> struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
>
> - *freq = (unsigned long) clk_get_rate(gpu->core_clk);
> + if (gpu->funcs->gpu_get_freq)
> + *freq = gpu->funcs->gpu_get_freq(gpu);
> + else
> + *freq = clk_get_rate(gpu->core_clk);
>
> return 0;
> }
> @@ -87,7 +92,7 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
> unsigned long *freq)
> static void msm_devfreq_init(struct msm_gpu *gpu)
> {
> /* We need target support to do devfreq */
> - if (!gpu->funcs->gpu_busy || !gpu->core_clk)
> + if (!gpu->funcs->gpu_busy)
> return;
>
> msm_devfreq_profile.initial_freq = gpu->fast_rate;
> @@ -185,6 +190,14 @@ static int disable_axi(struct msm_gpu *gpu)
> return 0;
> }
>
> +void msm_gpu_resume_devfreq(struct msm_gpu *gpu)
> +{
> + gpu->devfreq.busy_cycles = 0;
Re: [PATCH 3/5] drm/msm/A6x: Add gmu_read64() register read op
On Thu, Aug 23, 2018 at 02:48:29PM +0530, Sharat Masetty wrote:
> Add a simple function to read 64 registers in the GMU domain
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> index a08ee8f..f9e4dfe 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> @@ -106,6 +106,19 @@ static inline void gmu_rmw(struct a6xx_gmu *gmu, u32
> reg, u32 mask, u32 or)
> gmu_write(gmu, reg, val | or);
> }
>
> +static inline u64 gmu_read64(struct a6xx_gmu *gmu, u32 lo, u32 hi)
> +{
> + u64 val;
> +
> + /*
> + * Implementation similar to gpu_read64()
> + */
I'm not sure this comment is really needed, and it certainly could just be one
line if it is.
> + val = (u64) msm_readl(gmu->mmio + (lo << 2));
> + val |= ((u64) msm_readl(gmu->mmio + (hi << 2)) << 32);
> +
> + return val;
> +}
> +
> #define gmu_poll_timeout(gmu, addr, val, cond, interval, timeout) \
> readl_poll_timeout((gmu)->mmio + ((addr) << 2), val, cond, \
> interval, timeout)
> --
> 1.9.1
>
--
The Qualcomm Innovation Center, Inc. is a member of 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 2/5] drm/msm: unregister devfreq upon clean up
On Thu, Aug 23, 2018 at 02:48:28PM +0530, Sharat Masetty wrote:
> Call the devfreq_remove_device() API to remove the GPU devfreq instance
> during GPU driver cleanup.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 04f9604..83fd602 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -970,6 +970,8 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
>
> WARN_ON(!list_empty(>active_list));
>
> + devfreq_remove_device(gpu->devfreq.devfreq);
> +
Because everything eventually gets a devm_ wrapper we do have
devm_devfreq_add_device() - maybe that would be a better solution?
Jordan
> for (i = 0; i < ARRAY_SIZE(gpu->rb); i++) {
> msm_ringbuffer_destroy(gpu->rb[i]);
> gpu->rb[i] = NULL;
> --
> 1.9.1
>
--
The Qualcomm Innovation Center, Inc. is a member of 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] drm: Fix crtc color management when doing suspend/resume
Hi Alex,
On Thu, Aug 23, 2018 at 04:11:17PM +0100, Alexandru Gheorghe wrote:
When doing suspend/resume drivers usually use the
drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
state and then re-comitting it.
The problems is that drm_crtc_state has a bool field called
color_mgmt_changed, which mali-dp and other drivers uses it to detect
if coefficients need to be reprogrammed, but that never happens
because the save state has color_mgmt_changed set to 0.
Fix that by setting color_mgmt_changed to true if the crtc duplicated
state differs from the reset state.
Signed-off-by: Alexandru Gheorghe
LGTM.
Reviewed-by: Brian Starkey
---
drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 6dd5036545ec..e88aa62bc822 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3196,8 +3196,13 @@ int drm_atomic_helper_commit_duplicated_state(struct
drm_atomic_state *state,
for_each_new_plane_in_state(state, plane, new_plane_state, i)
state->planes[i].old_state = plane->state;
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
state->crtcs[i].old_state = crtc->state;
+ new_crtc_state->color_mgmt_changed =
+ new_crtc_state->degamma_lut != crtc->state->degamma_lut
||
+ new_crtc_state->ctm != crtc->state->ctm ||
+ new_crtc_state->gamma_lut != crtc->state->gamma_lut;
+ }
for_each_new_connector_in_state(state, connector, new_conn_state, i)
state->connectors[i].old_state = connector->state;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/malidp: Fix writeback in NV12
On Wed, Aug 22, 2018 at 04:18:19PM +0100, Alexandru Gheorghe wrote:
> When we want to writeback to memory in NV12 format we need to program
> the RGB2YUV coefficients. Currently, we don't program the coefficients
> and NV12 doesn't work at all.
>
> This patchset fixes that by programming a sane default(bt709, limited
> range) as rgb2yuv coefficients.
>
> In the long run, probably we need to think of a way for userspace to
> be able to program that, but for now I think this is better than not
> working at all or not advertising NV12 as a supported format for
> memwrite.
>
> Changes since v1:
> - Write the rgb2yuv coefficients only once, since we don't change
>them at all, just write them the first time NV12 is programmed,
>suggested by Brian Starkey, here [1]
>
> [1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186819.html
>
> Signed-off-by: Alexandru Gheorghe
Acked-by: Liviu Dudau
> ---
> drivers/gpu/drm/arm/malidp_hw.c | 25 +++--
> drivers/gpu/drm/arm/malidp_hw.h | 3 ++-
> drivers/gpu/drm/arm/malidp_mw.c | 25 +
> drivers/gpu/drm/arm/malidp_regs.h | 2 ++
> 4 files changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index c94a4422e0e9..2781e462c1ed 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -384,7 +384,8 @@ static long malidp500_se_calc_mclk(struct
> malidp_hw_device *hwdev,
>
> static int malidp500_enable_memwrite(struct malidp_hw_device *hwdev,
>dma_addr_t *addrs, s32 *pitches,
> - int num_planes, u16 w, u16 h, u32 fmt_id)
> + int num_planes, u16 w, u16 h, u32 fmt_id,
> + const s16 *rgb2yuv_coeffs)
> {
> u32 base = MALIDP500_SE_MEMWRITE_BASE;
> u32 de_base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
> @@ -416,6 +417,16 @@ static int malidp500_enable_memwrite(struct
> malidp_hw_device *hwdev,
>
> malidp_hw_write(hwdev, MALIDP_DE_H_ACTIVE(w) | MALIDP_DE_V_ACTIVE(h),
> MALIDP500_SE_MEMWRITE_OUT_SIZE);
> +
> + if (rgb2yuv_coeffs) {
> + int i;
> +
> + for (i = 0; i < MALIDP_COLORADJ_NUM_COEFFS; i++) {
> + malidp_hw_write(hwdev, rgb2yuv_coeffs[i],
> + MALIDP500_SE_RGB_YUV_COEFFS + i * 4);
> + }
> + }
> +
> malidp_hw_setbits(hwdev, MALIDP_SE_MEMWRITE_EN, MALIDP500_SE_CONTROL);
>
> return 0;
> @@ -658,7 +669,8 @@ static long malidp550_se_calc_mclk(struct
> malidp_hw_device *hwdev,
>
> static int malidp550_enable_memwrite(struct malidp_hw_device *hwdev,
>dma_addr_t *addrs, s32 *pitches,
> - int num_planes, u16 w, u16 h, u32 fmt_id)
> + int num_planes, u16 w, u16 h, u32 fmt_id,
> + const s16 *rgb2yuv_coeffs)
> {
> u32 base = MALIDP550_SE_MEMWRITE_BASE;
> u32 de_base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
> @@ -689,6 +701,15 @@ static int malidp550_enable_memwrite(struct
> malidp_hw_device *hwdev,
> malidp_hw_setbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT |
> MALIDP_SE_MEMWRITE_EN,
> MALIDP550_SE_CONTROL);
>
> + if (rgb2yuv_coeffs) {
> + int i;
> +
> + for (i = 0; i < MALIDP_COLORADJ_NUM_COEFFS; i++) {
> + malidp_hw_write(hwdev, rgb2yuv_coeffs[i],
> + MALIDP550_SE_RGB_YUV_COEFFS + i * 4);
> + }
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
> index ad2e96915d44..9fc94c08190f 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.h
> +++ b/drivers/gpu/drm/arm/malidp_hw.h
> @@ -191,7 +191,8 @@ struct malidp_hw {
>* @param fmt_id - internal format ID of output buffer
>*/
> int (*enable_memwrite)(struct malidp_hw_device *hwdev, dma_addr_t
> *addrs,
> -s32 *pitches, int num_planes, u16 w, u16 h, u32
> fmt_id);
> +s32 *pitches, int num_planes, u16 w, u16 h, u32
> fmt_id,
> +const s16 *rgb2yuv_coeffs);
>
> /*
>* Disable the writing to memory of the next frame's content.
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index cfd718e7e97c..429a11e6473b 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -26,6 +26,8 @@ struct malidp_mw_connector_state {
> s32 pitches[2];
> u8 format;
> u8 n_planes;
> + bool rgb2yuv_initialized;
> + const s16 *rgb2yuv_coeffs;
> };
>
> static int malidp_mw_connector_get_modes(struct drm_connector *connector)
> @@
Re: [PATCH] drm/fourcc: Add DOC: overview comment
Hi Matthew, On Thu, Aug 23, 2018 at 07:34:45AM -0700, Matthew Wilcox wrote: On Wed, Aug 22, 2018 at 04:57:33PM +0100, Brian Starkey wrote: On Wed, Aug 22, 2018 at 05:11:55PM +0200, Daniel Vetter wrote: > On Wed, Aug 22, 2018 at 4:59 PM, Eric Engestrom > wrote: > > On Tuesday, 2018-08-21 17:44:17 +0100, Brian Starkey wrote: > > > On Tue, Aug 21, 2018 at 09:26:39AM -0700, Matthew Wilcox wrote: > > > > Can you turn them into enums? This seems to work ok: I'm not sure that swapping out explicit 32-bit unsigned integers for enums (unspecified width, signed integers) is necessarily a good idea, it seems like Bad Things could happen. The C spec says: "the value of an enumeration constant shall be an integer constant expression that has a value representable as an int" Which likely gives us 4 bytes to play with on all machines that run Linux, but if drm_fourcc.h is ever going to be some kind of standard reference, making it non-portable seems like a fail. And even if you do have 4 bytes in an enum, signed integers act differently from unsigned ones, and compilers do love to invoke the UB clause... I think you're exaggerating how much latitude C compilers have here. Further down in 6.7.2.2, it says: Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined, but shall be capable of representing the values of all the members of the enumeration. So if we include an integer which isn't representable in a plain int, then the compiler _must_ choose a larger type. I don't think so... the sentence I pasted says that including a value which isn't representable in a plain int would be illegal, and so the compiler doesn't _have_ to do anything (nasal demons, right?). It could choose a signed-64-bit type rather than an unsigned-32-bit type, but I can't imagine any compiler being quite so insane. The paragraph about the implementation choosing a representation is separate from the valid range of values - the compiler can pick whatever storage it likes (smaller or even larger than an int), so long as that storage can fit all the defined values. However, providing a value in an enum definition which is not representable as an int would still be invalid (irrespective of how large the storage is) - it's a separate restriction. Anyhow, I'm not dying to replace all the current definitions with enums, so if someone else wants to pick that up, be my guest. Cheers, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/msm: suspend devfreq on init
On Thu, Aug 23, 2018 at 02:48:27PM +0530, Sharat Masetty wrote: > Devfreq turns on and starts recommending power level as soon as it is > initialized. The GPU is still not powered on by the time the devfreq > init happens and this leads to problems on GPU's where register access > is needed to get/set power levels. So we start suspended and only restart > devfreq when GPU is powered on. Reviewed-by: Jordan Crouse > Signed-off-by: Sharat Masetty > --- > drivers/gpu/drm/msm/msm_gpu.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c > index 5281a32..04f9604 100644 > --- a/drivers/gpu/drm/msm/msm_gpu.c > +++ b/drivers/gpu/drm/msm/msm_gpu.c > @@ -104,6 +104,8 @@ static void msm_devfreq_init(struct msm_gpu *gpu) > dev_err(>pdev->dev, "Couldn't initialize GPU devfreq\n"); > gpu->devfreq.devfreq = NULL; > } > + > + devfreq_suspend_device(gpu->devfreq.devfreq); > } > > static int enable_pwrrail(struct msm_gpu *gpu) > -- > 1.9.1 > -- The Qualcomm Innovation Center, Inc. is a member of 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 0/5] msm/drm: A6x DCVS series
On Thu, Aug 23, 2018 at 02:48:26PM +0530, Sharat Masetty wrote: > This patch series starts off with a few bug fixes in devfreq code, followed by > refactoring the devfreq code needed for supporting different chipsets, and > ends with adding devfreq support for A6x. Just an aside, I'm a sucker for consistency and I know the form A6x and A6xx are used interchangeably downstream but I feel like we should be more consistent upstream. I like the form a6xx since it matches the fine names and functions and is technically more correct in terms of the actual core name. > Sharat Masetty (5): > drm/msm: suspend devfreq on init > drm/msm: unregister devfreq upon clean up > drm/msm/A6x: Add gmu_read64() register read op > drm/msm: re-factor devfreq code > drm/msm/A6x: Add devfreq support in A6x > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 46 ++ > drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 15 ++ > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27 ++ > drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 ++ > drivers/gpu/drm/msm/msm_gpu.c | 53 > +-- > drivers/gpu/drm/msm/msm_gpu.h | 5 +++- > 7 files changed, 133 insertions(+), 31 deletions(-) > > -- > 1.9.1 > -- The Qualcomm Innovation Center, Inc. is a member of 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
[RFC PATCH v2 2/3] drm/fourcc: Add remaining fourccs for Mali
As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). The AFBC modifiers can be found in [3]. AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed
[RFC PATCH v2 3/3] drm/afbc: Add AFBC modifier usage documentation
AFBC is a flexible, proprietary, lossless compression protocol and format, with a number of defined DRM format modifiers. To facilitate consistency and compatibility between different AFBC producers and consumers, document the expectations for usage of the AFBC DRM format modifiers in a new .rst chapter. Signed-off-by: Brian Starkey --- Documentation/gpu/afbc.rst| 226 ++ Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + include/uapi/drm/drm_fourcc.h | 3 + 4 files changed, 231 insertions(+) create mode 100644 Documentation/gpu/afbc.rst diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst new file mode 100644 index ..58d2b6b5d48b --- /dev/null +++ b/Documentation/gpu/afbc.rst @@ -0,0 +1,226 @@ +=== + Arm Framebuffer Compression (AFBC) +=== + +AFBC is a proprietary lossless image compression protocol and format. +It provides fine-grained random access and minimizes the amount of +data transferred between IP blocks. + +AFBC can be enabled on drivers which support it via use of the AFBC +format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*). + +All users of the AFBC modifiers must follow the usage guidelines laid +out in this document, to ensure compatibility across different AFBC +producers and consumers. + +Components and Ordering +=== + +AFBC streams can contain several components - where a component +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). +The assignment of input/output color channels must be consistent +between the encoder and the decoder for correct operation, otherwise +the consumer will interpret the decoded data incorrectly. + +Furthermore, when the lossless colorspace transform is used +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for +maximum compression efficiency), the component order must be: + + * Component 0: R + * Component 1: G + * Component 2: B + +The component ordering is communicated via the fourcc code in the +fourcc:modifier pair. In general, component '0' is considered to +reside in the least-significant bits of the corresponding linear +format. For example, COMP(bits): + + * DRM_FORMAT_ABGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: A(8) + + * DRM_FORMAT_BGR888 + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + + * DRM_FORMAT_YUYV + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + +In AFBC, 'X' components are not treated any differently from any other +component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR +encodes with 4 components, like so: + + * DRM_FORMAT_XBGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: X(8) + +Please note, however, that the inclusion of a "wasted" 'X' channel is +bad for compression efficiency, and so it's recommended to avoid +formats containing 'X' bits. If a fourth component is +required/expected by the encoder/decoder, then it is recommended to +instead use an equivalent format with alpha, setting all alpha bits to +'1'. If there is no requirement for a fourth component, then a format +which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888. + +Number of Planes + + +Formats which are typically multi-planar in linear layouts (e.g. YUV +420), can be encoded into one, or multiple, AFBC planes. As with +component order, the encoder and decoder must agree about the number +of planes in order to correctly decode the buffer. The fourcc code is +used to determine the number of encoded planes in an AFBC buffer, +matching the number of planes for the linear (unmodified) format. +Within each plane, the component ordering also follows the fourcc +code: + +For example: + + * DRM_FORMAT_YUYV: nplanes = 1 + + * Plane 0: + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + + * DRM_FORMAT_NV12: nplanes = 2 + + * Plane 0: + + * Component 0: Y(8) + + * Plane 1: + + * Component 0: Cb(8, 2x1 subsampled) + * Component 1: Cr(8, 2x1 subsampled) + +Cross-device interoperability += + +For maximum compatibility across devices, the table below defines +canonical formats for use between AFBC-enabled devices. Formats which +are listed here must be used exactly as specified when using the AFBC +modifiers. Formats which are not listed should be avoided. + +.. flat-table:: AFBC formats + + * - Fourcc code + - Description + - Planes/Components + + * - DRM_FORMAT_ABGR2101010 + - 10-bit per component RGB, with 2-bit alpha + - Plane 0: 4 components + * Component 0: R(10) + * Component 1: G(10) + * Component 2: B(10) + * Component 3: A(2) + +
[RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel
Some formats have a non-integer number of bytes per pixel, which can't
be handled with the existing 'cpp' field in drm_format_info. To handle
these formats, add a 'bpp' field, which is only used if cpp[0] == 0.
This updates all the users of format->cpp in the core DRM code,
converting them to use a new function to get the bits-per-pixel for any
format.
It's assumed that drivers will use the 'bpp' field when they add support
for pixel formats with non-integer bytes-per-pixel.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_fb_cma_helper.c | 6 +++-
drivers/gpu/drm/drm_fb_helper.c | 8 +++--
drivers/gpu/drm/drm_fourcc.c | 50
drivers/gpu/drm/drm_framebuffer.c| 8 ++---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 +-
include/drm/drm_fourcc.h | 4 +++
6 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..e279d70d3e60 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -118,13 +118,17 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
{
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
+ u8 bpp = drm_format_info_plane_bpp(fb->format, plane);
+
+ /* This can't work for non-integer bytes-per-pixel */
+ WARN_ON(bpp % 8);
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
return 0;
paddr = obj->paddr + fb->offsets[plane];
- paddr += fb->format->cpp[plane] * (state->src_x >> 16);
+ paddr += (bpp / 8) * (state->src_x >> 16);
paddr += fb->pitches[plane] * (state->src_y >> 16);
return paddr;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0646b108030b..ab369f250af4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1572,6 +1572,7 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct drm_fb_helper *fb_helper = info->par;
struct drm_framebuffer *fb = fb_helper->fb;
int depth;
+ u8 bpp = drm_format_info_plane_bpp(fb->format, 0);
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;
@@ -1580,14 +1581,14 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
*/
- if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
+ if (var->bits_per_pixel != bpp ||
var->xres > fb->width || var->yres > fb->height ||
var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
DRM_DEBUG("fb requested width/height/bpp can't fit in current
fb "
"request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
var->xres, var->yres, var->bits_per_pixel,
var->xres_virtual, var->yres_virtual,
- fb->width, fb->height, fb->format->cpp[0] * 8);
+ fb->width, fb->height, bpp);
return -EINVAL;
}
@@ -1949,11 +1950,12 @@ void drm_fb_helper_fill_var(struct fb_info *info,
struct drm_fb_helper *fb_helpe
uint32_t fb_width, uint32_t fb_height)
{
struct drm_framebuffer *fb = fb_helper->fb;
+ u8 bpp = drm_format_info_plane_bpp(fb->format, 0);
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
info->var.yres_virtual = fb->height;
- info->var.bits_per_pixel = fb->format->cpp[0] * 8;
+ info->var.bits_per_pixel = bpp;
info->var.accel_flags = FB_ACCELF_TEXT;
info->var.xoffset = 0;
info->var.yoffset = 0;
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 3b42c25bd58d..bb28919c32f3 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -272,10 +272,60 @@ int drm_format_plane_cpp(uint32_t format, int plane)
if (!info || plane >= info->num_planes)
return 0;
+ /*
+* Not valid for formats with non-integer cpp,
+* use drm_format{_info}_plane_bpp instead
+*/
+ WARN_ON(!info->cpp[0]);
+
return info->cpp[plane];
}
EXPORT_SYMBOL(drm_format_plane_cpp);
+/**
+ * drm_format_plane_bpp - determine the bits per pixel value
+ * @format: pixel format (DRM_FORMAT_*)
+ * @plane: plane index
+ *
+ * Returns:
+ * The bits per pixel value for the specified plane.
+ */
+int drm_format_plane_bpp(uint32_t format, int plane)
+{
+ const struct drm_format_info *info;
+
+ info = drm_format_info(format);
+ if (!info)
+ return 0;
+
+ return drm_format_info_plane_bpp(info, plane);
+}
+EXPORT_SYMBOL(drm_format_plane_bpp);
+
[RFC PATCH v2 0/3] Groundwork for AFBC YUV formats
Hi, This is the second round of RFC for adding a bunch of new YUV formats for Mali/AFBC. I've included a proper AFBC documentation file too, for posterity. Some of the new formats don't have an integer number of bytes-per-pixel, so I've added a bpp field to drm_format_info (patch 1), keen to hear thoughts on that. These three patches don't make a huge amount of sense in isolation, so we'll pull them into a more comprehensive series for AFBC support to merge them later. Thanks, -Brian Brian Starkey (3): drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel drm/fourcc: Add remaining fourccs for Mali drm/afbc: Add AFBC modifier usage documentation Documentation/gpu/afbc.rst | 226 +++ Documentation/gpu/drivers.rst| 1 + MAINTAINERS | 1 + drivers/gpu/drm/drm_fb_cma_helper.c | 6 +- drivers/gpu/drm/drm_fb_helper.c | 8 +- drivers/gpu/drm/drm_fourcc.c | 57 +++ drivers/gpu/drm/drm_framebuffer.c| 41 - drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 +- include/drm/drm_fourcc.h | 4 + include/uapi/drm/drm_fourcc.h| 17 ++ 10 files changed, 351 insertions(+), 13 deletions(-) create mode 100644 Documentation/gpu/afbc.rst -- 2.16.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix crtc color management when doing suspend/resume
When doing suspend/resume drivers usually use the
drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
state and then re-comitting it.
The problems is that drm_crtc_state has a bool field called
color_mgmt_changed, which mali-dp and other drivers uses it to detect
if coefficients need to be reprogrammed, but that never happens
because the save state has color_mgmt_changed set to 0.
Fix that by setting color_mgmt_changed to true if the crtc duplicated
state differs from the reset state.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 6dd5036545ec..e88aa62bc822 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3196,8 +3196,13 @@ int drm_atomic_helper_commit_duplicated_state(struct
drm_atomic_state *state,
for_each_new_plane_in_state(state, plane, new_plane_state, i)
state->planes[i].old_state = plane->state;
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
state->crtcs[i].old_state = crtc->state;
+ new_crtc_state->color_mgmt_changed =
+ new_crtc_state->degamma_lut != crtc->state->degamma_lut
||
+ new_crtc_state->ctm != crtc->state->ctm ||
+ new_crtc_state->gamma_lut != crtc->state->gamma_lut;
+ }
for_each_new_connector_in_state(state, connector, new_conn_state, i)
state->connectors[i].old_state = connector->state;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2] xf86drm: fallback to normal path when realpath fails
On Thursday, 2018-08-23 14:37:28 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Earlier commit reworked our sysfs handling to use realpath.
> Sadly that backfired since the Firefox sandboxing mechanism rejects
> that. Despite the files/folders being in the allowed list, of the
> sandboxing mechanism.
>
> Oddly enough, the Chromium sandboxing doesn't complain about any of
> this.
>
> Since there are no Firefox releases with the fix, add a temporary
> solution which falls back to the original handling.
>
> Sadly, this won't work for virgl.
>
> v2: drop return type - function cannot return NULL (Eric)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107516
> Cc: Michel Dänzer
> Cc: Mike
> Fixes: a02900133b3 ("xf86drm: introduce a get_real_pci_path() helper")
> Signed-off-by: Emil Velikov
> Reviewed-by: Michel Dänzer (v1)
> Tested-by: Michel Dänzer (v1)
Reviewed-by: Eric Engestrom
> ---
> xf86drm.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 336d64de..7807dce9 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -3014,6 +3014,12 @@ get_real_pci_path(int maj, int min, char *real_path)
> return real_path;
> }
>
> +static void
> +get_normal_pci_path(int maj, int min, char *normal_path)
> +{
> +snprintf(normal_path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
> +}
> +
> static int drmParsePciBusInfo(int maj, int min, drmPciBusInfoPtr info)
> {
> #ifdef __linux__
> @@ -3022,7 +3028,7 @@ static int drmParsePciBusInfo(int maj, int min,
> drmPciBusInfoPtr info)
> int num;
>
> if (get_real_pci_path(maj, min, real_path) == NULL)
> -return -ENOENT;
> +get_normal_pci_path(maj, min, real_path);
>
> value = sysfs_uevent_get(real_path, "PCI_SLOT_NAME");
> if (!value)
> @@ -3143,7 +3149,7 @@ static int parse_separate_sysfs_files(int maj, int min,
> int ret;
>
> if (get_real_pci_path(maj, min, real_path) == NULL)
> -return -ENOENT;
> +get_normal_pci_path(maj, min, real_path);
>
> for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) {
> snprintf(path, PATH_MAX, "%s/%s", real_path, attrs[i]);
> @@ -3175,7 +3181,7 @@ static int parse_config_sysfs_file(int maj, int min,
> int fd, ret;
>
> if (get_real_pci_path(maj, min, real_path) == NULL)
> -return -ENOENT;
> +get_normal_pci_path(maj, min, real_path);
>
> snprintf(path, PATH_MAX, "%s/config", real_path);
> fd = open(path, O_RDONLY);
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm: fallback to normal path when realpath fails
On 2018-08-23 2:52 p.m., Emil Velikov wrote:
> On Thu, 23 Aug 2018 at 11:38, Michel Dänzer wrote:
>> On 2018-08-23 12:04 p.m., Emil Velikov wrote:
>>> From: Emil Velikov
>>>
>>> Earlier commit reworked our sysfs handling to use realpath.
>>> Sadly that backfired since the Firefox sandboxing mechanism rejects
>>> that. Despite the files/folders being in the allowed list, of the
>>> sandboxing mechanism.
>>
>> From the Firefox bug report, the problem was stat on the top-level /sys
>> directory.
>>
> That's the part I didn't quite get. I don't see anything in libdrm
> that would do that.
> We do have fstat(open("/dev/dri/foo"), stat("/dev/dri/foo").
>
> I guess the C runtime (compiler?) might be doing that one?
> Like the realpath call being translated to a series of stat() calls.
Yeah, probably something like that.
>>> Oddly enough, the Chromium sandboxing doesn't complain about any of
>>> this.
>>>
>>> Since there are no Firefox releases with the fix, add a temporary
>>> solution which falls back to the original handling.
>>>
>>> Sadly, this won't work for virgl.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107516
>>> Cc: Michel Dänzer
>>> Cc: Mike
>>> Fixes: a02900133b3 ("xf86drm: introduce a get_real_pci_path() helper")
>>> Signed-off-by: Emil Velikov
>>
>> Reviewed-by: Michel Dänzer
>> Tested-by: Michel Dänzer
These are now also valid for v2, thanks again!
--
Earthling Michel Dänzer | http://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
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> wrote:
> > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe wrote:
> >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> >> > > > The previous patch added tile_w and tile_h, which represent the
> >> > > > horizontal and vertical sizes of a tile.
> >> > > >
> >> > > > This one uses that to plumb through drm core in order to be able to
> >> > > > handle linear tile formats without the need for drivers to roll up
> >> > > > their own implementation.
> >> > > >
> >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> >> > > > bytes per pixel and where tiles are laid out in a linear manner.
> >> > > >
> >> > > > Now what are the restrictions:
> >> > > >
> >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> >> > > > pixels. Due to this the places where the pitch is checked/used need
> >> > > > to
> >> > > > be updated to take into consideration the tile_w, tile_h and
> >> > > > tile_size.
> >> > > > tile_size = cpp * tile_w * tile_h
> >> > > >
> >> > > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> >> > > > tile_w/tile_h and we need to take into consideration the
> >> > > > tile_w/tile_h
> >> > > > when computing the start address.
> >> > > >
> >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> >> > > > didn't miss anything nothing should change.
> >> > > >
> >> > > > Regarding multi-planar linear tile formats, I'm not sure how those
> >> > > > should be handle I kind of assumed that tile_h/tile_w will have to be
> >> > > > divided by horizontal/subsampling. Anyway, I think it's best to just
> >> > > > put an warning in there and handle it when someone tries to add
> >> > > > support for them.
> >> > > >
> >> > > > Signed-off-by: Alexandru Gheorghe
> >> > > > ---
> >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> >> > > > drivers/gpu/drm/drm_fourcc.c | 52
> >> > > >
> >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> >> > > > include/drm/drm_fourcc.h | 2 +
> >> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> >> > > >
> >> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> >> > > > b/drivers/gpu/drm/drm_atomic.c
> >> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> >> > > > --- a/drivers/gpu/drm/drm_atomic.c
> >> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> >> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> >> > > > drm_plane *plane,
> >> > > > return -ENOSPC;
> >> > > > }
> >> > > >
> >> > > > + /* Make sure source coordinates are a multiple of tile sizes
> >> > > > */
> >> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> >> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> >> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates
> >> > > > do not meet tile restrictions",
> >> > > > +plane->base.id, plane->name);
> >> > > > + return -EINVAL;
> >> > > > + }
> >> > >
> >> > > Feels rather wrong to me to put such hardware specific limitations into
> >> > > the core.
> >> >
> >> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
> >> > work.
> >>
> >> If that guy is supposed to give you a tile aligned address then it could
> >> just do that and leave it up to the driver to deal with the remainder of
> >> the coordinates?
> >>
> >> >
> >> > An alternative, would be to include it in the driver and put an WARN
> >> > in drm_fb_cma_get_gem_addr in case someone else uses it with a
> >> > src_x/src_y tile multiples.
> >> >
> >> > What do you think about that ?
> >> >
> >> > >
> >> > > > +
> >> > > > if (plane_switching_crtc(state->state, plane, state)) {
> >> > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> >> > > > directly\n",
> >> > > > plane->base.id, plane->name);
> >> > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> > > > index 47e0e2f6642d..4d8052adce67 100644
> >> > > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> > > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> > > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> >> > > > drm_framebuffer *fb,
> >> > > > struct drm_gem_cma_object *obj;
> >> > > > dma_addr_t paddr;
> >> > > > u8
Re: [PATCH v3 7/7] drm/bridge: ti-sn65dsi86: Add mystery delay to enable()
On Tue, Aug 14, 2018 at 10:01:45AM -0400, Sean Paul wrote: > On Tue, Aug 14, 2018 at 10:00:33AM -0400, Sean Paul wrote: > > On Tue, Aug 14, 2018 at 04:59:31PM +0530, spa...@codeaurora.org wrote: > > > On 2018-08-14 03:00, Sean Paul wrote: > > > > From: Sean Paul > > > > > > > > This patch adds a 70ms mystery delay to the bridge driver in enable. > > > > By experimentation, it seems like it can go anywhere up until we > > > > initiate semi-auto link training. If we don't have the delay, link > > > > training fails. > > > > > > > > I tried to root cause this as best I could, but neither the datasheet > > > > for the panel nor the bridge mention a delay of this magnitude in their > > > > timing requirements. So for now, add the mystery delay until someone > > > > figures out a better fix. > > > > > > > > Changes in v3: > > > > - Added to the set > > > > > > > > Cc: Sandeep Panda > > > > Signed-off-by: Sean Paul > > > > --- > > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 > > > > 1 file changed, 12 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > > index d3e27e52ea759..f8a931cf3665e 100644 > > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > > @@ -458,6 +458,18 @@ static void ti_sn_bridge_enable(struct drm_bridge > > > > *bridge) > > > > unsigned int val; > > > > int ret; > > > > > > > > + /* > > > > +* FIXME: > > > > +* This 70ms was found necessary by experimentation. If it's not > > > > +* present, link training fails. It seems like it can go > > > > anywhere from > > > > +* pre_enable() up to semi-auto link training initiation below. > > > > +* > > > > +* Neither the datasheet for the bridge nor the panel tested > > > > mention a > > > > +* delay of this magnitude in the timing requirements. So for > > > > now, add > > > > +* the mystery delay until someone figures out a better fix. > > > > +*/ > > > > > > Is this newly found issue? Specific to any board config? > > > > It's specific to cheza. > > Well, I suppose I shouldn't say that since I've not tried the bridge on > another > board. I should say, it reproduces on cheza. Ping. Sandeep: any more feedback? Sean > > Sean > > > This was found with swboyd changed the panel regulator > > from always-on/boot-on to toggle. > > > > I've pushed the tag "mtp-testing-0813" to dpu-staging so you can play around > > with it. Without this delay, link training fails. > > > > Sean > > > > > > > > > + msleep(70); > > > > + > > > > /* DSI_A lane config */ > > > > val = CHA_DSI_LANES(4 - pdata->dsi->lanes); > > > > regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG, > > > > -- > > Sean Paul, Software Engineer, Google / Chromium OS > > -- > Sean Paul, Software Engineer, Google / Chromium OS -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105913] [IGT] igt@gem_shrink@pread Test assertion failure function gem_read, file ioctl_wrappers.c
https://bugs.freedesktop.org/show_bug.cgi?id=105913 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Lakshmi --- Closing as not a bug. -- 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 1/2] drm: Add per-plane pixel blend mode property
On Thu, Aug 23, 2018 at 04:30:19PM +0800, Lowry Li wrote:
> Pixel blend modes represent the alpha blending equation
> selection, describing how the pixels from the current
> plane are composited with the background.
>
> Adds a pixel_blend_mode to drm_plane_state and a
> blend_mode_property to drm_plane, and related support
> functions.
>
> Defines three blend modes in drm_blend.h.
>
> Changes since v1:
> - Moves the blending equation into the DOC comment
> - Refines the comments of drm_plane_create_blend_mode_property to not
>enumerate the #defines, but instead the string values
> - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
> Changes since v2:
> - Refines the comments of drm_plane_create_blend_mode_property:
> 1) Puts the descriptions (after the ":") on a new line
> 2) Adds explaining why @supported_modes need PREMUL as default
> Changes since v3:
> - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
>can calculate the index itself just fine, so no point in having the
>caller pass it in.
> - Since the current DRM assumption is that alpha is premultiplied
>as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
> - Refines some comments.
> Changes since v4:
> - Adds comments in drm_blend.h.
> - Removes setting default value in drm_plane_create_blend_mode_property()
>as it is already in __drm_atomic_helper_plane_reset().
> - Fixes to use state->pixel_blend_mode instead of using
>plane->state->pixel_blend_mode in reset function.
> - Rebases on drm-misc-next.
>
> Reviewed-by: Liviu Dudau
Reviewed-by: Sean Paul
I've also Reviewed the userspace component in drm_hwc here:
https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/16#note_24690
Thanks,
Sean
> Signed-off-by: Lowry Li
> ---
> drivers/gpu/drm/drm_atomic.c| 4 ++
> drivers/gpu/drm/drm_atomic_helper.c | 1 +
> drivers/gpu/drm/drm_blend.c | 123
>
> include/drm/drm_blend.h | 6 ++
> include/drm/drm_plane.h | 9 +++
> 5 files changed, 143 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e..d0478ab 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -895,6 +895,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> state->src_h = val;
> } else if (property == plane->alpha_property) {
> state->alpha = val;
> + } else if (property == plane->blend_mode_property) {
> + state->pixel_blend_mode = val;
> } else if (property == plane->rotation_property) {
> if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] bad rotation bitmask:
> 0x%llx\n",
> @@ -968,6 +970,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> *val = state->src_h;
> } else if (property == plane->alpha_property) {
> *val = state->alpha;
> + } else if (property == plane->blend_mode_property) {
> + *val = state->pixel_blend_mode;
> } else if (property == plane->rotation_property) {
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 6dd5036..284a5d2 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3569,6 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct drm_plane
> *plane,
> /* Reset the alpha value to fully opaque if it matters */
> if (plane->alpha_property)
> state->alpha = plane->alpha_property->values[1];
> + state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>
> plane->state = state;
> }
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index a16a74d..402b62d 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -107,6 +107,52 @@
> * planes. Without this property the primary plane is always below the
> cursor
> * plane, and ordering between all other planes is undefined.
> *
> + * pixel blend mode:
> + * Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> + * It adds a blend mode for alpha blending equation selection, describing
> + * how the pixels from the current plane are composited with the
> + * background.
> + *
> + *Three alpha blending equations are defined:
> + *
> + *"None":
> + *Blend formula that ignores the pixel alpha::
> + *
> + *out.rgb = plane_alpha * fg.rgb +
> + *(1 - plane_alpha) * bg.rgb
> + *
> + *"Pre-multiplied":
> + *Blend formula that assumes the pixel color values
> + *have been already pre-multiplied with the alpha
Re: [PATCH v5 0/8] drm/rockchip: migrate to common dw-mipi-dsi bridge and dual-dsi
Hi Heiko, On 08/21/2018 04:05 PM, Heiko Stuebner wrote: > The Rockchip DSI driver was separate till now, not using the common > bridge driver that was introduced a bit later. So this series migrates > over to use that common bridge driver and then also adds support for > dual-dsi to both the bridge and Rockchip glue code. > > The bridge-migration itself is based on Nickeys earlier v8 > work, but adapted to current kernels and with a new split between probe > and bind, so that we do not create and drop the dsi-host on each deferred > bind attempt. > > changes in v2: > - rebase against newer drm code (dsi-bridge+rockchip changes) > - add SPDX header to new glue driver > - expect regular interface lanes from panel (like 4) not the double number >Similar to tegra > - keep links to both master and slave > changes in v3: > - don't defer in bridge_attach, instead add ability to check for finalized >panel attachement, for example in bind > - address bridge-conversion comments from Andrzej: >- include ordering >- moved hwaccess from mode_set to enable callback >- move pllref_clk enablement to bind (needed by bridge mode_set->lane_mbps) > - limited slave settings to dw_mipi_dsi_set_slave > - address dual-dsi comments from Philippe: >- remove unneeded separate variables >- remove unneeded second slave settings >- disable slave before master >- lane-sum calculation comments > changes in v4: > - rebase against some legacy rockchip-dsi changes > - add dsi-component only after panel has attached to dsi host >This solves quite some concurrency problems that happen when trying >to determine dsi-panel availability > changes in v5: > - use driver-internal method to find second host > - drop of-graph based dsi method for it FYI, Yannick tested successfully the v5 version on stm32 boards. Note that drm stm32 drivers do not use bind/unbind & dual-dsi so this email is simply to share with you this minor information: "v5 patch does not break stm32 dsi", hope it helps a little. Many thanks, Philippe :-) > > Unchanged from review comments: > - kept dw_mipi_dsi_bind, as the dsi->bridge member is only part of the >bridge drivers struct, so not accessible from glue drivers > - kept dual-dsi handling that mimicks tegra > > > Heiko Stuebner (4): >drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to > __dw_mipi_dsi_remove >drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from > dw_mipi_dsi_bind >drm/bridge/synopsys: dsi: add ability to have glue-specific attach and > detach >drm/rockchip: dsi: add dual mipi support > > Nickey Yang (3): >dt-bindings: display: rockchip: update DSI controller >drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver >drm/bridge/synopsys: dsi: add dual-dsi support > > .../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 +- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 114 +- > drivers/gpu/drm/rockchip/Kconfig |2 +- > drivers/gpu/drm/rockchip/Makefile |2 +- > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1044 + > drivers/gpu/drm/rockchip/dw-mipi-dsi.c| 1349 - > drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +- > drivers/gpu/drm/rockchip/rockchip_drm_drv.h |3 +- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c |3 + > drivers/gpu/drm/rockchip/rockchip_drm_vop.h |4 + > drivers/gpu/drm/rockchip/rockchip_vop_reg.c |1 + > include/drm/bridge/dw_mipi_dsi.h | 14 +- > 12 files changed, 1182 insertions(+), 1379 deletions(-) > create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c > delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107595] amd-staging-drm-next: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 - R4 Mullins
https://bugs.freedesktop.org/show_bug.cgi?id=107595 --- Comment #10 from Michel Dänzer --- Thanks for testing the patches. Looks like there's still an issue with DC. -- 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/pl111: add in missing sentinel to a of_device_id array
Hi, Colin
I has posted the same patch about a month ago. but it seems to be ignored.:-(
https://lore.kernel.org/patchwork/patch/971652/
Thanks,
zhong jiang
On 2018/8/21 18:54, Colin King wrote:
> From: Colin Ian King
>
> Array vexpress_muxfpga_match is missing an end of array sentinel,
> add it.
>
> Detected by Coccinelle: ("vexpress_muxfpga_match is not NULL
> terminated at line")
>
> Fixes: ca454bd42dc2 ("drm/pl111: Support the Versatile Express")
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/pl111/pl111_vexpress.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c
> b/drivers/gpu/drm/pl111/pl111_vexpress.c
> index a534b225e31b..48e2afcd4798 100644
> --- a/drivers/gpu/drm/pl111/pl111_vexpress.c
> +++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
> @@ -111,7 +111,8 @@ static int vexpress_muxfpga_probe(struct platform_device
> *pdev)
> }
>
> static const struct of_device_id vexpress_muxfpga_match[] = {
> - { .compatible = "arm,vexpress-muxfpga", }
> + { .compatible = "arm,vexpress-muxfpga", },
> + { /* sentinel */ }
> };
>
> static struct platform_driver vexpress_muxfpga_driver = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
Ping, Anyone has any objections a about the patch?
Best wishes,
zhong jiang
On 2018/8/17 10:24, zhong jiang wrote:
> for_each_available_child_of_node will get and put the node properly,
> the following of_node_put will lead to the double put. So just
> remove it.
>
> Signed-off-by: zhong jiang
> ---
> drivers/gpu/drm/zte/zx_drm_drv.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 6f4205e8..d7b9870 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -161,10 +161,8 @@ static int zx_drm_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - for_each_available_child_of_node(parent, child) {
> + for_each_available_child_of_node(parent, child)
> component_match_add(dev, , compare_of, child);
> - of_node_put(child);
> - }
>
> return component_master_add_with_match(dev, _drm_master_ops, match);
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm v2] xf86drm: fallback to normal path when realpath fails
From: Emil Velikov
Earlier commit reworked our sysfs handling to use realpath.
Sadly that backfired since the Firefox sandboxing mechanism rejects
that. Despite the files/folders being in the allowed list, of the
sandboxing mechanism.
Oddly enough, the Chromium sandboxing doesn't complain about any of
this.
Since there are no Firefox releases with the fix, add a temporary
solution which falls back to the original handling.
Sadly, this won't work for virgl.
v2: drop return type - function cannot return NULL (Eric)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107516
Cc: Michel Dänzer
Cc: Mike
Fixes: a02900133b3 ("xf86drm: introduce a get_real_pci_path() helper")
Signed-off-by: Emil Velikov
Reviewed-by: Michel Dänzer (v1)
Tested-by: Michel Dänzer (v1)
---
xf86drm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 336d64de..7807dce9 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3014,6 +3014,12 @@ get_real_pci_path(int maj, int min, char *real_path)
return real_path;
}
+static void
+get_normal_pci_path(int maj, int min, char *normal_path)
+{
+snprintf(normal_path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+}
+
static int drmParsePciBusInfo(int maj, int min, drmPciBusInfoPtr info)
{
#ifdef __linux__
@@ -3022,7 +3028,7 @@ static int drmParsePciBusInfo(int maj, int min,
drmPciBusInfoPtr info)
int num;
if (get_real_pci_path(maj, min, real_path) == NULL)
-return -ENOENT;
+get_normal_pci_path(maj, min, real_path);
value = sysfs_uevent_get(real_path, "PCI_SLOT_NAME");
if (!value)
@@ -3143,7 +3149,7 @@ static int parse_separate_sysfs_files(int maj, int min,
int ret;
if (get_real_pci_path(maj, min, real_path) == NULL)
-return -ENOENT;
+get_normal_pci_path(maj, min, real_path);
for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) {
snprintf(path, PATH_MAX, "%s/%s", real_path, attrs[i]);
@@ -3175,7 +3181,7 @@ static int parse_config_sysfs_file(int maj, int min,
int fd, ret;
if (get_real_pci_path(maj, min, real_path) == NULL)
-return -ENOENT;
+get_normal_pci_path(maj, min, real_path);
snprintf(path, PATH_MAX, "%s/config", real_path);
fd = open(path, O_RDONLY);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107595] amd-staging-drm-next: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 - R4 Mullins
https://bugs.freedesktop.org/show_bug.cgi?id=107595 --- Comment #9 from Przemek --- Created attachment 141248 --> https://bugs.freedesktop.org/attachment.cgi?id=141248=edit pstore kernel oops message with applied patches (In reply to Przemek from comment #7) > Repo is git fetched to the latest (today's). Did I miss something? > > Thanks, > Przemek. Yes I did. Fetching once again the online repo resolved the problem with compilation, but those patches didnt help with kernel oops. I have attached full pstore message log. Thanks, Przemek. -- 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 libdrm] xf86drm: fallback to normal path when realpath fails
On Thu, 23 Aug 2018 at 11:38, Michel Dänzer wrote:
>
> On 2018-08-23 12:04 p.m., Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Earlier commit reworked our sysfs handling to use realpath.
> > Sadly that backfired since the Firefox sandboxing mechanism rejects
> > that. Despite the files/folders being in the allowed list, of the
> > sandboxing mechanism.
>
> From the Firefox bug report, the problem was stat on the top-level /sys
> directory.
>
That's the part I didn't quite get. I don't see anything in libdrm
that would do that.
We do have fstat(open("/dev/dri/foo"), stat("/dev/dri/foo").
I guess the C runtime (compiler?) might be doing that one?
Like the realpath call being translated to a series of stat() calls.
>
> > Oddly enough, the Chromium sandboxing doesn't complain about any of
> > this.
> >
> > Since there are no Firefox releases with the fix, add a temporary
> > solution which falls back to the original handling.
> >
> > Sadly, this won't work for virgl.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107516
> > Cc: Michel Dänzer
> > Cc: Mike
> > Fixes: a02900133b3 ("xf86drm: introduce a get_real_pci_path() helper")
> > Signed-off-by: Emil Velikov
>
> Reviewed-by: Michel Dänzer
> Tested-by: Michel Dänzer
>
>
> Thanks Emil!
>
Sorry for these experiences. I should really test things with Firefox,
saying "it works with Chromium" doesn't quite cut it.
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107595] amd-staging-drm-next: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 - R4 Mullins
https://bugs.freedesktop.org/show_bug.cgi?id=107595 --- Comment #8 from Przemek --- compiling with gcc 8.2.0-r2. -- 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 107595] amd-staging-drm-next: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 - R4 Mullins
https://bugs.freedesktop.org/show_bug.cgi?id=107595 --- Comment #7 from Przemek --- The patches (all three) applies fine, but I cannot compile kernel due to: "drivers/gpu/drm/amd/amdgpu/kv_dpm.c: In function ‘kv_dpm_process_interrupt’: drivers/gpu/drm/amd/amdgpu/kv_dpm.c:3210:24: error: ‘handle’ undeclared (first use in this function); did you mean ‘ihandle’? kv_dpm_powergate_vce(handle, gate); ^~ ihandle drivers/gpu/drm/amd/amdgpu/kv_dpm.c:3210:24: note: each undeclared identifier is reported only once for each function it appears in drivers/gpu/drm/amd/amdgpu/kv_dpm.c:3210:32: error: ‘gate’ undeclared (first use in this function); did you mean ‘path’? kv_dpm_powergate_vce(handle, gate); ^~~~ path make[4]: *** [scripts/Makefile.build:317: drivers/gpu/drm/amd/amdgpu/kv_dpm.o] Błąd 1 make[4]: *** Oczekiwanie na niezakończone zadania" Repo is git fetched to the latest (today's). Did I miss something? Thanks, Przemek. -- 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 1/5] drm/nouveau: Check backlight IDs are >= 0, not > 0
Patches 1-5 are Reviewed-by: Karol Herbst
I think it might be worth to test those patches on a system without
any backlight devices just to verify we don't break things, but the
code looked good already, so maybe we don't really need to test.
On Thu, Aug 23, 2018 at 3:21 AM, Lyude Paul wrote:
> Remember, ida IDs start at 0, not 1!
>
> Signed-off-by: Lyude Paul
> Cc: sta...@vger.kernel.org
> Cc: Jeffery Miller
> Cc: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 408b955e5c39..6dd72bc32897 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -116,7 +116,7 @@ nv40_backlight_init(struct drm_connector *connector)
>_bl_ops, );
>
> if (IS_ERR(bd)) {
> - if (bl_connector.id > 0)
> + if (bl_connector.id >= 0)
> ida_simple_remove(_ida, bl_connector.id);
> return PTR_ERR(bd);
> }
> @@ -249,7 +249,7 @@ nv50_backlight_init(struct drm_connector *connector)
>nv_encoder, ops, );
>
> if (IS_ERR(bd)) {
> - if (bl_connector.id > 0)
> + if (bl_connector.id >= 0)
> ida_simple_remove(_ida, bl_connector.id);
> return PTR_ERR(bd);
> }
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] fbdev changes for v4.19
Hi Linus, Please pull fbdev changes for v4.19. There are mostly small fixes and cleanups for fb drivers (the biggest updates are for udlfb and pxafb drivers). This PR also adds deferred console takeover support to the console code and efifb driver. Please see the signed tag description for details. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics The following changes since commit 334bb8972a131e604a741e9b284d8867190c723e: console: dummycon: export dummycon_[un]register_output_notifier (2018-06-29 11:46:19 +0200) are available in the git repository at: https://github.com/bzolnier/linux.git tags/fbdev-v4.19 for you to fetch changes up to f39684524b391c5a7ed0ac44db4fec3357af1c5d: Documentation/fb: corrections for fbcon.txt (2018-08-10 17:23:02 +0200) fbdev changes for v4.19: - add support for deferred console takeover, when enabled defers fbcon taking over the console from the dummy console until the first text is displayed on the console - together with the "quiet" kernel commandline option this allows fbcon to still be used together with a smooth graphical bootup (Hans de Goede) - improve console locking debugging code (Thomas Zimmermann) - copy the ACPI BGRT boot graphics to the framebuffer when deferred console takeover support is used in efifb driver (Hans de Goede) - update udlfb driver - fix lost console when the user unplugs a USB adapter, fix the screen corruption issue, fix locking and add some performance optimizations (Mikulas Patocka) - update pxafb driver - fix using uninitialized memory, switch to devm_* API, handle initialization errors and add support for lcd-supply regulator (Daniel Mack) - add support for boards booted with a DeviceTree in pxa3xx_gcu driver (Daniel Mack) - rename omap2 module to omap2fb.ko to avoid conflicts with omap1 driver (Arnd Bergmann) - enable ACPI-based enumeration for goldfishfb driver (Yu Ning) - fix goldfishfb driver to make user space Android code use 60 fps (Christoffer Dall) - print big fat warning when nomodeset kernel parameter is used in vgacon driver (Lyude Paul) - remove VLA usage from fsl-diu-fb driver (Kees Cook) - misc fixes (Julia Lawall, Geert Uytterhoeven, Fredrik Noring, Yisheng Xie, Dan Carpenter, Daniel Vetter, Anton Vasilyev, Randy Dunlap, Gustavo A. R. Silva, Colin Ian King, Fengguang Wu) - misc cleanups (Roman Kiryanov, Yisheng Xie, Colin Ian King) Anton Vasilyev (1): video: goldfishfb: fix memory leak on driver remove Arnd Bergmann (1): omapfb: rename omap2 module to omap2fb.ko Bartlomiej Zolnierkiewicz (3): Merge tag 'v4.18-rc2' of https://git.kernel.org/.../torvalds/linux into fbdev-for-next Merge tag 'ib-fbdev-drm-v4.19-deferred-console-takeover' of https://github.com/bzolnier/linux into fbdev-for-next Merge tag 'ib-fbdev-drm-v4.19-deferred-console-takeover-fixup' of https://github.com/bzolnier/linux into fbdev-for-next Christoffer Dall (1): video: fbdev: Set pixclock = 0 in goldfishfb Colin Ian King (2): video: fbdev: tridentfb: remove deadcode on unreachable case statement omapfb: encoder-tpd12s015: remove redundant pointer 'in' Dan Carpenter (2): video: fbdev: metronomefb: fix some off by one bugs fbdev: omapfb: off by one in omapfb_register_client() Daniel Mack (6): dt-bindings: display: add devicetree bindings for pxa300-gcu video: fbdev: pxa3xx_gcu: add devicetree bindings video: fbdev: pxafb: clear allocated memory for video modes video: fbdev: pxafb: switch to devm_* API video: fbdev: pxafb: handle errors from pxafb_init_fbinfo() correctly video: fbdev: pxafb: Add support for lcd-supply regulator Daniel Vetter (1): fbdev: fix modedb docs in fb_find_mode Fredrik Noring (1): fbdev: Distinguish between interlaced and progressive modes Geert Uytterhoeven (1): video: fbdev: simplefb: Stop including Gustavo A. R. Silva (3): fbdev: fbmem: mark expected switch fall-through omapfb: Mark expected switch fall-throughs video: fbdev: mark expected switch fall-throughs Hans de Goede (7): efi/bgrt: Drop __initdata from bgrt_image_size efifb: Copy the ACPI BGRT boot graphics to the framebuffer efifb: BGRT: Do not copy the boot graphics for non native resolutions fbcon: Only allow FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER if fbdev is builtin fbcon: Only defer console takeover if the current console driver is the dummycon dummycon: Stop exporting dummycon_[un]register_output_notifier fbcon: Do not takeover the console from atomic context Julia Lawall (1): omapfb: encoder-tpd12s015: fix error return code Kees Cook (1): video: fbdev: fsl-diu-fb: Remove VLA usage Lyude Paul (1): video/console/vgacon: Print big fat
Re: [PATCH 5/5] drm: add syncobj timeline support v2
Am 23.08.2018 um 11:58 schrieb zhoucm1:
On 2018年08月23日 17:15, Christian König wrote:
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an
integer payload
identifying a point in a timeline. Such timeline semaphores support the
following operations:
* Host query - A host operation that allows querying the payload
of the
timeline semaphore.
* Host wait - A host operation that allows a blocking wait for a
timeline semaphore to reach a specified value.
I think I have a idea what "Host" means in this context, but it would
probably be better to describe it.
How about "CPU"?
Yeah, that's probably better.
* Device wait - A device operation that allows waiting for a
timeline semaphore to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline semaphore to a specified value.
Since it's a timeline, that means the front time point(PT) always is
signaled before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion
fence, when PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when
timeline is increasing, will compare
wait PTs value with new timeline value, if PT value is lower than
timeline value, then wait PT will be
signaled, otherwise keep in list. semaphore wait operation can wait
on any point of timeline,
so need a RB tree to order them. And wait PT could ahead of signal
PT, we need a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate
patch. (Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate
patch.
5. drop the submission_fence implementation and instead use
wait_event() for that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
I really liked Daniels idea to handle the classic syncobj like a
timeline synobj with just 1 entry. That can probably simplify the
implementation quite a bit.
Yeah, after timeline, seems we can remove old syncobj->fence, right?
will try to unify them in additional patch.
I think we could do something like the following:
1. When drm_syncobj_find_fence is called with point zero then we return
the last added one.
2. When drm_syncobj_find_fence is called with point zero we add the new
fence as with N+1 to the list.
This way syncobj should keep it's functionality as is with the timeline
support added on top.
Regards,
Christian.
Thanks,
David Zhou
Additional to that an amdgpu patch which shows how the interface is
to be used is probably something Daniel will want to see as well.
Christian.
TODO:
1. CPU query and wait on timeline semaphore.
2. test application (Daniel Vetter)
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 383
+++---
include/drm/drm_syncobj.h | 28 +++
include/uapi/drm/drm.h | 1 +
3 files changed, 389 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index 6227df2cc0a4..f738d78edf65 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,44 @@
#include "drm_internal.h"
#include
+struct drm_syncobj_stub_fence {
+ struct dma_fence base;
+ spinlock_t lock;
+};
+
+static const char *drm_syncobj_stub_fence_get_name(struct dma_fence
*fence)
+{
+ return "syncobjstub";
+}
+
+static bool drm_syncobj_stub_fence_enable_signaling(struct
dma_fence *fence)
+{
+ return !dma_fence_is_signaled(fence);
+}
+
+static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
+ .get_driver_name = drm_syncobj_stub_fence_get_name,
+ .get_timeline_name = drm_syncobj_stub_fence_get_name,
+ .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
+ .release = NULL,
+};
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64 value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_fence;
+ struct dma_fence *pre_pt_base;
+ struct dma_fence_cb signal_cb;
+ struct dma_fence_cb pre_pt_cb;
+ struct drm_syncobj *syncobj;
+ u64 value;
+ struct list_head list;
+};
+
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -137,6 +175,150 @@ void drm_syncobj_remove_callback(struct
drm_syncobj *syncobj,
spin_unlock(>lock);
}
+static void drm_syncobj_timeline_signal_wait_pts(struct
drm_syncobj *syncobj)
+{
+ struct rb_node *node = NULL;
+
Re: [PATCH] drm/pl111: add in missing sentinel to a of_device_id array
On Tue, Aug 21, 2018 at 12:54 PM Colin King wrote:
> From: Colin Ian King
>
> Array vexpress_muxfpga_match is missing an end of array sentinel,
> add it.
>
> Detected by Coccinelle: ("vexpress_muxfpga_match is not NULL
> terminated at line")
>
> Fixes: ca454bd42dc2 ("drm/pl111: Support the Versatile Express")
>
> Signed-off-by: Colin Ian King
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107595] amd-staging-drm-next: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 - R4 Mullins
https://bugs.freedesktop.org/show_bug.cgi?id=107595 --- Comment #6 from Michel Dänzer --- Does https://patchwork.freedesktop.org/series/48613/ (in particular the first patch) help? -- 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 libdrm] xf86drm: fallback to normal path when realpath fails
On 2018-08-23 12:04 p.m., Emil Velikov wrote:
> From: Emil Velikov
>
> Earlier commit reworked our sysfs handling to use realpath.
> Sadly that backfired since the Firefox sandboxing mechanism rejects
> that. Despite the files/folders being in the allowed list, of the
> sandboxing mechanism.
From the Firefox bug report, the problem was stat on the top-level /sys
directory.
> Oddly enough, the Chromium sandboxing doesn't complain about any of
> this.
>
> Since there are no Firefox releases with the fix, add a temporary
> solution which falls back to the original handling.
>
> Sadly, this won't work for virgl.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107516
> Cc: Michel Dänzer
> Cc: Mike
> Fixes: a02900133b3 ("xf86drm: introduce a get_real_pci_path() helper")
> Signed-off-by: Emil Velikov
Reviewed-by: Michel Dänzer
Tested-by: Michel Dänzer
Thanks Emil!
--
Earthling Michel Dänzer | http://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
[PATCH libdrm] xf86drm: fallback to normal path when realpath fails
From: Emil Velikov
Earlier commit reworked our sysfs handling to use realpath.
Sadly that backfired since the Firefox sandboxing mechanism rejects
that. Despite the files/folders being in the allowed list, of the
sandboxing mechanism.
Oddly enough, the Chromium sandboxing doesn't complain about any of
this.
Since there are no Firefox releases with the fix, add a temporary
solution which falls back to the original handling.
Sadly, this won't work for virgl.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107516
Cc: Michel Dänzer
Cc: Mike
Fixes: a02900133b3 ("xf86drm: introduce a get_real_pci_path() helper")
Signed-off-by: Emil Velikov
---
Gents, this should bring things back to normal. Can you please give it a
try?
Would be great to see Firefox roll out updates which make this workaround
unnessesary ;-)
---
xf86drm.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 336d64de..964bedf9 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3014,6 +3014,14 @@ get_real_pci_path(int maj, int min, char *real_path)
return real_path;
}
+static char *
+get_normal_pci_path(int maj, int min, char *normal_path)
+{
+snprintf(normal_path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+
+return normal_path;
+}
+
static int drmParsePciBusInfo(int maj, int min, drmPciBusInfoPtr info)
{
#ifdef __linux__
@@ -3021,7 +3029,8 @@ static int drmParsePciBusInfo(int maj, int min,
drmPciBusInfoPtr info)
char real_path[PATH_MAX + 1], *value;
int num;
-if (get_real_pci_path(maj, min, real_path) == NULL)
+if (get_real_pci_path(maj, min, real_path) == NULL &&
+get_normal_pci_path(maj, min, real_path) == NULL)
return -ENOENT;
value = sysfs_uevent_get(real_path, "PCI_SLOT_NAME");
@@ -3142,7 +3151,8 @@ static int parse_separate_sysfs_files(int maj, int min,
FILE *fp;
int ret;
-if (get_real_pci_path(maj, min, real_path) == NULL)
+if (get_real_pci_path(maj, min, real_path) == NULL &&
+get_normal_pci_path(maj, min, real_path) == NULL)
return -ENOENT;
for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) {
@@ -3174,7 +3184,8 @@ static int parse_config_sysfs_file(int maj, int min,
unsigned char config[64];
int fd, ret;
-if (get_real_pci_path(maj, min, real_path) == NULL)
+if (get_real_pci_path(maj, min, real_path) == NULL &&
+get_normal_pci_path(maj, min, real_path) == NULL)
return -ENOENT;
snprintf(path, PATH_MAX, "%s/config", real_path);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm: add syncobj timeline support v2
On 2018年08月23日 17:15, Christian König wrote:
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an integer
payload
identifying a point in a timeline. Such timeline semaphores support the
following operations:
* Host query - A host operation that allows querying the payload
of the
timeline semaphore.
* Host wait - A host operation that allows a blocking wait for a
timeline semaphore to reach a specified value.
I think I have a idea what "Host" means in this context, but it would
probably be better to describe it.
How about "CPU"?
* Device wait - A device operation that allows waiting for a
timeline semaphore to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline semaphore to a specified value.
Since it's a timeline, that means the front time point(PT) always is
signaled before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence,
when PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when
timeline is increasing, will compare
wait PTs value with new timeline value, if PT value is lower than
timeline value, then wait PT will be
signaled, otherwise keep in list. semaphore wait operation can wait
on any point of timeline,
so need a RB tree to order them. And wait PT could ahead of signal
PT, we need a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate
patch. (Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate
patch.
5. drop the submission_fence implementation and instead use
wait_event() for that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
I really liked Daniels idea to handle the classic syncobj like a
timeline synobj with just 1 entry. That can probably simplify the
implementation quite a bit.
Yeah, after timeline, seems we can remove old syncobj->fence, right?
will try to unify them in additional patch.
Thanks,
David Zhou
Additional to that an amdgpu patch which shows how the interface is to
be used is probably something Daniel will want to see as well.
Christian.
TODO:
1. CPU query and wait on timeline semaphore.
2. test application (Daniel Vetter)
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 383
+++---
include/drm/drm_syncobj.h | 28 +++
include/uapi/drm/drm.h | 1 +
3 files changed, 389 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index 6227df2cc0a4..f738d78edf65 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,44 @@
#include "drm_internal.h"
#include
+struct drm_syncobj_stub_fence {
+ struct dma_fence base;
+ spinlock_t lock;
+};
+
+static const char *drm_syncobj_stub_fence_get_name(struct dma_fence
*fence)
+{
+ return "syncobjstub";
+}
+
+static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence
*fence)
+{
+ return !dma_fence_is_signaled(fence);
+}
+
+static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
+ .get_driver_name = drm_syncobj_stub_fence_get_name,
+ .get_timeline_name = drm_syncobj_stub_fence_get_name,
+ .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
+ .release = NULL,
+};
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64 value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_fence;
+ struct dma_fence *pre_pt_base;
+ struct dma_fence_cb signal_cb;
+ struct dma_fence_cb pre_pt_cb;
+ struct drm_syncobj *syncobj;
+ u64 value;
+ struct list_head list;
+};
+
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -137,6 +175,150 @@ void drm_syncobj_remove_callback(struct
drm_syncobj *syncobj,
spin_unlock(>lock);
}
+static void drm_syncobj_timeline_signal_wait_pts(struct
drm_syncobj *syncobj)
+{
+ struct rb_node *node = NULL;
+ struct drm_syncobj_wait_pt *wait_pt = NULL;
+
+ spin_lock(>lock);
+ for(node = rb_first(>syncobj_timeline.wait_pt_tree);
+ node != NULL; ) {
+ wait_pt = rb_entry(node, struct drm_syncobj_wait_pt, node);
+ node = rb_next(node);
+ if (wait_pt->value <= syncobj->syncobj_timeline.timeline) {
+ dma_fence_signal(_pt->base.base);
+ rb_erase(_pt->node,
+ >syncobj_timeline.wait_pt_tree);
+
Re: [PATCH v5 2/9] drm/exynos: move connector creation to attach callback
On 22.08.2018 04:59, Inki Dae wrote:
>
> 2018년 08월 21일 20:21에 Andrzej Hajda 이(가) 쓴 글:
>> On 21.08.2018 07:27, Inki Dae wrote:
>>> 2018년 08월 20일 18:00에 Andrzej Hajda 이(가) 쓴 글:
On 17.08.2018 03:56, Inki Dae wrote:
> 2018년 08월 13일 20:17에 Andrzej Hajda 이(가) 쓴 글:
>> On 07.08.2018 10:53, Inki Dae wrote:
>>> 2018년 07월 26일 00:46에 Andrzej Hajda 이(가) 쓴 글:
From: Maciej Purski
The current implementation assumes that the only possible peripheral
device for DSIM is a panel. Using an output bridge child device
should also be possible.
If an output bridge is available, don't create a new connector.
Instead, call drm_bridge_attach() and set encoder's bridge to NULL
in order to avoid an out bridge from being visible by the framework, as
the DSI bus needs control on enabling its child output bridge.
Such sequence is required by Toshiba TC358764 bridge, which is a DSI
peripheral bridge device.
changed in v5:
- detach bridge in mipi_dsi detach callback
Signed-off-by: Maciej Purski
[ a.ha...@samsung.com: v5 ]
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 50 -
1 file changed, 32 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 351403f9d245..f5f51f584fa0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -255,6 +255,7 @@ struct exynos_dsi {
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
struct drm_panel *panel;
+ struct drm_bridge *out_bridge;
struct device *dev;
void __iomem *reg_base;
@@ -1499,7 +1500,30 @@ static int exynos_dsi_host_attach(struct
mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct exynos_dsi *dsi = host_to_dsi(host);
- struct drm_device *drm = dsi->connector.dev;
+ struct drm_encoder *encoder = >encoder;
+ struct drm_device *drm = encoder->dev;
+ struct drm_bridge *out_bridge;
+
+ out_bridge = of_drm_find_bridge(device->dev.of_node);
>>> Is there any reason to find out_bridge without considering device tree
>>> graph binding?
>> If the sink is a child MIPI-DSI device, the bindings can be omitted, as
>> in case of all DSI panels in Exynos platforms.
>> In case bindings are not present you cannot use graph functions.
> In other words, this means that this patch doesn't allow to use the
> device tree graph binding.
> I.e., if other people wrote the graph things in his board dts file for
> the use of bridge device then with this patch he cannot use the bride
> device.
>
> So I think it would be better to allow to use both of them, as a child
> device and graph binding.
>
> How about trying to bind the graph things using
> drm_of_find_panel_or_bridge funtion first and then for child device way?
It could be done this way, but it should be done for panels and for
bridges, and it should be rather generic helper, not Exynos specific. So
>>> As the function name says, drm_of_find_panel_or_bridge function will return
>>> panel, bridge or both of them according to given arguments.
>>>
>>>
it is something which require additional investigation, discussion and
separate patchset.
>>> So I think we wouldn't need additional discussion at all becuase we don't
>>> touch panel but add only bridge device as output, and the use of this
>>> function for bridge looks more generic way.
>> But drm_of_find_panel_or_bridge is only for looking for non-dsi devices,
>> or more specifically for looking for devices connected in DTS via
>> DT-graph. This is not case of panels and bridges used in Exynos boards.
>> So this function is currently useless with our boards. Maybe some day we
>> will have bridge/panel controlled via I2C and then it will become
>> useful, but for now it serves for nothing.
>>
>>> Of course, as a separate patch, we could consider using this function for
>>> panel device later.
>> As you said drm_of_find_panel_or_bridge looks for panel and/or bridge,
>> and it was created to merge similar code in panel and bridge lookup,
>> using it only for bridges and not for panels seems against it's purpose.
>>
On the other side this patch is enough to correctly handle all DSI
bridges in existing Exynos boards.
> And I'm not clear about what kinds of devices could be a child device of
> DSI, which isn't required for the graph binding.
> Is there any
Re: [PATCH 5/5] drm: add syncobj timeline support v2
On 2018年08月23日 17:08, Daniel Vetter wrote:
On Thu, Aug 23, 2018 at 04:25:42PM +0800, Chunming Zhou wrote:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an integer payload
identifying a point in a timeline. Such timeline semaphores support the
following operations:
* Host query - A host operation that allows querying the payload of the
timeline semaphore.
* Host wait - A host operation that allows a blocking wait for a
timeline semaphore to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline semaphore to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline semaphore to a specified value.
Since it's a timeline, that means the front time point(PT) always is signaled
before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is
increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline
value, then wait PT will be
signaled, otherwise keep in list. semaphore wait operation can wait on any
point of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need
a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch.
(Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for
that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
Depending upon how it's going to be used, this is the wrong thing to do.
TODO:
1. CPU query and wait on timeline semaphore.
2. test application (Daniel Vetter)
I also had some more suggestions, around aligning the two concepts of
future fences
submission fence is replaced by wait_event, so I don't address your
future fence suggestion. And welcome to explain future fence status.
and at least trying to merge the timeline and the other
fence (which really is just a special case of a timeline with only 1
slot).
Could you detail that? Do you mean merge syncobj->fence to timeline point?
Thanks,
David Zhou
-Daniel
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 383 +++---
include/drm/drm_syncobj.h | 28 +++
include/uapi/drm/drm.h| 1 +
3 files changed, 389 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 6227df2cc0a4..f738d78edf65 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,44 @@
#include "drm_internal.h"
#include
+struct drm_syncobj_stub_fence {
+ struct dma_fence base;
+ spinlock_t lock;
+};
+
+static const char *drm_syncobj_stub_fence_get_name(struct dma_fence *fence)
+{
+return "syncobjstub";
+}
+
+static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
+{
+return !dma_fence_is_signaled(fence);
+}
+
+static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
+ .get_driver_name = drm_syncobj_stub_fence_get_name,
+ .get_timeline_name = drm_syncobj_stub_fence_get_name,
+ .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
+ .release = NULL,
+};
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_fence;
+ struct dma_fence *pre_pt_base;
+ struct dma_fence_cb signal_cb;
+ struct dma_fence_cb pre_pt_cb;
+ struct drm_syncobj *syncobj;
+ u64value;
+ struct list_head list;
+};
+
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -137,6 +175,150 @@ void drm_syncobj_remove_callback(struct drm_syncobj
*syncobj,
spin_unlock(>lock);
}
+static void drm_syncobj_timeline_signal_wait_pts(struct drm_syncobj *syncobj)
+{
+ struct rb_node *node = NULL;
+ struct drm_syncobj_wait_pt *wait_pt = NULL;
+
+ spin_lock(>lock);
+ for(node = rb_first(>syncobj_timeline.wait_pt_tree);
+ node != NULL; ) {
+ wait_pt = rb_entry(node, struct drm_syncobj_wait_pt, node);
+ node = rb_next(node);
+ if (wait_pt->value <= syncobj->syncobj_timeline.timeline) {
+ dma_fence_signal(_pt->base.base);
+
[PATCH 5/5] drm/msm/A6x: Add devfreq support in A6x
Implement routines to estimate GPU busy time and fetching the
current frequency for the polling interval. This is required by
the devfreq framework which recommends a frequency change if needed.
The driver code then tries to set this new frequency on the GPU by
sending an Out Of Band(OOB) request.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 46 +++
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 ++
4 files changed, 72 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index f6634c0..92ff48b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -67,8 +67,10 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
}
-static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
+static int __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
{
+ int ret;
+
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
@@ -84,7 +86,41 @@ static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
a6xx_gmu_set_oob(gmu, GMU_OOB_DCVS_SET);
a6xx_gmu_clear_oob(gmu, GMU_OOB_DCVS_SET);
- return gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
+ ret = gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
+ if (!ret)
+ gmu->cur_freq = gmu->gpu_freqs[index];
+
+ return ret;
+}
+
+int a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ struct a6xx_gmu *gmu = _gpu->gmu;
+ u32 perf_index = 0;
+
+ if (freq == gmu->cur_freq)
+ return 0;
+
+ //TODO: Use a hashmap instead? This gets called potentially every ~10 ms
+ for (perf_index = 0; perf_index < gmu->nr_gpu_freqs; perf_index++)
+ if (freq == gmu->gpu_freqs[perf_index])
+ break;
+
+ if (perf_index == gmu->nr_gpu_freqs)
+ return -EINVAL;
+
+ return __a6xx_gmu_set_freq(gmu, perf_index);
+}
+
+unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ struct a6xx_gmu *gmu = _gpu->gmu;
+
+ return gmu->cur_freq;
}
static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
@@ -629,8 +665,8 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
if (!ret)
ret = a6xx_hfi_start(gmu, GMU_COLD_BOOT);
- /* Set the GPU back to the highest power frequency */
- a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
+ /* Save the current frequency for devfreq */
+ gmu->cur_freq = gmu->gpu_freqs[gmu->nr_gpu_freqs - 1];
out:
if (ret)
@@ -671,7 +707,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
ret = a6xx_hfi_start(gmu, status);
/* Set the GPU to the highest power frequency */
- a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
+ __a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
out:
/* Make sure to turn off the boot OOB request on error */
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index f9e4dfe..ce6e5ca 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -77,6 +77,8 @@ struct a6xx_gmu {
unsigned long gmu_freqs[4];
u32 cx_arc_votes[4];
+ unsigned long cur_freq;
+
struct a6xx_hfi_queue queues[2];
struct tasklet_struct hfi_tasklet;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 3429d33a..af90706 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -7,6 +7,8 @@
#include "a6xx_gpu.h"
#include "a6xx_gmu.xml.h"
+#include
+
static inline bool _a6xx_check_idle(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -682,6 +684,8 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
gpu->needs_hw_init = true;
+ msm_gpu_resume_devfreq(gpu);
+
return ret;
}
@@ -690,6 +694,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ devfreq_suspend_device(gpu->devfreq.devfreq);
+
/*
* Make sure the GMU is idle before continuing (because some transitions
* may use VBIF
@@ -753,6 +759,24 @@ static void a6xx_destroy(struct msm_gpu *gpu)
kfree(a6xx_gpu);
}
+static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu =
[PATCH 1/5] drm/msm: suspend devfreq on init
Devfreq turns on and starts recommending power level as soon as it is initialized. The GPU is still not powered on by the time the devfreq init happens and this leads to problems on GPU's where register access is needed to get/set power levels. So we start suspended and only restart devfreq when GPU is powered on. Signed-off-by: Sharat Masetty --- drivers/gpu/drm/msm/msm_gpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index 5281a32..04f9604 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -104,6 +104,8 @@ static void msm_devfreq_init(struct msm_gpu *gpu) dev_err(>pdev->dev, "Couldn't initialize GPU devfreq\n"); gpu->devfreq.devfreq = NULL; } + + devfreq_suspend_device(gpu->devfreq.devfreq); } static int enable_pwrrail(struct msm_gpu *gpu) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/msm/A6x: Add gmu_read64() register read op
Add a simple function to read 64 registers in the GMU domain
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index a08ee8f..f9e4dfe 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -106,6 +106,19 @@ static inline void gmu_rmw(struct a6xx_gmu *gmu, u32 reg,
u32 mask, u32 or)
gmu_write(gmu, reg, val | or);
}
+static inline u64 gmu_read64(struct a6xx_gmu *gmu, u32 lo, u32 hi)
+{
+ u64 val;
+
+ /*
+* Implementation similar to gpu_read64()
+*/
+ val = (u64) msm_readl(gmu->mmio + (lo << 2));
+ val |= ((u64) msm_readl(gmu->mmio + (hi << 2)) << 32);
+
+ return val;
+}
+
#define gmu_poll_timeout(gmu, addr, val, cond, interval, timeout) \
readl_poll_timeout((gmu)->mmio + ((addr) << 2), val, cond, \
interval, timeout)
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/msm: re-factor devfreq code
devfreq framework requires the drivers to provide busy time estimations.
The GPU driver relies on the hardware performance counteres for the busy time
estimations, but different hardware revisions have counters which can be
sourced from different clocks. So the busy time estimation will be target
dependent. Additionally on targets where the clocks are completely controlled
by the on chip microcontroller, fetching and setting the current GPU frequency
will be different. This patch aims to embrace these differences by re-factoring
the devfreq code a bit.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 +---
drivers/gpu/drm/msm/msm_gpu.c | 49 ---
drivers/gpu/drm/msm/msm_gpu.h | 5 +++-
3 files changed, 44 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 897f3e2..043e680 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1369,12 +1369,20 @@ static struct msm_ringbuffer *a5xx_active_ring(struct
msm_gpu *gpu)
return a5xx_gpu->cur_ring;
}
-static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t *value)
+static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
{
- *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
- REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+ u64 busy_cycles;
+ unsigned long busy_time;
- return 0;
+ busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
+ REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+
+ busy_time = (busy_cycles - gpu->devfreq.busy_cycles) /
+ (clk_get_rate(gpu->core_clk) / 100);
+
+ gpu->devfreq.busy_cycles = busy_cycles;
+
+ return busy_time;
}
static const struct adreno_gpu_funcs funcs = {
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 83fd602..32269ef 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -36,12 +36,16 @@ static int msm_devfreq_target(struct device *dev, unsigned
long *freq,
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
struct dev_pm_opp *opp;
- opp = dev_pm_opp_find_freq_ceil(dev, freq);
+ opp = devfreq_recommended_opp(dev, freq, flags);
+ if (IS_ERR(opp))
+ return PTR_ERR(opp);
- if (!IS_ERR(opp)) {
+ if (gpu->funcs->gpu_set_freq)
+ gpu->funcs->gpu_set_freq(gpu, (u64)*freq);
+ else
clk_set_rate(gpu->core_clk, *freq);
- dev_pm_opp_put(opp);
- }
+
+ dev_pm_opp_put(opp);
return 0;
}
@@ -50,16 +54,14 @@ static int msm_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *status)
{
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
- u64 cycles;
ktime_t time;
- status->current_frequency = (unsigned long) clk_get_rate(gpu->core_clk);
- gpu->funcs->gpu_busy(gpu, );
-
- status->busy_time = (cycles - gpu->devfreq.busy_cycles) /
- (status->current_frequency / 100);
+ if (gpu->funcs->gpu_get_freq)
+ status->current_frequency = gpu->funcs->gpu_get_freq(gpu);
+ else
+ status->current_frequency = clk_get_rate(gpu->core_clk);
- gpu->devfreq.busy_cycles = cycles;
+ status->busy_time = gpu->funcs->gpu_busy(gpu);
time = ktime_get();
status->total_time = ktime_us_delta(time, gpu->devfreq.time);
@@ -72,7 +74,10 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
unsigned long *freq)
{
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
- *freq = (unsigned long) clk_get_rate(gpu->core_clk);
+ if (gpu->funcs->gpu_get_freq)
+ *freq = gpu->funcs->gpu_get_freq(gpu);
+ else
+ *freq = clk_get_rate(gpu->core_clk);
return 0;
}
@@ -87,7 +92,7 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
unsigned long *freq)
static void msm_devfreq_init(struct msm_gpu *gpu)
{
/* We need target support to do devfreq */
- if (!gpu->funcs->gpu_busy || !gpu->core_clk)
+ if (!gpu->funcs->gpu_busy)
return;
msm_devfreq_profile.initial_freq = gpu->fast_rate;
@@ -185,6 +190,14 @@ static int disable_axi(struct msm_gpu *gpu)
return 0;
}
+void msm_gpu_resume_devfreq(struct msm_gpu *gpu)
+{
+ gpu->devfreq.busy_cycles = 0;
+ gpu->devfreq.time = ktime_get();
+
+ devfreq_resume_device(gpu->devfreq.devfreq);
+}
+
int msm_gpu_pm_resume(struct msm_gpu *gpu)
{
int ret;
@@ -203,12 +216,7 @@ int msm_gpu_pm_resume(struct msm_gpu *gpu)
if (ret)
return ret;
- if (gpu->devfreq.devfreq) {
- gpu->devfreq.busy_cycles = 0;
- gpu->devfreq.time = ktime_get();
-
[PATCH 2/5] drm/msm: unregister devfreq upon clean up
Call the devfreq_remove_device() API to remove the GPU devfreq instance
during GPU driver cleanup.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/msm_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 04f9604..83fd602 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -970,6 +970,8 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
WARN_ON(!list_empty(>active_list));
+ devfreq_remove_device(gpu->devfreq.devfreq);
+
for (i = 0; i < ARRAY_SIZE(gpu->rb); i++) {
msm_ringbuffer_destroy(gpu->rb[i]);
gpu->rb[i] = NULL;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] msm/drm: A6x DCVS series
This patch series starts off with a few bug fixes in devfreq code, followed by refactoring the devfreq code needed for supporting different chipsets, and ends with adding devfreq support for A6x. Sharat Masetty (5): drm/msm: suspend devfreq on init drm/msm: unregister devfreq upon clean up drm/msm/A6x: Add gmu_read64() register read op drm/msm: re-factor devfreq code drm/msm/A6x: Add devfreq support in A6x drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 46 ++ drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 15 ++ drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27 ++ drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 ++ drivers/gpu/drm/msm/msm_gpu.c | 53 +-- drivers/gpu/drm/msm/msm_gpu.h | 5 +++- 7 files changed, 133 insertions(+), 31 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm: add syncobj timeline support v2
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an integer payload
identifying a point in a timeline. Such timeline semaphores support the
following operations:
* Host query - A host operation that allows querying the payload of the
timeline semaphore.
* Host wait - A host operation that allows a blocking wait for a
timeline semaphore to reach a specified value.
I think I have a idea what "Host" means in this context, but it would
probably be better to describe it.
* Device wait - A device operation that allows waiting for a
timeline semaphore to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline semaphore to a specified value.
Since it's a timeline, that means the front time point(PT) always is signaled
before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is
increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline
value, then wait PT will be
signaled, otherwise keep in list. semaphore wait operation can wait on any
point of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need
a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch.
(Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for
that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
I really liked Daniels idea to handle the classic syncobj like a
timeline synobj with just 1 entry. That can probably simplify the
implementation quite a bit.
Additional to that an amdgpu patch which shows how the interface is to
be used is probably something Daniel will want to see as well.
Christian.
TODO:
1. CPU query and wait on timeline semaphore.
2. test application (Daniel Vetter)
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 383 +++---
include/drm/drm_syncobj.h | 28 +++
include/uapi/drm/drm.h| 1 +
3 files changed, 389 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 6227df2cc0a4..f738d78edf65 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,44 @@
#include "drm_internal.h"
#include
+struct drm_syncobj_stub_fence {
+ struct dma_fence base;
+ spinlock_t lock;
+};
+
+static const char *drm_syncobj_stub_fence_get_name(struct dma_fence *fence)
+{
+return "syncobjstub";
+}
+
+static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
+{
+return !dma_fence_is_signaled(fence);
+}
+
+static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
+ .get_driver_name = drm_syncobj_stub_fence_get_name,
+ .get_timeline_name = drm_syncobj_stub_fence_get_name,
+ .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
+ .release = NULL,
+};
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_fence;
+ struct dma_fence *pre_pt_base;
+ struct dma_fence_cb signal_cb;
+ struct dma_fence_cb pre_pt_cb;
+ struct drm_syncobj *syncobj;
+ u64value;
+ struct list_head list;
+};
+
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -137,6 +175,150 @@ void drm_syncobj_remove_callback(struct drm_syncobj
*syncobj,
spin_unlock(>lock);
}
+static void drm_syncobj_timeline_signal_wait_pts(struct drm_syncobj *syncobj)
+{
+ struct rb_node *node = NULL;
+ struct drm_syncobj_wait_pt *wait_pt = NULL;
+
+ spin_lock(>lock);
+ for(node = rb_first(>syncobj_timeline.wait_pt_tree);
+ node != NULL; ) {
+ wait_pt = rb_entry(node, struct drm_syncobj_wait_pt, node);
+ node = rb_next(node);
+ if (wait_pt->value <= syncobj->syncobj_timeline.timeline) {
+ dma_fence_signal(_pt->base.base);
+ rb_erase(_pt->node,
+>syncobj_timeline.wait_pt_tree);
+ RB_CLEAR_NODE(_pt->node);
+ /*
Re: [PATCH 2/5] drm: rename null fence to stub fence in syncobj
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
stub fence will be used by timeline syncobj as well.
Mhm, I'm leaning a bit towards renaming it but "null" fence or "stub"
fence doesn't make a large difference to me.
Point is that it is a fence which is always signaled right from the
beginning.
So any name which describes that would be welcome.
Christian.
Signed-off-by: Chunming Zhou
Cc: Jason Ekstrand
---
drivers/gpu/drm/drm_syncobj.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index d17ed75ac7e2..d4b48fb410a1 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -172,37 +172,37 @@ void drm_syncobj_replace_fence(struct drm_syncobj
*syncobj,
}
EXPORT_SYMBOL(drm_syncobj_replace_fence);
-struct drm_syncobj_null_fence {
+struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
};
-static const char *drm_syncobj_null_fence_get_name(struct dma_fence *fence)
+static const char *drm_syncobj_stub_fence_get_name(struct dma_fence *fence)
{
-return "syncobjnull";
+return "syncobjstub";
}
-static bool drm_syncobj_null_fence_enable_signaling(struct dma_fence *fence)
+static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
{
return !dma_fence_is_signaled(fence);
}
-static const struct dma_fence_ops drm_syncobj_null_fence_ops = {
- .get_driver_name = drm_syncobj_null_fence_get_name,
- .get_timeline_name = drm_syncobj_null_fence_get_name,
- .enable_signaling = drm_syncobj_null_fence_enable_signaling,
+static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
+ .get_driver_name = drm_syncobj_stub_fence_get_name,
+ .get_timeline_name = drm_syncobj_stub_fence_get_name,
+ .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
.release = NULL,
};
static int drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
{
- struct drm_syncobj_null_fence *fence;
+ struct drm_syncobj_stub_fence *fence;
fence = kzalloc(sizeof(*fence), GFP_KERNEL);
if (fence == NULL)
return -ENOMEM;
spin_lock_init(>lock);
- dma_fence_init(>base, _syncobj_null_fence_ops,
+ dma_fence_init(>base, _syncobj_stub_fence_ops,
>lock, 0, 0);
dma_fence_signal(>base);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm: add syncobj timeline support v2
On Thu, Aug 23, 2018 at 04:25:42PM +0800, Chunming Zhou wrote:
> VK_KHR_timeline_semaphore:
> This extension introduces a new type of semaphore that has an integer payload
> identifying a point in a timeline. Such timeline semaphores support the
> following operations:
>* Host query - A host operation that allows querying the payload of the
> timeline semaphore.
>* Host wait - A host operation that allows a blocking wait for a
> timeline semaphore to reach a specified value.
>* Device wait - A device operation that allows waiting for a
> timeline semaphore to reach a specified value.
>* Device signal - A device operation that allows advancing the
> timeline semaphore to a specified value.
>
> Since it's a timeline, that means the front time point(PT) always is signaled
> before the late PT.
> a. signal PT design:
> Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
> PT[N] fence is signaled,
> the timeline will increase to value of PT[N].
> b. wait PT design:
> Wait PT fence is signaled by reaching timeline point value, when timeline is
> increasing, will compare
> wait PTs value with new timeline value, if PT value is lower than timeline
> value, then wait PT will be
> signaled, otherwise keep in list. semaphore wait operation can wait on any
> point of timeline,
> so need a RB tree to order them. And wait PT could ahead of signal PT, we
> need a sumission fence to
> perform that.
>
> v2:
> 1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
> 2. move unexposed denitions to .c file. (Daniel Vetter)
> 3. split up the change to drm_syncobj_find_fence() in a separate patch.
> (Christian)
> 4. split up the change to drm_syncobj_replace_fence() in a separate patch.
> 5. drop the submission_fence implementation and instead use wait_event() for
> that. (Christian)
> 6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
Depending upon how it's going to be used, this is the wrong thing to do.
> TODO:
> 1. CPU query and wait on timeline semaphore.
> 2. test application (Daniel Vetter)
I also had some more suggestions, around aligning the two concepts of
future fences and at least trying to merge the timeline and the other
fence (which really is just a special case of a timeline with only 1
slot).
-Daniel
>
> Signed-off-by: Chunming Zhou
> Cc: Christian Konig
> Cc: Dave Airlie
> Cc: Daniel Rakos
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_syncobj.c | 383
> +++---
> include/drm/drm_syncobj.h | 28 +++
> include/uapi/drm/drm.h| 1 +
> 3 files changed, 389 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 6227df2cc0a4..f738d78edf65 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -56,6 +56,44 @@
> #include "drm_internal.h"
> #include
>
> +struct drm_syncobj_stub_fence {
> + struct dma_fence base;
> + spinlock_t lock;
> +};
> +
> +static const char *drm_syncobj_stub_fence_get_name(struct dma_fence *fence)
> +{
> +return "syncobjstub";
> +}
> +
> +static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
> +{
> +return !dma_fence_is_signaled(fence);
> +}
> +
> +static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
> + .get_driver_name = drm_syncobj_stub_fence_get_name,
> + .get_timeline_name = drm_syncobj_stub_fence_get_name,
> + .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
> + .release = NULL,
> +};
> +
> +struct drm_syncobj_wait_pt {
> + struct drm_syncobj_stub_fence base;
> + u64value;
> + struct rb_node node;
> +};
> +struct drm_syncobj_signal_pt {
> + struct drm_syncobj_stub_fence base;
> + struct dma_fence *signal_fence;
> + struct dma_fence *pre_pt_base;
> + struct dma_fence_cb signal_cb;
> + struct dma_fence_cb pre_pt_cb;
> + struct drm_syncobj *syncobj;
> + u64value;
> + struct list_head list;
> +};
> +
> /**
> * drm_syncobj_find - lookup and reference a sync object.
> * @file_private: drm file private pointer
> @@ -137,6 +175,150 @@ void drm_syncobj_remove_callback(struct drm_syncobj
> *syncobj,
> spin_unlock(>lock);
> }
>
> +static void drm_syncobj_timeline_signal_wait_pts(struct drm_syncobj *syncobj)
> +{
> + struct rb_node *node = NULL;
> + struct drm_syncobj_wait_pt *wait_pt = NULL;
> +
> + spin_lock(>lock);
> + for(node = rb_first(>syncobj_timeline.wait_pt_tree);
> + node != NULL; ) {
> + wait_pt = rb_entry(node, struct drm_syncobj_wait_pt, node);
> + node = rb_next(node);
> + if (wait_pt->value <= syncobj->syncobj_timeline.timeline) {
> + dma_fence_signal(_pt->base.base);
> + rb_erase(_pt->node,
> + >syncobj_timeline.wait_pt_tree);
> +
Re: [PATCH 4/5] drm: expand replace_fence to support timeline point
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
we can place a fence to a timeline point after expanded.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 16 +---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/v3d/v3d_gem.c | 3 ++-
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
include/drm/drm_syncobj.h | 2 +-
6 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4d3f1a6ee078..ef922e34086e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1151,7 +1151,7 @@ static void amdgpu_cs_post_dependencies(struct
amdgpu_cs_parser *p)
int i;
for (i = 0; i < p->num_post_dep_syncobjs; ++i)
- drm_syncobj_replace_fence(p->post_dep_syncobjs[i], p->fence);
+ drm_syncobj_replace_fence(p->post_dep_syncobjs[i], p->fence, 0);
}
static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 3aac0b50a104..6227df2cc0a4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -141,11 +141,13 @@ void drm_syncobj_remove_callback(struct drm_syncobj
*syncobj,
* drm_syncobj_replace_fence - replace fence in a sync object.
* @syncobj: Sync object to replace fence in
* @fence: fence to install in sync file.
+ * @point: timeline point
*
- * This replaces the fence on a sync object.
+ * This replaces the fence on a sync object, or a timeline point fence.
*/
void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
- struct dma_fence *fence)
+ struct dma_fence *fence,
+ u64 point)
{
struct dma_fence *old_fence;
struct drm_syncobj_cb *cur, *tmp;
@@ -206,7 +208,7 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
>lock, 0, 0);
dma_fence_signal(>base);
- drm_syncobj_replace_fence(syncobj, >base);
+ drm_syncobj_replace_fence(syncobj, >base, 0);
dma_fence_put(>base);
@@ -258,7 +260,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
struct drm_syncobj,
refcount);
- drm_syncobj_replace_fence(syncobj, NULL);
+ drm_syncobj_replace_fence(syncobj, NULL, 0);
kfree(syncobj);
}
EXPORT_SYMBOL(drm_syncobj_free);
@@ -298,7 +300,7 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj,
uint32_t flags,
}
if (fence)
- drm_syncobj_replace_fence(syncobj, fence);
+ drm_syncobj_replace_fence(syncobj, fence, 0);
*out_syncobj = syncobj;
return 0;
@@ -483,7 +485,7 @@ static int drm_syncobj_import_sync_file_fence(struct
drm_file *file_private,
return -ENOENT;
}
- drm_syncobj_replace_fence(syncobj, fence);
+ drm_syncobj_replace_fence(syncobj, fence, 0);
dma_fence_put(fence);
drm_syncobj_put(syncobj);
return 0;
@@ -965,7 +967,7 @@ drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
return ret;
for (i = 0; i < args->count_handles; i++)
- drm_syncobj_replace_fence(syncobjs[i], NULL);
+ drm_syncobj_replace_fence(syncobjs[i], NULL, 0);
drm_syncobj_array_free(syncobjs, args->count_handles);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 60dc2a865f5f..fab3b8fe7a60 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2211,7 +2211,7 @@ signal_fence_array(struct i915_execbuffer *eb,
if (!(flags & I915_EXEC_FENCE_SIGNAL))
continue;
- drm_syncobj_replace_fence(syncobj, fence);
+ drm_syncobj_replace_fence(syncobj, fence, 0);
}
}
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index f6dfb8140a62..f3ec1f18c04c 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -587,7 +587,8 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
sync_out = drm_syncobj_find(file_priv, args->out_sync);
if (sync_out) {
drm_syncobj_replace_fence(sync_out,
- >render.base.s_fence->finished);
+ >render.base.s_fence->finished,
+ 0);
drm_syncobj_put(sync_out);
}
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index f7b4971342e8..68832d66d716 100644
Re: [PATCH 1/5] drm: fix syncobj null_fence_enable_signaling
On Thu, Aug 23, 2018 at 11:02 AM, Christian König
wrote:
> Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
>>
>> That is certainly totally nonsense. dma_fence_enable_sw_signaling()
>> is the function who is calling this callback.
>>
>> Signed-off-by: Chunming Zhou
>> Cc: Jason Ekstrand
>
>
> For this one: Reviewed-by: Christian König
As mentioned in the v1 thread, you can outright nuke this, no longer
needed. But this at least makes sense now. Ack either way.
-Daniel
>
>> ---
>> drivers/gpu/drm/drm_syncobj.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>> index 3a8837c49639..d17ed75ac7e2 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -184,7 +184,6 @@ static const char
>> *drm_syncobj_null_fence_get_name(struct dma_fence *fence)
>> static bool drm_syncobj_null_fence_enable_signaling(struct dma_fence
>> *fence)
>> {
>> -dma_fence_enable_sw_signaling(fence);
>> return !dma_fence_is_signaled(fence);
>> }
>>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm: expand drm_syncobj_find_fence to support timeline point
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
we can fetch timeline point fence after expanded.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 6 --
drivers/gpu/drm/v3d/v3d_gem.c | 4 ++--
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
include/drm/drm_syncobj.h | 2 +-
5 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 7a625f3989a0..4d3f1a6ee078 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1062,7 +1062,7 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct
amdgpu_cs_parser *p,
{
int r;
struct dma_fence *fence;
- r = drm_syncobj_find_fence(p->filp, handle, );
+ r = drm_syncobj_find_fence(p->filp, handle, , 0);
if (r)
return r;
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index d4b48fb410a1..3aac0b50a104 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -218,6 +218,7 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
* @file_private: drm file private pointer
* @handle: sync object handle to lookup.
* @fence: out parameter for the fence
+ * @point: timeline point
*
* This is just a convenience function that combines drm_syncobj_find() and
* drm_syncobj_fence_get().
@@ -228,7 +229,8 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle,
- struct dma_fence **fence)
+ struct dma_fence **fence,
+ u64 point)
{
struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
int ret = 0;
@@ -498,7 +500,7 @@ static int drm_syncobj_export_sync_file(struct drm_file
*file_private,
if (fd < 0)
return fd;
- ret = drm_syncobj_find_fence(file_private, handle, );
+ ret = drm_syncobj_find_fence(file_private, handle, , 0);
if (ret)
goto err_put_fd;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index e1fcbb4cd0ae..f6dfb8140a62 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -521,12 +521,12 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
kref_init(>refcount);
ret = drm_syncobj_find_fence(file_priv, args->in_sync_bcl,
->bin.in_fence);
+>bin.in_fence, 0);
if (ret == -EINVAL)
goto fail;
ret = drm_syncobj_find_fence(file_priv, args->in_sync_rcl,
->render.in_fence);
+>render.in_fence, 0);
if (ret == -EINVAL)
goto fail;
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 7910b9acedd6..f7b4971342e8 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -1173,7 +1173,7 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
if (args->in_sync) {
ret = drm_syncobj_find_fence(file_priv, args->in_sync,
-_fence);
+_fence, 0);
if (ret)
goto fail;
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index e419c79ba94d..9962f7a1672c 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -135,7 +135,7 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
struct dma_fence *fence);
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle,
- struct dma_fence **fence);
+ struct dma_fence **fence, u64 point);
The fence is the result of the function and should come last.
Christian.
void drm_syncobj_free(struct kref *kref);
int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
struct dma_fence *fence);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: fix syncobj null_fence_enable_signaling
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
That is certainly totally nonsense. dma_fence_enable_sw_signaling()
is the function who is calling this callback.
Signed-off-by: Chunming Zhou
Cc: Jason Ekstrand
For this one: Reviewed-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 3a8837c49639..d17ed75ac7e2 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -184,7 +184,6 @@ static const char *drm_syncobj_null_fence_get_name(struct
dma_fence *fence)
static bool drm_syncobj_null_fence_enable_signaling(struct dma_fence *fence)
{
-dma_fence_enable_sw_signaling(fence);
return !dma_fence_is_signaled(fence);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] etnaviv: missing dma_mask
Am Freitag, den 17.08.2018, 08:42 +0200 schrieb Christoph Hellwig: > On Tue, Aug 14, 2018 at 05:12:25PM +0300, Eugeniy Paltsev wrote: > > Hi Lucas, Christoph, > > > > After switching ARC to generic dma_noncoherent cache ops > > etnaviv driver start failing on dma maping functions because of > > dma_mask lack. > > > > So I'm wondering is it valid case to have device which is > > DMA capable and doesn't have dma_mask set? > > > > If not, then I guess something like that should work > > (at least it works for ARC): > > This looks ok is a minimal fix: > > Reviewed-by: Christoph Hellwig > > But why doesn't this device have a dma-range property in DT? Because the etnaviv device is a virtual device not represented in DT, as it is only used to expose the DRM device, which may cover multiple GPU core devices. The GPU core devices are properly configured from DT, but unfortunately many of the dma related operations happen through the DRM device. We could fix this by replacing many of the DRM helpers with etnaviv specific functions handling dma per GPU core, but it isn't a clear win right now, as generally on SoCs with multiple GPU cores, the devices are on the same bus and have the same dma requirements. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
On 23/08/2018 08:07, Zhenyu Wang wrote:
> On 2018.08.22 20:20:46 +0200, Paolo Bonzini wrote:
>> On 22/08/2018 18:44, Linus Torvalds wrote:
>>> An example of something that *isn't* right, is the i915 kvm interface,
>>> which does
>>>
>>> use_mm(kvm->mm);
>>>
>>> on an mm that was initialized in virt/kvm/kvm_main.c using
>>>
>>> mmgrab(current->mm);
>>> kvm->mm = current->mm;
>>>
>>> which is *not* right. Using "mmgrab()" does indeed guarantee the
>>> lifetime of the 'struct mm_struct' itself, but it does *not* guarantee
>>> the lifetime of the page tables. You need to use "mmget()" and
>>> "mmput()", which get the reference to the actual process address
>>> space!
>>>
>>> Now, it is *possible* that the kvm use is correct too, because kvm
>>> does register a mmu_notifier chain, and in theory you can avoid the
>>> proper refcounting by just making sure the mmu "release" notifier
>>> kills any existing uses, but I don't really see kvm doing that. Kvm
>>> does register a release notifier, but that just flushes the shadow
>>> page tables, it doesn't kill any use_mm() use by some i915 use case.
>>
>> Yes, KVM is correct but the i915 bits are at least fishy. It's probably
>> as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init
>> and kvmgt_guest_exit, or maybe mmget_not_zero.
>>
>
> yeah, that's the clear way to fix this imo. We only depend on guest
> life cycle to access guest memory properly. Here's proposed fix, will
> verify and integrate it later.
>
> Thanks!
>
> From 5e5a8d0409aa150884adf5a4d0b956fd0b9906b3 Mon Sep 17 00:00:00 2001
> From: Zhenyu Wang
> Date: Thu, 23 Aug 2018 14:08:06 +0800
> Subject: [PATCH] drm/i915/gvt: Fix life cycle reference on KVM mm
>
> Handle guest mm access life cycle properly with mmget()/mmput()
> through guest init()/exit(). As noted by Linus, use_mm() depends
> on valid live page table but KVM's mmgrab() doesn't guarantee that.
> As vGPU usage depends on guest VM life cycle, need to make sure to
> use mmget()/mmput() to guarantee VM address access.
>
> Cc: Linus Torvalds
> Cc: Paolo Bonzini
> Cc: Zhi Wang
> Signed-off-by: Zhenyu Wang
Reviewed-by: Paolo Bonzini
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 71751be329e3..4a0988747d08 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1614,9 +1615,16 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
> if (__kvmgt_vgpu_exist(vgpu, kvm))
> return -EEXIST;
>
> + if (!mmget_not_zero(kvm->mm)) {
> + gvt_vgpu_err("Can't get KVM mm reference\n");
> + return -EINVAL;
> + }
> +
> info = vzalloc(sizeof(struct kvmgt_guest_info));
> - if (!info)
> + if (!info) {
> + mmput(kvm->mm);
> return -ENOMEM;
> + }
>
> vgpu->handle = (unsigned long)info;
> info->vgpu = vgpu;
> @@ -1647,6 +1655,8 @@ static bool kvmgt_guest_exit(struct kvmgt_guest_info
> *info)
> debugfs_remove(info->debugfs_cache_entries);
>
> kvm_page_track_unregister_notifier(info->kvm, >track_node);
> + if (info->kvm->mm)
> + mmput(info->kvm->mm);
> kvm_put_kvm(info->kvm);
> kvmgt_protect_table_destroy(info);
> gvt_cache_destroy(info->vgpu);
>
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/2] drm/blend: Add per-plane pixel blend mode property
Hi, This serie aims at adding the support for pixel blend modes represent the alpha blending equation selection in the driver. It also introduces to use it in the malidp driver. Let me know what you think, Lowry Changes for v5: - Adds comments in drm_blend.h. - Removes setting default value in drm_plane_create_blend_mode_property() as it is already in __drm_atomic_helper_plane_reset(). - Fixes to use state->pixel_blend_mode instead of using plane->state->pixel_blend_mode in reset function. - Rebases on drm-misc-next. Changes for v4: - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum() can calculate the index itself just fine, so no point in having the caller pass it in. - Since the current DRM assumption is that alpha is premultiplied as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better. - Refines some comments. - Updates on drm/malidp, hardware limitation check only when the format has alpha pixel. - Rebases on drm-misc-next and fixed the confilcts Changes for v3: - Refines the comments of drm_plane_create_blend_mode_property: 1) Puts the descriptions (after the ":") on a new line 2) Adds explaining why @supported_modes need PREMUL as default - Refines the comments of drm/mali-dp patchset - Rebased on drm-misc-next and fixed the confilcts with plane alpha patch Changes for v2: - Moves the blending equation into the DOC comment - Refines the comments of drm_plane_create_blend_mode_property to not enumerate the #defines, but instead the string values - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha - Introduces to use it in the malidp driver, which depends on the plane alpha patch Changes from v1: - v1 is just the core changes to request for commments - Adds a pixel_blend_mode to drm_plane_state and a blend_mode_property to drm_plane, and related support functions - Defines three blend modes in drm_blend.h - Rebased on current drm-next Lowry Li (2): drm: Add per-plane pixel blend mode property drm/mali-dp: Implement plane alpha and pixel blend on malidp drivers/gpu/drm/arm/malidp_planes.c | 74 +- drivers/gpu/drm/drm_atomic.c| 4 ++ drivers/gpu/drm/drm_atomic_helper.c | 1 + drivers/gpu/drm/drm_blend.c | 123 include/drm/drm_blend.h | 6 ++ include/drm/drm_plane.h | 9 +++ 6 files changed, 186 insertions(+), 31 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
