| Message ID | f3c89e4834665790ff13478c571cc9aaa9de5559.1463708766.git.dalias@libc.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, May 20, 2016 at 02:53:03AM +0000, Rich Felker wrote: > Signed-off-by: Rich Felker <dalias@libc.org> > --- > Documentation/devicetree/bindings/jcore/cpus.txt | 91 ++++++++++++++++++++++++ > 1 file changed, 91 insertions(+) > create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt > > diff --git a/Documentation/devicetree/bindings/jcore/cpus.txt b/Documentation/devicetree/bindings/jcore/cpus.txt > new file mode 100644 > index 0000000..00ef112 > --- /dev/null > +++ b/Documentation/devicetree/bindings/jcore/cpus.txt > @@ -0,0 +1,91 @@ > +=================== > +J-Core cpu bindings > +=================== > + > +The J-Core processors are open source CPU cores that can be built as FPGA > +soft cores or ASICs. The device tree is also responsible for describing the > +cache controls and, for SMP configurations, all details of the SMP method, > +as documented below. > + > + > +--------------------- > +Top-level "cpus" node > +--------------------- > + > +Required properties: > + > +- #address-cells: Must be 1. > + > +- #size-cells: Must be 0. > + > +Optional properties: > + > +- enable-method: Required only for SMP systems. If present, must be > + "jcore,spin-table". > + > + > +-------------------- > +Individual cpu nodes > +-------------------- > + > +Required properties: > + > +- device_type: Must be "cpu". > + > +- 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. > + > +- reg: Must be 0 on uniprocessor systems, or the sequential, zero-based > + hardware cpu id on SMP systems. > + > +Optional properties: > + > +- clock-frequency: Clock frequency of the cpu in Hz. > + > +- cpu-release-addr: Necessary only for secondary processors on SMP systems > + using the "jcore,spin-table" enable method. If present, must consist of > + two cells containing physical addresses. The first cell contains an > + address which, when written, unblocks the secondary cpu. The second cell > + contains an address from which the cpu will read its initial program > + counter when unblocked. > + > + > +--------------------- > +Cache controller node > +--------------------- > + > +Required properties: > + > +- compatible: Must be "jcore,cache". That's pretty generic... > + > +- reg: A memory range for the cache controller registers. And standard cache properties? Are size, sets, ways, line size, etc. discoverable? > + > + > +-------- > +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. > + > +- reg: A memory range used to IPI generation. > + > +- interrupts: An irq on which IPI will be received. > + > + > +---------- > +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. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 23, 2016 at 03:48:46PM -0500, Rob Herring wrote: > On Fri, May 20, 2016 at 02:53:03AM +0000, Rich Felker wrote: > > Signed-off-by: Rich Felker <dalias@libc.org> > > --- > > Documentation/devicetree/bindings/jcore/cpus.txt | 91 ++++++++++++++++++++++++ > > 1 file changed, 91 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt > > > > diff --git a/Documentation/devicetree/bindings/jcore/cpus.txt b/Documentation/devicetree/bindings/jcore/cpus.txt > > new file mode 100644 > > index 0000000..00ef112 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/jcore/cpus.txt > > @@ -0,0 +1,91 @@ > > +=================== > > +J-Core cpu bindings > > +=================== > > + > > +The J-Core processors are open source CPU cores that can be built as FPGA > > +soft cores or ASICs. The device tree is also responsible for describing the > > +cache controls and, for SMP configurations, all details of the SMP method, > > +as documented below. > > + > > + > > +--------------------- > > +Top-level "cpus" node > > +--------------------- > > + > > +Required properties: > > + > > +- #address-cells: Must be 1. > > + > > +- #size-cells: Must be 0. > > + > > +Optional properties: > > + > > +- enable-method: Required only for SMP systems. If present, must be > > + "jcore,spin-table". > > + > > + > > +-------------------- > > +Individual cpu nodes > > +-------------------- > > + > > +Required properties: > > + > > +- device_type: Must be "cpu". > > + > > +- 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. FYI the way we're trying to use DT is to avoid hard-coding any properties about the SoC (like mmio register addresses, cache properties, etc.) in the cpu compatible tag, and instead breaking things down into as many device nodes as possible, to allow variations to be represented without having to encode them in the kernel/driver sources. > > +- reg: Must be 0 on uniprocessor systems, or the sequential, zero-based > > + hardware cpu id on SMP systems. > > + > > +Optional properties: > > + > > +- clock-frequency: Clock frequency of the cpu in Hz. > > + > > +- cpu-release-addr: Necessary only for secondary processors on SMP systems > > + using the "jcore,spin-table" enable method. If present, must consist of > > + two cells containing physical addresses. The first cell contains an > > + address which, when written, unblocks the secondary cpu. The second cell > > + contains an address from which the cpu will read its initial program > > + counter when unblocked. > > + > > + > > +--------------------- > > +Cache controller node > > +--------------------- > > + > > +Required properties: > > + > > +- compatible: Must be "jcore,cache". > > That's pretty generic... Most of the DT compatible tags were derived from the component directory/source-file names in the J-Core source. In the case of cache, it's actually called "icache" in the source for historical reasons despite also including dcache, so I just used "cache" in the DT. > > + > > +- 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. > > +-------- > > +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. > > +---------- > > +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? Rich -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 23, 2016 at 4:03 PM, Rich Felker <dalias@libc.org> wrote: > On Mon, May 23, 2016 at 03:48:46PM -0500, Rob Herring wrote: >> On Fri, May 20, 2016 at 02:53:03AM +0000, Rich Felker wrote: >> > Signed-off-by: Rich Felker <dalias@libc.org> >> > --- >> > Documentation/devicetree/bindings/jcore/cpus.txt | 91 ++++++++++++++++++++++++ >> > 1 file changed, 91 insertions(+) >> > create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt >> > >> > diff --git a/Documentation/devicetree/bindings/jcore/cpus.txt b/Documentation/devicetree/bindings/jcore/cpus.txt >> > new file mode 100644 >> > index 0000000..00ef112 >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/jcore/cpus.txt >> > @@ -0,0 +1,91 @@ >> > +=================== >> > +J-Core cpu bindings >> > +=================== >> > + >> > +The J-Core processors are open source CPU cores that can be built as FPGA >> > +soft cores or ASICs. The device tree is also responsible for describing the >> > +cache controls and, for SMP configurations, all details of the SMP method, >> > +as documented below. >> > + >> > + >> > +--------------------- >> > +Top-level "cpus" node >> > +--------------------- >> > + >> > +Required properties: >> > + >> > +- #address-cells: Must be 1. >> > + >> > +- #size-cells: Must be 0. >> > + >> > +Optional properties: >> > + >> > +- enable-method: Required only for SMP systems. If present, must be >> > + "jcore,spin-table". >> > + >> > + >> > +-------------------- >> > +Individual cpu nodes >> > +-------------------- >> > + >> > +Required properties: >> > + >> > +- device_type: Must be "cpu". >> > + >> > +- 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. If you have sufficient s/w accessible version registers that are always going to be updated on IP changes then, you don't really need more specific compatible strings. > FYI the way we're trying to use DT is to avoid hard-coding any > properties about the SoC (like mmio register addresses, cache > properties, etc.) in the cpu compatible tag, and instead breaking > things down into as many device nodes as possible, to allow variations > to be represented without having to encode them in the kernel/driver > sources. Yes, that is the purpose of DT. >> > +- reg: Must be 0 on uniprocessor systems, or the sequential, zero-based >> > + hardware cpu id on SMP systems. >> > + >> > +Optional properties: >> > + >> > +- clock-frequency: Clock frequency of the cpu in Hz. >> > + >> > +- cpu-release-addr: Necessary only for secondary processors on SMP systems >> > + using the "jcore,spin-table" enable method. If present, must consist of >> > + two cells containing physical addresses. The first cell contains an >> > + address which, when written, unblocks the secondary cpu. The second cell >> > + contains an address from which the cpu will read its initial program >> > + counter when unblocked. >> > + >> > + >> > +--------------------- >> > +Cache controller node >> > +--------------------- >> > + >> > +Required properties: >> > + >> > +- compatible: Must be "jcore,cache". >> >> That's pretty generic... > > Most of the DT compatible tags were derived from the component > directory/source-file names in the J-Core source. In the case of > cache, it's actually called "icache" in the source for historical > reasons despite also including dcache, so I just used "cache" in the > DT. > >> > + >> > +- 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. >> > +-------- >> > +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... >> > +---------- >> > +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. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/23/2016 06:29 PM, Rob Herring wrote: > On Mon, May 23, 2016 at 4:03 PM, Rich Felker <dalias@libc.org> wrote: >> On Mon, May 23, 2016 at 03:48:46PM -0500, Rob Herring wrote: >>> On Fri, May 20, 2016 at 02:53:03AM +0000, Rich Felker wrote: >>>> Signed-off-by: Rich Felker <dalias@libc.org> >>>> --- >>>> Documentation/devicetree/bindings/jcore/cpus.txt | 91 ++++++++++++++++++++++++ >>>> 1 file changed, 91 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/jcore/cpus.txt b/Documentation/devicetree/bindings/jcore/cpus.txt >>>> new file mode 100644 >>>> index 0000000..00ef112 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/jcore/cpus.txt >>>> @@ -0,0 +1,91 @@ >>>> +=================== >>>> +J-Core cpu bindings >>>> +=================== >>>> + >>>> +The J-Core processors are open source CPU cores that can be built as FPGA >>>> +soft cores or ASICs. The device tree is also responsible for describing the >>>> +cache controls and, for SMP configurations, all details of the SMP method, >>>> +as documented below. >>>> + >>>> + >>>> +--------------------- >>>> +Top-level "cpus" node >>>> +--------------------- >>>> + >>>> +Required properties: >>>> + >>>> +- #address-cells: Must be 1. >>>> + >>>> +- #size-cells: Must be 0. >>>> + >>>> +Optional properties: >>>> + >>>> +- enable-method: Required only for SMP systems. If present, must be >>>> + "jcore,spin-table". >>>> + >>>> + >>>> +-------------------- >>>> +Individual cpu nodes >>>> +-------------------- >>>> + >>>> +Required properties: >>>> + >>>> +- device_type: Must be "cpu". >>>> + >>>> +- 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. > > If you have sufficient s/w accessible version registers that are > always going to be updated on IP changes then, you don't really need > more specific compatible strings. There are no version registers: the boot ROM can be output as part of the build, and the dtb can be provided by the boot ROM. So you don't need boot registers, you literally put any version info you need in the dtb in the boot rom. > 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... Why would you add hardware version registers when the hardware's attached boot rom is providing a dtb? What's the point? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 24, 2016 at 4:30 PM, Rob Landley <rob@landley.net> wrote: > > > On 05/23/2016 06:29 PM, Rob Herring wrote: >> On Mon, May 23, 2016 at 4:03 PM, Rich Felker <dalias@libc.org> wrote: >>> On Mon, May 23, 2016 at 03:48:46PM -0500, Rob Herring wrote: >>>> On Fri, May 20, 2016 at 02:53:03AM +0000, Rich Felker wrote: >>>>> Signed-off-by: Rich Felker <dalias@libc.org> >>>>> --- >>>>> Documentation/devicetree/bindings/jcore/cpus.txt | 91 ++++++++++++++++++++++++ >>>>> 1 file changed, 91 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/jcore/cpus.txt b/Documentation/devicetree/bindings/jcore/cpus.txt >>>>> new file mode 100644 >>>>> index 0000000..00ef112 >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/jcore/cpus.txt >>>>> @@ -0,0 +1,91 @@ >>>>> +=================== >>>>> +J-Core cpu bindings >>>>> +=================== >>>>> + >>>>> +The J-Core processors are open source CPU cores that can be built as FPGA >>>>> +soft cores or ASICs. The device tree is also responsible for describing the >>>>> +cache controls and, for SMP configurations, all details of the SMP method, >>>>> +as documented below. >>>>> + >>>>> + >>>>> +--------------------- >>>>> +Top-level "cpus" node >>>>> +--------------------- >>>>> + >>>>> +Required properties: >>>>> + >>>>> +- #address-cells: Must be 1. >>>>> + >>>>> +- #size-cells: Must be 0. >>>>> + >>>>> +Optional properties: >>>>> + >>>>> +- enable-method: Required only for SMP systems. If present, must be >>>>> + "jcore,spin-table". >>>>> + >>>>> + >>>>> +-------------------- >>>>> +Individual cpu nodes >>>>> +-------------------- >>>>> + >>>>> +Required properties: >>>>> + >>>>> +- device_type: Must be "cpu". >>>>> + >>>>> +- 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. >> >> If you have sufficient s/w accessible version registers that are >> always going to be updated on IP changes then, you don't really need >> more specific compatible strings. > > There are no version registers: the boot ROM can be output as part of > the build, and the dtb can be provided by the boot ROM. So you don't > need boot registers, you literally put any version info you need in the > dtb in the boot rom. You can, but you are not doing that from the looks of it. Maybe you're not to that point to need versioning and that's fine, but it doesn't sound like you all have thought about it. >> 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... > > Why would you add hardware version registers when the hardware's > attached boot rom is providing a dtb? > > What's the point? You are missing who is reading and caring about what the version is. It's all the software that cares what's in either version registers or dtb to know what are the specific features of the h/w. At some point you will have a single driver that needs to support multiple versions and/or configurations of hardware/IP. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 24, 2016 at 08:13:14PM -0500, Rob Herring wrote: > On Tue, May 24, 2016 at 4:30 PM, Rob Landley <rob@landley.net> wrote: > > > > > > On 05/23/2016 06:29 PM, Rob Herring wrote: > >> On Mon, May 23, 2016 at 4:03 PM, Rich Felker <dalias@libc.org> wrote: > >>> On Mon, May 23, 2016 at 03:48:46PM -0500, Rob Herring wrote: > >>>> On Fri, May 20, 2016 at 02:53:03AM +0000, Rich Felker wrote: > >>>>> Signed-off-by: Rich Felker <dalias@libc.org> > >>>>> --- > >>>>> Documentation/devicetree/bindings/jcore/cpus.txt | 91 ++++++++++++++++++++++++ > >>>>> 1 file changed, 91 insertions(+) > >>>>> create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt > >>>>> > >>>>> diff --git a/Documentation/devicetree/bindings/jcore/cpus.txt b/Documentation/devicetree/bindings/jcore/cpus.txt > >>>>> new file mode 100644 > >>>>> index 0000000..00ef112 > >>>>> --- /dev/null > >>>>> +++ b/Documentation/devicetree/bindings/jcore/cpus.txt > >>>>> @@ -0,0 +1,91 @@ > >>>>> +=================== > >>>>> +J-Core cpu bindings > >>>>> +=================== > >>>>> + > >>>>> +The J-Core processors are open source CPU cores that can be built as FPGA > >>>>> +soft cores or ASICs. The device tree is also responsible for describing the > >>>>> +cache controls and, for SMP configurations, all details of the SMP method, > >>>>> +as documented below. > >>>>> + > >>>>> + > >>>>> +--------------------- > >>>>> +Top-level "cpus" node > >>>>> +--------------------- > >>>>> + > >>>>> +Required properties: > >>>>> + > >>>>> +- #address-cells: Must be 1. > >>>>> + > >>>>> +- #size-cells: Must be 0. > >>>>> + > >>>>> +Optional properties: > >>>>> + > >>>>> +- enable-method: Required only for SMP systems. If present, must be > >>>>> + "jcore,spin-table". > >>>>> + > >>>>> + > >>>>> +-------------------- > >>>>> +Individual cpu nodes > >>>>> +-------------------- > >>>>> + > >>>>> +Required properties: > >>>>> + > >>>>> +- device_type: Must be "cpu". > >>>>> + > >>>>> +- 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. > >> > >> If you have sufficient s/w accessible version registers that are > >> always going to be updated on IP changes then, you don't really need > >> more specific compatible strings. > > > > There are no version registers: the boot ROM can be output as part of > > the build, and the dtb can be provided by the boot ROM. So you don't > > need boot registers, you literally put any version info you need in the > > dtb in the boot rom. > > You can, but you are not doing that from the looks of it. Maybe you're > not to that point to need versioning and that's fine, but it doesn't > sound like you all have thought about it. It's been thought about and discussed both on the linux-sh list and internally in the J-Core development process, but it's certainly a topic that could use more discussion. I don't think it should be a blocking issue for registering current bindings, though. > >> 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... > > > > Why would you add hardware version registers when the hardware's > > attached boot rom is providing a dtb? > > > > What's the point? > > You are missing who is reading and caring about what the version is. > It's all the software that cares what's in either version registers or > dtb to know what are the specific features of the h/w. At some point > you will have a single driver that needs to support multiple versions > and/or configurations of hardware/IP. This is why we have both "jcore,aic1" and "jcore,aic2" now, and why we'll soon have a "jcore,spi3" binding for the new SPI master with DMA support. The intent is that stable hardware interfaces are maintained at the hardware source level, and the binding names correspond to component names in the hardware source. If there are good reasons for more fine-grained version information, we can add binding specifications for such, but the only reason I've seen so far is bug workarounds, and it really doesn't make sense to be putting bug workarounds in the kernel rather than just fixing the source and flashing the FPGA configuration. Once we get to ASICs of course it might make sense. Do you have other compelling reasons for fine-grained versioning? Rich -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 24, 2016 at 9:33 PM, Rich Felker <dalias@libc.org> wrote: > On Tue, May 24, 2016 at 08:13:14PM -0500, Rob Herring wrote: >> On Tue, May 24, 2016 at 4:30 PM, Rob Landley <rob@landley.net> wrote: >> > >> > >> > On 05/23/2016 06:29 PM, Rob Herring wrote: >> >> On Mon, May 23, 2016 at 4:03 PM, Rich Felker <dalias@libc.org> wrote: >> >>> On Mon, May 23, 2016 at 03:48:46PM -0500, Rob Herring wrote: >> >>>> On Fri, May 20, 2016 at 02:53:03AM +0000, Rich Felker wrote: >> >>>>> Signed-off-by: Rich Felker <dalias@libc.org> >> >>>>> --- >> >>>>> Documentation/devicetree/bindings/jcore/cpus.txt | 91 ++++++++++++++++++++++++ >> >>>>> 1 file changed, 91 insertions(+) >> >>>>> create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt >> >>>>> >> >>>>> diff --git a/Documentation/devicetree/bindings/jcore/cpus.txt b/Documentation/devicetree/bindings/jcore/cpus.txt >> >>>>> new file mode 100644 >> >>>>> index 0000000..00ef112 >> >>>>> --- /dev/null >> >>>>> +++ b/Documentation/devicetree/bindings/jcore/cpus.txt >> >>>>> @@ -0,0 +1,91 @@ >> >>>>> +=================== >> >>>>> +J-Core cpu bindings >> >>>>> +=================== >> >>>>> + >> >>>>> +The J-Core processors are open source CPU cores that can be built as FPGA >> >>>>> +soft cores or ASICs. The device tree is also responsible for describing the >> >>>>> +cache controls and, for SMP configurations, all details of the SMP method, >> >>>>> +as documented below. >> >>>>> + >> >>>>> + >> >>>>> +--------------------- >> >>>>> +Top-level "cpus" node >> >>>>> +--------------------- >> >>>>> + >> >>>>> +Required properties: >> >>>>> + >> >>>>> +- #address-cells: Must be 1. >> >>>>> + >> >>>>> +- #size-cells: Must be 0. >> >>>>> + >> >>>>> +Optional properties: >> >>>>> + >> >>>>> +- enable-method: Required only for SMP systems. If present, must be >> >>>>> + "jcore,spin-table". >> >>>>> + >> >>>>> + >> >>>>> +-------------------- >> >>>>> +Individual cpu nodes >> >>>>> +-------------------- >> >>>>> + >> >>>>> +Required properties: >> >>>>> + >> >>>>> +- device_type: Must be "cpu". >> >>>>> + >> >>>>> +- 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. >> >> >> >> If you have sufficient s/w accessible version registers that are >> >> always going to be updated on IP changes then, you don't really need >> >> more specific compatible strings. >> > >> > There are no version registers: the boot ROM can be output as part of >> > the build, and the dtb can be provided by the boot ROM. So you don't >> > need boot registers, you literally put any version info you need in the >> > dtb in the boot rom. >> >> You can, but you are not doing that from the looks of it. Maybe you're >> not to that point to need versioning and that's fine, but it doesn't >> sound like you all have thought about it. > > It's been thought about and discussed both on the linux-sh list and > internally in the J-Core development process, but it's certainly a > topic that could use more discussion. I don't think it should be a > blocking issue for registering current bindings, though. It's not, I just want to understand the direction and that the need here is understood. >> >> 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... >> > >> > Why would you add hardware version registers when the hardware's >> > attached boot rom is providing a dtb? >> > >> > What's the point? >> >> You are missing who is reading and caring about what the version is. >> It's all the software that cares what's in either version registers or >> dtb to know what are the specific features of the h/w. At some point >> you will have a single driver that needs to support multiple versions >> and/or configurations of hardware/IP. > > This is why we have both "jcore,aic1" and "jcore,aic2" now, and why > we'll soon have a "jcore,spi3" binding for the new SPI master with DMA > support. The intent is that stable hardware interfaces are maintained > at the hardware source level, and the binding names correspond to > component names in the hardware source. > > If there are good reasons for more fine-grained version information, > we can add binding specifications for such, but the only reason I've > seen so far is bug workarounds, and it really doesn't make sense to be > putting bug workarounds in the kernel rather than just fixing the > source and flashing the FPGA configuration. Once we get to ASICs of > course it might make sense. > > Do you have other compelling reasons for fine-grained versioning? Differences in features implied by compatible strings is the other main reason. These would be features that are not configurable as those you will probably want separate properties for. But if your going to respin the VHDL to fix any issues, then what you have is sufficient. ASIC implementations should have compatible strings tied to the particular ASIC. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/jcore/cpus.txt b/Documentation/devicetree/bindings/jcore/cpus.txt new file mode 100644 index 0000000..00ef112 --- /dev/null +++ b/Documentation/devicetree/bindings/jcore/cpus.txt @@ -0,0 +1,91 @@ +=================== +J-Core cpu bindings +=================== + +The J-Core processors are open source CPU cores that can be built as FPGA +soft cores or ASICs. The device tree is also responsible for describing the +cache controls and, for SMP configurations, all details of the SMP method, +as documented below. + + +--------------------- +Top-level "cpus" node +--------------------- + +Required properties: + +- #address-cells: Must be 1. + +- #size-cells: Must be 0. + +Optional properties: + +- enable-method: Required only for SMP systems. If present, must be + "jcore,spin-table". + + +-------------------- +Individual cpu nodes +-------------------- + +Required properties: + +- device_type: Must be "cpu". + +- compatible: Must be "jcore,j2". + +- reg: Must be 0 on uniprocessor systems, or the sequential, zero-based + hardware cpu id on SMP systems. + +Optional properties: + +- clock-frequency: Clock frequency of the cpu in Hz. + +- cpu-release-addr: Necessary only for secondary processors on SMP systems + using the "jcore,spin-table" enable method. If present, must consist of + two cells containing physical addresses. The first cell contains an + address which, when written, unblocks the secondary cpu. The second cell + contains an address from which the cpu will read its initial program + counter when unblocked. + + +--------------------- +Cache controller node +--------------------- + +Required properties: + +- compatible: Must be "jcore,cache". + +- reg: A memory range for the cache controller registers. + + +-------- +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". + +- reg: A memory range used to IPI generation. + +- interrupts: An irq on which IPI will be received. + + +---------- +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.
Signed-off-by: Rich Felker <dalias@libc.org> --- Documentation/devicetree/bindings/jcore/cpus.txt | 91 ++++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt