From: Rich Felker <dalias@libc.org> To: Rob Herring <robh@kernel.org> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, SH-Linux <linux-sh@vger.kernel.org>, Ian Campbell <ijc+devicetree@hellion.org.uk>, Kumar Gala <galak@codeaurora.org>, Mark Rutland <mark.rutland@arm.com>, Pawel Moll <pawel.moll@arm.com> Subject: Re: [PATCH v2 02/12] of: add J-Core cpu bindings Date: Tue, 24 May 2016 02:39:39 +0000 [thread overview] Message-ID: <20160524023939.GJ21636@brightrain.aerifal.cx> (raw) In-Reply-To: <CAL_JsqK0O2RY5PO9vHuOPjimRb34n8RwXMa7c8xmbY7Oh7D2Xg@mail.gmail.com> On Mon, May 23, 2016 at 06:29:48PM -0500, Rob Herring wrote: > >> > +- compatible: Must be "jcore,j2". > >> > >> Okay to have this, but you should have compatible strings for specific > >> core implementations. AIUI, J2 is just the ISA. > > > > There was some past discussion you probably missed on the linux-sh > > list, starting here: > > > > http://www.spinics.net/lists/linux-sh/msg50028.html > > > > Basically it's really hard to identify what "the specific core > > implementation" even means with a soft core. If you have some ideas > > I'd be happy to hear them, but I think there should always be a > > "jcore,j2" fallback compatible tag in any case. > > Presumably you do some sort of versioning on the VHDL source that you > can correlate to. Yes, but I'm not convinced that helps with anything. Presumably the point of having a fine-grained version in the compatible tag would be to work around bugs. But if those bugs could come from build options, specific version of the FPGA tools used, specific board targets, etc. then a version really isn't sufficient to help you work around bugs. On the other hand, as long as it's soft core, if there is a bug you just fix the bitstream rather than putting workaround hacks in the kernel or other software. It does make sense to have some identifier for particular builds and production runs once we have ASICs, of course, but that's a topic to discuss when we get there. I think most of this was already discussed in the thread I linked above. > >> > +- reg: A memory range for the cache controller registers. > >> > >> And standard cache properties? Are size, sets, ways, line size, etc. > >> discoverable? > > > > I want to do the cache properties in a way that's generic for all of > > arch/sh rather than specific to J2, but that's going to be part of the > > DT conversion project. That's why I just have properties hard-coded > > for now in the kernel source. They're not really used anyway except > > for presenting them in /proc/cpuinfo. > > The DT spec (devicetree.org, formerly ePAPR) already defines arch > independent cache properties. Indeed, but they don't seem to be comprehensive. In particular they don't seem to represent the properties needed to compute aliasing for VIPT cache architectures, or to represent whether the cache is virtually or physically indexed or tagged. > >> > +-------- > >> > +IPI node > >> > +-------- > >> > + > >> > +Device trees for SMP systems must have an IPI node representing the mechanism > >> > +used for inter-processor interrupt generation. > >> > + > >> > +Required properties: > >> > + > >> > +- compatible: Must be "jcore,ipi-controller". > >> > >> Again, seems pretty generic. > > > > I'm open to different ideas for naming schemes, but in the big scheme > > of things it doesn't really matter. When there's a new incompatible > > one, it can have a new compatible tag. > > It should make sense according to how you version the VHDL sources. > The Xilinx folks have X.Y version numbers for example. We generally > don't accept those, but for soft IP that is an exception. > > Better yet, since you can change "the hardware", make it more > discoverable with registers for version numbering and feature bits. > The failure here is having a process where that can be forgotten... I suspect that takes more space on the FPGA/ASIC than adding a few bytes to the DTB in the boot rom would, so it's probably a worse solution. We could potentially allow compatible tags of the form "foo-v*" for each "foo" documented now, where the version is from the jcore source repo, and recommend (for example): compatible = "jcore,foo-v1.23", "jcore,foo"; This would be separate from the numbers that are already present in things like "spi2" and "spi3" (functionally distinct spi master devices) or "aic1" and "aic2" (functionally distinct interrupt controllers). How would you want this to be documented, if we go that route? Certainly all possible values cannot be specified in the binding docs then. > >> > +---------- > >> > +CPUID node > >> > +---------- > >> > + > >> > +Device trees for SMP systems must have a CPUID node representing the mechanism > >> > +used to identify the current processor on which execution is taking place. > >> > + > >> > +Required properties: > >> > + > >> > +- compatible: Must be "jcore,cpuid-mmio". > >> > + > >> > +- reg: A memory range containing a single 32-bit mmio register which produces > >> > + the current cpu id when read. > >> > >> This id matches the reg value in cpu node, right? If not, it should. > > > > Yes. Should I document that here? > > Yes. OK, adding it to read: - reg: A memory range containing a single 32-bit mmio register which produces the current cpu id (matching the "reg" property of the cpu performing the read) when read. Rich
WARNING: multiple messages have this Message-ID (diff)
From: Rich Felker <dalias@libc.org> To: Rob Herring <robh@kernel.org> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, SH-Linux <linux-sh@vger.kernel.org>, Ian Campbell <ijc+devicetree@hellion.org.uk>, Kumar Gala <galak@codeaurora.org>, Mark Rutland <mark.rutland@arm.com>, Pawel Moll <pawel.moll@arm.com> Subject: Re: [PATCH v2 02/12] of: add J-Core cpu bindings Date: Mon, 23 May 2016 22:39:39 -0400 [thread overview] Message-ID: <20160524023939.GJ21636@brightrain.aerifal.cx> (raw) In-Reply-To: <CAL_JsqK0O2RY5PO9vHuOPjimRb34n8RwXMa7c8xmbY7Oh7D2Xg@mail.gmail.com> On Mon, May 23, 2016 at 06:29:48PM -0500, Rob Herring wrote: > >> > +- compatible: Must be "jcore,j2". > >> > >> Okay to have this, but you should have compatible strings for specific > >> core implementations. AIUI, J2 is just the ISA. > > > > There was some past discussion you probably missed on the linux-sh > > list, starting here: > > > > http://www.spinics.net/lists/linux-sh/msg50028.html > > > > Basically it's really hard to identify what "the specific core > > implementation" even means with a soft core. If you have some ideas > > I'd be happy to hear them, but I think there should always be a > > "jcore,j2" fallback compatible tag in any case. > > Presumably you do some sort of versioning on the VHDL source that you > can correlate to. Yes, but I'm not convinced that helps with anything. Presumably the point of having a fine-grained version in the compatible tag would be to work around bugs. But if those bugs could come from build options, specific version of the FPGA tools used, specific board targets, etc. then a version really isn't sufficient to help you work around bugs. On the other hand, as long as it's soft core, if there is a bug you just fix the bitstream rather than putting workaround hacks in the kernel or other software. It does make sense to have some identifier for particular builds and production runs once we have ASICs, of course, but that's a topic to discuss when we get there. I think most of this was already discussed in the thread I linked above. > >> > +- reg: A memory range for the cache controller registers. > >> > >> And standard cache properties? Are size, sets, ways, line size, etc. > >> discoverable? > > > > I want to do the cache properties in a way that's generic for all of > > arch/sh rather than specific to J2, but that's going to be part of the > > DT conversion project. That's why I just have properties hard-coded > > for now in the kernel source. They're not really used anyway except > > for presenting them in /proc/cpuinfo. > > The DT spec (devicetree.org, formerly ePAPR) already defines arch > independent cache properties. Indeed, but they don't seem to be comprehensive. In particular they don't seem to represent the properties needed to compute aliasing for VIPT cache architectures, or to represent whether the cache is virtually or physically indexed or tagged. > >> > +-------- > >> > +IPI node > >> > +-------- > >> > + > >> > +Device trees for SMP systems must have an IPI node representing the mechanism > >> > +used for inter-processor interrupt generation. > >> > + > >> > +Required properties: > >> > + > >> > +- compatible: Must be "jcore,ipi-controller". > >> > >> Again, seems pretty generic. > > > > I'm open to different ideas for naming schemes, but in the big scheme > > of things it doesn't really matter. When there's a new incompatible > > one, it can have a new compatible tag. > > It should make sense according to how you version the VHDL sources. > The Xilinx folks have X.Y version numbers for example. We generally > don't accept those, but for soft IP that is an exception. > > Better yet, since you can change "the hardware", make it more > discoverable with registers for version numbering and feature bits. > The failure here is having a process where that can be forgotten... I suspect that takes more space on the FPGA/ASIC than adding a few bytes to the DTB in the boot rom would, so it's probably a worse solution. We could potentially allow compatible tags of the form "foo-v*" for each "foo" documented now, where the version is from the jcore source repo, and recommend (for example): compatible = "jcore,foo-v1.23", "jcore,foo"; This would be separate from the numbers that are already present in things like "spi2" and "spi3" (functionally distinct spi master devices) or "aic1" and "aic2" (functionally distinct interrupt controllers). How would you want this to be documented, if we go that route? Certainly all possible values cannot be specified in the binding docs then. > >> > +---------- > >> > +CPUID node > >> > +---------- > >> > + > >> > +Device trees for SMP systems must have a CPUID node representing the mechanism > >> > +used to identify the current processor on which execution is taking place. > >> > + > >> > +Required properties: > >> > + > >> > +- compatible: Must be "jcore,cpuid-mmio". > >> > + > >> > +- reg: A memory range containing a single 32-bit mmio register which produces > >> > + the current cpu id when read. > >> > >> This id matches the reg value in cpu node, right? If not, it should. > > > > Yes. Should I document that here? > > Yes. OK, adding it to read: - reg: A memory range containing a single 32-bit mmio register which produces the current cpu id (matching the "reg" property of the cpu performing the read) when read. Rich
next prev parent reply other threads:[~2016-05-24 2:39 UTC|newest] Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-05-20 2:53 [PATCH v2 00/12] J-core J2 cpu and SoC peripherals support Rich Felker 2016-05-20 2:53 ` [PATCH v2 02/12] of: add J-Core cpu bindings Rich Felker 2016-05-20 2:53 ` Rich Felker [not found] ` <f3c89e4834665790ff13478c571cc9aaa9de5559.1463708766.git.dalias-8zAoT0mYgF4@public.gmane.org> 2016-05-23 20:48 ` Rob Herring 2016-05-23 20:48 ` Rob Herring 2016-05-23 20:48 ` Rob Herring 2016-05-23 21:03 ` Rich Felker 2016-05-23 21:03 ` Rich Felker 2016-05-23 23:29 ` Rob Herring 2016-05-23 23:29 ` Rob Herring 2016-05-24 2:39 ` Rich Felker [this message] 2016-05-24 2:39 ` Rich Felker 2016-05-24 21:30 ` Rob Landley 2016-05-24 21:30 ` Rob Landley 2016-05-25 1:13 ` Rob Herring 2016-05-25 1:13 ` Rob Herring 2016-05-25 2:33 ` Rich Felker 2016-05-25 2:33 ` Rich Felker 2016-05-25 13:13 ` Rob Herring 2016-05-25 13:13 ` Rob Herring 2016-05-20 2:53 ` [PATCH v2 03/12] of: add J-Core interrupt controller bindings Rich Felker 2016-05-20 8:04 ` Geert Uytterhoeven 2016-05-20 8:04 ` Geert Uytterhoeven [not found] ` <CAMuHMdVs9=8BGwmCBuYch2abJBnCLKoEx7i3EMghW3UUjXc7dA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-05-20 22:34 ` Rich Felker 2016-05-20 22:34 ` Rich Felker 2016-05-20 22:34 ` Rich Felker 2016-05-21 18:07 ` Geert Uytterhoeven 2016-05-21 18:07 ` Geert Uytterhoeven 2016-05-21 19:17 ` Rich Felker 2016-05-21 19:17 ` Rich Felker 2016-05-23 20:53 ` Rob Herring 2016-05-23 20:53 ` Rob Herring 2016-05-23 21:13 ` Rich Felker 2016-05-23 21:13 ` Rich Felker 2016-05-23 21:13 ` Rich Felker [not found] ` <20160523211342.GG21636-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org> 2016-05-24 8:09 ` Marc Zyngier 2016-05-24 8:09 ` Marc Zyngier 2016-05-24 8:09 ` Marc Zyngier [not found] ` <57440C45.5040105-5wv7dgnIgG8@public.gmane.org> 2016-05-25 2:25 ` Rich Felker 2016-05-25 2:25 ` Rich Felker 2016-05-25 2:25 ` Rich Felker 2016-05-20 2:53 ` [PATCH v2 08/12] irqchip: add J-Core AIC driver Rich Felker 2016-05-20 8:08 ` Geert Uytterhoeven 2016-05-20 8:08 ` Geert Uytterhoeven 2016-05-20 8:15 ` Marc Zyngier 2016-05-20 8:15 ` Marc Zyngier 2016-05-25 4:29 ` Rich Felker 2016-05-25 4:29 ` Rich Felker [not found] ` <cover.1463708766.git.dalias-8zAoT0mYgF4@public.gmane.org> 2016-05-20 2:53 ` [PATCH v2 01/12] of: add vendor prefix for J-Core Rich Felker 2016-05-20 2:53 ` Rich Felker 2016-05-20 2:53 ` Rich Felker 2016-05-23 20:49 ` Rob Herring 2016-05-23 20:49 ` Rob Herring 2016-05-20 2:53 ` [PATCH v2 12/12] sh: add device tree source for J2 FPGA on Mimas v2 board Rich Felker 2016-05-20 2:53 ` Rich Felker 2016-05-20 2:53 ` Rich Felker [not found] ` <9960d6526523727d1bee3d11c6704e09e600c6fe.1463708766.git.dalias-8zAoT0mYgF4@public.gmane.org> 2016-05-20 8:17 ` Geert Uytterhoeven 2016-05-20 8:17 ` Geert Uytterhoeven 2016-05-20 8:17 ` Geert Uytterhoeven 2016-05-20 22:42 ` Rich Felker 2016-05-20 22:42 ` Rich Felker 2016-05-20 2:53 ` [PATCH v2 06/12] sh: add support for J-Core J2 processor Rich Felker 2016-05-20 2:53 ` Rich Felker 2016-05-20 2:53 ` [PATCH v2 11/12] sh: add defconfig for J-Core J2 Rich Felker 2016-05-20 2:53 ` [PATCH v2 04/12] of: add J-Core timer bindings Rich Felker 2016-05-20 8:03 ` Geert Uytterhoeven 2016-05-20 8:03 ` Geert Uytterhoeven 2016-05-20 2:53 ` [PATCH v2 09/12] clocksource: add J-Core PIT/RTC driver Rich Felker 2016-05-20 14:01 ` Daniel Lezcano 2016-05-20 14:01 ` Daniel Lezcano 2016-05-21 3:15 ` Rich Felker 2016-05-21 3:15 ` Rich Felker 2016-05-21 15:55 ` Rob Landley 2016-05-21 15:55 ` Rob Landley 2016-05-23 20:32 ` Daniel Lezcano 2016-05-23 20:32 ` Daniel Lezcano 2016-05-24 2:25 ` Rich Felker 2016-05-24 2:25 ` Rich Felker 2016-05-20 2:53 ` [PATCH v2 10/12] spi: add driver for J-Core SPI controller Rich Felker 2016-05-20 2:53 ` Rich Felker 2016-05-20 8:15 ` Geert Uytterhoeven 2016-05-20 8:15 ` Geert Uytterhoeven 2016-05-20 22:50 ` Rich Felker 2016-05-20 22:50 ` Rich Felker 2016-05-20 10:23 ` Mark Brown 2016-05-20 10:23 ` Mark Brown 2016-05-20 23:24 ` Rich Felker 2016-05-20 23:24 ` Rich Felker 2016-05-23 15:30 ` Mark Brown 2016-05-23 15:30 ` Mark Brown 2016-05-23 20:29 ` Rich Felker 2016-05-23 20:29 ` Rich Felker [not found] ` <20160523202938.GD21636-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org> 2016-05-23 22:11 ` Mark Brown 2016-05-23 22:11 ` Mark Brown 2016-05-23 22:11 ` Mark Brown 2016-05-20 2:53 ` [PATCH v2 07/12] sh: add AT_HWCAP flag for J-Core cas.l instruction Rich Felker 2016-05-20 2:53 ` [PATCH v2 05/12] of: add J-Core SPI master bindings Rich Felker 2016-05-20 8:05 ` Geert Uytterhoeven 2016-05-20 8:05 ` Geert Uytterhoeven 2016-05-20 8:05 ` Geert Uytterhoeven 2016-05-23 21:00 ` Rob Herring 2016-05-23 21:00 ` Rob Herring 2016-05-23 21:06 ` Rich Felker 2016-05-23 21:06 ` Rich Felker [not found] ` <20160523210618.GF21636-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org> 2016-05-23 23:16 ` Rob Herring 2016-05-23 23:16 ` Rob Herring 2016-05-23 23:16 ` Rob Herring
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=20160524023939.GJ21636@brightrain.aerifal.cx \ --to=dalias@libc.org \ --cc=devicetree@vger.kernel.org \ --cc=galak@codeaurora.org \ --cc=ijc+devicetree@hellion.org.uk \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=pawel.moll@arm.com \ --cc=robh@kernel.org \ /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.