dri-devel November 2021

dri-devel@lists.freedesktop.org

340 participants
748 discussions

[PATCH] drm: sti: fix spelling mistake: rejec -> rejection
by Colin King 07 Apr '22

07 Apr '22

From: Colin Ian King <colin.king(a)canonical.com> In other places of the driver the string hdmi_rejection_pll is used instead of the truncated hdmi_rejec_pll, so use this string instead to be consistent. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/sti/sti_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index 814560ead4e1..e2018e4a3ec5 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -886,7 +886,7 @@ static void sti_hdmi_pre_enable(struct drm_bridge *bridge) if (clk_prepare_enable(hdmi->clk_tmds)) DRM_ERROR("Failed to prepare/enable hdmi_tmds clk\n"); if (clk_prepare_enable(hdmi->clk_phy)) - DRM_ERROR("Failed to prepare/enable hdmi_rejec_pll clk\n"); + DRM_ERROR("Failed to prepare/enable hdmi_rejection_pll clk\n"); hdmi->enabled = true; -- 2.20.1

2 1

Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier
by Thierry Reding 01 Apr '22

01 Apr '22

On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote: > 01.07.2021 21:14, Thierry Reding пишет: > > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote: > >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote: > >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote: > >>>> On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote: > >>>>> From: Thierry Reding <treding(a)nvidia.com> > >>>>> > >>>>> Reserved memory region phandle references can be accompanied by a > >>>>> specifier that provides additional information about how that specific > >>>>> reference should be treated. > >>>>> > >>>>> One use-case is to mark a memory region as needing an identity mapping > >>>>> in the system's IOMMU for the device that references the region. This is > >>>>> needed for example when the bootloader has set up hardware (such as a > >>>>> display controller) to actively access a memory region (e.g. a boot > >>>>> splash screen framebuffer) during boot. The operating system can use the > >>>>> identity mapping flag from the specifier to make sure an IOMMU identity > >>>>> mapping is set up for the framebuffer before IOMMU translations are > >>>>> enabled for the display controller. > >>>>> > >>>>> Signed-off-by: Thierry Reding <treding(a)nvidia.com> > >>>>> --- > >>>>> .../reserved-memory/reserved-memory.txt | 21 +++++++++++++++++++ > >>>>> include/dt-bindings/reserved-memory.h | 8 +++++++ > >>>>> 2 files changed, 29 insertions(+) > >>>>> create mode 100644 include/dt-bindings/reserved-memory.h > >>>> > >>>> Sorry for being slow on this. I have 2 concerns. > >>>> > >>>> First, this creates an ABI issue. A DT with cells in 'memory-region' > >>>> will not be understood by an existing OS. I'm less concerned about this > >>>> if we address that with a stable fix. (Though I'm pretty sure we've > >>>> naively added #?-cells in the past ignoring this issue.) > >>> > >>> A while ago I had proposed adding memory-region*s* as an alternative > >>> name for memory-region to make the naming more consistent with other > >>> types of properties (think clocks, resets, gpios, ...). If we added > >>> that, we could easily differentiate between the "legacy" cases where > >>> no #memory-region-cells was allowed and the new cases where it was. > >>> > >>>> Second, it could be the bootloader setting up the reserved region. If a > >>>> node already has 'memory-region', then adding more regions is more > >>>> complicated compared to adding new properties. And defining what each > >>>> memory-region entry is or how many in schemas is impossible. > >>> > >>> It's true that updating the property gets a bit complicated, but it's > >>> not exactly rocket science. We really just need to splice the array. I > >>> have a working implemention for this in U-Boot. > >>> > >>> For what it's worth, we could run into the same issue with any new > >>> property that we add. Even if we renamed this to iommu-memory-region, > >>> it's still possible that a bootloader may have to update this property > >>> if it already exists (it could be hard-coded in DT, or it could have > >>> been added by some earlier bootloader or firmware). > >>> > >>>> Both could be addressed with a new property. Perhaps something like > >>>> 'iommu-memory-region = <&phandle>;'. I think the 'iommu' prefix is > >>>> appropriate given this is entirely because of the IOMMU being in the > >>>> mix. I might feel differently if we had other uses for cells, but I > >>>> don't really see it in this case. > >>> > >>> I'm afraid that down the road we'll end up with other cases and then we > >>> might proliferate a number of *-memory-region properties with varying > >>> prefixes. > >>> > >>> I am aware of one other case where we might need something like this: on > >>> some Tegra SoCs we have audio processors that will access memory buffers > >>> using a DMA engine. These processors are booted from early firmware > >>> using firmware from system memory. In order to avoid trashing the > >>> firmware, we need to reserve memory. We can do this using reserved > >>> memory nodes. However, the audio DMA engine also uses the SMMU, so we > >>> need to make sure that the firmware memory is marked as reserved within > >>> the SMMU. This is similar to the identity mapping case, but not exactly > >>> the same. Instead of creating a 1:1 mapping, we just want that IOVA > >>> region to be reserved (i.e. IOMMU_RESV_RESERVED instead of > >>> IOMMU_RESV_DIRECT{,_RELAXABLE}). > >>> > >>> That would also fall into the IOMMU domain, but we can't reuse the > >>> iommu-memory-region property for that because then we don't have enough > >>> information to decide which type of reservation we need. > >>> > >>> We could obviously make iommu-memory-region take a specifier, but we > >>> could just as well use memory-regions in that case since we have > >>> something more generic anyway. > >>> > >>> With the #memory-region-cells proposal, we can easily extend the cell in > >>> the specifier with an additional MEMORY_REGION_IOMMU_RESERVE flag to > >>> take that other use case into account. If we than also change to the new > >>> memory-regions property name, we avoid the ABI issue (and we gain a bit > >>> of consistency while at it). > >> > >> Ping? Rob, do you want me to add this second use-case to the patch > >> series to make it more obvious that this isn't just a one-off thing? Or > >> how do we proceed? > > > > Rob, given that additional use-case, do you want me to run with this > > proposal and send out an updated series? > > > What about variant with a "descriptor" properties that will describe > each region: > > fb_desc: display-framebuffer-memory-descriptor { > needs-identity-mapping; > } > > display@52400000 { > memory-region = <&fb ...>; > memory-region-descriptor = <&fb_desc ...>; > }; > > It could be a more flexible/extendible variant. This problem recently came up on #dri-devel again. Adding Alyssa and Sven who are facing a similar challenge on their work on Apple M1 (if I understood correctly). Also adding dri-devel for visibility since this is a very common problem for display in particular. On M1 the situation is slightly more complicated: the firmware will allocate a couple of buffers (including the framebuffer) in high memory (> 4 GiB) and use the IOMMU to map that into an IOVA region below 4 GiB so that the display hardware can access it. This makes it impossible to bypass the IOMMU like we do on other chips (in particular to work around the fault-by-default policy of the ARM SMMU driver). It also means that in addition to the simple reserved regions I mentioned we need for audio use-cases and identity mapping use-cases we need for display on Tegra, we now also need to be able to convey physical to IOVA mappings. Fitting the latter into the original proposal sounds difficult. A quick fix would've been to generate a mapping table in memory and pass that to the kernel using a reserved-memory node (similar to what's done for example on Tegra for the EMC frequency table on Tegra210) and mark it as such using a special flag. But that then involves two layers of parsing, which seems a bit suboptimal. Another way to shoehorn that into the original proposal would've been to add flags for physical and virtual address regions and use pairs to pass them using special flags. Again, this is a bit wonky because it needs these to be carefully parsed and matched up. Another downside is that we now have a situation where some of these regions are no longer "reserved-memory regions" in the traditional sense. This would require an additional flag in the reserved-memory region nodes to prevent the IOVA regions from being reserved. By the way, this is something that would also be needed for the audio use-case I mentioned before, because the physical memory at that address can still be used by an operating system. A more general solution would be to draw a bit from Dmitry's proposal and introduce a new top-level "iov-reserved-memory" node. This could be modelled on the existing reserved-memory node, except that the physical memory pages for regions represented by child nodes would not be marked as reserved. Only the IOVA range described by the region would be reserved subsequently by the IOMMU framework and/or IOMMU driver. The simplest case where we just want to reserve some IOVA region could then be done like this: iov-reserved-memory { /* * Probably safest to default to <2>, <2> here given * that most IOMMUs support either > 32 bits of IAS * or OAS. */ #address-cells = <2>; #size-cells = <2>; firmware: firmware@80000000 { reg = <0 0x80000000 0 0x01000000>; }; }; audio@30000000 { ... iov-memory-regions = <&firmware>; ... }; Mappings could be represented by an IOV reserved region taking a reference to the reserved-region that they map: reserved-memory { #address-cells = <2>; #size-cells = <2>; /* 16 MiB of framebuffer at top-of-memory */ framebuffer: framebuffer@1,ff000000 { reg = <0x1 0xff000000 0 0x01000000>; no-map; }; }; iov-reserved-memory { /* IOMMU supports only 32-bit output address space */ #address-cells = <1>; #size-cells = <1>; /* 16 MiB of framebuffer mapped to top of IOVA */ fb: fb@ff000000 { reg = <0 0xff000000 0 0x01000000>; memory-region = <&framebuffer>; }; }; display@40000000 { ... /* optional? */ memory-region = <&framebuffer>; iov-memory-regions = <&fb>; ... }; It's interesting how identity mapped regions now become a trivial special case of mappings. All that is needed is to make the reg property of the IOV reserved region correspond to the reg property of the normal reserved region. Alternatively, as a small optimization for lazy people like me, we could just allow these cases to omit the reg property and instead inherit it from the referenced reserved region. As the second example shows it might be convenient if memory-region could be derived from iov-memory-regions. This could be useful for cases where the driver wants to do something with the physical pages of the reserved region (such as mapping them and copying out the framebuffer data to another buffer so that the reserved memory can be recycled). If we have the IOV reserved region, we could provide an API to extract the physical reserved region (if it exists). That way we could avoid referencing it twice in DT. Then again, there's something elegant about the explicit second reference to. It indicates the intent that we may want to use the region for something other than just the IOV mapping. Anyway, this has been long enough. Let me know what you think. Alyssa, Sven, it'd be interesting to hear if you think this could work as a solution to the problem on M1. Rob, I think you might like this alternative because it basically gets rid of all the points in the original proposal that you were concerned about. Let me know what you think. Thierry

3 12

[Bug 214071] New: amdgpu idle power draw to high at +75Hz
by bugzilla-daemon＠bugzilla.kernel.org 31 Mar '22

31 Mar '22

https://bugzilla.kernel.org/show_bug.cgi?id=214071 Bug ID: 214071 Summary: amdgpu idle power draw to high at +75Hz Product: Drivers Version: 2.5 Kernel Version: 5.13.10 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: pb.g(a)gmx.de Regression: No For best viewing pleasure I usually set my monitor to 144Hz and native 1080p. At that refresh rate my RX6900XT draws about 35 Watts in idle situations Memory clock stays at 1000Hz. I have to lower the monitors refresh rate to 75Hz, then the card draws only 8 Watts in idle and memory clock goes significantly down to 96MHz. Using 100 or 120 Hz does not help. Situation in windows is different. The same hardware setup works in Windows10 at 1080p@144 with idle power draw of just 8 Watts. So my guess is this is a driver issue and not a hardware issue. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 4

[Bug 213983] New: WARNING: CPU: 3 PID: 520 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x7a/0x803 [ttm]
by bugzilla-daemon＠bugzilla.kernel.org 29 Mar '22

29 Mar '22

https://bugzilla.kernel.org/show_bug.cgi?id=213983 Bug ID: 213983 Summary: WARNING: CPU: 3 PID: 520 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x7a/0x803 [ttm] Product: Drivers Version: 2.5 Kernel Version: 5.14-rc4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: erhard_f(a)mailbox.org Regression: No Created attachment 298221 --> https://bugzilla.kernel.org/attachment.cgi?id=298221&action=edit kernel dmesg (5.14-rc4, AMD A10-7860K) System was running fine for hours but got this at reboot: [...] [35939.202358] ------------[ cut here ]------------ [35939.202603] WARNING: CPU: 3 PID: 520 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x7a/0x803 [ttm] [35939.202870] Modules linked in: rfkill dm_crypt nhpoly1305_sse2 nhpoly1305 chacha_generic chacha_x86_64 libchacha adiantum libpoly1305 algif_skcipher input_leds joydev led_class dm_mod hid_generic usbhid hid raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx amdgpu md_mod evdev f2fs crc32_generic lz4hc_compress lz4_compress lz4_decompress edac_mce_amd crc32_pclmul ext4 crc16 mbcache jbd2 ohci_pci snd_hda_codec_hdmi drm_ttm_helper ttm aesni_intel snd_hda_intel mfd_core libaes crypto_simd cryptd gpu_sched snd_intel_dspcfg i2c_algo_bit k10temp snd_hda_codec fam15h_power i2c_piix4 snd_hwdep drm_kms_helper snd_hda_core ohci_hcd cfbfillrect ehci_pci xhci_pci xhci_hcd ehci_hcd syscopyarea cfbimgblt snd_pcm sysfillrect sysimgblt usbcore fb_sys_fops snd_timer cfbcopyarea usb_common snd soundcore video acpi_cpufreq processor button zram nct6775 zsmalloc hwmon_vid hwmon drm nfsd fb fuse font fbdev auth_rpcgss drm_panel_orientation_quirks backlight lockd grace configfs sunrpc [35939.203200] efivarfs [35939.205121] CPU: 3 PID: 520 Comm: X Not tainted 5.14.0-rc4-bdver3 #2 [35939.212327] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./A88M-G/3.1, BIOS P1.40C 11/21/2016 [35939.219364] RIP: 0010:ttm_bo_release+0x7a/0x803 [ttm] [35939.219387] Code: e0 2a 48 c1 ea 03 8a 14 02 48 8b 04 24 83 e0 07 83 c0 03 38 d0 7c 0d 84 d2 74 09 48 8b 3c 24 e8 99 eb 7c dd 83 7b 4c 00 74 02 <0f> 0b 48 8d 43 18 48 89 c2 48 89 44 24 10 b8 ff ff 37 00 48 c1 ea [35939.230367] RSP: 0018:ffffc900050dfb08 EFLAGS: 00010202 [35939.230376] RAX: 0000000000000007 RBX: ffff8881716441f0 RCX: ffff8881716441f0 [35939.230381] RDX: 1ffff1102e2c8800 RSI: 0000000000000004 RDI: ffff8881716441f0 [35939.230387] RBP: ffff8881716441d8 R08: 0000000000000001 R09: ffffed102e2c883f [35939.230391] R10: ffff8881716441f3 R11: ffffffffc0b6a201 R12: ffff888115000010 [35939.264555] R13: ffff888115005608 R14: ffff888171644058 R15: ffffffff9f5cf160 [35939.264564] FS: 00007fe7325f9980(0000) GS:ffff8883e0580000(0000) knlGS:0000000000000000 [35939.264572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35939.264579] CR2: 00007fe73190d0e8 CR3: 0000000141978000 CR4: 00000000000506e0 [35939.264586] Call Trace: [35939.264591] ? fsnotify_grab_connector+0x8c/0x93 [35939.264608] amdgpu_bo_unref+0x30/0x57 [amdgpu] [35939.318763] amdgpu_gem_object_free+0x69/0x95 [amdgpu] [35939.319132] ? list_add+0xd1/0xd1 [amdgpu] [35939.319478] ? test_bit+0x1d/0x27 [35939.319489] drm_gem_dmabuf_release+0x5b/0x67 [drm] [35939.319551] dma_buf_release+0x113/0x1b6 [35939.319563] __dentry_kill+0x29e/0x302 [35939.319573] dput+0x184/0x1c3 [35939.319582] __fput+0x4dc/0x598 [35939.319590] task_work_run+0xfa/0x118 [35939.319599] do_exit+0x984/0x17ba [35939.319609] ? mm_update_next_owner+0x3fd/0x3fd [35939.319619] do_group_exit+0x229/0x229 [35939.319627] __x64_sys_exit_group+0x39/0x39 [35939.319635] do_syscall_64+0x75/0x88 [35939.319649] ? do_syscall_64+0xe/0x88 [35939.319658] entry_SYSCALL_64_after_hwframe+0x44/0xae [35939.319668] RIP: 0033:0x7fe731edd459 [35939.319676] Code: Unable to access opcode bytes at RIP 0x7fe731edd42f. [35939.319680] RSP: 002b:00007ffc8d3e1298 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [35939.319691] RAX: ffffffffffffffda RBX: 00007fe731fc6920 RCX: 00007fe731edd459 [35939.319698] RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 [35939.319704] RBP: 00007fe731fc6920 R08: fffffffffffffd40 R09: 00005630715eb7c0 [35939.319711] R10: 00007fe710db0a14 R11: 0000000000000246 R12: 0000000000000000 [35939.319716] R13: 0000000000000000 R14: 0000000000000668 R15: 0000000000000000 [35939.319724] ---[ end trace 0f92591c8b7a0f11 ]--- # inxi -bZ System: Kernel: 5.14.0-rc4-bdver3 x86_64 bits: 64 Desktop: MATE 1.24.1 Distro: Gentoo Base System release 2.7 Machine: Type: Desktop Mobo: ASRock model: A88M-G/3.1 serial: <superuser/root required> UEFI: American Megatrends v: P1.40C date: 11/21/2016 CPU: Info: Quad Core AMD A10-7860K Radeon R7 12 Compute Cores 4C+8G [MCP] speed: 1560 MHz min/max: 1400/3600 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Kaveri [Radeon R7 Graphics] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.11 driver: amdgpu,ati unloaded: fbdev,modesetting resolution: 1920x1080~60Hz OpenGL: renderer: AMD KAVERI (DRM 3.42.0 5.14.0-rc4-bdver3 LLVM 12.0.1) v: 4.6 Mesa 21.1.4 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Drives: Local Storage: total: 9.33 TiB used: 4.13 TiB (44.3%) Info: Processes: 225 Uptime: 16m Memory: 13.32 GiB used: 1.38 GiB (10.3%) Shell: Bash inxi: 3.1.06 # lspci -s 00:01.0 -vv 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] (rev d6) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Kaveri [Radeon R7 Graphics] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 62 IOMMU group: 0 Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at d0000000 (64-bit, prefetchable) [size=8M] Region 4: I/O ports at f000 [size=256] Region 5: Memory at feb00000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0 ExtTag+ RBE+ FLReset- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix+, MaxEETLPPrefixes 1 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, AtomicOpsCtl: ReqEn- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee04004 Data: 002a Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [270 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: 0 Capabilities: [2b0 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable+, Smallest Translation Unit: 00 Capabilities: [2c0 v1] Page Request Interface (PRI) PRICtl: Enable- Reset- PRISta: RF- UPRGI- Stopped+ Page Request Capacity: 00000020, Page Request Allocation: 00000000 Capabilities: [2d0 v1] Process Address Space ID (PASID) PASIDCap: Exec- Priv-, Max PASID Width: 10 PASIDCtl: Enable- Exec- Priv- Kernel driver in use: amdgpu Kernel modules: amdgpu -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 6

linux-next: build warning after merge of the drm-misc tree
by Stephen Rothwell 28 Mar '22

28 Mar '22

Hi all, After merging the drm-misc tree, today's linux-next build (htmldocs) produced this warning: include/drm/gpu_scheduler.h:316: warning: Function parameter or member 'work' not described in 'drm_sched_job' Introduced by commit 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes") -- Cheers, Stephen Rothwell

3 6

[PATCH v12 1/4] dt-bindings:drm/bridge:anx7625:add vendor define
by Xin Ji 28 Mar '22

28 Mar '22

Add 'bus-type' and 'data-lanes' define for port0. Add DP tx lane0, lane1 swing register setting array, and audio enable flag. The device which cannot pass DP tx PHY CTS caused by long PCB trace or embedded MUX, adjusting ANX7625 PHY parameters can pass the CTS test. The adjusting type include Pre-emphasis, Vp-p, Rterm(Resistor Termination) and Rsel(Driven Strength). Each lane has maximum 20 registers for these settings. Signed-off-by: Xin Ji <xji(a)analogixsemi.com> Reviewed-by: Rob Herring <robh(a)kernel.org> --- .../display/bridge/analogix,anx7625.yaml | 65 ++++++++++++++++++- 1 file changed, 63 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index ab48ab2f4240..1d3e88daca04 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -43,14 +43,70 @@ properties: vdd33-supply: description: Regulator that provides the supply 3.3V power. + analogix,lane0-swing: + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 1 + maxItems: 20 + description: + an array of swing register setting for DP tx lane0 PHY. + Registers 0~9 are Swing0_Pre0, Swing1_Pre0, Swing2_Pre0, + Swing3_Pre0, Swing0_Pre1, Swing1_Pre1, Swing2_Pre1, Swing0_Pre2, + Swing1_Pre2, Swing0_Pre3, they are for [Boost control] and + [Swing control] setting. + Registers 0~9, bit 3:0 is [Boost control], these bits control + post cursor manual, increase the [Boost control] to increase + Pre-emphasis value. + Registers 0~9, bit 6:4 is [Swing control], these bits control + swing manual, increase [Swing control] setting to add Vp-p value + for each Swing, Pre. + Registers 10~19 are Swing0_Pre0, Swing1_Pre0, Swing2_Pre0, + Swing3_Pre0, Swing0_Pre1, Swing1_Pre1, Swing2_Pre1, Swing0_Pre2, + Swing1_Pre2, Swing0_Pre3, they are for [R select control] and + [R Termination control] setting. + Registers 10~19, bit 4:0 is [R select control], these bits are + compensation manual, increase it can enhance IO driven strength + and Vp-p. + Registers 10~19, bit 5:6 is [R termination control], these bits + adjust 50ohm impedance of DP tx termination. 00:55 ohm, + 01:50 ohm(default), 10:45 ohm, 11:40 ohm. + + analogix,lane1-swing: + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 1 + maxItems: 20 + description: + an array of swing register setting for DP tx lane1 PHY. + DP TX lane1 swing register setting same with lane0 + swing, please refer lane0-swing property description. + + analogix,audio-enable: + type: boolean + description: let the driver enable audio HDMI codec function or not. + ports: $ref: /schemas/graph.yaml#/properties/ports properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: - Video port for MIPI DSI input. + MIPI DSI/DPI input. + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + type: object + additionalProperties: false + + properties: + remote-endpoint: true + + bus-type: + enum: [1, 5] + default: 1 + + data-lanes: true port@1: $ref: /schemas/graph.yaml#/properties/port @@ -87,6 +143,9 @@ examples: vdd10-supply = <&pp1000_mipibrdg>; vdd18-supply = <&pp1800_mipibrdg>; vdd33-supply = <&pp3300_mipibrdg>; + analogix,audio-enable; + analogix,lane0-swing = /bits/ 8 <0x14 0x54 0x64 0x74>; + analogix,lane1-swing = /bits/ 8 <0x14 0x54 0x64 0x74>; ports { #address-cells = <1>; @@ -96,6 +155,8 @@ examples: reg = <0>; anx7625_in: endpoint { remote-endpoint = <&mipi_dsi>; + bus-type = <5>; + data-lanes = <0 1 2 3>; }; }; -- 2.25.1

5 18

[PATCH v5 0/5] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
by Liu Ying 27 Mar '22

27 Mar '22

Hi, This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the Freescale i.MX8qxp SoC. The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by i.MX8qxp SCU firmware. The PHY driver would call a SCU function to configure the mode. The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC, where it appears to be a single MIPI DPHY. Patch 1/5 sets PHY mode in the Northwest Logic MIPI DSI host controller bridge driver, since i.MX8qxp SoC embeds this controller IP to support MIPI DSI displays together with the Mixel PHY. Patch 2/5 allows LVDS PHYs to be configured through the generic PHY functions and through a custom structure added to the generic PHY configuration union. Patch 3/5 converts mixel,mipi-dsi-phy plain text dt binding to json-schema. Patch 4/5 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC. Patch 5/5 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver. Welcome comments, thanks. v4->v5: * Align kernel-doc style of include/linux/phy/phy-lvds.h to include/linux/phy/phy.h for patch 2/5. (Vinod) * Trivial tweaks on patch 2/5. * Drop Robert's R-b tag on patch 2/5. v3->v4: * Add all R-b tags received from v3 on relevant patches and respin. (Robert) v2->v3: * Improve readability of mixel_dphy_set_mode() in the Mixel PHY driver. (Guido) * Improve the 'clock-names' property in the PHY dt binding. v1->v2: * Convert mixel,mipi-dsi-phy plain text dt binding to json-schema. (Guido) * Print invalid PHY mode in dmesg from the Mixel PHY driver. (Guido) * Add Guido's R-b tag on the patch for the nwl-dsi drm bridge driver. Liu Ying (5): drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable() phy: Add LVDS configuration options dt-bindings: phy: Convert mixel,mipi-dsi-phy to json-schema dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for i.MX8qxp phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 29 --- .../bindings/phy/mixel,mipi-dsi-phy.yaml | 107 ++++++++ drivers/gpu/drm/bridge/nwl-dsi.c | 6 + drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 269 ++++++++++++++++++++- include/linux/phy/phy-lvds.h | 32 +++ include/linux/phy/phy.h | 4 + 6 files changed, 407 insertions(+), 40 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml create mode 100644 include/linux/phy/phy-lvds.h -- 2.7.4

2 9

[PATCH v3 00/13] drm/msm: Add Display Stream Compression Support
by Vinod Koul 23 Mar '22

23 Mar '22

Display Stream Compression (DSC) compresses the display stream in host which is later decoded by panel. This series enables this for Qualcomm msm driver. This was tested on Google Pixel3 phone which use LGE SW43408 panel. The changes include DSC data and hardware block enabling for DPU1 then support in encoder. We also add support in DSI and introduce required topology changes. In order for panel to set the DSC parameters we add dsc in drm_panel and set it from the msm driver. We still have dsc as a globabl entity. I think while doing DP + DSC we should be able to update it, right now comprehending the requirements are bit difficult. Complete changes which enable this for Pixel3 along with panel driver (not part of this series) and DT changes can be found at: git.linaro.org/people/vinod.koul/kernel.git pixel/dsc_v3 Comments welcome! Changes since v2: - Fix comments by Dimitry except the dsc being global. - Move RM patch later for dependency on topology now - Add patch for mode valid callback for dsi_mgr - Add missing structure documentation patch - Fix errors in mode_3d changes - Rebase on v5.16-rc1 and test Changes since v1: - Fix various issues spotted by kbuildbot - Rebase to v5.15-rc3 - Remove unused fields and duplicate defines - Enable DSC blocks only when DSC is enabled - remove sdm845 feature mask, use 0 - Check for DSC in hw_ctl Changes since RFC: - Drop the DT binding patch as we derive the configuration from panel - Drop the drm api patch as we no longer need it (use pps drm api) - Fix comments raised by Dimitry - Add dsc parameters calculation from downstream Vinod Koul (13): drm/msm/dsi: add support for dsc data drm/msm/disp/dpu1: Add support for DSC drm/msm/disp/dpu1: Add support for DSC in pingpong block drm/msm/disp/dpu1: Add DSC for SDM845 to hw_catalog drm/msm/disp/dpu1: Don't use DSC with mode_3d drm/msm/disp/dpu1: Add DSC support in hw_ctl drm/msm/disp/dpu1: Add support for DSC in encoder drm/msm: Add missing structure documentation drm/msm/disp/dpu1: Add support for DSC in topology drm/msm/disp/dpu1: Add DSC support in RM drm/msm/dsi: add mode valid callback for dsi_mgr drm/msm/dsi: Add support for DSC configuration drm/msm/dsi: Pass DSC params to drm_panel drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 158 +++++++++- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 11 + .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 2 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 14 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 210 +++++++++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 77 +++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 13 + .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 32 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 66 ++++ drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 1 + drivers/gpu/drm/msm/dsi/dsi.h | 2 + drivers/gpu/drm/msm/dsi/dsi.xml.h | 10 + drivers/gpu/drm/msm/dsi/dsi_host.c | 285 +++++++++++++++++- drivers/gpu/drm/msm/dsi/dsi_manager.c | 12 + drivers/gpu/drm/msm/msm_drv.h | 23 ++ include/drm/drm_panel.h | 7 + 22 files changed, 970 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h -- 2.31.1

5 40

[PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)
by Jason Ekstrand 22 Mar '22

22 Mar '22

Modern userspace APIs like Vulkan are built on an explicit synchronization model. This doesn't always play nicely with the implicit synchronization used in the kernel and assumed by X11 and Wayland. The client -> compositor half of the synchronization isn't too bad, at least on intel, because we can control whether or not i915 synchronizes on the buffer and whether or not it's considered written. The harder part is the compositor -> client synchronization when we get the buffer back from the compositor. We're required to be able to provide the client with a VkSemaphore and VkFence representing the point in time where the window system (compositor and/or display) finished using the buffer. With current APIs, it's very hard to do this in such a way that we don't get confused by the Vulkan driver's access of the buffer. In particular, once we tell the kernel that we're rendering to the buffer again, any CPU waits on the buffer or GPU dependencies will wait on some of the client rendering and not just the compositor. This new IOCTL solves this problem by allowing us to get a snapshot of the implicit synchronization state of a given dma-buf in the form of a sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, instead of CPU waiting directly, it encapsulates the wait operation, at the current moment in time, in a sync_file so we can check/wait on it later. As long as the Vulkan driver does the sync_file export from the dma-buf before we re-introduce it for rendering, it will only contain fences from the compositor or display. This allows to accurately turn it into a VkFence or VkSemaphore without any over- synchronization. This patch series actually contains two new ioctls. There is the export one mentioned above as well as an RFC for an import ioctl which provides the other half. The intention is to land the export ioctl since it seems like there's no real disagreement on that one. The import ioctl, however, has a lot of debate around it so it's intended to be RFC-only for now. Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037 IGT tests: https://patchwork.freedesktop.org/series/90490/ v10 (Jason Ekstrand, Daniel Vetter): - Add reviews/acks - Add a patch to rename _rcu to _unlocked - Split things better so import is clearly RFC status v11 (Daniel Vetter): - Add more CCs to try and get maintainers - Add a patch to document DMA_BUF_IOCTL_SYNC - Generally better docs - Use separate structs for import/export (easier to document) - Fix an issue in the import patch v12 (Daniel Vetter): - Better docs for DMA_BUF_IOCTL_SYNC v12 (Christian König): - Drop the rename patch in favor of Christian's series - Add a comment to the commit message for the dma-buf sync_file export ioctl saying why we made it an ioctl on dma-buf Cc: Christian König <christian.koenig(a)amd.com> Cc: Michel Dänzer <michel(a)daenzer.net> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Cc: Daniel Stone <daniels(a)collabora.com> Cc: mesa-dev(a)lists.freedesktop.org Cc: wayland-devel(a)lists.freedesktop.org Test-with: 20210524205225.872316-1-jason(a)jlekstrand.net Christian König (1): dma-buf: Add dma_fence_array_for_each (v2) Jason Ekstrand (5): dma-buf: Add dma_resv_get_singleton (v6) dma-buf: Document DMA_BUF_IOCTL_SYNC (v2) dma-buf: Add an API for exporting sync files (v12) RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked RFC: dma-buf: Add an API for importing sync files (v7) Documentation/driver-api/dma-buf.rst | 8 ++ drivers/dma-buf/dma-buf.c | 103 +++++++++++++++++++++++++ drivers/dma-buf/dma-fence-array.c | 27 +++++++ drivers/dma-buf/dma-resv.c | 110 +++++++++++++++++++++++++++ include/linux/dma-fence-array.h | 17 +++++ include/linux/dma-resv.h | 2 + include/uapi/linux/dma-buf.h | 103 ++++++++++++++++++++++++- 7 files changed, 369 insertions(+), 1 deletion(-) -- 2.31.1

8 31

[PATCH] drm: bridge: it66121: Added it66121 chip external screen status judgment
by Yunlongli 10 Mar '22

10 Mar '22

In the actual tests, the IT66121 chip sometimes misjudged whether it had an external screen, so, reference the it66121_user_guid.pdf about Audio/Video data is stable or not A typical initialization of HDMI link should be based on interrupt signal and appropriate register probing. Recommended flow is detailed in IT66121 Programming Guide. Simply put, the microcontroller should monitor the HPD status first. Upon valid HPD event, move on to check RxSENDetect register to see if the receiver chip is ready for further handshaking. When RxSENDetect is asserted, start reading EDID data through DDC channels and carry on the rest of the handshaking subsequently.If the micro-controller makes no use of the interrupt signal as well as the above-mentioned status registers, the link establishment might fail. Please do follow the suggested initialization flow recommended in IT66121 Programming Guide. So, I add the IT66121_SYS_STATUS_SENDECTECT register status detection. Signed-off-by: Yunlongli <liyunlonga(a)uniontech.com> --- drivers/gpu/drm/bridge/ite-it66121.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c index 2f2a09adb4bc..9ed4fa298d11 100644 --- a/drivers/gpu/drm/bridge/ite-it66121.c +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -523,7 +523,7 @@ static bool it66121_is_hpd_detect(struct it66121_ctx *ctx) if (regmap_read(ctx->regmap, IT66121_SYS_STATUS_REG, &val)) return false; - return val & IT66121_SYS_STATUS_HPDETECT; + return ((val & IT66121_SYS_STATUS_HPDETECT) && (val & IT66121_SYS_STATUS_SENDECTECT)); } static int it66121_bridge_attach(struct drm_bridge *bridge, -- 2.20.1

3 2

← Newer
1
2
3
4
5
6
7
...
75
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2021