From: Aneesh V <aneesh@ti.com> To: Olof Johansson <olof@lixom.net> Cc: devicetree-discuss@lists.ozlabs.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Rajendra Nayak <rnayak@ti.com>, Benoit Cousson <b-cousson@ti.com> Subject: Re: [RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories Date: Tue, 20 Dec 2011 12:39:52 +0530 [thread overview] Message-ID: <4EF034C0.9070401@ti.com> (raw) In-Reply-To: <CAOesGMjOybCbu1Bgxe0Te=XANVOqOPcaDOL_6c4=pVCxzu9ZnA@mail.gmail.com> Hi Olof, On Monday 19 December 2011 10:22 PM, Olof Johansson wrote: > Hi, > > Some comments below, but also a more general question: How much of > this generic data makes sense to encode in the device tree? Final > hardware configuration usually has to take into consideration board > layout/signal delays, etc, and that's not part of this binding. The JEDEC specifies base values for all timing parameters. But Vendors can improve on these timings and provide better values. Using device specific timing values therefore provides scope for optimization. Everything that I have encoded here is needed by our driver to re-configure our SDRAM controller during DVFS. In fact, I have not listed all AC timing parameters in the spec in this binding, leaving the rest for future users to add if they need them. > > > On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V<aneesh@ti.com> wrote: > >> diff --git a/Documentation/devicetree/bindings/ddr/ddr.txt b/Documentation/devicetree/bindings/ddr/ddr.txt >> new file mode 100644 >> index 0000000..f15c4dd >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/ddr/ddr.txt >> @@ -0,0 +1,114 @@ >> +* DDR SDRAM memories compliant to JEDEC specifications JESD209-2(LPDDR2) >> + or JESD79-3(DDR3). >> + >> +Required properties: >> +- compatible : Should be one of - "jedec,ddr3", "jedec,lpddr2-nvm", >> + "jedec,lpddr2-s2", "jedec,lpddr2-s4" >> + >> + "ti,jedec-ddr3" should be listed if the memory part is DDR3 type >> + >> + "ti,jedec-lpddr2-s2" should be listed if the memory part is LPDDR2-S2 type >> + >> + "ti,jedec-lpddr2-s4" should be listed if the memory part is LPDDR2-S4 type >> + >> + "ti,jedec-lpddr2-nvm" should be listed if the memory part is LPDDR2-NVM type >> + >> +- density : string representing the density of the device in terms of >> + Mb (mega bits). Following are the allowed values: "64Mb", "128Mb", >> + "256Mb", "512Mb", "1Gb", "2Gb", "4Gb", "8Gb", "16Gb", or "32Gb" > > No, please encode as a two-cell integer instead. That is what I thought of doing initially. But I felt that "32Gb" is more readable than 34359738368 or 33554432(if the unit is Mb). > >> +- io-width : string representing the io width: "x8", "x16" or "x32". > > No, encode as an integer. Ok. > >> + >> +Optional properties: >> + >> +The following optional properties represent the minimum value of some AC >> +timing parameters of the DDR device in terms of number of clock cycles. >> +These values shall be obtained from the device data-sheet. >> + >> +The suffix nCK indicates that the unit for these parameters is number >> +of DDR clock cycles. Note: In LPDDR2 spec and data-sheets tCK is used >> +inter-changeably for nCK. Both are equivalent in this context. > > Please use only lower characters in property names unless absolutely > necessary, which this doesn't qualify as, in my opinion. I have used the names "as is" from the spec. Thought that might be useful when users extract data from the data-sheets in the future to create dts for new devices. > > Also, can't these strings be shortened a bit? All of them have '-min' > in common, and none of them seem to be very devicetree-like in their > naming. Most of these have a counter part in the timings node. That is we have both "tCKESR-min-nCK" and "tCKESR-ps" albeit in different nodes. > > Finally, the "lpddr2" and "ddr3" properties could just be prefixed > with "lpddr2,<propertyname>" instead. Makes sense. But a given node will have data for only either of them, not both and the compatible property will clearly mention what the data is for. Would you still like to have the above scheme? > >> + >> +- tRRD-min-nCK >> +- tWTR-min-nCK >> +- tXP-min-nCK >> +- tRTP-min-nCK >> +- tCKE-min-nCK >> +- tRPab-min-nCK /* LPDDR2 only */ >> +- tRCD-min-nCK /* LPDDR2 only */ >> +- tWR-min-nCK /* LPDDR2 only */ >> +- tRASmin-min-nCK /* LPDDR2 only */ >> +- tCKESR-min-nCK /* LPDDR2 only */ >> +- tFAW-min-nCK /* LPDDR2 only */ >> +- tZQCS-min-nCK /* DDR3 only */ >> +- tZQoper-min-nCK /* DDR3 only */ >> +- tZQinit-min-nCK /* DDR3 only */ >> +- tXS-min-nCK /* DDR3 only */ >> + >> +Child nodes: >> +- The ddr node may have one or more child nodes of type "ddr-timings". >> + "ddr-timings" provides AC timing parameters of the device for >> + a given speed-bin. The user may provide the timings for as many >> + speed-bins as is required. Please see Documentation/devicetree/ >> + bindings/ddr/ddr-timings.txt for more information on "ddr-timings" >> + >> +Example: >> + >> +elpida_ECB240ABACN : ddr { >> + compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4"; >> + density = "2Gb"; >> + io-width = "x32"; >> + >> + tRPab-min-nCK =<3>; >> + tRCD-min-nCK =<3>; >> + tWR-min-nCK =<3>; >> + tRASmin-min-nCK =<3>; >> + tRRD-min-nCK =<2>; >> + tWTR-min-nCK =<2>; >> + tXP-min-nCK =<2>; >> + tRTP-min-nCK =<2>; >> + tCKE-min-nCK =<3>; >> + tCKESR-min-nCK =<3>; >> + tFAW-min-nCK =<8>; >> + >> + timings_elpida_ECB240ABACN_400mhz: ddr-timings { > > You will need a unit address here. Ok. ddr-timing@0, ddr-timings@1 etc, right? > >> + min-freq =<10000000>; >> + max-freq =<400000000>; >> + tRP-ps =<21000>; >> + tRCD-ps =<18000>; >> + tWR-ps =<15000>; >> + tRAS-min-ps =<42000:; >> + tRRD-ps =<10000>; >> + tWTR-ps =<7500>; >> + tXP-ps =<7500>; >> + tRTP-ps =<7500>; >> + tCKESR-ps =<15000>; >> + tDQSCK-max-ps =<5500>; >> + tFAW-ps =<50000>; >> + tZQCS-ps =<90000>; >> + tZQoper-ps =<360000>; >> + tZQinit-ps =<1000000>; >> + tRAS-max-ns =<70000>; >> + }; >> + >> + timings_elpida_ECB240ABACN_200mhz: ddr-timings { > > Same here, since you have more than one table. See previous > discussions about emc tables on tegra (I'll repost that series this > week). Ok. > >> + min-freq =<10000000>; >> + max-freq =<200000000>; >> + tRP-ps =<21000>; >> + tRCD-ps =<18000>; >> + tWR-ps =<15000>; >> + tRAS-min-ps =<42000:; > > Typo Will fix. > >> + tRRD-ps =<10000>; >> + tWTR-ps =<10000>; >> + tXP-ps =<7500>; >> + tRTP-ps =<7500>; >> + tCKESR-ps =<15000>; >> + tDQSCK-max-ps =<5500>; >> + tFAW-ps =<50000>; >> + tZQCS-ps =<90000>; >> + tZQoper-ps =<360000>; >> + tZQinit-ps =<1000000>; >> + tRAS-max-ns =<70000>; >> + }; >> + >> +} >> diff --git a/Documentation/devicetree/bindings/ddr/ddr_timings.txt b/Documentation/devicetree/bindings/ddr/ddr_timings.txt >> new file mode 100644 >> index 0000000..38fcdec >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/ddr/ddr_timings.txt >> @@ -0,0 +1,62 @@ >> +* AC timing parameters of DDR memories for a given speed-bin >> + At the moment properties for only LPDDR2 and DDR3 have been added >> + >> +Required properties: >> +- min-freq : minimum DDR clock frequency for the speed-bin >> +- max-freq : maximum DDR clock frequency for the speed-bin > > There should be a compatible field here too, especially if the binding > ever has to be revised. Ok. Bindings may have to be extended while adapting for other controllers. > >> + >> +Optional properties: >> + >> +The following properties represent AC timing parameters from the memory >> +data-sheet of the device for a given speed-bin. All these properties are >> +of type<u32> and "-ps", "-ns", "-nCK" etc in the name indicates the >> +unit of the corresponding parameter: >> + ps - pico seconds >> + ns - nano seconds >> + nCK - number of DDR clock cycles. Please note that in LPDDR2 spec and >> + data-sheets tCK is used inter-changeably for nCK. Both are equivalent >> + in this context. > > Seems noisy to include the units on every single property instead of > just in the bindings. Hmm.. How about having them only for the exceptions below, that is, "nCK" and "ns" so that people don't make avoidable mistakes while entering the data. > >> + >> +- tRCD-ps >> +- tWR-ps >> +- tRAS-min-ps >> +- tRRD-ps >> +- tWTR-ps >> +- tXP-ps >> +- tRTP-ps >> +- tDQSCK-max-ps >> +- tFAW-ps >> +- tZQCS-ps >> +- tZQinit-ps >> +- tRP-ps /* DDR3 only */ >> +- tRC-ps /* DDR3 only */ >> +- tXSDLL-nCK /* DDR3 only */ >> +- tCKE-ps /* DDR3 only */ >> +- tZQoper-ps /* DDR3 only */ >> +- tRPab-ps /* LPDDR2 only */ >> +- tZQCL-ps /* LPDDR2 only */ >> +- tCKESR-ps /* LPDDR2 only */ >> +- tRAS-max-ns /* LPDDR2 only */ > > Same above about type-specific properties. Explained above. Thanks for the review. best regards, Aneesh
WARNING: multiple messages have this Message-ID (diff)
From: aneesh@ti.com (Aneesh V) To: linux-arm-kernel@lists.infradead.org Subject: [RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories Date: Tue, 20 Dec 2011 12:39:52 +0530 [thread overview] Message-ID: <4EF034C0.9070401@ti.com> (raw) In-Reply-To: <CAOesGMjOybCbu1Bgxe0Te=XANVOqOPcaDOL_6c4=pVCxzu9ZnA@mail.gmail.com> Hi Olof, On Monday 19 December 2011 10:22 PM, Olof Johansson wrote: > Hi, > > Some comments below, but also a more general question: How much of > this generic data makes sense to encode in the device tree? Final > hardware configuration usually has to take into consideration board > layout/signal delays, etc, and that's not part of this binding. The JEDEC specifies base values for all timing parameters. But Vendors can improve on these timings and provide better values. Using device specific timing values therefore provides scope for optimization. Everything that I have encoded here is needed by our driver to re-configure our SDRAM controller during DVFS. In fact, I have not listed all AC timing parameters in the spec in this binding, leaving the rest for future users to add if they need them. > > > On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V<aneesh@ti.com> wrote: > >> diff --git a/Documentation/devicetree/bindings/ddr/ddr.txt b/Documentation/devicetree/bindings/ddr/ddr.txt >> new file mode 100644 >> index 0000000..f15c4dd >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/ddr/ddr.txt >> @@ -0,0 +1,114 @@ >> +* DDR SDRAM memories compliant to JEDEC specifications JESD209-2(LPDDR2) >> + or JESD79-3(DDR3). >> + >> +Required properties: >> +- compatible : Should be one of - "jedec,ddr3", "jedec,lpddr2-nvm", >> + "jedec,lpddr2-s2", "jedec,lpddr2-s4" >> + >> + "ti,jedec-ddr3" should be listed if the memory part is DDR3 type >> + >> + "ti,jedec-lpddr2-s2" should be listed if the memory part is LPDDR2-S2 type >> + >> + "ti,jedec-lpddr2-s4" should be listed if the memory part is LPDDR2-S4 type >> + >> + "ti,jedec-lpddr2-nvm" should be listed if the memory part is LPDDR2-NVM type >> + >> +- density : string representing the density of the device in terms of >> + Mb (mega bits). Following are the allowed values: "64Mb", "128Mb", >> + "256Mb", "512Mb", "1Gb", "2Gb", "4Gb", "8Gb", "16Gb", or "32Gb" > > No, please encode as a two-cell integer instead. That is what I thought of doing initially. But I felt that "32Gb" is more readable than 34359738368 or 33554432(if the unit is Mb). > >> +- io-width : string representing the io width: "x8", "x16" or "x32". > > No, encode as an integer. Ok. > >> + >> +Optional properties: >> + >> +The following optional properties represent the minimum value of some AC >> +timing parameters of the DDR device in terms of number of clock cycles. >> +These values shall be obtained from the device data-sheet. >> + >> +The suffix nCK indicates that the unit for these parameters is number >> +of DDR clock cycles. Note: In LPDDR2 spec and data-sheets tCK is used >> +inter-changeably for nCK. Both are equivalent in this context. > > Please use only lower characters in property names unless absolutely > necessary, which this doesn't qualify as, in my opinion. I have used the names "as is" from the spec. Thought that might be useful when users extract data from the data-sheets in the future to create dts for new devices. > > Also, can't these strings be shortened a bit? All of them have '-min' > in common, and none of them seem to be very devicetree-like in their > naming. Most of these have a counter part in the timings node. That is we have both "tCKESR-min-nCK" and "tCKESR-ps" albeit in different nodes. > > Finally, the "lpddr2" and "ddr3" properties could just be prefixed > with "lpddr2,<propertyname>" instead. Makes sense. But a given node will have data for only either of them, not both and the compatible property will clearly mention what the data is for. Would you still like to have the above scheme? > >> + >> +- tRRD-min-nCK >> +- tWTR-min-nCK >> +- tXP-min-nCK >> +- tRTP-min-nCK >> +- tCKE-min-nCK >> +- tRPab-min-nCK /* LPDDR2 only */ >> +- tRCD-min-nCK /* LPDDR2 only */ >> +- tWR-min-nCK /* LPDDR2 only */ >> +- tRASmin-min-nCK /* LPDDR2 only */ >> +- tCKESR-min-nCK /* LPDDR2 only */ >> +- tFAW-min-nCK /* LPDDR2 only */ >> +- tZQCS-min-nCK /* DDR3 only */ >> +- tZQoper-min-nCK /* DDR3 only */ >> +- tZQinit-min-nCK /* DDR3 only */ >> +- tXS-min-nCK /* DDR3 only */ >> + >> +Child nodes: >> +- The ddr node may have one or more child nodes of type "ddr-timings". >> + "ddr-timings" provides AC timing parameters of the device for >> + a given speed-bin. The user may provide the timings for as many >> + speed-bins as is required. Please see Documentation/devicetree/ >> + bindings/ddr/ddr-timings.txt for more information on "ddr-timings" >> + >> +Example: >> + >> +elpida_ECB240ABACN : ddr { >> + compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4"; >> + density = "2Gb"; >> + io-width = "x32"; >> + >> + tRPab-min-nCK =<3>; >> + tRCD-min-nCK =<3>; >> + tWR-min-nCK =<3>; >> + tRASmin-min-nCK =<3>; >> + tRRD-min-nCK =<2>; >> + tWTR-min-nCK =<2>; >> + tXP-min-nCK =<2>; >> + tRTP-min-nCK =<2>; >> + tCKE-min-nCK =<3>; >> + tCKESR-min-nCK =<3>; >> + tFAW-min-nCK =<8>; >> + >> + timings_elpida_ECB240ABACN_400mhz: ddr-timings { > > You will need a unit address here. Ok. ddr-timing at 0, ddr-timings at 1 etc, right? > >> + min-freq =<10000000>; >> + max-freq =<400000000>; >> + tRP-ps =<21000>; >> + tRCD-ps =<18000>; >> + tWR-ps =<15000>; >> + tRAS-min-ps =<42000:; >> + tRRD-ps =<10000>; >> + tWTR-ps =<7500>; >> + tXP-ps =<7500>; >> + tRTP-ps =<7500>; >> + tCKESR-ps =<15000>; >> + tDQSCK-max-ps =<5500>; >> + tFAW-ps =<50000>; >> + tZQCS-ps =<90000>; >> + tZQoper-ps =<360000>; >> + tZQinit-ps =<1000000>; >> + tRAS-max-ns =<70000>; >> + }; >> + >> + timings_elpida_ECB240ABACN_200mhz: ddr-timings { > > Same here, since you have more than one table. See previous > discussions about emc tables on tegra (I'll repost that series this > week). Ok. > >> + min-freq =<10000000>; >> + max-freq =<200000000>; >> + tRP-ps =<21000>; >> + tRCD-ps =<18000>; >> + tWR-ps =<15000>; >> + tRAS-min-ps =<42000:; > > Typo Will fix. > >> + tRRD-ps =<10000>; >> + tWTR-ps =<10000>; >> + tXP-ps =<7500>; >> + tRTP-ps =<7500>; >> + tCKESR-ps =<15000>; >> + tDQSCK-max-ps =<5500>; >> + tFAW-ps =<50000>; >> + tZQCS-ps =<90000>; >> + tZQoper-ps =<360000>; >> + tZQinit-ps =<1000000>; >> + tRAS-max-ns =<70000>; >> + }; >> + >> +} >> diff --git a/Documentation/devicetree/bindings/ddr/ddr_timings.txt b/Documentation/devicetree/bindings/ddr/ddr_timings.txt >> new file mode 100644 >> index 0000000..38fcdec >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/ddr/ddr_timings.txt >> @@ -0,0 +1,62 @@ >> +* AC timing parameters of DDR memories for a given speed-bin >> + At the moment properties for only LPDDR2 and DDR3 have been added >> + >> +Required properties: >> +- min-freq : minimum DDR clock frequency for the speed-bin >> +- max-freq : maximum DDR clock frequency for the speed-bin > > There should be a compatible field here too, especially if the binding > ever has to be revised. Ok. Bindings may have to be extended while adapting for other controllers. > >> + >> +Optional properties: >> + >> +The following properties represent AC timing parameters from the memory >> +data-sheet of the device for a given speed-bin. All these properties are >> +of type<u32> and "-ps", "-ns", "-nCK" etc in the name indicates the >> +unit of the corresponding parameter: >> + ps - pico seconds >> + ns - nano seconds >> + nCK - number of DDR clock cycles. Please note that in LPDDR2 spec and >> + data-sheets tCK is used inter-changeably for nCK. Both are equivalent >> + in this context. > > Seems noisy to include the units on every single property instead of > just in the bindings. Hmm.. How about having them only for the exceptions below, that is, "nCK" and "ns" so that people don't make avoidable mistakes while entering the data. > >> + >> +- tRCD-ps >> +- tWR-ps >> +- tRAS-min-ps >> +- tRRD-ps >> +- tWTR-ps >> +- tXP-ps >> +- tRTP-ps >> +- tDQSCK-max-ps >> +- tFAW-ps >> +- tZQCS-ps >> +- tZQinit-ps >> +- tRP-ps /* DDR3 only */ >> +- tRC-ps /* DDR3 only */ >> +- tXSDLL-nCK /* DDR3 only */ >> +- tCKE-ps /* DDR3 only */ >> +- tZQoper-ps /* DDR3 only */ >> +- tRPab-ps /* LPDDR2 only */ >> +- tZQCL-ps /* LPDDR2 only */ >> +- tCKESR-ps /* LPDDR2 only */ >> +- tRAS-max-ns /* LPDDR2 only */ > > Same above about type-specific properties. Explained above. Thanks for the review. best regards, Aneesh
next prev parent reply other threads:[~2011-12-20 7:09 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-12-19 14:05 [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR Aneesh V 2011-12-19 14:05 ` Aneesh V 2011-12-19 14:05 ` [RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories Aneesh V 2011-12-19 14:05 ` Aneesh V 2011-12-19 16:52 ` Olof Johansson 2011-12-19 16:52 ` Olof Johansson 2011-12-20 7:09 ` Aneesh V [this message] 2011-12-20 7:09 ` Aneesh V 2012-01-19 12:18 ` Aneesh V 2012-01-19 12:18 ` Aneesh V 2011-12-19 14:05 ` [RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller Aneesh V 2011-12-19 14:05 ` Aneesh V 2011-12-19 16:56 ` Olof Johansson 2011-12-19 16:56 ` Olof Johansson 2011-12-20 7:12 ` Aneesh V 2011-12-20 7:12 ` Aneesh V 2011-12-19 16:59 ` Olof Johansson 2011-12-19 16:59 ` Olof Johansson 2011-12-20 7:19 ` Aneesh V 2011-12-20 7:19 ` Aneesh V 2011-12-19 14:05 ` [RFC v2 PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards Aneesh V 2011-12-19 14:05 ` Aneesh V 2011-12-19 23:01 ` [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR Rob Herring 2011-12-19 23:01 ` Rob Herring 2011-12-19 23:35 ` Tony Lindgren 2011-12-19 23:35 ` Tony Lindgren 2011-12-20 10:44 ` Aneesh V 2011-12-20 10:44 ` Aneesh V 2011-12-20 12:40 ` Cousson, Benoit 2011-12-20 12:40 ` Cousson, Benoit 2011-12-20 14:08 ` Aneesh V 2011-12-20 14:08 ` Aneesh V 2012-01-08 17:23 ` Aneesh V 2012-01-08 17:23 ` Aneesh V 2012-01-09 5:42 ` Olof Johansson 2012-01-09 5:42 ` Olof Johansson 2012-01-13 19:36 ` Aneesh V 2012-01-13 19:36 ` Aneesh V 2012-01-16 19:15 ` Turquette, Mike 2012-01-16 19:15 ` Turquette, Mike 2012-01-19 19:26 ` Olof Johansson 2012-01-19 19:26 ` Olof Johansson 2012-01-17 12:06 ` Aneesh V 2012-01-17 12:06 ` Aneesh V 2011-12-20 10:16 ` Aneesh V 2011-12-20 10:16 ` Aneesh V 2012-01-19 14:28 ` Aneesh V 2012-01-19 14:28 ` Aneesh V 2012-01-19 14:31 ` Aneesh V 2012-01-19 14:31 ` Aneesh V 2012-01-19 14:28 ` [PATCH 1/3] dt: device tree bindings for DDR memories Aneesh V 2012-01-19 14:28 ` Aneesh V 2012-01-19 14:28 ` [PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller Aneesh V 2012-01-19 14:28 ` Aneesh V 2012-01-19 14:28 ` [PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards Aneesh V 2012-01-19 14:28 ` Aneesh V
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4EF034C0.9070401@ti.com \ --to=aneesh@ti.com \ --cc=b-cousson@ti.com \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=olof@lixom.net \ --cc=rnayak@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.