From: Pavel Pisa <[email protected]>
Signed-off-by: Pavel Pisa <[email protected]>
---
.../devicetree/bindings/net/can/ctu,ctucanfd.txt | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt
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>;
+ };
+ };
+ };
--
2.11.0
On Sat, Dec 21, 2019 at 03:07:31PM +0100, [email protected] wrote:
> From: Pavel Pisa <[email protected]>
>
> Signed-off-by: Pavel Pisa <[email protected]>
> ---
> .../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 <[email protected]>
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, [email protected] wrote:
> > From: Pavel Pisa <[email protected]>
> > .../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, [email protected] wrote:
> > From: Pavel Pisa <[email protected]>
> >
> > Signed-off-by: Pavel Pisa <[email protected]>
> > ---
> > .../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 <[email protected]>
>
> 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 <[email protected]>
- Ondrej Ille <[email protected]>
- Martin Jerabek <[email protected]>
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, [email protected] wrote:
> > > From: Pavel Pisa <[email protected]>
> > >
> > > Signed-off-by: Pavel Pisa <[email protected]>
> > > ---
> > > .../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 <[email protected]>
> >
> > 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
--
Pavel Pisa
phone: +420 603531357
e-mail: [email protected]
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://dce.fel.cvut.cz/
personal: http://cmp.felk.cvut.cz/~pisa
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
On Sat, Aug 1, 2020 at 3:28 PM Pavel Pisa <[email protected]> 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, [email protected] wrote:
> > > > From: Pavel Pisa <[email protected]>
> > > >
> > > > Signed-off-by: Pavel Pisa <[email protected]>
> > > > ---
> > > > .../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 <[email protected]>
> > >
> > > 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