| Message ID | 61533d59378822f8c808abf193b40070810d3d35.1576922226.git.pisa@cmp.felk.cvut.cz |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | David Miller |
| Headers | show |
| Series | CTU CAN FD open-source IP core SocketCAN driver, PCI, platform integration and documentation | expand |
On Sat, Dec 21, 2019 at 03:07:31PM +0100, pisa@cmp.felk.cvut.cz wrote: > From: Pavel Pisa <pisa@cmp.felk.cvut.cz> > > Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> > --- > .../devicetree/bindings/net/can/ctu,ctucanfd.txt | 61 ++++++++++++++++++++++ > 1 file changed, 61 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt Bindings are moving DT schema format now. Not something I'd require on a respin I've already reviewed, but OTOH it's been 10 months to respin from v2. So: Reviewed-by: Rob Herring <robh@kernel.org> If you have a v4, then please convert to a schema. Rob
Hello Rob, thanks much for review. On Saturday 04 of January 2020 00:53:59 Rob Herring wrote: > On Sat, Dec 21, 2019 at 03:07:31PM +0100, pisa@cmp.felk.cvut.cz wrote: > > From: Pavel Pisa <pisa@cmp.felk.cvut.cz> > > .../devicetree/bindings/net/can/ctu,ctucanfd.txt | 61 > > Bindings are moving DT schema format now. Not something I'd require on a > respin I've already reviewed, but OTOH it's been 10 months to respin > from v2. So: Please, can you send me pointer to some CAN or other bindings doc which is well formed according to future direction? I have not dig deeper but I have not found relevant discussion about introduction of DT schema format. > If you have a v4, then please convert to a schema. I expect that we need at least one more iteration. When recheck, I have found that I have forgot to update paths in RST documentation when moved from standalone automatic CI build into kernel tree [PATCH v3 6/6] docs: ctucanfd: CTU CAN FD open-source IP core documentation. https://lkml.org/lkml/2019/12/21/96 And the most important is review of the driver core to allow the project (http://canbus.pages.fel.cvut.cz/) to move forward. [PATCH v3 3/6] can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part. https://lkml.org/lkml/2019/12/21/95 The code has no errors and a few questionable warnings reported by 4.19 patchcheck (we have run many iterations of it to cleanup code) but 5.4 kernel patchcheck is more strict as I noticed after submission and reports a few more warnings and some of them could be easily resolved. What makes me to feel good is that CTU CAN FD IP core development stabilized, there are only changes to better cover the core by test framework and more than one month there is no commit disturbing CI build process of IP core integration for Xilinx Zynq. CI builds complete driver and FPGA design and then deploys and runs tests between multiple CTU CAN FD cores and against OpenCores SJA1000 cores with FD tolerance https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top/pipelines https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top/-/jobs/51334 The second link points to one of many logs of test running on MZ_APO (Xilinx Zynq) education kits designed for Department of Control Engineering https://dce.fel.cvut.cz/en at PiKRON.com. MZ_APO kist are used in Computer Architectures and Real-time Systems Programming courses. Thanks for help, Pavel
Hello Rob, On Saturday 04 of January 2020 00:53:59 Rob Herring wrote: > On Sat, Dec 21, 2019 at 03:07:31PM +0100, pisa@cmp.felk.cvut.cz wrote: > > From: Pavel Pisa <pisa@cmp.felk.cvut.cz> > > > > Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> > > --- > > .../devicetree/bindings/net/can/ctu,ctucanfd.txt | 61 > > ++++++++++++++++++++++ 1 file changed, 61 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt > > Bindings are moving DT schema format now. Not something I'd require on a > respin I've already reviewed, but OTOH it's been 10 months to respin > from v2. So: > > Reviewed-by: Rob Herring <robh@kernel.org> > > If you have a v4, then please convert to a schema. The first, thanks much for Device-tree part review, it is only one received from relevant person for last six months. So I have wait update for v4 patches and focused on teaching forced to be distance one https://cw.fel.cvut.cz/wiki/courses/b35apo/lectures/start another part of the CTU CAN FD project. QEMU emulation for the CTU CAN FD IP core is result of Jan Charvat's bachelor thesis led by me. The patches are waiting for QEMU developers review https://lists.nongnu.org/archive/html/qemu-devel/2020-07/msg04653.html The other people have significant interrest in our project, Oliver Hartkopp, CAN in Automation representatives etc. https://can-newsletter.org/hardware/semiconductors/200609_open-source-ip-core-compliant-with-iso-can-fd_ctu/ https://can-newsletter.org/hardware/semiconductors/181121_can-fd-core-as-an-open-project_university Project is integrated into complex CAN LIN etc.. tester build for Skoda Auto based on Intel SoC as well. I am trying to resolve that only one review feedback which I have received before v4 patches sending. I have spent half day to update and integrate self build packages to my stable Debian to can run make -k dt_binding_check but unfortunately, I have not achieved promissing result even when tested on Linux kernel unpatched sources. I used actual git dt-schema/dt-doc-validate with 5.4 kernel build but I get only long series of pi@baree:/usr/src/linux-5.4-rt/_build/arm/px6$ make dt_binding_check -k GNUmakefile:40: *** mixed implicit and normal rules: deprecated syntax make -C /usr/src/linux-5.4-rt O=/usr/src/linux-5.4-rt/_build/arm/px6/ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- QTDIR=/usr/share/qt4 dt_binding_check CHKDT Documentation/devicetree/bindings/arm/actions.yaml /usr/src/linux-5.4-rt/Documentation/devicetree/bindings/arm/actions.yaml: found incompatible YAML document in "<unicode string>", line 2, column 1 make[3]: *** [/usr/src/linux-5.4-rt/Documentation/devicetree/bindings/Makefile:12: Documentation/devicetree/bindings/arm/actions.example.dts] Error 1 CHKDT Documentation/devicetree/bindings/arm/al,alpine.yaml /usr/src/linux-5.4-rt/Documentation/devicetree/bindings/arm/al,alpine.yaml: found incompatible YAML document in "<unicode string>", line 2, column 1 make[3]: *** [/usr/src/linux-5.4-rt/Documentation/devicetree/bindings/Makefile:12: Documentation/devicetree/bindings/arm/al,alpine.example.dts] Error 1 CHKDT Documentation/devicetree/bindings/arm/altera.yaml /usr/src/linux-5.4-rt/Documentation/devicetree/bindings/arm/altera.yaml: found incompatible YAML document in "<unicode string>", line 2, column 1 make[3]: *** [/usr/src/linux-5.4-rt/Documentation/devicetree/bindings/Makefile:12: Documentation/devicetree/bindings/arm/altera.example.dts] Error 1 CHKDT Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml /usr/src/linux-5.4-rt/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml: found incompatible YAML document in "<unicode string>", line 2, column 1 make[3]: *** [/usr/src/linux-5.4-rt/Documentation/devicetree/bindings/Makefile:12: Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.example.dts] Error 1 CHKDT Documentation/devicetree/bindings/arm/amlogic.yaml The same for ctu,ctucanfd.yam . Please, if you have working setup, test if the followup content of Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml is acceptable Thanks in advance, Pavel # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- $id: http://devicetree.org/schemas/net/can/ctu,ctucanfd.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: CTU CAN FD Open-source IP Core Device Tree Bindings description: | Open-source CAN FD IP core developed at the Czech Technical University in Prague The core sources and documentation on project page [1] sources : https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core [2] datasheet : https://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/Progdokum.pdf Integration in Xilinx Zynq SoC based system together with OpenCores SJA1000 compatible controllers [3] project : https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top Martin Jerabek dimploma thesis with integration and testing framework description [4] PDF : https://dspace.cvut.cz/bitstream/handle/10467/80366/F3-DP-2019-Jerabek-Martin-Jerabek-thesis-2019-canfd.pdf maintainers: - Pavel Pisa <pisa@cmp.felk.cvut.cz> - Ondrej Ille <ondrej.ille@gmail.com> - Martin Jerabek <martin.jerabek01@gmail.com> properties: compatible: oneOf: - items: - const: ctu,ctucanfd - const: ctu,canfd-2 - const: ctu,ctucanfd reg: description: mapping into bus address space, offset and size maxItems: 1 interrupts: description: | interrupt source. For Zynq SoC system, format is <(is_spi) (number) (type)> where is_spi defines if it is SPI (shared peripheral) interrupt, the second number is translated to the vector by addition of 32 on Zynq-7000 systems and type is IRQ_TYPE_LEVEL_HIGH (4) for Zynq. maxItems: 1 clocks: description: | phandle of reference clock (100 MHz is appropriate for FPGA implementation on Zynq-7000 system). maxItems: 1 required: - compatible - reg - interrupts - clocks additionalProperties: false examples: - | ctu_can_fd_0: can@43c30000 { compatible = "ctu,ctucanfd"; interrupts = <0 30 4>; clocks = <&clkc 15>; reg = <0x43c30000 0x10000>; };
Hello Rob ad others, On Wednesday 29 of July 2020 01:12:31 Pavel Pisa wrote: > On Saturday 04 of January 2020 00:53:59 Rob Herring wrote: > > On Sat, Dec 21, 2019 at 03:07:31PM +0100, pisa@cmp.felk.cvut.cz wrote: > > > From: Pavel Pisa <pisa@cmp.felk.cvut.cz> > > > > > > Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> > > > --- > > > .../devicetree/bindings/net/can/ctu,ctucanfd.txt | 61 > > > ++++++++++++++++++++++ 1 file changed, 61 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt > > > > Bindings are moving DT schema format now. Not something I'd require on a > > respin I've already reviewed, but OTOH it's been 10 months to respin > > from v2. So: > > > > Reviewed-by: Rob Herring <robh@kernel.org> > > > > If you have a v4, then please convert to a schema. > ... > I am trying to resolve that only one review feedback which I have received > before v4 patches sending. I have spent half day to update and integrate > self build packages to my stable Debian to can run > > make -k dt_binding_check > > but unfortunately, I have not achieved promissing result even when tested > on Linux kernel unpatched sources. I used actual git > dt-schema/dt-doc-validate with 5.4 kernel build but I get only long series > of I have succeed to run make dt_binding_check on stable Debian with 5.4 kernel with only denumerable bunch of errors, probably normal one. Details to make dt_binding_check usable on stable Debian later. When invoked with base directory specified /usr/local/bin/dt-doc-validate -u /usr/src/linux-5.4/Documentation/devicetree/bindings/ net/can/ctu,ctucanfd.yaml then no problem is reported in ctu,ctucanfd.yaml . Please is the specification correct even after human check? > pi@baree:/usr/src/linux-5.4-rt/_build/arm/px6$ make dt_binding_check -k > GNUmakefile:40: *** mixed implicit and normal rules: deprecated syntax > make -C /usr/src/linux-5.4-rt O=/usr/src/linux-5.4-rt/_build/arm/px6/ > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- QTDIR=/usr/share/qt4 > dt_binding_check CHKDT Documentation/devicetree/bindings/arm/actions.yaml > /usr/src/linux-5.4-rt/Documentation/devicetree/bindings/arm/actions.yaml: > found incompatible YAML document in "<unicode string>", line 2, column 1 > make[3]: *** The remark to save time of others, actual stable Debian Buster provides package python3-ruamel.yaml in 0.15.34-1+b1 version. But use of make dt_binding_check and dt-doc-validate and dt-validate with this version lead to many errors "found incompatible YAML document". The validation tools can be make to work when next packages are added and replaced in stable Debian python3-pyrsistent 0.15.5-1 python3-pyfakefs 4.0.2-1 python3-zipp 1.0.0-3 python3-importlib-metadata 1.6.0 python3-jsonschema 3.2.0-3 python3-ruamel.yaml.clib 0.2.0-3 python3-ruamel.yaml 0.16.10-2 The dependencies and interdependence of the tools are really wide and that the tools are unusable in the actual regular Debian stable distribution should be described somewhere visible enough to save developers time. Best wishes, Pavel
On Sat, Aug 1, 2020 at 3:28 PM Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote: > > Hello Rob ad others, > > On Wednesday 29 of July 2020 01:12:31 Pavel Pisa wrote: > > On Saturday 04 of January 2020 00:53:59 Rob Herring wrote: > > > On Sat, Dec 21, 2019 at 03:07:31PM +0100, pisa@cmp.felk.cvut.cz wrote: > > > > From: Pavel Pisa <pisa@cmp.felk.cvut.cz> > > > > > > > > Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> > > > > --- > > > > .../devicetree/bindings/net/can/ctu,ctucanfd.txt | 61 > > > > ++++++++++++++++++++++ 1 file changed, 61 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt > > > > > > Bindings are moving DT schema format now. Not something I'd require on a > > > respin I've already reviewed, but OTOH it's been 10 months to respin > > > from v2. So: > > > > > > Reviewed-by: Rob Herring <robh@kernel.org> > > > > > > If you have a v4, then please convert to a schema. > > > > ... > > > I am trying to resolve that only one review feedback which I have received > > before v4 patches sending. I have spent half day to update and integrate > > self build packages to my stable Debian to can run > > > > make -k dt_binding_check > > > > but unfortunately, I have not achieved promissing result even when tested > > on Linux kernel unpatched sources. I used actual git > > dt-schema/dt-doc-validate with 5.4 kernel build but I get only long series > > of > > I have succeed to run make dt_binding_check on stable Debian with 5.4 > kernel with only denumerable bunch of errors, probably normal one. > Details to make dt_binding_check usable on stable Debian later. > > When invoked with base directory specified > > /usr/local/bin/dt-doc-validate -u /usr/src/linux-5.4/Documentation/devicetree/bindings/ net/can/ctu,ctucanfd.yaml > > then no problem is reported in ctu,ctucanfd.yaml . > Please is the specification correct even after human check? > > > pi@baree:/usr/src/linux-5.4-rt/_build/arm/px6$ make dt_binding_check -k > > GNUmakefile:40: *** mixed implicit and normal rules: deprecated syntax > > make -C /usr/src/linux-5.4-rt O=/usr/src/linux-5.4-rt/_build/arm/px6/ > > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- QTDIR=/usr/share/qt4 > > dt_binding_check CHKDT Documentation/devicetree/bindings/arm/actions.yaml > > /usr/src/linux-5.4-rt/Documentation/devicetree/bindings/arm/actions.yaml: > > found incompatible YAML document in "<unicode string>", line 2, column 1 > > make[3]: *** > > The remark to save time of others, actual stable Debian Buster provides package > python3-ruamel.yaml in 0.15.34-1+b1 version. But use of make dt_binding_check > and dt-doc-validate and dt-validate with this version lead to many errors > "found incompatible YAML document". The validation tools can be make > to work when next packages are added and replaced in stable Debian pip/setup.py should check the dependencies which includes 'ruamel.yaml>0.15.69'. Did you not use pip? > python3-pyrsistent 0.15.5-1 > python3-pyfakefs 4.0.2-1 > python3-zipp 1.0.0-3 > python3-importlib-metadata 1.6.0 These must all be indirect dependencies as I have no idea what they provide. > python3-jsonschema 3.2.0-3 > python3-ruamel.yaml.clib 0.2.0-3 > python3-ruamel.yaml 0.16.10-2 > > The dependencies and interdependence of the tools are really wide and that > the tools are unusable in the actual regular Debian stable distribution > should be described somewhere visible enough to save developers > time. I can't document distro specifics for what I don't have. Manually documenting dependencies and their versions seems like a recipe for inaccurate and out of date documentation. Rob
diff --git a/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt new file mode 100644 index 000000000000..4cb2f04cb412 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt @@ -0,0 +1,61 @@ +Memory Mapped CTU CAN FD Open-source IP Core Device Tree Bindings +----------------------------------------------------------------- + + +The core sources and documentation on project page + + https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core + http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/Progdokum.pdf + +Integration in Xilinx Zynq SoC based system together with +OpenCores SJA1000 compatible controllers + + https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top + +Martin Jerabek's dimploma thesis with integration and testing +framework description + + https://dspace.cvut.cz/bitstream/handle/10467/80366/F3-DP-2019-Jerabek-Martin-Jerabek-thesis-2019-canfd.pdf + +Required properties: + +- compatible : should be one of "ctu,ctucanfd", "ctu,canfd-2". + The "canfd-2" has been reserved for older revision of the IP core. + The revision can be read from the IP core register as well. + +- reg = <(baseaddr) (size)> : specify mapping into physical address + space of the processor system. + +- interrupts : property with a value describing the interrupt source + required for the CTU CAN FD. For Zynq SoC system format is + <(is_spi) (number) (type)> where is_spi defines if it is SPI + (shared peripheral) interrupt, the second number is translated + to the vector by addition of 32 on Zynq-7000 systems and type + is IRQ_TYPE_LEVEL_HIGH (4) for Zynq. + +- clocks: phandle of reference clock (100 MHz is appropriate + for FPGA implementation on Zynq-7000 system). + +Optional properties: + +- clock-names: not used in actual design but if more clocks are used + by cores then "can_clk" would be clock source name for the clocks + used to define CAN time-quanta. + +Example when integrated to Zynq-7000 system DTS: + + / { + /* ... */ + amba: amba { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + + ctu_can_fd_0: can@43c30000 { + compatible = "ctu,ctucanfd"; + interrupts = <0 30 4>; + clocks = <&clkc 15>; + reg = <0x43c30000 0x10000>; + }; + }; + };