From nobody Fri Dec 2 23:34:24 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NP8Rw6gFRz4jg5n for ; Fri, 2 Dec 2022 23:34:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NP8Rv5Y8cz4Yxp for ; Fri, 2 Dec 2022 23:34:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=SFWvxBMg; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670024088; bh=ARh77kr9UTEjmy7gNZ+9bgK6u5oQ3snnQcLdpnWbJ24=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=SFWvxBMgHpgIl8KEENY2H4fSRXByNJxWYLktPyZLRCAKitPp94OKXmxkuTPABffx56tfs/HoLkyE6jy/DaVnLDyGd8z5jHz3A4ijjAanLWmaDYnBGKwsLc4rK/v6NWbgA9tMJ1zwqrcMB4hnNMlxqgjwPofdszbRbfmmZldv58z0p0vsBkKKtvoxz9q/PYLSOGWO2r3kt1iM9dKxOdwmfgT4MKw6q1A8HlfEITgda+ZxkgfFohOf+H8FAKNHviTFRa+9zQTsKWIm08ijOB93PPQ3O8d7kRldWTY7z1+lsJqUEcdp89w1mC2kdLv6bPYohU+6wRIxzzVEKaKrqny4/A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670024088; bh=z3TFDX0oFmXHc8btBHgNrnxaNdtZozQnt1itqdMfDOp=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kXY31ELuUWdcx8oSTAaW++ri5Dq5aYChqUla5mnhRymniptNrz6liNog7aH4W17vBISOR73jbMWjKJ714aOjjWobjjWujhqPcM/WjbRTsJ6J57FLpzwA1Up665MkahTYSHxOEkiuCOhW+HWN/vP8D4uOhWg0R/ovZK3wtUinbYHXbLdZm33Oqv/JwTMRsM8I8TFaZTsZ6/VL67z4NdZ6ZcG/RvF+iUtLYgLbN1GSoiGsPA7zvUzWCORo0MPcob9mUKuUT3WmQvJvHr1Vikx+77M88///7oDHKKFv1wzRtJdgtN5PvmoxVQaX/vgpJU+fKuGPhaXMQhOW3CLTx9f5Iw== X-YMail-OSG: G_0DpPwVM1nMF8FabBaLpndkbfjc0NjOY.cI7VSh7UoSze2E.e6hxbllDX_4Krl KTH2D100HHYQ8N1SNAZCSXw8rxcs1UmoBWYzquV7cwejq3lMd3iwWZkHm19YExv_cv1BUu93fdwr B9BPMk9OzCRFxgvhE3v2uDqZW82jCG2i3vvCl4hkePiYHCEg3xwvGfxf0lUByZSp62tHrImxjaFe DlVH2x9brt5E7oFHFH6j8ZG313DVZgzlLYG0I3JMK9JLqeV8fv1twBXy0STGtobvIqdGffb1OdrH Mggb5JdDCY3NPqG93p1XlntLIgIR.nEpPOGj4OzmAOS4MvaAorUYww5tSXkclArJXKDQyWcRv6wh .wIuu5OYeC3KU9pc3KCcz1IJgesuZg4HHp.JNKKB9Vgu9NCpgcTUR1KxtrC2nTM1Rp.Hopox4dOC uqgzQTjt0Io3XqB5ZJXWaYZuS8RTv6pTNiDXy3W0Hwqo1BSp1UTJO04OJp.tQq1iUOuLp43iPt1D XVkdj.APj_g2DiqSYEamSellYliZr8yIVpPQwO33THrPnF8vHerXUJJUJcpiM0JHp2NJSvkg0IFM uvgNis9CqhJUX6.g.4I0hSNdG4BOPeHY.AkO3VAWODq3LQxg35lmYMdZmGiqtkqZTknjRRkvx1ex HIoUIDSgBivYYha6BVAF37fr4nfYdSxGwfoUpxQVkYWTc.Xi6JEJlpEImIX4gVRTE0UbT.X5QlMI 5zky0yAam1MbTJdIi_qSzvxp6yto604Sm.H3VqqNNSdAy6gTC6WmC7pRHjHOwDGRR7EhN6EpjpSN AsFEND2JM1PtC2c5j7r2fFkJAcw.xT4XxkS_1wtm3vxrpEq2uZ47P6EZwQTGGu4B1cfG8P9ZLhSH Fm9WdF2NEVSyOyb6uv9R5f0UUDt8EZ8V8RumE2FEZhyKERixqMvT5ekFnWssBqGceNiZOyINcqxX SQSd6lyExU44Tv9vsnVKDb1EjMQqyU7GvRM8fXQOjkdXide.FPxWCLfYAXJfHetHFIh6FQQ0pPys SaJmrXqCU.T2zCAEDBBql6p3LrjtGlzSKZcYv_lSIKTJEJCKB7MwWxWZDZrlasa8WbBdsn69zK.R _yTzJ7H_VcZtLzrGUY.bq5xQVE6hTZKeLxQfNioswcDZehSb2l5iTZVhc6.K_li7M1Wbo6bDwl16 D2lOBwO31zMGmGAGTYGsvM9l5RyEGAtZiQ05JKGsRTuTkEwknhvhnSysR_69QUoncsx39J7u3qmp vpi7KSMhHZ6JffLFjS5c7fzGVZ3KU4l0HRkz9tTUiLpxXR0S0Rh_a7uyc5eBCrq28m7KAQmszQf5 Y47Kzy6JV7sH005FmhaqQ.vnU7kdtu_Cg_ZDvlUqd.ko5oUet9FeD3xLSLxXYbKqyPKYuq6_3w_p NMgw.Aw0gh1kvBRQThjdsUf8xCFkK6YiG81c.HG4c74gzorIxMDYGM7VG5qQccKqf1onsi_qZe.9 Sqn9hjPGPou58cgOy1suHuCkbif.UkxlJ4g7_bEXsAKrYPlhLb7qg0sx2twPw3O_iKX949SD3tQU FUUbxo_oqJBALFBdCRttL1nFFaomIBhSU2MCToTMZ8uE7eVaPl3obrxWxME3rl14G8_1PEys9CWi D8B25sYQqoiEuTM03HAAZDtAsVjndcLqINZDeJAVoU4Gm5A3CeOmnW2O6nzxPMkQLpKtFXGYVfii 6ncBcVdxrFmov9.2bdFnbaDJt0NoqU_d1INFh3TgSYeVgKbvRR3SXonm8.H9T_r6t8z5jiv1PsIH IS319BQf1oUTcw6oY1AylMHXHXyjmIDthxlN8CZjjTTneU.kaZj3iOwfjdkkVdYBVKpQdqULyzxn piW5fC9SRwd6QTTKIUOMrXBb.zweEXKMxvJRxRuvVeDExDaT7L8kx8O7ITQlf4HH3ImEmlP0W4zr OnLUPRs.lXo2mZQopSXN70ECaS2FWTelPIYaLmUjZu11vYtjOZsesmgFhmjpQyRkOw_3ReAFR_.I 16LkeCmqV670Ijwd7aRQKuOxvbnCNWVjNDhQm2P6PGbhlxXL3qCpzwpRJsp4DZ.iKNcHTG58NoPX x5nJzOX53aYrRkaT61I2LPgdPq1RZPIl8jAHscfsj0M7CG_4YsmJ67EBVyJ0r0j7xPsayXYkgleE .24DsXwFowB2r2HecSZF1DiiczGP15HBcrsXjLKhI0yikU3btm36WrQHgepEM6HY87URFaN3dBmC amWgMHj2O2fr2FzueNEHkeMqvFtw7E.54boD9QC.lOFcYFf9S8yXoOzWadQtEiiuZJAgHnabwSMk E X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 2 Dec 2022 23:34:48 +0000 Received: by hermes--production-bf1-5458f64d4-2b7vw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a2add2a49fb2038e614f303f4cefd114; Fri, 02 Dec 2022 23:34:42 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Does the RPi* DMA code in the kernel handle the distinctions between the 3 kinds of DMA engines? Message-Id: <18DF2CDD-3BC2-4100-9B8E-3BFD08F1F119@yahoo.com> Date: Fri, 2 Dec 2022 15:34:24 -0800 To: freebsd-arm , FreeBSD Hackers X-Mailer: Apple Mail (2.3731.200.110.1.12) References: <18DF2CDD-3BC2-4100-9B8E-3BFD08F1F119.ref@yahoo.com> X-Spamd-Result: default: False [-1.12 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_SHORT(0.37)[0.374]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from] X-Rspamd-Queue-Id: 4NP8Rv5Y8cz4Yxp X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Does the RPi* DMA code in the kernel handle the distinctions between the 3 kinds of DMA engines? The engine types are named: DMA engine (30-bit DMA addressing: 1 GiByte, 256-bit burst space) DMA lite engine (only 128 bit burst space, no YLENGTH, TDMODE, S_STRIDE, D_STRIDE registsers, only 16 bits for DMA length (?_TXFR_LEN XLENGTH), no SRC_IGNORE or DEST_IGNORE modes, only about half the bandwidth of type DMA, uses ENABLE Regsiter 31:28 "PAGELITE" instead of 27:24 "PAGE" to control the "1G SDRAM ram page" used) DMA4 engine (not the same as dma4 of specific engines dma0..dma15; different register map offset pattern after ??_CB, more register map offsets than the other DMA types, 40 address bits with 40:32 in ??_SRCI/??_DESTI 7:0, ??_CB bits 31:0 are for Control Block Address 36:5, higher performance via "uncoupled read/write design", write burst capable, directly accesses the BCM2711 35-bit address bus so bypasses the paginging registers that are used for types DMA and DMA lite) The specific instances of engines (channels) have types: dma0 ..dma6 : Always type DMA (so far?) dma7 ..dma10: Always type DMA lite (so far?) dma11..dma14: Not the same for BCM2711: For BCM2711, type DMA4 Otherwise, type DMA lite (so far?) BCM2711 specific note: dma11 "is additionally able to access the PCIe interface". For reference, the live device tree for the BCM2711 has (examples from an 8 GiByte RPi4B): dma@7e007000 { compatible =3D "brcm,bcm2835-dma"; reg =3D <0x7e007000 0x00000b00>; interrupts =3D <0x00000000 0x00000050 0x00000004 = 0x00000000 0x00000051 0x00000004 0x00000000 0x00000052 0x00000004 = 0x00000000 0x00000053 0x00000004 0x00000000 0x00000054 0x00000004 = 0x00000000 0x00000055 0x00000004 0x00000000 0x00000056 0x00000004 = 0x00000000 0x00000057 0x00000004 0x00000000 0x00000057 0x00000004 = 0x00000000 0x00000058 0x00000004 0x00000000 0x00000058 0x00000004>; interrupt-names =3D "dma0", "dma1", "dma2", = "dma3", "dma4", "dma5", "dma6", "dma7", "dma8", "dma9", "dma10"; #dma-cells =3D <0x00000001>; brcm,dma-channel-mask =3D <0x000007f5>; phandle =3D <0x0000000b>; }; . . . dma@7e007b00 { compatible =3D "brcm,bcm2711-dma"; reg =3D <0x00000000 0x7e007b00 0x00000000 = 0x00000400>; interrupts =3D <0x00000000 0x00000059 0x00000004 = 0x00000000 0x0000005a 0x00000004 0x00000000 0x0000005b 0x00000004 = 0x00000000 0x0000005c 0x00000004>; interrupt-names =3D "dma11", "dma12", "dma13", = "dma14"; #dma-cells =3D <0x00000001>; brcm,dma-channel-mask =3D <0x00003000>; phandle =3D <0x00000040>; }; Note: dma15 "is exclusively used by the VPU" and I ignore it here. I ask, in part, because of: #define BCM_DMA_CH_MAX 12 that is used via the likes of: struct bcm_dma_ch sc_dma_ch[BCM_DMA_CH_MAX]; and: for (i =3D 0; i < BCM_DMA_CH_MAX; i++) { But the BCM2711 only has 0..10 defined for brcm,bcm2835-dma in its device live device tree, although brcm,dma-channel-mask allows avoiding what is missing. 11..14 are defined in brcm,bcm2711-dma instead --but the code makes no use of it, given the brcm,bcm2835-dma's brcm,dma-channel-mask. But/also, the brcm,bcm2835-dma's brcm,dma-channel-mask includes examples of both "DMA engine" and "DMA lite engine", so still leading to some distinctions that should be made. So far, I've not been able to identify code/data making any distinctions for the likes of dma7..dma14 beyond what brcm,dma-channel-mask completely avoids. Note: So far as I can tell, the PCIe bus-mastering that is associated with the XHCI in the BCM2711 is separate from the above. The "B0T" BCM2711 parts have a 3 GiByte limitation just for this PCIe bus-mastering(/XHCI) and the "C0T" BCM2711 parts no longer are limited to a subset of the available RAM for PCIe bus-mastering(/XHCI). Examples from 8 GiByte RPi4B's: dma-ranges =3D <0x02000000 0x00000004 0x00000000 = 0x00000000 0x00000000 0x00000000 0xc0000000>; vs. dma-ranges =3D <0x02000000 0x00000004 0x00000000 = 0x00000000 0x00000000 0x00000002 0x00000000>; So, XHCI related bounce buffering could be avoided on=20 "C0T" parts. For BCM2711 "B0T" vs. "C0T" there is also emmc2bus with: dma-ranges =3D <0x00000000 0xc0000000 0x00000000 = 0x00000000 0x40000000>; (so: matching the soc dma-ranges, other than the #of = cells for holding the 1st addr) vs. dma-ranges =3D <0x00000000 0x00000000 0x00000000 = 0x00000000 0xfc000000>; (so not matching the soc dma-ranges) emmc2bus contains: emmc2@7e340000 { compatible =3D "brcm,bcm2711-emmc2"; . . . which looks to mean that the dma_ranges for brcm,bcm2711-emmc2 changed to not match the soc dma-ranges. I've not noticed any code/data that would track this change. I do not know the implications of the difference for what FreeBSD's code does --or if FreeBSD ever tries to use the brcm,bcm2711-emmc2 . =3D=3D=3D Mark Millard marklmi at yahoo.com