Re: [PATCH v7 0/6] CTU CAN FD open-source IP core SocketCAN driver, PCI, platform integration and documentation
Hello Marc, thanks for response On Saturday 31 of October 2020 12:35:11 Marc Kleine-Budde wrote: > On 10/30/20 11:19 PM, Pavel Pisa wrote: > > This driver adds support for the CTU CAN FD open-source IP core. > > Please fix the following checkpatch warnings/errors: Yes I recheck with actual checkpatch, I have used 5.4 one and may it be overlooked something during last upadates. > - > drivers/net/can/ctucanfd/ctucanfd_frame.h > - > CHECK: Please don't use multiple blank lines > #46: FILE: drivers/net/can/ctucanfd/ctucanfd_frame.h:46: OK, we find a reason for this blank line in header generator. > CHECK: Prefer kernel type 'u32' over 'uint32_t' > #49: FILE: drivers/net/can/ctucanfd/ctucanfd_frame.h:49: > + uint32_t u32; In this case, please confirm that even your personal opinion is against uint32_t in headers, you request the change. uint32_t is used in many kernel headers and in this case allows our tooling to use headers for mutual test of HDL design match with HW access in the C. If the reasons to remove uint32_t prevails, we need to separate Linux generator from the one used for other purposes. When we add Linux mode then we can revamp headers even more and in such case we can even invest time to switch from structure bitfields to plain bitmask defines. It is quite lot of work and takes some time, but if there is consensus I do it during next weeks, I would like to see what is preferred way to define registers bitfields. I personally like RTEMS approach for which we have prepared generator from parsed PDFs when we added BSP for TMS570 https://git.rtems.org/rtems/tree/bsps/arm/tms570/include/bsp/ti_herc/reg_dcan.h#n152 Other solution I like (biased, because I have even designed it) is #define __val2mfld(mask,val) (((mask)&~((mask)<<1))*(val)&(mask)) #define __mfld2val(mask,val) (((val)&(mask))/((mask)&~((mask)<<1))) https://gitlab.com/pikron/sw-base/sysless/-/blob/master/arch/arm/generic/defines/cpu_def.h#L314 Which allows to use simple masks, i.e. #define SSP_CR0_DSS_m 0x000f /* Data Size Select (num bits - 1) */ #define SSP_CR0_FRF_m 0x0030 /* Frame Format: 0 SPI, 1 TI, 2 Microwire */ #define SSP_CR0_CPOL_m 0x0040 /* SPI Clock Polarity. 0 low between frames, 1 high */ # https://gitlab.com/pikron/sw-base/sysless/-/blob/master/libs4c/spi/spi_lpcssp.c#L46 in the sources lpcssp_drv->ssp_regs->CR0 = __val2mfld(SSP_CR0_DSS_m, lpcssp_drv->data16_fl? 16 - 1 : 8 - 1) | __val2mfld(SSP_CR0_FRF_m, 0) | (msg->size_mode & SPI_MODE_CPOL? SSP_CR0_CPOL_m: 0) | (msg->size_mode & SPI_MODE_CPHA? SSP_CR0_CPHA_m: 0) | __val2mfld(SSP_CR0_SCR_m, rate); https://gitlab.com/pikron/sw-base/sysless/-/blob/master/libs4c/spi/spi_lpcssp.c#L217 If you have some preferred Linux style then please send us pointers. In the fact, Ondrej Ille has based his structure bitfileds style on the other driver included in the Linux kernel and it seems to be a problem now. So when I invest my time, I want to use style which pleases me and others. Thanks for the support and best wishes, Pavel Pisa
[PATCH v7 6/6] docs: ctucanfd: CTU CAN FD open-source IP core documentation.
CTU CAN FD IP core documentation based on Martin Jeřábek's diploma theses
Open-source and Open-hardware CAN FD Protocol Support
https://dspace.cvut.cz/handle/10467/80366
.
Signed-off-by: Pavel Pisa
Signed-off-by: Martin Jerabek
Signed-off-by: Ondrej Ille
---
.../device_drivers/ctu/ctucanfd-driver.rst| 638 ++
.../ctu/fsm_txt_buffer_user.svg | 151 +
2 files changed, 789 insertions(+)
create mode 100644
Documentation/networking/device_drivers/ctu/ctucanfd-driver.rst
create mode 100644
Documentation/networking/device_drivers/ctu/fsm_txt_buffer_user.svg
diff --git a/Documentation/networking/device_drivers/ctu/ctucanfd-driver.rst
b/Documentation/networking/device_drivers/ctu/ctucanfd-driver.rst
new file mode 100644
index ..da5b0002e358
--- /dev/null
+++ b/Documentation/networking/device_drivers/ctu/ctucanfd-driver.rst
@@ -0,0 +1,638 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+CTU CAN FD Driver
+=
+
+Author: Martin Jerabek
+
+
+About CTU CAN FD IP Core
+
+
+`CTU CAN FD <https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core>`_
+is an open source soft core written in VHDL.
+It originated in 2015 as Ondrej Ille's project
+at the `Department of Measurement <https://meas.fel.cvut.cz/>`_
+of `FEE <http://www.fel.cvut.cz/en/>`_ at `CTU <http://www.fel.cvut.cz/en/>`_.
+
+The SocketCAN driver for Xilinx Zynq SoC based MicroZed board
+`Vivado integration
<https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top>`_
+and Intel Cyclone V 5CSEMA4U23C6 based DE0-Nano-SoC Terasic board
+`QSys integration <https://gitlab.fel.cvut.cz/canbus/intel-soc-ctucanfd>`_
+has been developed as well as support for
+`PCIe integration <https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd>`_ of the
core.
+
+In the case of Zynq, the core is connected via the APB system bus, which does
+not have enumeration support, and the device must be specified in Device Tree.
+This kind of devices is called platform device in the kernel and is
+handled by a platform device driver.
+
+The basic functional model of the CTU CAN FD peripheral has been
+accepted into QEMU mainline. See QEMU `CAN emulation support
<https://git.qemu.org/?p=qemu.git;a=blob;f=docs/can.txt>`_
+for CAN FD buses, host connection and CTU CAN FD core emulation. The
development
+version of emulation support can be cloned from ctu-canfd branch of QEMU local
+development `repository <https://gitlab.fel.cvut.cz/canbus/qemu-canbus>`_.
+
+
+About SocketCAN
+---
+
+SocketCAN is a standard common interface for CAN devices in the Linux
+kernel. As the name suggests, the bus is accessed via sockets, similarly
+to common network devices. The reasoning behind this is in depth
+described in `Linux SocketCAN
<https://www.kernel.org/doc/html/latest/networking/can.html>`_.
+In short, it offers a
+natural way to implement and work with higher layer protocols over CAN,
+in the same way as, e.g., UDP/IP over Ethernet.
+
+Device probe
+
+
+Before going into detail about the structure of a CAN bus device driver,
+let's reiterate how the kernel gets to know about the device at all.
+Some buses, like PCI or PCIe, support device enumeration. That is, when
+the system boots, it discovers all the devices on the bus and reads
+their configuration. The kernel identifies the device via its vendor ID
+and device ID, and if there is a driver registered for this identifier
+combination, its probe method is invoked to populate the driver's
+instance for the given hardware. A similar situation goes with USB, only
+it allows for device hot-plug.
+
+The situation is different for peripherals which are directly embedded
+in the SoC and connected to an internal system bus (AXI, APB, Avalon,
+and others). These buses do not support enumeration, and thus the kernel
+has to learn about the devices from elsewhere. This is exactly what the
+Device Tree was made for.
+
+Device tree
+~~~
+
+An entry in device tree states that a device exists in the system, how
+it is reachable (on which bus it resides) and its configuration –
+registers address, interrupts and so on. An example of such a device
+tree is given in .
+
+.. code:: raw
+
+ / {
+ /* ... */
+ amba: amba {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+
+ CTU_CAN_FD_0: CTU_CAN_FD@43c3 {
+ compatible = "ctu,ctucanfd";
+ interrupt-parent = <>;
+ interrupts = <0 30 4>;
+ clocks = < 15>;
+ reg = <0x43c3 0x1>;
+ };
+ };
+ };
+
+
+.. _sec:socketcan:drv:
+
+Driver structure
+
+
+The driver can be d
[PATCH v7 5/6] can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support.
Platform bus adaptation for CTU CAN FD open-source IP core.
The core has been tested together with OpenCores SJA1000
modified to be CAN FD frames tolerant on MicroZed Zynq based
MZ_APO education kits designed by Petr Porazil from PiKRON.com
company. FPGA design
https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top.
The kit description at the Computer Architectures course pages
https://cw.fel.cvut.cz/wiki/courses/b35apo/documentation/mz_apo/start .
Kit carrier board and mechanics design source files
https://gitlab.com/pikron/projects/mz_apo/microzed_apo
The work is documented in Martin Jeřábek's diploma theses
Open-source and Open-hardware CAN FD Protocol Support
https://dspace.cvut.cz/handle/10467/80366
.
Signed-off-by: Pavel Pisa
Signed-off-by: Martin Jerabek
Signed-off-by: Ondrej Ille
---
drivers/net/can/ctucanfd/Kconfig | 12 ++
drivers/net/can/ctucanfd/Makefile| 1 +
drivers/net/can/ctucanfd/ctucanfd_platform.c | 142 +++
3 files changed, 155 insertions(+)
create mode 100644 drivers/net/can/ctucanfd/ctucanfd_platform.c
diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig
index 039df460cf0c..20a9a1b5ae8d 100644
--- a/drivers/net/can/ctucanfd/Kconfig
+++ b/drivers/net/can/ctucanfd/Kconfig
@@ -20,3 +20,15 @@ config CAN_CTUCANFD_PCI
The project providing FPGA design for Intel EP4CGX15 based DB4CGX15
PCIe board with PiKRON.com designed transceiver riser shield is
available
at https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd .
+
+config CAN_CTUCANFD_PLATFORM
+ tristate "CTU CAN-FD IP core platform (FPGA, SoC) driver"
+ depends on CAN_CTUCANFD
+ depends on OF || COMPILE_TEST
+ help
+ The core has been tested together with OpenCores SJA1000
+ modified to be CAN FD frames tolerant on MicroZed Zynq based
+ MZ_APO education kits designed by Petr Porazil from PiKRON.com
+ company. FPGA design
https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top.
+ The kit description at the Computer Architectures course pages
+ https://cw.fel.cvut.cz/b182/courses/b35apo/documentation/mz_apo/start
.
diff --git a/drivers/net/can/ctucanfd/Makefile
b/drivers/net/can/ctucanfd/Makefile
index b679859c7c9b..d4223812391d 100644
--- a/drivers/net/can/ctucanfd/Makefile
+++ b/drivers/net/can/ctucanfd/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_CAN_CTUCANFD) := ctucanfd.o
ctucanfd-y := ctucanfd_base.o ctucanfd_hw.o
obj-$(CONFIG_CAN_CTUCANFD_PCI) += ctucanfd_pci.o
+obj-$(CONFIG_CAN_CTUCANFD_PLATFORM) += ctucanfd_platform.o
diff --git a/drivers/net/can/ctucanfd/ctucanfd_platform.c
b/drivers/net/can/ctucanfd/ctucanfd_platform.c
new file mode 100644
index ..d8146cfb2f39
--- /dev/null
+++ b/drivers/net/can/ctucanfd/ctucanfd_platform.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/***
+ *
+ * CTU CAN FD IP Core
+ *
+ * Copyright (C) 2015-2018 Ondrej Ille FEE CTU
+ * Copyright (C) 2018-2020 Ondrej Ille self-funded
+ * Copyright (C) 2018-2019 Martin Jerabek FEE CTU
+ * Copyright (C) 2018-2020 Pavel Pisa FEE
CTU/self-funded
+ *
+ * Project advisors:
+ * Jiri Novak
+ * Pavel Pisa
+ *
+ * Department of Measurement (http://meas.fel.cvut.cz/)
+ * Faculty of Electrical Engineering (http://www.fel.cvut.cz)
+ * Czech Technical University(http://www.cvut.cz/)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
**/
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ctucanfd.h"
+
+#define DRV_NAME "ctucanfd"
+
+static void ctucan_platform_set_drvdata(struct device *dev,
+ struct net_device *ndev)
+{
+ struct platform_device *pdev = container_of(dev, struct platform_device,
+ dev);
+
+ platform_set_drvdata(pdev, ndev);
+}
+
+/**
+ * ctucan_platform_probe - Platform registration call
+ * @pdev: Handle to the platform device structure
+ *
+ * This function does all the memory allocation and registration for the CAN
+ * device.
+ *
+ * Return: 0 on success and failure value on error
+ */
+static int ctucan_platform_probe(struct platform_device *pdev)
+{
+ struct resource *res; /* IO mem resources */
+ struct device *de
[PATCH v7 3/6] can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.
From: Martin Jerabek This driver adds support for the CTU CAN FD open-source IP core. More documentation and core sources at project page (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). The core integration to Xilinx Zynq system as platform driver is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). Implementation on Intel FPGA based PCI Express board is available from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd). More about CAN bus related projects used and developed at CTU FEE at http://canbus.pages.fel.cvut.cz/ . Signed-off-by: Martin Jerabek Signed-off-by: Ondrej Ille Signed-off-by: Pavel Pisa --- drivers/net/can/Kconfig |1 + drivers/net/can/Makefile |1 + drivers/net/can/ctucanfd/Kconfig | 12 + drivers/net/can/ctucanfd/Makefile |7 + drivers/net/can/ctucanfd/ctucanfd.h | 87 ++ drivers/net/can/ctucanfd/ctucanfd_base.c | 1142 + drivers/net/can/ctucanfd/ctucanfd_frame.h | 189 drivers/net/can/ctucanfd/ctucanfd_hw.c| 751 ++ drivers/net/can/ctucanfd/ctucanfd_hw.h| 935 + drivers/net/can/ctucanfd/ctucanfd_regs.h | 971 ++ 10 files changed, 4096 insertions(+) create mode 100644 drivers/net/can/ctucanfd/Kconfig create mode 100644 drivers/net/can/ctucanfd/Makefile create mode 100644 drivers/net/can/ctucanfd/ctucanfd.h create mode 100644 drivers/net/can/ctucanfd/ctucanfd_base.c create mode 100644 drivers/net/can/ctucanfd/ctucanfd_frame.h create mode 100644 drivers/net/can/ctucanfd/ctucanfd_hw.c create mode 100644 drivers/net/can/ctucanfd/ctucanfd_hw.h create mode 100644 drivers/net/can/ctucanfd/ctucanfd_regs.h diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 17c166cc8482..458afc4b81f2 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -168,6 +168,7 @@ config PCH_CAN source "drivers/net/can/c_can/Kconfig" source "drivers/net/can/cc770/Kconfig" +source "drivers/net/can/ctucanfd/Kconfig" source "drivers/net/can/ifi_canfd/Kconfig" source "drivers/net/can/m_can/Kconfig" source "drivers/net/can/mscan/Kconfig" diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile index 22164300122d..28b39cd122f0 100644 --- a/drivers/net/can/Makefile +++ b/drivers/net/can/Makefile @@ -21,6 +21,7 @@ obj-y += softing/ obj-$(CONFIG_CAN_AT91) += at91_can.o obj-$(CONFIG_CAN_CC770)+= cc770/ obj-$(CONFIG_CAN_C_CAN)+= c_can/ +obj-$(CONFIG_CAN_CTUCANFD) += ctucanfd/ obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o obj-$(CONFIG_CAN_GRCAN)+= grcan.o obj-$(CONFIG_CAN_IFI_CANFD)+= ifi_canfd/ diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig new file mode 100644 index ..8210a5fcd444 --- /dev/null +++ b/drivers/net/can/ctucanfd/Kconfig @@ -0,0 +1,12 @@ +config CAN_CTUCANFD + tristate "CTU CAN-FD IP core" + help + This driver adds support for the CTU CAN FD open-source IP core. + More documentation and core sources at project page + (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). + The core integration to Xilinx Zynq system as platform driver + is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). + Implementation on Intel FPGA-based PCI Express board is available + from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd) and + on Intel SoC from project (https://gitlab.fel.cvut.cz/canbus/intel-soc-ctucanfd). + Guidepost CTU FEE CAN bus projects page http://canbus.pages.fel.cvut.cz/ . diff --git a/drivers/net/can/ctucanfd/Makefile b/drivers/net/can/ctucanfd/Makefile new file mode 100644 index ..1fd0610964f0 --- /dev/null +++ b/drivers/net/can/ctucanfd/Makefile @@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +# +# Makefile for the CTU CAN-FD IP module drivers +# + +obj-$(CONFIG_CAN_CTUCANFD) := ctucanfd.o +ctucanfd-y := ctucanfd_base.o ctucanfd_hw.o diff --git a/drivers/net/can/ctucanfd/ctucanfd.h b/drivers/net/can/ctucanfd/ctucanfd.h new file mode 100644 index ..6ea1482d1807 --- /dev/null +++ b/drivers/net/can/ctucanfd/ctucanfd.h @@ -0,0 +1,87 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/*** + * + * CTU CAN FD IP Core + * + * Copyright (C) 2015-2018 Ondrej Ille FEE CTU + * Copyright (C) 2018-2020 Ondrej Ille self-funded + * Copyright (C) 2018-2019 Martin Jerabek FEE CTU + * Copyright (C) 2018-2020 Pavel Pisa FEE CTU/self-funded + * + * Project advisors: + * Jiri Novak + * Pavel Pisa + * + * Department of Measurement (http://meas.fel.cvut.cz/) + * Faculty of Electrical Engineering (http://www.fel.cvut.cz) + * Czech
[PATCH v7 4/6] can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.
PCI bus adaptation for CTU CAN FD open-source IP core.
The project providing FPGA design for Intel EP4CGX15 based DB4CGX15
PCIe board with PiKRON.com designed transceiver riser shield is available
at https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd .
Signed-off-by: Pavel Pisa
Signed-off-by: Martin Jerabek
Signed-off-by: Ondrej Ille
---
drivers/net/can/ctucanfd/Kconfig| 10 +
drivers/net/can/ctucanfd/Makefile | 2 +
drivers/net/can/ctucanfd/ctucanfd_pci.c | 316
3 files changed, 328 insertions(+)
create mode 100644 drivers/net/can/ctucanfd/ctucanfd_pci.c
diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig
index 8210a5fcd444..039df460cf0c 100644
--- a/drivers/net/can/ctucanfd/Kconfig
+++ b/drivers/net/can/ctucanfd/Kconfig
@@ -10,3 +10,13 @@ config CAN_CTUCANFD
from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd) and
on Intel SoC from project
(https://gitlab.fel.cvut.cz/canbus/intel-soc-ctucanfd).
Guidepost CTU FEE CAN bus projects page
http://canbus.pages.fel.cvut.cz/ .
+
+config CAN_CTUCANFD_PCI
+ tristate "CTU CAN-FD IP core PCI/PCIe driver"
+ depends on CAN_CTUCANFD
+ depends on PCI
+ help
+ This driver adds PCI/PCIe support for CTU CAN-FD IP core.
+ The project providing FPGA design for Intel EP4CGX15 based DB4CGX15
+ PCIe board with PiKRON.com designed transceiver riser shield is
available
+ at https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd .
diff --git a/drivers/net/can/ctucanfd/Makefile
b/drivers/net/can/ctucanfd/Makefile
index 1fd0610964f0..b679859c7c9b 100644
--- a/drivers/net/can/ctucanfd/Makefile
+++ b/drivers/net/can/ctucanfd/Makefile
@@ -5,3 +5,5 @@
obj-$(CONFIG_CAN_CTUCANFD) := ctucanfd.o
ctucanfd-y := ctucanfd_base.o ctucanfd_hw.o
+
+obj-$(CONFIG_CAN_CTUCANFD_PCI) += ctucanfd_pci.o
diff --git a/drivers/net/can/ctucanfd/ctucanfd_pci.c
b/drivers/net/can/ctucanfd/ctucanfd_pci.c
new file mode 100644
index ..298b5137
--- /dev/null
+++ b/drivers/net/can/ctucanfd/ctucanfd_pci.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/***
+ *
+ * CTU CAN FD IP Core
+ *
+ * Copyright (C) 2015-2018 Ondrej Ille FEE CTU
+ * Copyright (C) 2018-2020 Ondrej Ille self-funded
+ * Copyright (C) 2018-2019 Martin Jerabek FEE CTU
+ * Copyright (C) 2018-2020 Pavel Pisa FEE
CTU/self-funded
+ *
+ * Project advisors:
+ * Jiri Novak
+ * Pavel Pisa
+ *
+ * Department of Measurement (http://meas.fel.cvut.cz/)
+ * Faculty of Electrical Engineering (http://www.fel.cvut.cz)
+ * Czech Technical University(http://www.cvut.cz/)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
**/
+
+#include
+#include
+
+#include "ctucanfd.h"
+
+#define DRV_NAME "ctucanfd_pci"
+
+#ifndef PCI_DEVICE_DATA
+#define PCI_DEVICE_DATA(vend, dev, data) \
+.vendor = PCI_VENDOR_ID_##vend, \
+.device = PCI_DEVICE_ID_##vend##_##dev, \
+.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, 0, 0, \
+.driver_data = (kernel_ulong_t)(data)
+#endif
+
+#ifndef PCI_VENDOR_ID_TEDIA
+#define PCI_VENDOR_ID_TEDIA 0x1760
+#endif
+
+#ifndef PCI_DEVICE_ID_TEDIA_CTUCAN_VER21
+#define PCI_DEVICE_ID_TEDIA_CTUCAN_VER21 0xff00
+#endif
+
+#define CTUCAN_BAR0_CTUCAN_ID 0x
+#define CTUCAN_BAR0_CRA_BASE 0x4000
+#define CYCLONE_IV_CRA_A2P_IE (0x0050)
+
+#define CTUCAN_WITHOUT_CTUCAN_ID 0
+#define CTUCAN_WITH_CTUCAN_ID 1
+
+static bool use_msi = true;
+module_param(use_msi, bool, 0444);
+MODULE_PARM_DESC(use_msi, "PCIe implementation use MSI interrupts. Default: 1
(yes)");
+
+static bool pci_use_second = true;
+module_param(pci_use_second, bool, 0444);
+MODULE_PARM_DESC(pci_use_second, "Use the second CAN core on PCIe card.
Default: 1 (yes)");
+
+struct ctucan_pci_board_data {
+ void __iomem *bar0_base;
+ void __iomem *cra_base;
+ void __iomem *bar1_base;
+ struct list_head ndev_list_head;
+ int use_msi;
+};
+
+static struct ctucan_pci_board_data *ctucan_pci_get_bdata(struct pci_dev *pdev)
+{
+ return (struct ctucan_pci_board_data *)pci_get_drvdata(pdev);
+}
+
+static void ctucan_pci_set_drvdata(struct device *dev,
+ struct net_device *ndev)
+{
+ struct pci_dev *pdev = container_of(dev, stru
[PATCH v7 1/6] dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague.
The Czech Technical University in Prague (CTU) is one of the biggest and oldest (founded 1707) technical universities in Europe. The abbreviation in Czech language is ČVUT according to official name in Czech language České vysoké učení technické v Praze The English translation The Czech Technical University in Prague The university pages in English https://www.cvut.cz/en Signed-off-by: Pavel Pisa Acked-by: Rob Herring Acked-by: Pavel Machek --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 967e78c5ec0a..dedb10f1b250 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -215,6 +215,8 @@ patternProperties: description: Hangzhou C-SKY Microsystems Co., Ltd "^csq,.*": description: Shenzen Chuangsiqi Technology Co.,Ltd. + "^ctu,.*": +description: Czech Technical University in Prague "^cubietech,.*": description: Cubietech, Ltd. "^cypress,.*": -- 2.20.1
[PATCH v7 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
The device-tree bindings for open-source/open-hardware CAN FD IP core
designed at the Czech Technical University in Prague.
CTU CAN FD IP core and other CTU CAN bus related projects
listing and documentation page
http://canbus.pages.fel.cvut.cz/
Signed-off-by: Pavel Pisa
Reviewed-by: Rob Herring
Acked-by: Pavel Machek
---
.../bindings/net/can/ctu,ctucanfd.yaml| 63 +++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
diff --git a/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
new file mode 100644
index ..5113bb419ec1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%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
+ - Ondrej Ille
+ - Martin Jerabek
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: ctu,ctucanfd-2
+ - const: ctu,ctucanfd
+ - const: ctu,ctucanfd
+
+ reg:
+maxItems: 1
+
+ interrupts:
+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@43c3 {
+ compatible = "ctu,ctucanfd";
+ interrupts = <0 30 4>;
+ clocks = < 15>;
+ reg = <0x43c3 0x1>;
+};
--
2.20.1
[PATCH v7 0/6] CTU CAN FD open-source IP core SocketCAN driver, PCI, platform integration and documentation
This driver adds support for the CTU CAN FD open-source IP core. More documentation and core sources at project page (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). The core integration to Xilinx Zynq system as platform driver is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). Implementation on Intel FPGA based PCI Express board is available from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd). The CTU CAN FD core emulation send for review for QEMU mainline. Development repository for QEMU emulation - ctu-canfd branch of https://gitlab.fel.cvut.cz/canbus/qemu-canbus More about CAN bus related projects used and developed at CTU FEE on the guidepost page http://canbus.pages.fel.cvut.cz/ . Martin Jerabek (1): can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part. Pavel Pisa (5): dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague. dt-bindings: net: can: binding for CTU CAN FD open-source IP core. can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support. can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support. docs: ctucanfd: CTU CAN FD open-source IP core documentation. The version 7 changes: - sent at 2020-10-31 - In response of Pavel Machek review, renamed files to match directly module names. The core specification updated to provide better description and match of the fields. Driver headers, routines adjusted etc.. To achieve this, registers HDL was regenerated and and its connection updated. - CAN_STATE_* translation to text has been made robust to Linux kernel define value changes/updates and the function which uses table has moved after table for better readability. - fsm_txt_buffer_user.svg redrawn from scratch to reduce file to 16 kB. - documentation updated, unified references to recently renamed pcie-ctucanfd - I have tried to fullfill request to cross-reference SocketCAN document by :doc: or :ref: constructs in Sphinx way, but without success. I reference geerated HTML on kernel.org site for now. The version 6 changes: - sent at 2020-10-22 - the driver has been tested with 5.9 bigendian MIPS kernel against QEMU CTU CAN FD model and correct behavior on PCIe virtual board for big-endian system passed - documentation updated to reflect inclusion of SocketCAN FD and CTU CAN FD functional model support into QEMU mainline - the integration for Cyclone V 5CSEMA4U23C6 based DE0-Nano-SoC Terasic board used for SkodaAuto research projects at our university has been clean up by its author (Jaroslav Beran) and published https://gitlab.fel.cvut.cz/canbus/intel-soc-ctucanfd - Xilinx Zynq Microzed MZ_APO based target for automatic test updated to Debian 10 base. The version 5 changes: - sent at 2020-08-15 - correct Kconfig formatting according to Randy Dunlap - silence warnings reported by make W=1 C=1 flags. Changes suggested by Jakub Kicinski - big thanks for core patch review by Pavel Machek resulting in more readability and formating updates - fix power management errors found by Pavel Machek - removed comments from d-t bindings as suggested by Rob Herring - selected ctu,ctucanfd-2 as alternative name to ctu,ctucanfd which allows to bind to actual major HDL core sources version 2.x if for some reason driver adaptation would not work on version read from the core - line length limit relaxed to 100 characters on some cases where it helps to readability The version 4 changes: - sent at 2020-08-04 - changes summary, 169 non-merge commits, 6 driver, 32 IP core sources enhancements and fixes, 58 tests in master and about additional 30 iso-testbench preparation branch. - convert device-tree binding documentation to YAML - QEMU model of CTU CAN FD IP core and generic extension of QEMU CAN bus emulation developed by Jan Charvat. - driver tested on QEMU emulated Malta big-endian MIPS platform and big endian-support fixed. - checkpatch from 5.4 kernel used to cleanup driver formatting - header files generated from IP core IP-Xact description updated to include protocol exception (pex) field. Mechanism to set it from the driver is not provided yet. The version 3 changes: - sent at 2019-12-21 - adapts device tree bindings documentation according to Rob Herring suggestions. - the driver has been separated to individual modules for core support, PCI bus integration and platform, SoC integration. - the FPGA design has been cleaned up and CAN protocol FSM redesigned by Ondrej Ille (the core redesign has been reason to pause attempts to driver submission) - the work from February 2019 on core, test framework and driver 1601 commits in total, 436 commits in the core sources, 144 commits in the driver, 151 documentation, 502 in tests. - not all continuous
Re: [PATCH v6 3/6] can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.
Hello Ondrej and others,
On Monday 26 of October 2020 14:38:59 Ondrej Ille wrote:
> Hello Pavel and Pavel,
>
> first of all, Pavel (Machek) thank you for review, we appreciate it.
> We will try to fix as much mistakes as possible. Please, see my comments
> below.
>
> With Regards
> Ondrej
>
> On Thu, Oct 22, 2020 at 10:22 PM Pavel Pisa wrote:
...
> > > > +/**
> > > > + * ctucan_start_xmit - Starts the transmission
> > > > + * @skb: sk_buff pointer that contains data to be Txed
> > > > + * @ndev: Pointer to net_device structure
> > > > + *
> > > > + * This function is invoked from upper layers to initiate
> >
> > transmission.
> >
> > > > This + * function uses the next available free txbuf and populates
> >
> > their
> >
> > > > fields to + * start the transmission.
> > > > + *
> > > > + * Return: %NETDEV_TX_OK on success and failure value on error
> > > > + */
> > >
> > > Based on other documentation, I'd expect this to return -ESOMETHING on
> > > error, but it returns NETDEV_TX_BUSY.
> >
> > I add information about explicit error/need for postpone type.
>
> Changing description, OK. Pavel Pisa, but why did you change handling of
> insertion
> failure to TXT Buffer to return NETDEV_TX_BUSY and increment tx_dropped?
> Is there some preference on what should the driver return in case of HW
> error?
> Also, couldnt we afford not to check return value of ctucan_hw_insert_frame
> ? Is purpose of
> driver to be fail-safe against HW bug which says "There is TX buffer free
> in Status register", but in reality,
> no TXT Buffer is free?
>
> If we look at when ctu_can_hw_insert_frame returns false, it is when:
> 1. We attempt to insert to non-existent TXT buffer -> Under drivers
> control to do rotation correctly.
> 2. If cfg->len > CAN_FD_MAX_LEN. Couldnt this check be removed?
> CAN_FD_MAX_LEN is
> defined for Linux, so it is not OS agnostic... Also, is it possible
> that driver will call insert with
> cf->len > CAN_FD_MAX_LEN?
> 3. When there is HW bug (as mentioned earlier). There are assertions in
> RTL checking this situation
> will not happend!
> So maybe we dont even need to check return value of this function at all?
I try to follow other drivers.
So if everything is OK then return NETDEV_TX_OK.
If there is no Tx buffer available then return
NETDEV_TX_BUSY. Some retransmit or drop should be handled by
NET core in such case. This situation should not appear
in reality, because Tx queue should be stopped if there is no
free Tx buffer and should not be reenable earlien than
at least one is available. So this situation is bug in
driver logic or NET core.
If the check for CAN FD frame format fails then it is right
to drop SKB and it is handled with NETDEV_TX_OK return
in other drivers as well. Only statistic counter increments.
If the Tx buffer selected by driver s in incorrect state
then it is even more serious bug so alternative is to
stop whole driver and report fatal error.
> > > > + /* Check for Bus Error interrupt */
> > > > + if (isr.s.bei) {
> > > > + netdev_info(ndev, " bus error");
> > >
> > > Missing "if (dologerr)" here?
> >
> > Intention was to left this one to appear without rate limit, it is really
> > indication of bigger problem. But on the other hand without dologerr
> > would be quite short/unclear, but does not overflow the log buffers...
> > We would discuss what to do with my colleagues, suggestions welcomed.
>
> I agree with adding "dologerror" check here. It is true that arbitration
> lost is not really an
> error, and Bus error (error frame), therefore Bus error has higher
> "severity". Could we
> maybe do it that both have "dologerr" condition, but arbitration lost uses
> "netdev_dbg"?
Arbitration lost should not be reported nor generate interrupt
for usual can application setup.
> > > > +static int ctucan_rx_poll(struct napi_struct *napi, int quota)
> > > > +{
> > > > + struct net_device *ndev = napi->dev;
> > > > + struct ctucan_priv *priv = netdev_priv(ndev);
> > > > + int work_done = 0;
> > > > + union ctu_can_fd_status status;
> > > > + u32 framecnt;
> > > > +
> > > > + framecnt = ctucan_hw_get_rx_frame_count(>p);
> > > > + netdev_dbg(ndev, "rx_poll: %d frames in RX FIFO", framecnt);
> > >
> > > This will be rather noisy, right?
> >
> > It has use to debug during
Re: [PATCH v6 3/6] can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.
> > + return true;
> > + break;
> > + }
>
> Check indentation of break statemnts, also elsewhere in this file
Strange that checkpatch accepts this, but changing.
> > +bool ctucan_hw_get_range_filter_support(struct ctucan_hw_priv *priv)
> > +{
> > + union ctu_can_fd_filter_control_filter_status reg;
> > +
> > + reg.u32 = priv->read_reg(priv, CTU_CAN_FD_FILTER_CONTROL);
> > +
> > + if (reg.s.sfr)
> > + return true;
>
> return !!reg.s.sfr; ?
Replaced
> > +enum ctu_can_fd_tx_status_tx1s ctucan_hw_get_tx_status(struct
> > ctucan_hw_priv +*priv,
> > u8 buf)
>
> ...
>
> > + default:
> > + status = ~0;
> > + }
> > + return (enum ctu_can_fd_tx_status_tx1s)status;
> > +}
>
> Is ~0 in the enum?
Hmm enum ctu_can_fd_tx_status_tx1s is generated from IPXACT CTU CAN FD
specification.
The ~0 is there to catch fatal problems, to put something, which does not match
any enum value. Changing enum is problematic, it would require to change
generator or specification... It is to catch real problem in the code
implementation. So I am not sure what else I can do there.
> > + // TODO: use named constants for the command
>
> TODO...
>
> > +// TODO: AL_CAPTURE and ERROR_CAPTURE
Removed, I am not sure what was on the mind of colleagues who has placed this
TODO there.
> > +#if defined(__LITTLE_ENDIAN_BITFIELD) == defined(__BIG_ENDIAN_BITFIELD)
> > +# error __BIG_ENDIAN_BITFIELD or __LITTLE_ENDIAN_BITFIELD must be
> > defined. +#endif
> >
> :-).
> :
> > +// True if Core is transceiver of current frame
> > +#define CTU_CAN_FD_IS_TRANSMITTER(stat) (!!(stat).ts)
> > +
> > +// True if Core is receiver of current frame
> > +#define CTU_CAN_FD_IS_RECEIVER(stat) (!!(stat).s.rxs)
>
> Why not, documentation is nice. But it is in big contrast to other
> parts of code where there's no docs at all.
The ctucanfd_hw.h API should be documented for driver implementers.
ctucanfd_hw.c require to read real HW docs.
> > +struct ctucan_hw_priv;
> > +#ifndef ctucan_hw_priv
> > +struct ctucan_hw_priv {
> > + void __iomem *mem_base;
> > + u32 (*read_reg)(struct ctucan_hw_priv *priv,
> > + enum ctu_can_fd_can_registers reg);
> > + void (*write_reg)(struct ctucan_hw_priv *priv,
> > + enum ctu_can_fd_can_registers reg, u32 val);
> > +};
> > +#endif
>
> Should not be needed in kernel.
Old mechanism, actual user space tests can live without it.
> > +/**
> > + * ctucan_hw_read_rx_word - Reads one word of CAN Frame from RX FIFO
> > Buffer. + *
> > + * @priv: Private info
> > + *
> > + * Return: One wword of received frame
>
> Typo 'word'.
>
> > +++ b/drivers/net/can/ctucanfd/ctu_can_fd_regs.h
> > @@ -0,0 +1,971 @@
> > +
> > +/* This file is autogenerated, DO NOT EDIT! */
> > +
>
> Yay. How is that supposed to work after merge?
>
> Best regards,
> Pavel
On Thursday 22 of October 2020 13:39:52 Pavel Machek wrote:
> > @@ -12,4 +12,13 @@ config CAN_CTUCANFD
> >
> > if CAN_CTUCANFD
> >
> > +config CAN_CTUCANFD_PCI
> > + tristate "CTU CAN-FD IP core PCI/PCIe driver"
> > + depends on PCI
> > + help
> > + This driver adds PCI/PCIe support for CTU CAN-FD IP core.
> > + The project providing FPGA design for Intel EP4CGX15 based DB4CGX15
> > + PCIe board with PiKRON.com designed transceiver riser shield is
> > available + at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
> > +
> > endif
>
> Ok, now the if in the first patch makes sense. It can stay.
>
> And it is separate module, so EXPORT_SYMBOLs make sense. Ok.
I have changed dependency to not use if but
depends on CAN_CTUCANFD
> > +#ifndef PCI_VENDOR_ID_TEDIA
> > +#define PCI_VENDOR_ID_TEDIA 0x1760
> > +#endif
> >
> > +#define PCI_DEVICE_ID_TEDIA_CTUCAN_VER21 0xff00
>
> These should go elsewhere.
Kept for now, I will adapt to suggestions but I would
prefer to put it independent to allow easy backports
for meanwhile.
> > +#define PCI_DEVICE_ID_ALTERA_CTUCAN_TEST 0xCAFD
Test integration not in use removed.
>
> > +static bool use_msi = 1;
> > +static bool pci_use_second = 1;
>
> true?
Changed to true.
On Thursday 22 of October 2020 13:43:06 Pavel Machek wrote:
> Hi!
>
> > +++ b/drivers/net/can/ctucanfd/Kconfig
> > @@ -21,4 +21,15 @@ config CAN_CTUCANFD_PCI
> > PCIe board with PiKRON.com designed transceiver riser shield is
> > available at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
> >
> > +config CAN_CTUCANFD_PLATFORM
> > + tristate "CTU CAN-FD IP core platform (FPGA, SoC) driver"
> > + depends on OF || COMPILE_TEST
> > + help
>
> This is likely wrong, as it can enable config of CAN_CTUCANFD=M,
> CAN_CTUCANFD_PLATFORM=y, right?
Chanegd to depends on
> > @@ -8,3 +8,6 @@ ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o
> >
> > obj-$(CONFIG_CAN_CTUCANFD_PCI) += ctucanfd_pci.o
> > ctucanfd_pci-y := ctu_can_fd_pci.o
> > +
> > +obj-$(CONFIG_CAN_CTUCANFD_PLATFORM) += ctucanfd_platform.o
> > +ctucanfd_platform-y += ctu_can_fd_platform.o
>
> Can you simply add right object files directly?
I have done rename in many places to fullfill this single line.
Full rename in HDL would require to analyze 4k+ occurrences.
On Thursday 22 of October 2020 13:25:40 Pavel Machek wrote:
> On Thu 2020-10-22 10:36:21, Pavel Pisa wrote:
> > CTU CAN FD IP core documentation based on Martin Jeřábek's diploma theses
> > Open-source and Open-hardware CAN FD Protocol Support
> > https://dspace.cvut.cz/handle/10467/80366
> > .
> >
> > ---
> > .../ctu/FSM_TXT_Buffer_user.png | Bin 0 -> 174807 bytes
>
> Maybe picture should stay on website, somewhere. It is rather big for
> kernel sources.
I have invested time to redraw image in Inscape and do more
optimization to reduce 172K to 16K SVG.
> > +About SocketCAN
> > +---
> > +
> > +SocketCAN is a standard common interface for CAN devices in the Linux
> > +kernel. As the name suggests, the bus is accessed via sockets, similarly
> > +to common network devices. The reasoning behind this is in depth
> > +described in `Linux SocketCAN
> > <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Doc
> >umentation/networking/can.rst>`_. +In short, it offers a
> > +natural way to implement and work with higher layer protocols over CAN,
> > +in the same way as, e.g., UDP/IP over Ethernet.
>
> Drop? Or at least link directly to the file in kernel tree?
What is the best way to cross-reference RST documentation in Linux kernel
sources??
> > +Device probe
> > +
...
>
> Dunno. Is it suitable? This is supposed to be ctu-can documentation,
> not "how hardware works" docs.
I would be happy if it stays in our standalone build.
If it is problem for mainline I try to reduce text.
Help, suggestions etc. much appreciated.
Mr. Ille, Mr. Jerabek and others, please help there.
Same with checking for errors.
Thanks for your time (when you reached the end of the discussion),
Pavel
Re: [PATCH v6 3/6] can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.
Hello Pavel,
thanks for review.
For everybody: the amount of code, analyses etc. is really huge.
If you do not have time and consider this discussion as lost of your
time and or badwidth send me a note. I will remove your from the
recipients list and if you think that some lists should be omitted
as well, please give me notice too. Same if you want to receive
only final resolutions, patches when they pass through some
of the lists.
On Thursday 22 of October 2020 13:02:13 Pavel Machek wrote:
> Hi!
>
> > From: Martin Jerabek
> >
> > This driver adds support for the CTU CAN FD open-source IP core.
> > More documentation and core sources at project page
> > (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core).
> > The core integration to Xilinx Zynq system as platform driver
> > is available
> > (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top).
> > Implementation on Intel FGA based PCI Express board is available from
> > project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd).
>
> Is "FGA" a typo? Yes, it is.
Done, thanks for catching.
I really need to force some of other people from the project
and follow up project to read all original Matin Jerabek's
and mine texts. I am blind to many of these typos as I see
same text many times.
> Anyway, following link tells me:
>
> Project 'canbus/pcie-ctu_can_fd' was moved to
> 'canbus/pcie-ctucanfd'. Please update any links and bookmarks that may
> still have the old path. Fixing it in Kconfig is more important.
Done, move is result of some more steps to name unification.
> > +++ b/drivers/net/can/ctucanfd/Kconfig
> > @@ -0,0 +1,15 @@
> >
> > +if CAN_CTUCANFD
> > +
> > +endif
>
> Empty -> drop?
Considering as appropriate after other patches comments read.
If you have other idea for patches series build give me a hint.
> > +++ b/drivers/net/can/ctucanfd/Makefile
> > @@ -0,0 +1,7 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> >
> > +++ b/drivers/net/can/ctucanfd/ctu_can_fd.c
> > @@ -0,0 +1,1105 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
>
> Having Makefile and sources with different licenses is rather unusual.
Makefile changed to GPL-2.0-or-later.
I do not consider use of Linux specific Makefile outside
GPL 2 only Linux kernel tree. But C sources are important
for us even in userspace tests and possible future projects.
> > +static const char * const ctucan_state_strings[] = {
> > + "CAN_STATE_ERROR_ACTIVE",
> > + "CAN_STATE_ERROR_WARNING",
> > + "CAN_STATE_ERROR_PASSIVE",
> > + "CAN_STATE_BUS_OFF",
> > + "CAN_STATE_STOPPED",
> > + "CAN_STATE_SLEEPING"
> > +};
>
> Put this near function that uses this?
I prefer defines at start of the file, but I agree that in this
case it is different case and used only in ctucan_state_to_str .
I would prefer to move function up after array.
> > +/**
> > + * ctucan_set_bittiming - CAN set bit timing routine
> > + * @ndev: Pointer to net_device structure
> > + *
> > + * This is the driver set bittiming routine.
> > + * Return: 0 on success and failure value on error
> > + */
> >
> > +/**
> > + * ctucan_chip_start - This routine starts the driver
> > + * @ndev: Pointer to net_device structure
> > + *
> > + * This is the drivers start routine.
> > + *
> > + * Return: 0 on success and failure value on error
> > + */
>
> Good documentation is nice, but repeating "This routine starts the
> driver" in "This is the drivers start routine." is not too helpful.
OK, initially probably more or less placeholder to add more infomation.
I will remove it.
> > +/**
> > + * ctucan_start_xmit - Starts the transmission
> > + * @skb: sk_buff pointer that contains data to be Txed
> > + * @ndev: Pointer to net_device structure
> > + *
> > + * This function is invoked from upper layers to initiate transmission.
> > This + * function uses the next available free txbuf and populates their
> > fields to + * start the transmission.
> > + *
> > + * Return: %NETDEV_TX_OK on success and failure value on error
> > + */
>
> Based on other documentation, I'd expect this to return -ESOMETHING on
> error, but it returns NETDEV_TX_BUSY.
I add information about explicit error/need for postpone type.
> > + /* Check if the TX buffer is full */
> > + if (unlikely(!CTU_CAN_FD_TXTNF(ctu_can_get_status(>p {
> > + netif_stop_queue(ndev);
> > + netdev_err(ndev, "BUG!, no TXB free when queue awake!\n");
> > + return NETDEV_TX_BUSY;
> > + }
>
> You call stop_queue() without spinlock...
>
> > + spin_lock_irqsave(>tx_lock, flags);
> > +
> > + ctucan_hw_txt_set_rdy(>p, txb_id);
> > +
> > + priv->txb_head++;
> > +
> > + /* Check if all TX buffers are full */
> > + if (!CTU_CAN_FD_TXTNF(ctu_can_get_status(>p)))
> > + netif_stop_queue(ndev);
> > +
> > + spin_unlock_irqrestore(>tx_lock, flags);
>
> ...and then with spinlock held. One of them is buggy.
I did not feel it that way initially. But may it be there is a problem.
I expect that NET core does not invoke
Re: [PATCH v6 4/6] can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.
Hello Pavel, thanks for review. On Thursday 22 of October 2020 13:39:52 Pavel Machek wrote: > Hi! > > > @@ -12,4 +12,13 @@ config CAN_CTUCANFD > > > > if CAN_CTUCANFD > > > > +config CAN_CTUCANFD_PCI > > + tristate "CTU CAN-FD IP core PCI/PCIe driver" > > + depends on PCI > > + help > > + This driver adds PCI/PCIe support for CTU CAN-FD IP core. > > + The project providing FPGA design for Intel EP4CGX15 based DB4CGX15 > > + PCIe board with PiKRON.com designed transceiver riser shield is > > available + at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd . > > + > > endif > > Ok, now the if in the first patch makes sense. It can stay. > > And it is separate module, so EXPORT_SYMBOLs make sense. Ok. Great. > > +#ifndef PCI_VENDOR_ID_TEDIA > > +#define PCI_VENDOR_ID_TEDIA 0x1760 > > +#endif > > > > +#define PCI_DEVICE_ID_ALTERA_CTUCAN_TEST 0xCAFD > > +#define PCI_DEVICE_ID_TEDIA_CTUCAN_VER21 0xff00 > > These should go elsewhere. They should propagate somehow from https://pci-ids.ucw.cz/read/PC/1760/ff00 We have registered them long time ago. I am not sure what is right mechanism. > > +#ifndef PCI_VENDOR_ID_TEDIA > > +#define PCI_VENDOR_ID_TEDIA 0x1760 > > +#endif So this one should be known to kernel globally, but I would be happy if driver build even if global process to introduce define did not proceed end even backports would be required for long time until kernel including CTU CAN FD propagates into distributions, and industrial systems distributions lag often a lot > > +#define PCI_DEVICE_ID_ALTERA_CTUCAN_TEST 0xCAFD We drop this, I hope we have no system running old test version of the core integration before Tedia offered us to reserve some IDs (promissed that they would never use them in future) for us. > > +#define PCI_DEVICE_ID_TEDIA_CTUCAN_VER21 0xff00 This should propagate into kernel from registry or at least match registry. > > +static bool use_msi = 1; > > +static bool pci_use_second = 1; > > true? Done Best wishes, Pavel
Re: [PATCH v6 5/6] can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support.
Hello Pavel, thanks for review. On Thursday 22 of October 2020 13:43:06 Pavel Machek wrote: > Hi! > > > +++ b/drivers/net/can/ctucanfd/Kconfig > > @@ -21,4 +21,15 @@ config CAN_CTUCANFD_PCI > > PCIe board with PiKRON.com designed transceiver riser shield is > > available at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd . > > > > +config CAN_CTUCANFD_PLATFORM > > + tristate "CTU CAN-FD IP core platform (FPGA, SoC) driver" > > + depends on OF || COMPILE_TEST > > + help > > This is likely wrong, as it can enable config of CAN_CTUCANFD=M, > CAN_CTUCANFD_PLATFORM=y, right? My original code has not || COMPILE_TEST alternative. But I have been asked to add it On Sunday 16 of August 2020 01:28:13 Randy Dunlap wrote: > Can this be > depends on OF || COMPILE_TEST > ? I have send discussion later that I am not sure if it is right but followed suggestion. If there is no other reply now, I would drop || COMPILE_TEST. I believe that then it is correct for regular use. I ma not sure about all consequences of COMPILE_TEST missing. > > @@ -8,3 +8,6 @@ ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o > > > > obj-$(CONFIG_CAN_CTUCANFD_PCI) += ctucanfd_pci.o > > ctucanfd_pci-y := ctu_can_fd_pci.o > > + > > +obj-$(CONFIG_CAN_CTUCANFD_PLATFORM) += ctucanfd_platform.o > > +ctucanfd_platform-y += ctu_can_fd_platform.o > > Can you simply add right object files directly? This is more tough question. We have kept sources as ctu_can_fd.c, ctu_can_fd_hw.c etc. to produce final ctucanfd.ko which matches device tree entry etc. after name simplification now... So we move from underscores to ctucanfd on more places. So yes, we can rename ctu_can_fd.c to ctucanfd_drv.c + others keep final ctucanfd.ko and change to single file based objects ctucanfd_platform.c and ctucanfd_pci.c If you think that it worth to be redone, I would do that. It would disrupt sources history, may it be blames, merging etc... but I would invest effort into it if asked for. Best wishes, Pavel
Re: [PATCH v6 6/6] docs: ctucanfd: CTU CAN FD open-source IP core documentation.
Hello Pavel, thanks for review. As for the documentation, my current intention is to keep/maintain the common driver documentation for CTU CAN FD site and kernel source. The standalone driver documentation http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/driver_doc/ctucanfd-driver.html when the driver documentation moves to https://www.kernel.org/doc/html/latest/ we may consider to drop standalone. But resource are limited and keeping and maintaining sync between slightly different files is error prone. I run manual kdiff3 updates of both RST files because references to sources are different. On Thursday 22 of October 2020 13:25:40 Pavel Machek wrote: > On Thu 2020-10-22 10:36:21, Pavel Pisa wrote: > > CTU CAN FD IP core documentation based on Martin Jeřábek's diploma theses > > Open-source and Open-hardware CAN FD Protocol Support > > https://dspace.cvut.cz/handle/10467/80366 > > . > > > > --- > > .../ctu/FSM_TXT_Buffer_user.png | Bin 0 -> 174807 bytes > > Maybe picture should stay on website, somewhere. It is rather big for > kernel sources. My sense is that it is proffered that documentation is self-contained without embedded references to "untrusted" third party sites. But we try to do something with it. I try reduce size or switch to SVG, our actual source is PDF prepared by Ondrej Ille as part of CTU CAN FD IP core architecture. I probably redraw image in inscape with little worse graphics style, fonts, smoothness etc. but in smaller and simpler SVG file size format. I expect that use of original PDF in vector form would not help much. > > +About SocketCAN > > +--- > > + > > +SocketCAN is a standard common interface for CAN devices in the Linux > > +kernel. As the name suggests, the bus is accessed via sockets, similarly > > +to common network devices. The reasoning behind this is in depth > > +described in `Linux SocketCAN > > <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Doc > >umentation/networking/can.rst>`_. +In short, it offers a > > +natural way to implement and work with higher layer protocols over CAN, > > +in the same way as, e.g., UDP/IP over Ethernet. > > Drop? Or at least link directly to the file in kernel tree? Yes, this is another place where we need other diversion between standalone and kernel. I try to learn what is the right way to cross-reference Linux kernel manuals writtent n RST? If you can speedup it by hint/right done example I would be happy. > > +Device probe > > + > > + > > +Before going into detail about the structure of a CAN bus device driver, > > +let's reiterate how the kernel gets to know about the device at all. > > +Some buses, like PCI or PCIe, support device enumeration. That is, when > > +the system boots, it discovers all the devices on the bus and reads > > +their configuration. The kernel identifies the device via its vendor ID > > +and device ID, and if there is a driver registered for this identifier > > +combination, its probe method is invoked to populate the driver's > > +instance for the given hardware. A similar situation goes with USB, only > > +it allows for device hot-plug. > > + > > +The situation is different for peripherals which are directly embedded > > +in the SoC and connected to an internal system bus (AXI, APB, Avalon, > > +and others). These buses do not support enumeration, and thus the kernel > > +has to learn about the devices from elsewhere. This is exactly what the > > +Device Tree was made for. > > Dunno. Is it suitable? This is supposed to be ctu-can documentation, > not "how hardware works" docs. I think that this text is fully valid for standalone driver documentation, I understand that in the kernel tree this can be replaced by references to right places if we locate them. > > +Platform device driver > > +^^ > > + > > +In the case of Zynq, the core is connected via the AXI system bus, which > > +does not have enumeration support, and the device must be specified in > > +Device Tree. This kind of devices is called *platform device* in the > > +kernel and is handled by a *platform device driver*\ [1]_. > > + > > +A platform device driver provides the following things: > > + > > +- A *probe* function > > + > > +- A *remove* function > > + > > +- A table of *compatible* devices that the driver can handle > > + > > +The *probe* function is called exactly once when the device appears (or > > +the driver is loaded, whichever happens later). If there are more > > +devices handled by the same driver, the *probe* function is called for > > +each
[PATCH v6 0/6] CTU CAN FD open-source IP core SocketCAN driver, PCI, platform integration and documentation
This driver adds support for the CTU CAN FD open-source IP core. More documentation and core sources at project page (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). The core integration to Xilinx Zynq system as platform driver is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). Implementation on Intel FPGA based PCI Express board is available from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). The CTU CAN FD core emulation send for review for QEMU mainline. Development repository for QEMU emulation - ctu-canfd branch of https://gitlab.fel.cvut.cz/canbus/qemu-canbus More about CAN bus related projects used and developed at CTU FEE on the guidepost page http://canbus.pages.fel.cvut.cz/ . Martin Jerabek (1): can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part. Pavel Pisa (5): dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague. dt-bindings: net: can: binding for CTU CAN FD open-source IP core. can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support. can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support. docs: ctucanfd: CTU CAN FD open-source IP core documentation. The version 6 changes: - sent at 2020-10-22 - the driver has been tested with 5.9 bigendian MIPS kernel against QEMU CTU CAN FD model and correct behavior on PCIe virtual board for big-endian system passed - documentation updated to reflect inclusion of SocketCAN FD and CTU CAN FD functional model support into QEMU mainline - the integration for Cyclone V 5CSEMA4U23C6 based DE0-Nano-SoC Terasic board used for SkodaAuto research projects at our university has been clean up by its author (Jaroslav Beran) and published https://gitlab.fel.cvut.cz/canbus/intel-soc-ctucanfd - Xilinx Zynq Microzed MZ_APO based target for automatic test updated to Debian 10 base. The version 5 changes: - sent at 2020-08-15 - correct Kconfig formatting according to Randy Dunlap - silence warnings reported by make W=1 C=1 flags. Changes suggested by Jakub Kicinski - big thanks for core patch review by Pavel Machek resulting in more readability and formating updates - fix power management errors found by Pavel Machek - removed comments from d-t bindings as suggested by Rob Herring - selected ctu,ctucanfd-2 as alternative name to ctu,ctucanfd which allows to bind to actual major HDL core sources version 2.x if for some reason driver adaptation would not work on version read from the core - line length limit relaxed to 100 characters on some cases where it helps to readability The version 4 changes: - sent at 2020-08-04 - changes summary, 169 non-merge commits, 6 driver, 32 IP core sources enhancements and fixes, 58 tests in master and about additional 30 iso-testbench preparation branch. - convert device-tree binding documentation to YAML - QEMU model of CTU CAN FD IP core and generic extension of QEMU CAN bus emulation developed by Jan Charvat. - driver tested on QEMU emulated Malta big-endian MIPS platform and big endian-support fixed. - checkpatch from 5.4 kernel used to cleanup driver formatting - header files generated from IP core IP-Xact description updated to include protocol exception (pex) field. Mechanism to set it from the driver is not provided yet. The version 3 changes: - sent at 2019-12-21 - adapts device tree bindings documentation according to Rob Herring suggestions. - the driver has been separated to individual modules for core support, PCI bus integration and platform, SoC integration. - the FPGA design has been cleaned up and CAN protocol FSM redesigned by Ondrej Ille (the core redesign has been reason to pause attempts to driver submission) - the work from February 2019 on core, test framework and driver 1601 commits in total, 436 commits in the core sources, 144 commits in the driver, 151 documentation, 502 in tests. - not all continuous integration tests updated for latest design version yet https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/pipelines - Zynq hardware in the loop test show no issues for after driver PCI and platform separation and latest VHDL sources updates. - driver code has been periodically tested on 4.18.5-rt3 and 4.19 long term stable kernels. - test of the patches before submission is run on 5.4 kernel - the core has been integrated by Jaroslav Beran into Intel FPGA based SoC used in the tester developed for Skoda auto at Department of Measurement, Faculty of Electrical Engineering, Czech Technical University https://meas.fel.cvut.cz/ . He has contributed feedback and fixes to the project. The version 2 sent at 2019-02-27 The version 1 sent at 2019-02-22 Ondrej Ille has prepared the CTU CAN IP Core sources for new release. We are waiting with it for the driver review, our
[PATCH v6 5/6] can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support.
Platform bus adaptation for CTU CAN FD open-source IP core.
The core has been tested together with OpenCores SJA1000
modified to be CAN FD frames tolerant on MicroZed Zynq based
MZ_APO education kits designed by Petr Porazil from PiKRON.com
company. FPGA design
https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top.
The kit description at the Computer Architectures course pages
https://cw.fel.cvut.cz/wiki/courses/b35apo/documentation/mz_apo/start .
Kit carrier board and mechanics design source files
https://gitlab.com/pikron/projects/mz_apo/microzed_apo
The work is documented in Martin Jeřábek's diploma theses
Open-source and Open-hardware CAN FD Protocol Support
https://dspace.cvut.cz/handle/10467/80366
.
Signed-off-by: Pavel Pisa
Signed-off-by: Martin Jerabek
Signed-off-by: Ondrej Ille
---
drivers/net/can/ctucanfd/Kconfig | 11 ++
drivers/net/can/ctucanfd/Makefile | 3 +
.../net/can/ctucanfd/ctu_can_fd_platform.c| 142 ++
3 files changed, 156 insertions(+)
create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_platform.c
diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig
index fb4d3cda6885..01fcfe5873cc 100644
--- a/drivers/net/can/ctucanfd/Kconfig
+++ b/drivers/net/can/ctucanfd/Kconfig
@@ -21,4 +21,15 @@ config CAN_CTUCANFD_PCI
PCIe board with PiKRON.com designed transceiver riser shield is
available
at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
+config CAN_CTUCANFD_PLATFORM
+ tristate "CTU CAN-FD IP core platform (FPGA, SoC) driver"
+ depends on OF || COMPILE_TEST
+ help
+ The core has been tested together with OpenCores SJA1000
+ modified to be CAN FD frames tolerant on MicroZed Zynq based
+ MZ_APO education kits designed by Petr Porazil from PiKRON.com
+ company. FPGA design
https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top.
+ The kit description at the Computer Architectures course pages
+ https://cw.fel.cvut.cz/b182/courses/b35apo/documentation/mz_apo/start
.
+
endif
diff --git a/drivers/net/can/ctucanfd/Makefile
b/drivers/net/can/ctucanfd/Makefile
index eb945260952d..a77ca72d534e 100644
--- a/drivers/net/can/ctucanfd/Makefile
+++ b/drivers/net/can/ctucanfd/Makefile
@@ -8,3 +8,6 @@ ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o
obj-$(CONFIG_CAN_CTUCANFD_PCI) += ctucanfd_pci.o
ctucanfd_pci-y := ctu_can_fd_pci.o
+
+obj-$(CONFIG_CAN_CTUCANFD_PLATFORM) += ctucanfd_platform.o
+ctucanfd_platform-y += ctu_can_fd_platform.o
diff --git a/drivers/net/can/ctucanfd/ctu_can_fd_platform.c
b/drivers/net/can/ctucanfd/ctu_can_fd_platform.c
new file mode 100644
index ..c35b16b8566b
--- /dev/null
+++ b/drivers/net/can/ctucanfd/ctu_can_fd_platform.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/***
+ *
+ * CTU CAN FD IP Core
+ *
+ * Copyright (C) 2015-2018 Ondrej Ille FEE CTU
+ * Copyright (C) 2018-2020 Ondrej Ille self-funded
+ * Copyright (C) 2018-2019 Martin Jerabek FEE CTU
+ * Copyright (C) 2018-2020 Pavel Pisa FEE
CTU/self-funded
+ *
+ * Project advisors:
+ * Jiri Novak
+ * Pavel Pisa
+ *
+ * Department of Measurement (http://meas.fel.cvut.cz/)
+ * Faculty of Electrical Engineering (http://www.fel.cvut.cz)
+ * Czech Technical University(http://www.cvut.cz/)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
**/
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ctu_can_fd.h"
+
+#define DRV_NAME "ctucanfd"
+
+static void ctucan_platform_set_drvdata(struct device *dev,
+ struct net_device *ndev)
+{
+ struct platform_device *pdev = container_of(dev, struct platform_device,
+ dev);
+
+ platform_set_drvdata(pdev, ndev);
+}
+
+/**
+ * ctucan_platform_probe - Platform registration call
+ * @pdev: Handle to the platform device structure
+ *
+ * This function does all the memory allocation and registration for the CAN
+ * device.
+ *
+ * Return: 0 on success and failure value on error
+ */
+static int ctucan_platform_probe(struct platform_device *pdev)
+{
+ struct resource *res; /* IO mem resources */
+ struct device *dev = >dev;
+ void __iomem *addr;
+
[PATCH v6 4/6] can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.
PCI bus adaptation for CTU CAN FD open-source IP core.
The project providing FPGA design for Intel EP4CGX15 based DB4CGX15
PCIe board with PiKRON.com designed transceiver riser shield is available
at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
Signed-off-by: Pavel Pisa
Signed-off-by: Martin Jerabek
Signed-off-by: Ondrej Ille
---
drivers/net/can/ctucanfd/Kconfig | 9 +
drivers/net/can/ctucanfd/Makefile | 3 +
drivers/net/can/ctucanfd/ctu_can_fd_pci.c | 314 ++
3 files changed, 326 insertions(+)
create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_pci.c
diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig
index b6d47bba7150..fb4d3cda6885 100644
--- a/drivers/net/can/ctucanfd/Kconfig
+++ b/drivers/net/can/ctucanfd/Kconfig
@@ -12,4 +12,13 @@ config CAN_CTUCANFD
if CAN_CTUCANFD
+config CAN_CTUCANFD_PCI
+ tristate "CTU CAN-FD IP core PCI/PCIe driver"
+ depends on PCI
+ help
+ This driver adds PCI/PCIe support for CTU CAN-FD IP core.
+ The project providing FPGA design for Intel EP4CGX15 based DB4CGX15
+ PCIe board with PiKRON.com designed transceiver riser shield is
available
+ at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
+
endif
diff --git a/drivers/net/can/ctucanfd/Makefile
b/drivers/net/can/ctucanfd/Makefile
index 8d47008d0076..eb945260952d 100644
--- a/drivers/net/can/ctucanfd/Makefile
+++ b/drivers/net/can/ctucanfd/Makefile
@@ -5,3 +5,6 @@
obj-$(CONFIG_CAN_CTUCANFD) := ctucanfd.o
ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o
+
+obj-$(CONFIG_CAN_CTUCANFD_PCI) += ctucanfd_pci.o
+ctucanfd_pci-y := ctu_can_fd_pci.o
diff --git a/drivers/net/can/ctucanfd/ctu_can_fd_pci.c
b/drivers/net/can/ctucanfd/ctu_can_fd_pci.c
new file mode 100644
index ..c4542eac2747
--- /dev/null
+++ b/drivers/net/can/ctucanfd/ctu_can_fd_pci.c
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/***
+ *
+ * CTU CAN FD IP Core
+ *
+ * Copyright (C) 2015-2018 Ondrej Ille FEE CTU
+ * Copyright (C) 2018-2020 Ondrej Ille self-funded
+ * Copyright (C) 2018-2019 Martin Jerabek FEE CTU
+ * Copyright (C) 2018-2020 Pavel Pisa FEE
CTU/self-funded
+ *
+ * Project advisors:
+ * Jiri Novak
+ * Pavel Pisa
+ *
+ * Department of Measurement (http://meas.fel.cvut.cz/)
+ * Faculty of Electrical Engineering (http://www.fel.cvut.cz)
+ * Czech Technical University(http://www.cvut.cz/)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
**/
+
+#include
+#include
+
+#include "ctu_can_fd.h"
+
+#define DRV_NAME "ctucanfd_pci"
+
+#ifndef PCI_DEVICE_DATA
+#define PCI_DEVICE_DATA(vend, dev, data) \
+.vendor = PCI_VENDOR_ID_##vend, \
+.device = PCI_DEVICE_ID_##vend##_##dev, \
+.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, 0, 0, \
+.driver_data = (kernel_ulong_t)(data)
+#endif
+#ifndef PCI_VENDOR_ID_TEDIA
+#define PCI_VENDOR_ID_TEDIA 0x1760
+#endif
+
+#define PCI_DEVICE_ID_ALTERA_CTUCAN_TEST 0xCAFD
+#define PCI_DEVICE_ID_TEDIA_CTUCAN_VER21 0xff00
+
+#define CTUCAN_BAR0_CTUCAN_ID 0x
+#define CTUCAN_BAR0_CRA_BASE 0x4000
+#define CYCLONE_IV_CRA_A2P_IE (0x0050)
+
+#define CTUCAN_WITHOUT_CTUCAN_ID 0
+#define CTUCAN_WITH_CTUCAN_ID 1
+
+static bool use_msi = 1;
+module_param(use_msi, bool, 0444);
+MODULE_PARM_DESC(use_msi, "PCIe implementation use MSI interrupts. Default: 1
(yes)");
+
+static bool pci_use_second = 1;
+module_param(pci_use_second, bool, 0444);
+MODULE_PARM_DESC(pci_use_second, "Use the second CAN core on PCIe card.
Default: 1 (yes)");
+
+struct ctucan_pci_board_data {
+ void __iomem *bar0_base;
+ void __iomem *cra_base;
+ void __iomem *bar1_base;
+ struct list_head ndev_list_head;
+ int use_msi;
+};
+
+static struct ctucan_pci_board_data *ctucan_pci_get_bdata(struct pci_dev *pdev)
+{
+ return (struct ctucan_pci_board_data *)pci_get_drvdata(pdev);
+}
+
+static void ctucan_pci_set_drvdata(struct device *dev,
+ struct net_device *ndev)
+{
+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
+ struct ctucan_priv *priv = netdev_priv(ndev);
+ struct ctucan_pci_board_data *bdata = ctucan_pci_get_bdata(pdev);
+
+ list_add(>peers_on_pdev, >ndev_list_head);
+ priv-
[PATCH v6 3/6] can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.
From: Martin Jerabek This driver adds support for the CTU CAN FD open-source IP core. More documentation and core sources at project page (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). The core integration to Xilinx Zynq system as platform driver is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). Implementation on Intel FGA based PCI Express board is available from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). More about CAN bus related projects used and developed at CTU FEE at http://canbus.pages.fel.cvut.cz/ . Signed-off-by: Martin Jerabek Signed-off-by: Ondrej Ille Signed-off-by: Pavel Pisa --- drivers/net/can/Kconfig |1 + drivers/net/can/Makefile|1 + drivers/net/can/ctucanfd/Kconfig| 15 + drivers/net/can/ctucanfd/Makefile |7 + drivers/net/can/ctucanfd/ctu_can_fd.c | 1105 +++ drivers/net/can/ctucanfd/ctu_can_fd.h | 87 ++ drivers/net/can/ctucanfd/ctu_can_fd_frame.h | 189 drivers/net/can/ctucanfd/ctu_can_fd_hw.c| 790 + drivers/net/can/ctucanfd/ctu_can_fd_hw.h| 916 +++ drivers/net/can/ctucanfd/ctu_can_fd_regs.h | 971 10 files changed, 4082 insertions(+) create mode 100644 drivers/net/can/ctucanfd/Kconfig create mode 100644 drivers/net/can/ctucanfd/Makefile create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd.c create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd.h create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_frame.h create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_hw.c create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_hw.h create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_regs.h diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 17c166cc8482..458afc4b81f2 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -168,6 +168,7 @@ config PCH_CAN source "drivers/net/can/c_can/Kconfig" source "drivers/net/can/cc770/Kconfig" +source "drivers/net/can/ctucanfd/Kconfig" source "drivers/net/can/ifi_canfd/Kconfig" source "drivers/net/can/m_can/Kconfig" source "drivers/net/can/mscan/Kconfig" diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile index 22164300122d..28b39cd122f0 100644 --- a/drivers/net/can/Makefile +++ b/drivers/net/can/Makefile @@ -21,6 +21,7 @@ obj-y += softing/ obj-$(CONFIG_CAN_AT91) += at91_can.o obj-$(CONFIG_CAN_CC770)+= cc770/ obj-$(CONFIG_CAN_C_CAN)+= c_can/ +obj-$(CONFIG_CAN_CTUCANFD) += ctucanfd/ obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o obj-$(CONFIG_CAN_GRCAN)+= grcan.o obj-$(CONFIG_CAN_IFI_CANFD)+= ifi_canfd/ diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig new file mode 100644 index ..b6d47bba7150 --- /dev/null +++ b/drivers/net/can/ctucanfd/Kconfig @@ -0,0 +1,15 @@ +config CAN_CTUCANFD + tristate "CTU CAN-FD IP core" + help + This driver adds support for the CTU CAN FD open-source IP core. + More documentation and core sources at project page + (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). + The core integration to Xilinx Zynq system as platform driver + is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). + Implementation on Intel FPGA-based PCI Express board is available + from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). + Guidepost CTU FEE CAN bus projects page http://canbus.pages.fel.cvut.cz/ . + +if CAN_CTUCANFD + +endif diff --git a/drivers/net/can/ctucanfd/Makefile b/drivers/net/can/ctucanfd/Makefile new file mode 100644 index ..8d47008d0076 --- /dev/null +++ b/drivers/net/can/ctucanfd/Makefile @@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Makefile for the CTU CAN-FD IP module drivers +# + +obj-$(CONFIG_CAN_CTUCANFD) := ctucanfd.o +ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o diff --git a/drivers/net/can/ctucanfd/ctu_can_fd.c b/drivers/net/can/ctucanfd/ctu_can_fd.c new file mode 100644 index ..c8953627a9f9 --- /dev/null +++ b/drivers/net/can/ctucanfd/ctu_can_fd.c @@ -0,0 +1,1105 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/*** + * + * CTU CAN FD IP Core + * + * Copyright (C) 2015-2018 Ondrej Ille FEE CTU + * Copyright (C) 2018-2020 Ondrej Ille self-funded + * Copyright (C) 2018-2019 Martin Jerabek FEE CTU + * Copyright (C) 2018-2020 Pavel Pisa FEE CTU/self-funded + * + * Project advisors: + * Jiri Novak + * Pavel Pisa + * + * Department of Measurement (http://meas.fel.cvut.cz/) + * Faculty of Electrical Engineering (http://www.fel.cvut.cz) + * Czech Technical University(http://www
[PATCH v6 1/6] dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague.
The Czech Technical University in Prague (CTU) is one of the biggest and oldest (founded 1707) technical universities in Europe. The abbreviation in Czech language is ČVUT according to official name in Czech language České vysoké učení technické v Praze The English translation The Czech Technical University in Prague The university pages in English https://www.cvut.cz/en Signed-off-by: Pavel Pisa Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 967e78c5ec0a..dedb10f1b250 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -215,6 +215,8 @@ patternProperties: description: Hangzhou C-SKY Microsystems Co., Ltd "^csq,.*": description: Shenzen Chuangsiqi Technology Co.,Ltd. + "^ctu,.*": +description: Czech Technical University in Prague "^cubietech,.*": description: Cubietech, Ltd. "^cypress,.*": -- 2.20.1
[PATCH v6 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
The device-tree bindings for open-source/open-hardware CAN FD IP core
designed at the Czech Technical University in Prague.
CTU CAN FD IP core and other CTU CAN bus related projects
listing and documentation page
http://canbus.pages.fel.cvut.cz/
Signed-off-by: Pavel Pisa
Reviewed-by: Rob Herring
---
.../bindings/net/can/ctu,ctucanfd.yaml| 63 +++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
diff --git a/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
new file mode 100644
index ..5113bb419ec1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%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
+ - Ondrej Ille
+ - Martin Jerabek
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: ctu,ctucanfd-2
+ - const: ctu,ctucanfd
+ - const: ctu,ctucanfd
+
+ reg:
+maxItems: 1
+
+ interrupts:
+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@43c3 {
+ compatible = "ctu,ctucanfd";
+ interrupts = <0 30 4>;
+ clocks = < 15>;
+ reg = <0x43c3 0x1>;
+};
--
2.20.1
Re: [PATCH v5 5/6] can: ctucanfd: CTU CAN FD open-source IP core - platform and next steps and mainlining chances
Hello Randy and Rob, thanks much for review, I have corrected FPGA spelling and binding YAML license. On Sunday 16 of August 2020 01:28:13 Randy Dunlap wrote: > On 8/15/20 12:43 PM, Pavel Pisa wrote: > > diff --git a/drivers/net/can/ctucanfd/Kconfig > > b/drivers/net/can/ctucanfd/Kconfig index e1636373628a..a8c9cc38f216 > > 100644 > > --- a/drivers/net/can/ctucanfd/Kconfig > > +++ b/drivers/net/can/ctucanfd/Kconfig > > @@ -21,4 +21,15 @@ config CAN_CTUCANFD_PCI > > PCIe board with PiKRON.com designed transceiver riser shield is > > available at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd . > > > > +config CAN_CTUCANFD_PLATFORM > > + tristate "CTU CAN-FD IP core platform (FPGA, SoC) driver" > > + depends on OF > > Can this be > depends on OF || COMPILE_TEST > ? I am not sure for this change. Is it ensured/documented somewhere that header files provide dummy definition such way, that OF drivers builds even if OF support is disabled? If I remember well, CTU CAN FD OF module build fails if attempted in the frame of native x86_64 build where OF has been disabled. Does COMPILE_TEST ensure that such build succeeds. As for the next steps, I expect that without any review of Marc Kleine-Budde or Wolfgang Grandegger from initial attempt for submission from February 2019, we are at the end of the road now. If there is confirmed preference, I would shorten license headers in the C files, but I am not sure if SPDX-License-Identifier is recognized by copyright law and because code and CTU CAN FD IP can be used outside of Linux kernel by others, we would like to keep legally binding preamble. It is reduced by not listing address to obtain complete GPL-2.0 from anyway. And change of preamble requires to update main repository, because header files are generated from IP core IPXACT definition by Python based tools. I am aware of only one other suggestion not followed yet and it is separation of part of ctucan_tx_interrupt() function into new one suggested by Pavel Machek. I agree that function length of 108 lines is big. When blank lines are removed we are on 68 lines and 28 lines are switch statement. The function consist of two nested loops. External one required to ensure no lost interrupt when edge triggered delivery or implementation is used. For me personally, it is more readable in the actual format then to separate and propagate local variables to another function. And particular function code received only formatting and ctu_can_fd_ -> ctucan_hw_ rename in past year so it is tested many/many times by manual PCI test and automated Zynq tests. Each of the following pipelines which contains two jobs ands by test of FPGA design and driver build and tests on real HW https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top/pipelines You can go through years of the testing and development back. So I have even tendency to not shuffle code which does not result in indisputable better readability and breaks more than year of unmodified code successful (pass) test result line and confidence. Because I understand that you all are loaded a lot I expect that after ACK/review-by by Rob, there is no need to send v6 to devicet...@vger.kernel.org I am not sure about cross-post to net...@vger.kernel.org linux-kernel@vger.kernel.org when the progress is stuck on linux-...@vger.kernel.org Problem is that linux-can seems to eat core driver patch, probably because it is too long. Thanks to all for patience and if somebody does want to be loaded by minor updates, resends and pings to linux-can, send me note to not bother you again. Thanks for your time, Pavel PS: I would be available on Drew Fustini's LPC 2020 BoF: upstream drivers for open source FPGA SoC peripherals today. If there is interrest I can provide some information and show some overview and results.
[PATCH v5 1/6] dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague.
The Czech Technical University in Prague (CTU) is one of the biggest and oldest (founded 1707) technical universities in Europe. The abbreviation in Czech language is ČVUT according to official name in Czech language České vysoké učení technické v Praze The English translation The Czech Technical University in Prague The university pages in English https://www.cvut.cz/en Signed-off-by: Pavel Pisa --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 967e78c5ec0a..dedb10f1b250 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -215,6 +215,8 @@ patternProperties: description: Hangzhou C-SKY Microsystems Co., Ltd "^csq,.*": description: Shenzen Chuangsiqi Technology Co.,Ltd. + "^ctu,.*": +description: Czech Technical University in Prague "^cubietech,.*": description: Cubietech, Ltd. "^cypress,.*": -- 2.20.1
[PATCH v5 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
The device-tree bindings for open-source/open-hardware CAN FD IP core
designed at the Czech Technical University in Prague.
CTU CAN FD IP core and other CTU CAN bus related projects
listing and documentation page
http://canbus.pages.fel.cvut.cz/
Signed-off-by: Pavel Pisa
---
.../bindings/net/can/ctu,ctucanfd.yaml| 63 +++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
diff --git a/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
new file mode 100644
index ..6fa42112bb58
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
@@ -0,0 +1,63 @@
+# 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
+ - Ondrej Ille
+ - Martin Jerabek
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: ctu,ctucanfd-2
+ - const: ctu,ctucanfd
+ - const: ctu,ctucanfd
+
+ reg:
+maxItems: 1
+
+ interrupts:
+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@43c3 {
+ compatible = "ctu,ctucanfd";
+ interrupts = <0 30 4>;
+ clocks = < 15>;
+ reg = <0x43c3 0x1>;
+};
--
2.20.1
[PATCH v5 3/6] can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.
From: Martin Jerabek This driver adds support for the CTU CAN FD open-source IP core. More documentation and core sources at project page (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). The core integration to Xilinx Zynq system as platform driver is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). Implementation on Intel FGA based PCI Express board is available from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). More about CAN bus related projects used and developed at CTU FEE at http://canbus.pages.fel.cvut.cz/ . Signed-off-by: Martin Jerabek Signed-off-by: Ondrej Ille Signed-off-by: Pavel Pisa --- drivers/net/can/Kconfig |1 + drivers/net/can/Makefile|1 + drivers/net/can/ctucanfd/Kconfig| 15 + drivers/net/can/ctucanfd/Makefile |7 + drivers/net/can/ctucanfd/ctu_can_fd.c | 1105 +++ drivers/net/can/ctucanfd/ctu_can_fd.h | 87 ++ drivers/net/can/ctucanfd/ctu_can_fd_frame.h | 189 drivers/net/can/ctucanfd/ctu_can_fd_hw.c| 790 + drivers/net/can/ctucanfd/ctu_can_fd_hw.h| 916 +++ drivers/net/can/ctucanfd/ctu_can_fd_regs.h | 971 10 files changed, 4082 insertions(+) create mode 100644 drivers/net/can/ctucanfd/Kconfig create mode 100644 drivers/net/can/ctucanfd/Makefile create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd.c create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd.h create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_frame.h create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_hw.c create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_hw.h create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_regs.h diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig index 17c166cc8482..458afc4b81f2 100644 --- a/drivers/net/can/Kconfig +++ b/drivers/net/can/Kconfig @@ -168,6 +168,7 @@ config PCH_CAN source "drivers/net/can/c_can/Kconfig" source "drivers/net/can/cc770/Kconfig" +source "drivers/net/can/ctucanfd/Kconfig" source "drivers/net/can/ifi_canfd/Kconfig" source "drivers/net/can/m_can/Kconfig" source "drivers/net/can/mscan/Kconfig" diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile index 22164300122d..28b39cd122f0 100644 --- a/drivers/net/can/Makefile +++ b/drivers/net/can/Makefile @@ -21,6 +21,7 @@ obj-y += softing/ obj-$(CONFIG_CAN_AT91) += at91_can.o obj-$(CONFIG_CAN_CC770)+= cc770/ obj-$(CONFIG_CAN_C_CAN)+= c_can/ +obj-$(CONFIG_CAN_CTUCANFD) += ctucanfd/ obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o obj-$(CONFIG_CAN_GRCAN)+= grcan.o obj-$(CONFIG_CAN_IFI_CANFD)+= ifi_canfd/ diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig new file mode 100644 index ..d8da44d7f926 --- /dev/null +++ b/drivers/net/can/ctucanfd/Kconfig @@ -0,0 +1,15 @@ +config CAN_CTUCANFD + tristate "CTU CAN-FD IP core" + help + This driver adds support for the CTU CAN FD open-source IP core. + More documentation and core sources at project page + (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). + The core integration to Xilinx Zynq system as platform driver + is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). + Implementation on Intel FGA based PCI Express board is available + from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). + Guidepost CTU FEE CAN bus projects page http://canbus.pages.fel.cvut.cz/ . + +if CAN_CTUCANFD + +endif diff --git a/drivers/net/can/ctucanfd/Makefile b/drivers/net/can/ctucanfd/Makefile new file mode 100644 index ..8d47008d0076 --- /dev/null +++ b/drivers/net/can/ctucanfd/Makefile @@ -0,0 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Makefile for the CTU CAN-FD IP module drivers +# + +obj-$(CONFIG_CAN_CTUCANFD) := ctucanfd.o +ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o diff --git a/drivers/net/can/ctucanfd/ctu_can_fd.c b/drivers/net/can/ctucanfd/ctu_can_fd.c new file mode 100644 index ..c8953627a9f9 --- /dev/null +++ b/drivers/net/can/ctucanfd/ctu_can_fd.c @@ -0,0 +1,1105 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/*** + * + * CTU CAN FD IP Core + * + * Copyright (C) 2015-2018 Ondrej Ille FEE CTU + * Copyright (C) 2018-2020 Ondrej Ille self-funded + * Copyright (C) 2018-2019 Martin Jerabek FEE CTU + * Copyright (C) 2018-2020 Pavel Pisa FEE CTU/self-funded + * + * Project advisors: + * Jiri Novak + * Pavel Pisa + * + * Department of Measurement (http://meas.fel.cvut.cz/) + * Faculty of Electrical Engineering (http://www.fel.cvut.cz) + * Czech Technical University(http://www
[PATCH v5 4/6] can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.
PCI bus adaptation for CTU CAN FD open-source IP core.
The project providing FPGA design for Intel EP4CGX15 based DB4CGX15
PCIe board with PiKRON.com designed transceiver riser shield is available
at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
Signed-off-by: Pavel Pisa
Signed-off-by: Martin Jerabek
Signed-off-by: Ondrej Ille
---
drivers/net/can/ctucanfd/Kconfig | 9 +
drivers/net/can/ctucanfd/Makefile | 3 +
drivers/net/can/ctucanfd/ctu_can_fd_pci.c | 314 ++
3 files changed, 326 insertions(+)
create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_pci.c
diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig
index d8da44d7f926..e1636373628a 100644
--- a/drivers/net/can/ctucanfd/Kconfig
+++ b/drivers/net/can/ctucanfd/Kconfig
@@ -12,4 +12,13 @@ config CAN_CTUCANFD
if CAN_CTUCANFD
+config CAN_CTUCANFD_PCI
+ tristate "CTU CAN-FD IP core PCI/PCIe driver"
+ depends on PCI
+ help
+ This driver adds PCI/PCIe support for CTU CAN-FD IP core.
+ The project providing FPGA design for Intel EP4CGX15 based DB4CGX15
+ PCIe board with PiKRON.com designed transceiver riser shield is
available
+ at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
+
endif
diff --git a/drivers/net/can/ctucanfd/Makefile
b/drivers/net/can/ctucanfd/Makefile
index 8d47008d0076..eb945260952d 100644
--- a/drivers/net/can/ctucanfd/Makefile
+++ b/drivers/net/can/ctucanfd/Makefile
@@ -5,3 +5,6 @@
obj-$(CONFIG_CAN_CTUCANFD) := ctucanfd.o
ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o
+
+obj-$(CONFIG_CAN_CTUCANFD_PCI) += ctucanfd_pci.o
+ctucanfd_pci-y := ctu_can_fd_pci.o
diff --git a/drivers/net/can/ctucanfd/ctu_can_fd_pci.c
b/drivers/net/can/ctucanfd/ctu_can_fd_pci.c
new file mode 100644
index ..c4542eac2747
--- /dev/null
+++ b/drivers/net/can/ctucanfd/ctu_can_fd_pci.c
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/***
+ *
+ * CTU CAN FD IP Core
+ *
+ * Copyright (C) 2015-2018 Ondrej Ille FEE CTU
+ * Copyright (C) 2018-2020 Ondrej Ille self-funded
+ * Copyright (C) 2018-2019 Martin Jerabek FEE CTU
+ * Copyright (C) 2018-2020 Pavel Pisa FEE
CTU/self-funded
+ *
+ * Project advisors:
+ * Jiri Novak
+ * Pavel Pisa
+ *
+ * Department of Measurement (http://meas.fel.cvut.cz/)
+ * Faculty of Electrical Engineering (http://www.fel.cvut.cz)
+ * Czech Technical University(http://www.cvut.cz/)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
**/
+
+#include
+#include
+
+#include "ctu_can_fd.h"
+
+#define DRV_NAME "ctucanfd_pci"
+
+#ifndef PCI_DEVICE_DATA
+#define PCI_DEVICE_DATA(vend, dev, data) \
+.vendor = PCI_VENDOR_ID_##vend, \
+.device = PCI_DEVICE_ID_##vend##_##dev, \
+.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, 0, 0, \
+.driver_data = (kernel_ulong_t)(data)
+#endif
+#ifndef PCI_VENDOR_ID_TEDIA
+#define PCI_VENDOR_ID_TEDIA 0x1760
+#endif
+
+#define PCI_DEVICE_ID_ALTERA_CTUCAN_TEST 0xCAFD
+#define PCI_DEVICE_ID_TEDIA_CTUCAN_VER21 0xff00
+
+#define CTUCAN_BAR0_CTUCAN_ID 0x
+#define CTUCAN_BAR0_CRA_BASE 0x4000
+#define CYCLONE_IV_CRA_A2P_IE (0x0050)
+
+#define CTUCAN_WITHOUT_CTUCAN_ID 0
+#define CTUCAN_WITH_CTUCAN_ID 1
+
+static bool use_msi = 1;
+module_param(use_msi, bool, 0444);
+MODULE_PARM_DESC(use_msi, "PCIe implementation use MSI interrupts. Default: 1
(yes)");
+
+static bool pci_use_second = 1;
+module_param(pci_use_second, bool, 0444);
+MODULE_PARM_DESC(pci_use_second, "Use the second CAN core on PCIe card.
Default: 1 (yes)");
+
+struct ctucan_pci_board_data {
+ void __iomem *bar0_base;
+ void __iomem *cra_base;
+ void __iomem *bar1_base;
+ struct list_head ndev_list_head;
+ int use_msi;
+};
+
+static struct ctucan_pci_board_data *ctucan_pci_get_bdata(struct pci_dev *pdev)
+{
+ return (struct ctucan_pci_board_data *)pci_get_drvdata(pdev);
+}
+
+static void ctucan_pci_set_drvdata(struct device *dev,
+ struct net_device *ndev)
+{
+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
+ struct ctucan_priv *priv = netdev_priv(ndev);
+ struct ctucan_pci_board_data *bdata = ctucan_pci_get_bdata(pdev);
+
+ list_add(>peers_on_pdev, >ndev_list_head);
+ priv-
[PATCH v5 5/6] can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support.
Platform bus adaptation for CTU CAN FD open-source IP core.
The core has been tested together with OpenCores SJA1000
modified to be CAN FD frames tolerant on MicroZed Zynq based
MZ_APO education kits designed by Petr Porazil from PiKRON.com
company. FPGA design
https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top.
The kit description at the Computer Architectures course pages
https://cw.fel.cvut.cz/wiki/courses/b35apo/documentation/mz_apo/start .
Kit carrier board and mechanics design source files
https://gitlab.com/pikron/projects/mz_apo/microzed_apo
The work is documented in Martin Jeřábek's diploma theses
Open-source and Open-hardware CAN FD Protocol Support
https://dspace.cvut.cz/handle/10467/80366
.
Signed-off-by: Pavel Pisa
Signed-off-by: Martin Jerabek
Signed-off-by: Ondrej Ille
---
drivers/net/can/ctucanfd/Kconfig | 11 ++
drivers/net/can/ctucanfd/Makefile | 3 +
.../net/can/ctucanfd/ctu_can_fd_platform.c| 142 ++
3 files changed, 156 insertions(+)
create mode 100644 drivers/net/can/ctucanfd/ctu_can_fd_platform.c
diff --git a/drivers/net/can/ctucanfd/Kconfig b/drivers/net/can/ctucanfd/Kconfig
index e1636373628a..a8c9cc38f216 100644
--- a/drivers/net/can/ctucanfd/Kconfig
+++ b/drivers/net/can/ctucanfd/Kconfig
@@ -21,4 +21,15 @@ config CAN_CTUCANFD_PCI
PCIe board with PiKRON.com designed transceiver riser shield is
available
at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
+config CAN_CTUCANFD_PLATFORM
+ tristate "CTU CAN-FD IP core platform (FPGA, SoC) driver"
+ depends on OF
+ help
+ The core has been tested together with OpenCores SJA1000
+ modified to be CAN FD frames tolerant on MicroZed Zynq based
+ MZ_APO education kits designed by Petr Porazil from PiKRON.com
+ company. FPGA design
https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top.
+ The kit description at the Computer Architectures course pages
+ https://cw.fel.cvut.cz/b182/courses/b35apo/documentation/mz_apo/start
.
+
endif
diff --git a/drivers/net/can/ctucanfd/Makefile
b/drivers/net/can/ctucanfd/Makefile
index eb945260952d..a77ca72d534e 100644
--- a/drivers/net/can/ctucanfd/Makefile
+++ b/drivers/net/can/ctucanfd/Makefile
@@ -8,3 +8,6 @@ ctucanfd-y := ctu_can_fd.o ctu_can_fd_hw.o
obj-$(CONFIG_CAN_CTUCANFD_PCI) += ctucanfd_pci.o
ctucanfd_pci-y := ctu_can_fd_pci.o
+
+obj-$(CONFIG_CAN_CTUCANFD_PLATFORM) += ctucanfd_platform.o
+ctucanfd_platform-y += ctu_can_fd_platform.o
diff --git a/drivers/net/can/ctucanfd/ctu_can_fd_platform.c
b/drivers/net/can/ctucanfd/ctu_can_fd_platform.c
new file mode 100644
index ..c35b16b8566b
--- /dev/null
+++ b/drivers/net/can/ctucanfd/ctu_can_fd_platform.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/***
+ *
+ * CTU CAN FD IP Core
+ *
+ * Copyright (C) 2015-2018 Ondrej Ille FEE CTU
+ * Copyright (C) 2018-2020 Ondrej Ille self-funded
+ * Copyright (C) 2018-2019 Martin Jerabek FEE CTU
+ * Copyright (C) 2018-2020 Pavel Pisa FEE
CTU/self-funded
+ *
+ * Project advisors:
+ * Jiri Novak
+ * Pavel Pisa
+ *
+ * Department of Measurement (http://meas.fel.cvut.cz/)
+ * Faculty of Electrical Engineering (http://www.fel.cvut.cz)
+ * Czech Technical University(http://www.cvut.cz/)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
**/
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ctu_can_fd.h"
+
+#define DRV_NAME "ctucanfd"
+
+static void ctucan_platform_set_drvdata(struct device *dev,
+ struct net_device *ndev)
+{
+ struct platform_device *pdev = container_of(dev, struct platform_device,
+ dev);
+
+ platform_set_drvdata(pdev, ndev);
+}
+
+/**
+ * ctucan_platform_probe - Platform registration call
+ * @pdev: Handle to the platform device structure
+ *
+ * This function does all the memory allocation and registration for the CAN
+ * device.
+ *
+ * Return: 0 on success and failure value on error
+ */
+static int ctucan_platform_probe(struct platform_device *pdev)
+{
+ struct resource *res; /* IO mem resources */
+ struct device *dev = >dev;
+ void __iomem *addr;
+ int
[PATCH v5 0/6] CTU CAN FD open-source IP core SocketCAN driver, PCI, platform integration and documentation
From: Pavel Pisa This driver adds support for the CTU CAN FD open-source IP core. More documentation and core sources at project page (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). The core integration to Xilinx Zynq system as platform driver is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). Implementation on Intel FPGA based PCI Express board is available from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). The CTU CAN FD core emulation send for review for QEMU mainline. Development repository for QEMU emulation - ctu-canfd branch of https://gitlab.fel.cvut.cz/canbus/qemu-canbus More about CAN bus related projects used and developed at CTU FEE on the guidepost page http://canbus.pages.fel.cvut.cz/ . Martin Jerabek (1): can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part. Pavel Pisa (5): dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague. dt-bindings: net: can: binding for CTU CAN FD open-source IP core. can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support. can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support. docs: ctucanfd: CTU CAN FD open-source IP core documentation. The version 5 changes: - sent at 2020-08-15 - correct Kconfig formatting according to Randy Dunlap - silence warnings reported by make W=1 C=1 flags. Changes suggested by Jakub Kicinski - big thanks for core patch review by Pavel Machek resulting in more readability and formating updates - fix power management errors found by Pavel Machek - removed comments from d-t bindings as suggested by Rob Herring - selected ctu,ctucanfd-2 as alternative name to ctu,ctucanfd which allows to bind to actual major HDL core sources version 2.x if for some reason driver adaptation would not work on version read from the core - line length limit relaxed to 100 characters on some cases where it helps to readability The version 4 changes: - sent at 2020-08-04 - changes summary, 169 non-merge commits, 6 driver, 32 IP core sources enhancements and fixes, 58 tests in master and about additional 30 iso-testbench preparation branch. - convert device-tree binding documentation to YAML - QEMU model of CTU CAN FD IP core and generic extension of QEMU CAN bus emulation developed by Jan Charvat. - driver tested on QEMU emulated Malta big-endian MIPS platform and big endian-support fixed. - checkpatch from 5.4 kernel used to cleanup driver formatting - header files generated from IP core IP-Xact description updated to include protocol exception (pex) field. Mechanism to set it from the driver is not provided yet. The version 3 changes: - sent at 2019-12-21 - adapts device tree bindings documentation according to Rob Herring suggestions. - the driver has been separated to individual modules for core support, PCI bus integration and platform, SoC integration. - the FPGA design has been cleaned up and CAN protocol FSM redesigned by Ondrej Ille (the core redesign has been reason to pause attempts to driver submission) - the work from February 2019 on core, test framework and driver 1601 commits in total, 436 commits in the core sources, 144 commits in the driver, 151 documentation, 502 in tests. - not all continuous integration tests updated for latest design version yet https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/pipelines - Zynq hardware in the loop test show no issues for after driver PCI and platform separation and latest VHDL sources updates. - driver code has been periodically tested on 4.18.5-rt3 and 4.19 long term stable kernels. - test of the patches before submission is run on 5.4 kernel - the core has been integrated by Jaroslav Beran into Intel FPGA based SoC used in the tester developed for Skoda auto at Department of Measurement, Faculty of Electrical Engineering, Czech Technical University https://meas.fel.cvut.cz/ . He has contributed feedback and fixes to the project. The version 2 sent at 2019-02-27 The version 1 sent at 2019-02-22 Ondrej Ille has prepared the CTU CAN IP Core sources for new release. We are waiting with it for the driver review, our intention is to release IP when driver is reviewed and mainlined. DKMS CTU CAN FD driver build by OpenBuildService to ease integration into Debian systems when driver is not provided by the distribution https://build.opensuse.org/package/show/home:ppisa/ctu_can_fd Jan Charvat finished work to extend already mainlined QEMU SJA1000 and SocketCAN support to provide even CAN FD support and CTU CAN FD core support. https://gitlab.fel.cvut.cz/canbus/qemu-canbus/-/tree/ctu-canfd The patches has been sent for review to QEMU mainlining list. Thanks in advance to all who help us to deliver the project into public. Thanks to all colleagues, reviewers and other providing feedback
Re: [PATCH v4 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
Hello Pavel and Rob, thanks much for review. On Thursday 06 of August 2020 16:47:13 Rob Herring wrote: > On Tue, Aug 04, 2020 at 11:20:21AM +0200, Pavel Machek wrote: > > On Tue 2020-08-04 11:18:17, Pavel Machek wrote: > > > Hi! > > > > > > > The commit text again to make checkpatch happy. > > > > > > ? The checkpatch reports as a problem when there is no description of the patch. At least for patch [PATCH v4 1/6] dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague. I consider that little pontificate but I have fullfiled its suggestion with remark, that in this case, It is not my intention to add these promotions. I remove the reference to patchcheck from these commit messages. > > > > +oneOf: > > > > + - items: > > > > + - const: ctu,ctucanfd > > > > + - const: ctu,canfd-2 > > > > + - const: ctu,ctucanfd > > > > > > For consistency, can we have ctu,canfd-1, ctu,canfd-2? > > > > Make it ctu,ctucanfd-1, ctu,ctucanfd-2... to make it consistent with > > the file names. > > If you are going to do version numbers, please define where they come > from. Hopefully some tag of the h/w IP version... > > Better yet, put version numbers in the h/w registers itself and you > don't need different compatibles. The actual major version of the core is 2. The minor intended for release was 1. But we wait for driver inclusion and release and IP core release has not been realized. Sources moved to 2.2-pre version and compiled core reports 2.2 now. There is added control bit for protocol exception behavior selection and minor enhancements in sync of standard and data rate bittimes starts. Yes, version can be obtained from hardware. There is magic and version in the first core register. See 3.1.1 DEVICE_ID section of the manual (page 22/28) http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/Progdokum.pdf As for the DT identifier we use "ctu,ctucanfd" in more projects already. Some devices are in the wild now. So I would prefer to keep compatibility with that name. Other name reflects that this driver is compatible with major version 2 of the core. It can be "ctu,ctucanfd-2". I am not sure if the repeat of "ctu" is good idea, but yes, full sources prefix is "ctucanfd". The second alias can be omitted alltogether. But I am not sure, there can be one day fundamental change between IP core versions which would be better handled by change of PCI ID and DT ID. It is questionable if attempt to keep single driver for more too different versions would be more manageable or convoluted than two fully independent ones. May it be we do not need to solve that because by that time it would be "ctu,ctucanxl". At this time, our actual first first choic for the IP core identifier is ctu,ctucanfd. As for the pointed description, I would remove them from version 5 according to your reference. My personal one is to keep documentation (even of actual/local functional setup) directly in the sources and mainline to find it out when I or somebody else need to recreate or update designs, my biological memory is already worn out by past events. I am not sure if I should wait for subsystem maintainers review now or sent new patches version. I may get to its preparation tommorrow or may it be later because I want to take some time in countrysite/mountains. Best wishes Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz 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/
Re: [PATCH v3 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
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, p...@cmp.felk.cvut.cz wrote: > > > From: Pavel Pisa > > > > > > Signed-off-by: Pavel Pisa > > > --- > > > .../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 > > > > 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 "", 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: p...@cmp.felk.cvut.cz 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/
Re: [PATCH v3 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
Hello Rob, On Saturday 04 of January 2020 00:53:59 Rob Herring wrote: > On Sat, Dec 21, 2019 at 03:07:31PM +0100, p...@cmp.felk.cvut.cz wrote: > > From: Pavel Pisa > > > > Signed-off-by: Pavel Pisa > > --- > > .../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 > > 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 "", 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 "", 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 "", 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 "", 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 descripti
[PATCH] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
>From 3e19a7f5c33e5fb50f52c9df05bf00022e3f3dd5 Mon Sep 17 00:00:00 2001
From: Pavel Pisa
Date: Fri, 22 Feb 2019 14:11:11 +0100
Subject: [PATCH] dt-bindings: net: can: binding for CTU CAN FD open-source IP
core.
Signed-off-by: Pavel Pisa
---
.../devicetree/bindings/net/can/ctu,ctucanfd.txt | 102 +
1 file changed, 102 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 ..6c75e5850904
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt
@@ -0,0 +1,102 @@
+Memory mapped CTU CAN FD open-source IP core
+
+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".
+
+- 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.
+
+- interrupt-parent = <> :
+ is required for Zynq SoC to find map interrupt
+ to the correct controller
+
+- clocks: phandle of reference clock (100 MHz is appropriate
+ for FPGA implementation on Zynq-7000 system).
+
+Example when integrated to Zynq-7000 system DTS:
+
+/ {
+/* ... */
+amba: amba {
+#address-cells = <1>;
+#size-cells = <1>;
+compatible = "simple-bus";
+
+CTU_CAN_FD_0: CTU_CAN_FD@43c3 {
+compatible = "ctu,ctucanfd";
+interrupt-parent = <>;
+interrupts = <0 30 4>;
+clocks = < 15>;
+reg = <0x43c3 0x1>;
+};
+};
+};
+
+
+Example when used as DTS overlay on Zynq-7000 system:
+
+
+// Device Tree Example: Full Reconfiguration without Bridges
+/dts-v1/;
+/plugin/;
+
+/ {
+fragment@0 {
+target-path = "/fpga-full";
+
+__overlay__ {
+#address-cells = <1>;
+#size-cells = <1>;
+
+firmware-name = "system.bit.bin";
+};
+};
+
+fragment@1 {
+target-path = "/amba";
+__overlay__ {
+#address-cells = <1>;
+#size-cells = <1>;
+
+CTU_CAN_FD_0: CTU_CAN_FD@43c3 {
+compatible = "ctu,ctucanfd";
+interrupt-parent = <>;
+interrupts = <0 30 4>;
+clocks = < 15>;
+//clock-names = "can_clk";
+reg = <0x43c3 0x1>;
+};
+CTU_CAN_FD_1: CTU_CAN_FD@43c7 {
+compatible = "ctu,ctucanfd";
+interrupt-parent = <>;
+interrupts = <0 31 4>;
+clocks = < 15>;
+//clock-names = "can_clk";
+reg = <0x43c7 0x1>;
+};
+};
+};
+};
--
2.11.0
Re: [PATCH 18/24] MAINTAINERS: remove drivers/mmc/host/imxmmc.*
On Saturday 24 November 2012 01:26:42 Cesar Eduardo Barros wrote: > This driver was removed by commit 6187fee (mmc: remove imxmmc driver). > > Cc: Sascha Hauer > Cc: Pavel Pisa > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Cesar Eduardo Barros > --- > MAINTAINERS | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index fc646ef..cac8e49 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4905,12 +4905,6 @@ F: Documentation/video4linux/meye.txt > F: drivers/media/pci/meye/ > F: include/uapi/linux/meye.h > > -MOTOROLA IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER > -M: Pavel Pisa > -L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > -S: Maintained > -F: drivers/mmc/host/imxmmc.* > - > MOXA SMARTIO/INDUSTIO/INTELLIO SERIAL CARD > M: Jiri Slaby > S: Maintained Acked-by: Pavel Pisa I have still the hardware but have lack resources to keep with current kernel development for that old HW. We plan to switch to newer i.MX hardware - hopefully with more bug free MMC/SD support, because MX1 has taken me yer a year of fighting with its bugs (on Linux and RTEMS as well). Best wishes, Pavel Pisa e-mail: p...@cmp.felk.cvut.cz www:http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company:http://www.pikron.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/24] MAINTAINERS: remove drivers/mmc/host/imxmmc.*
On Saturday 24 November 2012 01:26:42 Cesar Eduardo Barros wrote: This driver was removed by commit 6187fee (mmc: remove imxmmc driver). Cc: Sascha Hauer s.ha...@pengutronix.de Cc: Pavel Pisa pp...@pikron.com Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Cesar Eduardo Barros ces...@cesarb.net --- MAINTAINERS | 6 -- 1 file changed, 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fc646ef..cac8e49 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4905,12 +4905,6 @@ F: Documentation/video4linux/meye.txt F: drivers/media/pci/meye/ F: include/uapi/linux/meye.h -MOTOROLA IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER -M: Pavel Pisa pp...@pikron.com -L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -S: Maintained -F: drivers/mmc/host/imxmmc.* - MOXA SMARTIO/INDUSTIO/INTELLIO SERIAL CARD M: Jiri Slaby jirisl...@gmail.com S: Maintained Acked-by: Pavel Pisa p...@cmp.felk.cvut.cz I have still the hardware but have lack resources to keep with current kernel development for that old HW. We plan to switch to newer i.MX hardware - hopefully with more bug free MMC/SD support, because MX1 has taken me yer a year of fighting with its bugs (on Linux and RTEMS as well). Best wishes, Pavel Pisa e-mail: p...@cmp.felk.cvut.cz www:http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company:http://www.pikron.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [322/2many] MAINTAINERS - MOTOROLA IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER
On Monday 13 August 2007 08:32, [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Acked-by: Pavel Pisa <[EMAIL PROTECTED]>
By the way, I am hunting write timeouts bugs now.
I expect it is some MX1 SDHC hardware-driver
interaction problem. Any help appreciated.
I have patch implementing specialized imxmmc
logger which writes couple of last 64 SDHC events
before bug occurred.
Best wishes
Pavel Pisa
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aeb86e6..ddff41d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3099,6 +3099,7 @@ M: [EMAIL PROTECTED]
> L: [EMAIL PROTECTED] (subscribers-only)
> W: http://mmc.drzeus.cx/wiki/Controllers/Freescale/SDHC
> S: Maintained
> +F: drivers/mmc/host/imxmmc.*
>
> MOUSE AND MISC DEVICES [GENERAL]
> P: Alessandro Rubini
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [322/2many] MAINTAINERS - MOTOROLA IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER
On Monday 13 August 2007 08:32, [EMAIL PROTECTED] wrote: Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] Acked-by: Pavel Pisa [EMAIL PROTECTED] By the way, I am hunting write timeouts bugs now. I expect it is some MX1 SDHC hardware-driver interaction problem. Any help appreciated. I have patch implementing specialized imxmmc logger which writes couple of last 64 SDHC events before bug occurred. Best wishes Pavel Pisa diff --git a/MAINTAINERS b/MAINTAINERS index aeb86e6..ddff41d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3099,6 +3099,7 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) W: http://mmc.drzeus.cx/wiki/Controllers/Freescale/SDHC S: Maintained +F: drivers/mmc/host/imxmmc.* MOUSE AND MISC DEVICES [GENERAL] P: Alessandro Rubini - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Orphaning MMC host drivers
On Monday 14 May 2007 21:38, Pierre Ossman wrote: > @@ -2382,6 +2391,9 @@ M:[EMAIL PROTECTED] > W: http://popies.net/meye/ > S: Maintained > > +MOTOROLA I.MX MMCI DRIVER > +S: Orphan > + > MOUSE AND MISC DEVICES [GENERAL] > P: Alessandro Rubini > M:[EMAIL PROTECTED] > @@ -2902,6 +2914,9 @@ M:[EMAIL PROTECTED] Hello Pierre, as I have already stated, I would take responsibility for I.MX SDHC driver. It is not perfect, but I am trying to keep and fix it and I would be happy to receive feedback or help from others. The actual state is such, that read works for both SD/MMC, but write is failing. The write path is timing sensitive and some other kernel changes above 2.6.18 exposes these problems. I have some ideas, how to dig for this problem in mind, but I did not find time to try them yet. I have already proposed MAINTAINERS change, but you did not liked to point L: field to "sdhci-devel" list. I propose ALKML mailing list this time as you suggested. Do you include change or should I send my own patch for review? Would you suggest change in driver name to MOTOROLA I.MX MMCI DRIVER ? Best wishes Pavel My original proposal with L: changed to ALKML Index: linux-2.6.21/MAINTAINERS === --- linux-2.6.21.orig/MAINTAINERS +++ linux-2.6.21/MAINTAINERS @@ -1717,6 +1717,13 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) S: Maintained +IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER +P: Pavel Pisa +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +W: http://mmc.drzeus.cx/wiki/Controllers/Freescale/SDHC +S: Maintained + INFINIBAND SUBSYSTEM P: Roland Dreier M: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Orphaning MMC host drivers
On Monday 14 May 2007 21:38, Pierre Ossman wrote: @@ -2382,6 +2391,9 @@ M:[EMAIL PROTECTED] W: http://popies.net/meye/ S: Maintained +MOTOROLA I.MX MMCI DRIVER +S: Orphan + MOUSE AND MISC DEVICES [GENERAL] P: Alessandro Rubini M:[EMAIL PROTECTED] @@ -2902,6 +2914,9 @@ M:[EMAIL PROTECTED] Hello Pierre, as I have already stated, I would take responsibility for I.MX SDHC driver. It is not perfect, but I am trying to keep and fix it and I would be happy to receive feedback or help from others. The actual state is such, that read works for both SD/MMC, but write is failing. The write path is timing sensitive and some other kernel changes above 2.6.18 exposes these problems. I have some ideas, how to dig for this problem in mind, but I did not find time to try them yet. I have already proposed MAINTAINERS change, but you did not liked to point L: field to sdhci-devel list. I propose ALKML mailing list this time as you suggested. Do you include change or should I send my own patch for review? Would you suggest change in driver name to MOTOROLA I.MX MMCI DRIVER ? Best wishes Pavel My original proposal with L: changed to ALKML Index: linux-2.6.21/MAINTAINERS === --- linux-2.6.21.orig/MAINTAINERS +++ linux-2.6.21/MAINTAINERS @@ -1717,6 +1717,13 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) S: Maintained +IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER +P: Pavel Pisa +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) +W: http://mmc.drzeus.cx/wiki/Controllers/Freescale/SDHC +S: Maintained + INFINIBAND SUBSYSTEM P: Roland Dreier M: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007 07:47, Davide Libenzi wrote: > On Mon, 16 Apr 2007, Pavel Pisa wrote: > > I cannot help myself to not report results with GAVL > > tree algorithm there as an another race competitor. > > I believe, that it is better solution for large priority > > queues than RB-tree and even heap trees. It could be > > disputable if the scheduler needs such scalability on > > the other hand. The AVL heritage guarantees lower height > > which results in shorter search times which could > > be profitable for other uses in kernel. > > > > GAVL algorithm is AVL tree based, so it does not suffer from > > "infinite" priorities granularity there as TR does. It allows > > use for generalized case where tree is not fully balanced. > > This allows to cut the first item withour rebalancing. > > This leads to the degradation of the tree by one more level > > (than non degraded AVL gives) in maximum, which is still > > considerably better than RB-trees maximum. > > > > http://cmp.felk.cvut.cz/~pisa/linux/smart-queue-v-gavl.c > > Here are the results on my Opteron 252: > > Testing N=1 > gavl_cfs = 187.20 cycles/loop > CFS = 194.16 cycles/loop > TR = 314.87 cycles/loop > CFS = 194.15 cycles/loop > gavl_cfs = 187.15 cycles/loop > > Testing N=2 > gavl_cfs = 268.94 cycles/loop > CFS = 305.53 cycles/loop > TR = 313.78 cycles/loop > CFS = 289.58 cycles/loop > gavl_cfs = 266.02 cycles/loop > > Testing N=4 > gavl_cfs = 452.13 cycles/loop > CFS = 518.81 cycles/loop > TR = 311.54 cycles/loop > CFS = 516.23 cycles/loop > gavl_cfs = 450.73 cycles/loop > > Testing N=8 > gavl_cfs = 609.29 cycles/loop > CFS = 644.65 cycles/loop > TR = 308.11 cycles/loop > CFS = 667.01 cycles/loop > gavl_cfs = 592.89 cycles/loop > > Testing N=16 > gavl_cfs = 686.30 cycles/loop > CFS = 807.41 cycles/loop > TR = 317.20 cycles/loop > CFS = 810.24 cycles/loop > gavl_cfs = 688.42 cycles/loop > > Testing N=32 > gavl_cfs = 756.57 cycles/loop > CFS = 852.14 cycles/loop > TR = 301.22 cycles/loop > CFS = 876.12 cycles/loop > gavl_cfs = 758.46 cycles/loop > > Testing N=64 > gavl_cfs = 831.97 cycles/loop > CFS = 997.16 cycles/loop > TR = 304.74 cycles/loop > CFS = 1003.26 cycles/loop > gavl_cfs = 832.83 cycles/loop > > Testing N=128 > gavl_cfs = 897.33 cycles/loop > CFS = 1030.36 cycles/loop > TR = 295.65 cycles/loop > CFS = 1035.29 cycles/loop > gavl_cfs = 892.51 cycles/loop > > Testing N=256 > gavl_cfs = 963.17 cycles/loop > CFS = 1146.04 cycles/loop > TR = 295.35 cycles/loop > CFS = 1162.04 cycles/loop > gavl_cfs = 966.31 cycles/loop > > Testing N=512 > gavl_cfs = 1029.82 cycles/loop > CFS = 1218.34 cycles/loop > TR = 288.78 cycles/loop > CFS = 1257.97 cycles/loop > gavl_cfs = 1029.83 cycles/loop > > Testing N=1024 > gavl_cfs = 1091.76 cycles/loop > CFS = 1318.47 cycles/loop > TR = 287.74 cycles/loop > CFS = 1311.72 cycles/loop > gavl_cfs = 1093.29 cycles/loop > > Testing N=2048 > gavl_cfs = 1153.03 cycles/loop > CFS = 1398.84 cycles/loop > TR = 286.75 cycles/loop > CFS = 1438.68 cycles/loop > gavl_cfs = 1149.97 cycles/loop > > > There seem to be some difference from your numbers. This is with: > > gcc version 4.1.2 > > and -O2. But then and Opteron can behave quite differentyl than a Duron on > a bench like this ;) Thanks for testing, but yours numbers are more correct than my first report. My numbers seemed to be over-optimistic even to me, In the fact I have been surprised that difference is so high. But I have tested bad version of code without GAVL_FAFTER option set. The code pushed to the web page has been the correct one. I have not get to look into case until now because I have busy day to prepare some Linux based labs at university. Without GAVL_FAFTER option, insert operation does fail if item with same key is already inserted (intended feature of the code) and as result of that, not all items have been inserted in the test. The meaning of GAVL_FAFTER is find/insert after all items with the same key value. Default behavior is operate on unique keys in tree and reject duplicates. My results are even worse for GAVL than yours. It is possible to try tweak code and optimize it more (likely/unlikely/do not keep last ptr etc) for this actual usage. May it be, that I try this exercise, but I do not expect that the result after tuning would be so much better, that it would outweight some redesign work. I could see some advantages of AVL still, but it has its own drawbacks with need of separate height field and little worse delete in the middle timing. So excuse me for disturbance. I have been only curious how GAVL code would behave in the
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007 07:47, Davide Libenzi wrote: On Mon, 16 Apr 2007, Pavel Pisa wrote: I cannot help myself to not report results with GAVL tree algorithm there as an another race competitor. I believe, that it is better solution for large priority queues than RB-tree and even heap trees. It could be disputable if the scheduler needs such scalability on the other hand. The AVL heritage guarantees lower height which results in shorter search times which could be profitable for other uses in kernel. GAVL algorithm is AVL tree based, so it does not suffer from infinite priorities granularity there as TR does. It allows use for generalized case where tree is not fully balanced. This allows to cut the first item withour rebalancing. This leads to the degradation of the tree by one more level (than non degraded AVL gives) in maximum, which is still considerably better than RB-trees maximum. http://cmp.felk.cvut.cz/~pisa/linux/smart-queue-v-gavl.c Here are the results on my Opteron 252: Testing N=1 gavl_cfs = 187.20 cycles/loop CFS = 194.16 cycles/loop TR = 314.87 cycles/loop CFS = 194.15 cycles/loop gavl_cfs = 187.15 cycles/loop Testing N=2 gavl_cfs = 268.94 cycles/loop CFS = 305.53 cycles/loop TR = 313.78 cycles/loop CFS = 289.58 cycles/loop gavl_cfs = 266.02 cycles/loop Testing N=4 gavl_cfs = 452.13 cycles/loop CFS = 518.81 cycles/loop TR = 311.54 cycles/loop CFS = 516.23 cycles/loop gavl_cfs = 450.73 cycles/loop Testing N=8 gavl_cfs = 609.29 cycles/loop CFS = 644.65 cycles/loop TR = 308.11 cycles/loop CFS = 667.01 cycles/loop gavl_cfs = 592.89 cycles/loop Testing N=16 gavl_cfs = 686.30 cycles/loop CFS = 807.41 cycles/loop TR = 317.20 cycles/loop CFS = 810.24 cycles/loop gavl_cfs = 688.42 cycles/loop Testing N=32 gavl_cfs = 756.57 cycles/loop CFS = 852.14 cycles/loop TR = 301.22 cycles/loop CFS = 876.12 cycles/loop gavl_cfs = 758.46 cycles/loop Testing N=64 gavl_cfs = 831.97 cycles/loop CFS = 997.16 cycles/loop TR = 304.74 cycles/loop CFS = 1003.26 cycles/loop gavl_cfs = 832.83 cycles/loop Testing N=128 gavl_cfs = 897.33 cycles/loop CFS = 1030.36 cycles/loop TR = 295.65 cycles/loop CFS = 1035.29 cycles/loop gavl_cfs = 892.51 cycles/loop Testing N=256 gavl_cfs = 963.17 cycles/loop CFS = 1146.04 cycles/loop TR = 295.35 cycles/loop CFS = 1162.04 cycles/loop gavl_cfs = 966.31 cycles/loop Testing N=512 gavl_cfs = 1029.82 cycles/loop CFS = 1218.34 cycles/loop TR = 288.78 cycles/loop CFS = 1257.97 cycles/loop gavl_cfs = 1029.83 cycles/loop Testing N=1024 gavl_cfs = 1091.76 cycles/loop CFS = 1318.47 cycles/loop TR = 287.74 cycles/loop CFS = 1311.72 cycles/loop gavl_cfs = 1093.29 cycles/loop Testing N=2048 gavl_cfs = 1153.03 cycles/loop CFS = 1398.84 cycles/loop TR = 286.75 cycles/loop CFS = 1438.68 cycles/loop gavl_cfs = 1149.97 cycles/loop There seem to be some difference from your numbers. This is with: gcc version 4.1.2 and -O2. But then and Opteron can behave quite differentyl than a Duron on a bench like this ;) Thanks for testing, but yours numbers are more correct than my first report. My numbers seemed to be over-optimistic even to me, In the fact I have been surprised that difference is so high. But I have tested bad version of code without GAVL_FAFTER option set. The code pushed to the web page has been the correct one. I have not get to look into case until now because I have busy day to prepare some Linux based labs at university. Without GAVL_FAFTER option, insert operation does fail if item with same key is already inserted (intended feature of the code) and as result of that, not all items have been inserted in the test. The meaning of GAVL_FAFTER is find/insert after all items with the same key value. Default behavior is operate on unique keys in tree and reject duplicates. My results are even worse for GAVL than yours. It is possible to try tweak code and optimize it more (likely/unlikely/do not keep last ptr etc) for this actual usage. May it be, that I try this exercise, but I do not expect that the result after tuning would be so much better, that it would outweight some redesign work. I could see some advantages of AVL still, but it has its own drawbacks with need of separate height field and little worse delete in the middle timing. So excuse me for disturbance. I have been only curious how GAVL code would behave in the comparison of other algorithms and I did not kept my premature enthusiasm under the lock. Best wishes Pavel Pisa ./smart-queue-v-gavl -n 4 gavl_cfs = 279.02 cycles/loop CFS = 200.87 cycles/loop TR = 229.55 cycles/loop CFS = 201.23 cycles/loop gavl_cfs = 276.08 cycles/loop ./smart-queue-v-gavl -n 8 gavl_cfs = 310.92 cycles/loop CFS = 288.45 cycles/loop TR = 192.46 cycles/loop CFS = 284.94 cycles/loop gavl_cfs = 357.02 cycles/loop ./smart-queue-v-gavl -n 16 gavl_cfs = 350.45 cycles/loop CFS = 354.01 cycles/loop
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
I have not found case with real performance degradation. On the other hand, there are cases for small items counts where GAVL is sometimes a little worse than others (array based heap-tree for example). The GAVL code itself is used in more opensource and commercial projects and we have noticed no problems after one small fix at the time of the first release in 2004. Best wishes Pavel Pisa e-mail: [EMAIL PROTECTED] www:http://cmp.felk.cvut.cz/~pisa work: http://www.pikron.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
than others (array based heap-tree for example). The GAVL code itself is used in more opensource and commercial projects and we have noticed no problems after one small fix at the time of the first release in 2004. Best wishes Pavel Pisa e-mail: [EMAIL PROTECTED] www:http://cmp.felk.cvut.cz/~pisa work: http://www.pikron.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i.MX/MX1 SDHC fix/workaround of SD card recognition problems
On Monday 12 March 2007 00:36, you wrote: > Pavel Pisa wrote: > > The SDHC controllers cannot process shorter transfers. > > They has to be handled as longer ones, but it such case CRC > > error is evaluated. There was a case in the code still, > > where this error is not ignored as it should to be process > > these transfers. > > > > Signed-off-by: Pavel Pisa <[EMAIL PROTECTED]> > > Thanks, applied. Is this something critical that should be in 2.6.21? > > Rgds Hello Pierre, this should go to 2.6.21, I have hold this for some months and I have discussed it in the thread "Re: CRC Errors with SD cards in 4bits mode (on i.MXl)" You have been CCed. This is not solution for seen data CRC problem, but solves problems with recognition of cards which has been timing sensitive sometimes. I have sent it into Russell's patch queue with my others MX1 fixes I have intended to be included in 2.6.21. It was probably mistake for this one, because it should go through your tree. If you send it to mainline yourself, I would discard patch from patch daemon. We have spoken about MX1 SDHC maintainership. I am attaching my subscription. I am not sure about mailing list field there. Do you suggest this one, ALKML or other? Best wishes Pavel Pisa -- Subject: i.MX/MX1 SDHC maintainer I am reporting to responsibility for i.MX MMC driver bugs and coordination of the fighting against problems of this hardware beast. Signed-off-by: Pavel Pisa <[EMAIL PROTECTED]> MAINTAINERS |7 +++ 1 file changed, 7 insertions(+) Index: linux-2.6.21-rc1/MAINTAINERS === --- linux-2.6.21-rc1.orig/MAINTAINERS +++ linux-2.6.21-rc1/MAINTAINERS @@ -1713,6 +1713,13 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) S: Maintained +IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER +P: Pavel Pisa +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: http://mmc.drzeus.cx/wiki/Controllers/Freescale/SDHC +S: Maintained + INFINIBAND SUBSYSTEM P: Roland Dreier M: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i.MX/MX1 SDHC fix/workaround of SD card recognition problems
On Monday 12 March 2007 00:36, you wrote: Pavel Pisa wrote: The SDHC controllers cannot process shorter transfers. They has to be handled as longer ones, but it such case CRC error is evaluated. There was a case in the code still, where this error is not ignored as it should to be process these transfers. Signed-off-by: Pavel Pisa [EMAIL PROTECTED] Thanks, applied. Is this something critical that should be in 2.6.21? Rgds Hello Pierre, this should go to 2.6.21, I have hold this for some months and I have discussed it in the thread Re: CRC Errors with SD cards in 4bits mode (on i.MXl) You have been CCed. This is not solution for seen data CRC problem, but solves problems with recognition of cards which has been timing sensitive sometimes. I have sent it into Russell's patch queue with my others MX1 fixes I have intended to be included in 2.6.21. It was probably mistake for this one, because it should go through your tree. If you send it to mainline yourself, I would discard patch from patch daemon. We have spoken about MX1 SDHC maintainership. I am attaching my subscription. I am not sure about mailing list field there. Do you suggest this one, ALKML or other? Best wishes Pavel Pisa -- Subject: i.MX/MX1 SDHC maintainer I am reporting to responsibility for i.MX MMC driver bugs and coordination of the fighting against problems of this hardware beast. Signed-off-by: Pavel Pisa [EMAIL PROTECTED] MAINTAINERS |7 +++ 1 file changed, 7 insertions(+) Index: linux-2.6.21-rc1/MAINTAINERS === --- linux-2.6.21-rc1.orig/MAINTAINERS +++ linux-2.6.21-rc1/MAINTAINERS @@ -1713,6 +1713,13 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] (subscribers-only) S: Maintained +IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER +P: Pavel Pisa +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: http://mmc.drzeus.cx/wiki/Controllers/Freescale/SDHC +S: Maintained + INFINIBAND SUBSYSTEM P: Roland Dreier M: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-02-06-16-59.tar.gz uploaded
On Wednesday 07 February 2007 01:59, [EMAIL PROTECTED] wrote: > docbook-html-generate-chapter-section-level-tocs-for-functions.patch > docbook-html-correction-of-recursive-a-tags-in-html-output.patch Hello Randy and Andrew, what is state of these patches. Are there some comments? Am I expected to carry some action during merge window or they are already on their way to Linus. Thanks Pavel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Coding style question
Hello All, I have question if next style of macros definitions for hardware registers is acceptable (tastefull for maintainers) for Linux kernel. /* Register offset against peripheral base */ #define SUBSYSTEM_REGISTER_o 0x0 /* The register field mask */ #define REGISTER_FUNCTION_m 0x0 /* The register field starting bit */ #define REGISTER_FUNCTION_b 0x00 I am used to use this over many of our embedded targets mainly developed without operating system. I would like to use this for Linux drivers as well. The naming convention has advantage, that it prevents mistakes, when mask value (*_m) is used in bit set/clear function without notice instead of bitnumber (*_b). The SUBSYSTEM_REGISTER -> REGISTER_FUNCTION prevents mistakes, when field defined for one register is used with incorrect register by mistake. I would like to use this style in i.MX SDHC to allow support both controllers on MX21. I would like to use it in other areas as well. There are tightly copled two macros for preparation and acquisition of muti-bit masked fields values #define __val2mfld(mask,val) (((mask)&~((mask)<<1))*(val)&(mask)) #define __mfld2val(mask,val) (((val)&(mask))/((mask)&~((mask)<<1))) __raw_writel(REGISTER_SINGLEBIT_m | __val2mfld(REGISTER_MULTIBIT_m,value), periph_base + SUBSYSTEM_REGISTER_o) x = __mfld2val(REGISTER_MULTIBIT_m, _raw_readl(periph_base + SUBSYSTEM_REGISTER_o)) The macros seems to be complicated, but they generate optimal code for constant fields masks. I am not aware, that there is some commonly available alternative in Linux kernel header files. Suggestions, names corrections etc. are welcomed. If you think, that it is not good idea to introduce yet another style, I would try to follow actual style found in each source file. If you prefer some already utilized style, direct me to right examples, please. Best wishes Pavel Pisa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Coding style question
Hello All, I have question if next style of macros definitions for hardware registers is acceptable (tastefull for maintainers) for Linux kernel. /* Register offset against peripheral base */ #define SUBSYSTEM_REGISTER_o 0x0 /* The register field mask */ #define REGISTER_FUNCTION_m 0x0 /* The register field starting bit */ #define REGISTER_FUNCTION_b 0x00 I am used to use this over many of our embedded targets mainly developed without operating system. I would like to use this for Linux drivers as well. The naming convention has advantage, that it prevents mistakes, when mask value (*_m) is used in bit set/clear function without notice instead of bitnumber (*_b). The SUBSYSTEM_REGISTER - REGISTER_FUNCTION prevents mistakes, when field defined for one register is used with incorrect register by mistake. I would like to use this style in i.MX SDHC to allow support both controllers on MX21. I would like to use it in other areas as well. There are tightly copled two macros for preparation and acquisition of muti-bit masked fields values #define __val2mfld(mask,val) (((mask)~((mask)1))*(val)(mask)) #define __mfld2val(mask,val) (((val)(mask))/((mask)~((mask)1))) __raw_writel(REGISTER_SINGLEBIT_m | __val2mfld(REGISTER_MULTIBIT_m,value), periph_base + SUBSYSTEM_REGISTER_o) x = __mfld2val(REGISTER_MULTIBIT_m, _raw_readl(periph_base + SUBSYSTEM_REGISTER_o)) The macros seems to be complicated, but they generate optimal code for constant fields masks. I am not aware, that there is some commonly available alternative in Linux kernel header files. Suggestions, names corrections etc. are welcomed. If you think, that it is not good idea to introduce yet another style, I would try to follow actual style found in each source file. If you prefer some already utilized style, direct me to right examples, please. Best wishes Pavel Pisa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-02-06-16-59.tar.gz uploaded
On Wednesday 07 February 2007 01:59, [EMAIL PROTECTED] wrote: docbook-html-generate-chapter-section-level-tocs-for-functions.patch docbook-html-correction-of-recursive-a-tags-in-html-output.patch Hello Randy and Andrew, what is state of these patches. Are there some comments? Am I expected to carry some action during merge window or they are already on their way to Linus. Thanks Pavel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH updated] arm: i.MX/MX1 clock event source
On Wednesday 24 January 2007 12:37, Thomas Gleixner wrote:
> On Wed, 2007-01-24 at 03:00 +0100, Pavel Pisa wrote:
> > stays NULL after clock event registration. Interrupts
> > runs, but my code doesnot call any function. The notification
> > chain and clock events list seems to be filled correctly.
> > I have added
> >
> > clockevent_imx.cpumask = cpumask_of_cpu(0);
>
> Correct. I probably should disable the check for UP.
I have made mistake last time on 2.6.20-rc5-rt8.
I have returned to testing today with 2.6.20-rc6-rt2.
I have added checking outputs to the tickregistration
routines, but all works correctly after right cpumask correction.
I have rechecked even without additional printks
and I have observed no problems. The clock events enabled kernels
requires next minor changes to compile on ARM still
arch/arm/kernel/process.c |5 +++--
kernel/time/tick-sched.c |1 +
2 files changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6.20-rc6/kernel/time/tick-sched.c
===
--- linux-2.6.20-rc6.orig/kernel/time/tick-sched.c
+++ linux-2.6.20-rc6/kernel/time/tick-sched.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "tick-internal.h"
Index: linux-2.6.20-rc6/arch/arm/kernel/process.c
===
--- linux-2.6.20-rc6.orig/arch/arm/kernel/process.c
+++ linux-2.6.20-rc6/arch/arm/kernel/process.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -154,11 +155,11 @@ void cpu_idle(void)
if (!idle)
idle = default_idle;
leds_event(led_idle_start);
- hrtimer_stop_sched_tick();
+ tick_nohz_stop_sched_tick();
while (!need_resched() && !need_resched_delayed())
idle();
leds_event(led_idle_end);
- hrtimer_restart_sched_tick();
+ tick_nohz_restart_sched_tick();
local_irq_disable();
__preempt_enable_no_resched();
__schedule();
Updated version of i.MX patch follows. If somebody wants it,
I can send patch to revert code of previous version from
full 2.6.20-rc6-rt2 patch.
Ingo, please, can you replace i.MX1 patch in your series?
Thanks
Pavel
Subject: arm: i.MX/MX1 clock event source
Support clock event source based on i.MX general purpose
timer in free running timer mode.
Signed-off-by: Pavel Pisa <[EMAIL PROTECTED]>
arch/arm/mach-imx/time.c | 130 +--
1 file changed, 125 insertions(+), 5 deletions(-)
Index: linux-2.6.20-rc6/arch/arm/mach-imx/time.c
===
--- linux-2.6.20-rc6.orig/arch/arm/mach-imx/time.c
+++ linux-2.6.20-rc6/arch/arm/mach-imx/time.c
@@ -15,6 +15,9 @@
#include
#include
#include
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#include
+#endif
#include
#include
@@ -25,6 +28,11 @@
/* Use timer 1 as system timer */
#define TIMER_BASE IMX_TIM1_BASE
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+static struct clock_event_device clockevent_imx;
+static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_PERIODIC;
+#endif
+
static unsigned long evt_diff;
/*
@@ -33,6 +41,7 @@ static unsigned long evt_diff;
static irqreturn_t
imx_timer_interrupt(int irq, void *dev_id)
{
+ unsigned long tcmp;
uint32_t tstat;
/* clear the interrupt */
@@ -42,13 +51,20 @@ imx_timer_interrupt(int irq, void *dev_i
if (tstat & TSTAT_COMP) {
do {
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+ if (clockevent_imx.event_handler)
+ clockevent_imx.event_handler(_imx);
+ if (likely(clockevent_mode != CLOCK_EVT_MODE_PERIODIC))
+ break;
+#else
write_seqlock(_lock);
timer_tick();
write_sequnlock(_lock);
- IMX_TCMP(TIMER_BASE) += evt_diff;
+#endif
+ tcmp = IMX_TCMP(TIMER_BASE) + evt_diff;
+ IMX_TCMP(TIMER_BASE) = tcmp;
- } while (unlikely((int32_t)(IMX_TCMP(TIMER_BASE)
- - IMX_TCN(TIMER_BASE)) < 0));
+ } while (unli
Re: [PATCH updated] arm: i.MX/MX1 clock event source
On Wednesday 24 January 2007 12:37, Thomas Gleixner wrote:
On Wed, 2007-01-24 at 03:00 +0100, Pavel Pisa wrote:
stays NULL after clock event registration. Interrupts
runs, but my code doesnot call any function. The notification
chain and clock events list seems to be filled correctly.
I have added
clockevent_imx.cpumask = cpumask_of_cpu(0);
Correct. I probably should disable the check for UP.
I have made mistake last time on 2.6.20-rc5-rt8.
I have returned to testing today with 2.6.20-rc6-rt2.
I have added checking outputs to the tickregistration
routines, but all works correctly after right cpumask correction.
I have rechecked even without additional printks
and I have observed no problems. The clock events enabled kernels
requires next minor changes to compile on ARM still
arch/arm/kernel/process.c |5 +++--
kernel/time/tick-sched.c |1 +
2 files changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6.20-rc6/kernel/time/tick-sched.c
===
--- linux-2.6.20-rc6.orig/kernel/time/tick-sched.c
+++ linux-2.6.20-rc6/kernel/time/tick-sched.c
@@ -20,6 +20,7 @@
#include linux/profile.h
#include linux/sched.h
#include linux/tick.h
+#include asm/irq_regs.h
#include tick-internal.h
Index: linux-2.6.20-rc6/arch/arm/kernel/process.c
===
--- linux-2.6.20-rc6.orig/arch/arm/kernel/process.c
+++ linux-2.6.20-rc6/arch/arm/kernel/process.c
@@ -28,6 +28,7 @@
#include linux/cpu.h
#include linux/elfcore.h
#include linux/pm.h
+#include linux/tick.h
#include asm/leds.h
#include asm/processor.h
@@ -154,11 +155,11 @@ void cpu_idle(void)
if (!idle)
idle = default_idle;
leds_event(led_idle_start);
- hrtimer_stop_sched_tick();
+ tick_nohz_stop_sched_tick();
while (!need_resched() !need_resched_delayed())
idle();
leds_event(led_idle_end);
- hrtimer_restart_sched_tick();
+ tick_nohz_restart_sched_tick();
local_irq_disable();
__preempt_enable_no_resched();
__schedule();
Updated version of i.MX patch follows. If somebody wants it,
I can send patch to revert code of previous version from
full 2.6.20-rc6-rt2 patch.
Ingo, please, can you replace i.MX1 patch in your series?
Thanks
Pavel
Subject: arm: i.MX/MX1 clock event source
Support clock event source based on i.MX general purpose
timer in free running timer mode.
Signed-off-by: Pavel Pisa [EMAIL PROTECTED]
arch/arm/mach-imx/time.c | 130 +--
1 file changed, 125 insertions(+), 5 deletions(-)
Index: linux-2.6.20-rc6/arch/arm/mach-imx/time.c
===
--- linux-2.6.20-rc6.orig/arch/arm/mach-imx/time.c
+++ linux-2.6.20-rc6/arch/arm/mach-imx/time.c
@@ -15,6 +15,9 @@
#include linux/irq.h
#include linux/time.h
#include linux/clocksource.h
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#include linux/clockchips.h
+#endif
#include asm/hardware.h
#include asm/io.h
@@ -25,6 +28,11 @@
/* Use timer 1 as system timer */
#define TIMER_BASE IMX_TIM1_BASE
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+static struct clock_event_device clockevent_imx;
+static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_PERIODIC;
+#endif
+
static unsigned long evt_diff;
/*
@@ -33,6 +41,7 @@ static unsigned long evt_diff;
static irqreturn_t
imx_timer_interrupt(int irq, void *dev_id)
{
+ unsigned long tcmp;
uint32_t tstat;
/* clear the interrupt */
@@ -42,13 +51,20 @@ imx_timer_interrupt(int irq, void *dev_i
if (tstat TSTAT_COMP) {
do {
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+ if (clockevent_imx.event_handler)
+ clockevent_imx.event_handler(clockevent_imx);
+ if (likely(clockevent_mode != CLOCK_EVT_MODE_PERIODIC))
+ break;
+#else
write_seqlock(xtime_lock);
timer_tick();
write_sequnlock(xtime_lock);
- IMX_TCMP(TIMER_BASE) += evt_diff;
+#endif
+ tcmp = IMX_TCMP(TIMER_BASE) + evt_diff;
+ IMX_TCMP(TIMER_BASE) = tcmp;
- } while (unlikely
Re: [PATCH query] arm: i.MX/MX1 clock event source
On Tuesday 23 January 2007 03:52, Pavel Pisa wrote: > > i've added your patch to -rt, but note that there's a new, slightly > > incompatible clockevents code in -rt now so you'll need to do some more > > (hopefully trivial) fixups for this to build and work. > > > > Ingo > > Hello Ingo, > > Unfortunately, even with these corrections boot stuck at > > Memory: 18972KB available (2488K code, 358K data, 92K init) > > I have not time now to start JTAG debugging session, so I look at that > tomorrow or on Friday. > > It seems, that the interrupts are not coming from device. > > Best wishes > > Pavel > Hello Ingo, I have found some time and tried to debugg problem with help of JTAG debugger. But I have found, that IRQs are processed right. The plain rc5 runs flawlessly. The rt8 doesnot start. The problem is, that handler stays NULL after clock event registration. Interrupts runs, but my code doesnot call any function. The notification chain and clock events list seems to be filled correctly. I have added clockevent_imx.cpumask = cpumask_of_cpu(0); to ensure that clock are not used for affinity mask reasons. I have tried even exchange clock event forcibly at the end of clockevent_imx initialization. But it only resulted in asking timer to switch off into unused mode. I have added next hack into IRQ write_seqlock(_lock); timer_tick(); write_sequnlock(_lock); which stays enabled until imx_set_mode() is called first time, The system boots after this modification, but imx_set_mode() is never called and there is no switch to high resolution mode. CONFIG_ARM=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y ??? CONFIG_TICK_ONESHOT=y ??? CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y Could I preset some handler directly during timer initialization? Can I declare somehow, that I want to use that clock event device as source of tick from beginning? Should I try to rebuild with CONFIG_NO_HZ=n? I would like to keep up with changes, because I have tested RTs for ARM already over more "stable" releases and over many rc-s. And high resolution timers support has worked well over for me last three months (up to 2.6.20-rc4). So I want to learn what is required to be compatible with latest code. Thanks for any hints to the problem Pavel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH query] arm: i.MX/MX1 clock event source
On Tuesday 23 January 2007 03:52, Pavel Pisa wrote: i've added your patch to -rt, but note that there's a new, slightly incompatible clockevents code in -rt now so you'll need to do some more (hopefully trivial) fixups for this to build and work. Ingo Hello Ingo, Unfortunately, even with these corrections boot stuck at Memory: 18972KB available (2488K code, 358K data, 92K init) I have not time now to start JTAG debugging session, so I look at that tomorrow or on Friday. It seems, that the interrupts are not coming from device. Best wishes Pavel Hello Ingo, I have found some time and tried to debugg problem with help of JTAG debugger. But I have found, that IRQs are processed right. The plain rc5 runs flawlessly. The rt8 doesnot start. The problem is, that handler stays NULL after clock event registration. Interrupts runs, but my code doesnot call any function. The notification chain and clock events list seems to be filled correctly. I have added clockevent_imx.cpumask = cpumask_of_cpu(0); to ensure that clock are not used for affinity mask reasons. I have tried even exchange clock event forcibly at the end of clockevent_imx initialization. But it only resulted in asking timer to switch off into unused mode. I have added next hack into IRQ write_seqlock(xtime_lock); timer_tick(); write_sequnlock(xtime_lock); which stays enabled until imx_set_mode() is called first time, The system boots after this modification, but imx_set_mode() is never called and there is no switch to high resolution mode. CONFIG_ARM=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y ??? CONFIG_TICK_ONESHOT=y ??? CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y Could I preset some handler directly during timer initialization? Can I declare somehow, that I want to use that clock event device as source of tick from beginning? Should I try to rebuild with CONFIG_NO_HZ=n? I would like to keep up with changes, because I have tested RTs for ARM already over more stable releases and over many rc-s. And high resolution timers support has worked well over for me last three months (up to 2.6.20-rc4). So I want to learn what is required to be compatible with latest code. Thanks for any hints to the problem Pavel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH query] arm: i.MX/MX1 clock event source
On Monday 22 January 2007 20:59, Ingo Molnar wrote:
> * Pavel Pisa <[EMAIL PROTECTED]> wrote:
> > Hello Thomas, Sascha and Ingo
> >
> > please can you find some time to review next patch
> > arm: i.MX/MX1 clock event source
> > which has been sent to you and to the ALKML at 2007-01-13.
> >
> > http://thread.gmane.org/gmane.linux.ports.arm.kernel/29510/focus=29533
> >
> > There seems to be some problems, because this patch has not been
> > accepted to patch-2.6.20-rc5-rt7.patch, but GENERIC_CLOCKEVENTS are
> > set already for i.MX and this results in a problems to run RT kernel
> > on this architecture.
>
> i've added your patch to -rt, but note that there's a new, slightly
> incompatible clockevents code in -rt now so you'll need to do some more
> (hopefully trivial) fixups for this to build and work.
>
> Ingo
Hello Ingo,
thanks for reply. I am attaching updated version of the patch at the end of
e-mail.
There is problem with missing include in tick-sched.c
CC kernel/time/tick-sched.o
/usr/src/linux-2.6.20-rc5/kernel/time/tick-sched.c: In function
`tick_nohz_handler':
/usr/src/linux-2.6.20-rc5/kernel/time/tick-sched.c:330: warning: implicit
declaration of function `get_irq_regs'
/usr/src/linux-2.6.20-rc5/kernel/time/tick-sched.c:330: warning: initialization
makes pointer from integer without a cast
/usr/src/linux-2.6.20-rc5/kernel/time/tick-sched.c: In function
`tick_sched_timer':
/usr/src/linux-2.6.20-rc5/kernel/time/tick-sched.c:425: warning: initialization
makes pointer from integer without a cast
LD kernel/time/built-in.o
--- linux-2.6.20-rc5.orig/kernel/time/tick-sched.c
+++ linux-2.6.20-rc5/kernel/time/tick-sched.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "tick-internal.h"
And
CC arch/arm/kernel/process.o
/usr/src/linux-2.6.20-rc5/arch/arm/kernel/process.c: In function `cpu_idle':
/usr/src/linux-2.6.20-rc5/arch/arm/kernel/process.c:157: warning: implicit
declaration of function `hrtimer_stop_sched_tick'
/usr/src/linux-2.6.20-rc5/arch/arm/kernel/process.c:161: warning: implicit
declaration of function `hrtimer_restart_sched_tick'
--- linux-2.6.20-rc5.orig/arch/arm/kernel/process.c
+++ linux-2.6.20-rc5/arch/arm/kernel/process.c
@@ -154,11 +154,11 @@ void cpu_idle(void)
if (!idle)
idle = default_idle;
leds_event(led_idle_start);
- hrtimer_stop_sched_tick();
+ tick_nohz_stop_sched_tick();
while (!need_resched() && !need_resched_delayed())
idle();
leds_event(led_idle_end);
- hrtimer_restart_sched_tick();
+ tick_nohz_restart_sched_tick();
local_irq_disable();
__preempt_enable_no_resched();
__schedule();
Unfortunately, even with these corrections boot stuck at
Memory: 18972KB available (2488K code, 358K data, 92K init)
I have not time now to start JTAG debugging session, so I look at that
tomorrow or on Friday.
It seems, that the interrupts are not coming from device.
Best wishes
Pavel
==
Subject: arm: i.MX/MX1 clock event source
Support clock event source based on i.MX general purpose
timer in free running timer mode.
Signed-off-by: Pavel Pisa <[EMAIL PROTECTED]>
arch/arm/mach-imx/time.c | 112 ---
1 file changed, 107 insertions(+), 5 deletions(-)
Index: linux-2.6.20-rc5/arch/arm/mach-imx/time.c
===
--- linux-2.6.20-rc5.orig/arch/arm/mach-imx/time.c
+++ linux-2.6.20-rc5/arch/arm/mach-imx/time.c
@@ -15,6 +15,9 @@
#include
#include
#include
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#include
+#endif
#include
#include
@@ -25,6 +28,11 @@
/* Use timer 1 as system timer */
#define TIMER_BASE IMX_TIM1_BASE
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+static struct clock_event_device clockevent_imx;
+static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_PERIODIC;
+#endif
+
static unsigned long evt_diff;
/*
@@ -33,6 +41,7 @@ static unsigned long evt_diff;
static irqreturn_t
imx_timer_interrupt(int irq, void *dev_id)
{
+ unsigned long tcmp;
uint32_t tstat;
/* clear the interrupt */
@@ -42,13 +51,20 @@ imx_timer_interrupt(int irq, void *dev_i
if (tstat & TSTAT_COMP) {
do {
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+ if (clockevent_imx.event_handler)
+ clockevent_imx.event_handler(_imx);
+ if (likely(clockevent_mode != CLOCK_EVT_MODE_PERIODIC))
+ break;
+#else
write_seqlock(_lock);
Re: [PATCH query] arm: i.MX/MX1 clock event source
On Monday 22 January 2007 20:59, Ingo Molnar wrote:
* Pavel Pisa [EMAIL PROTECTED] wrote:
Hello Thomas, Sascha and Ingo
please can you find some time to review next patch
arm: i.MX/MX1 clock event source
which has been sent to you and to the ALKML at 2007-01-13.
http://thread.gmane.org/gmane.linux.ports.arm.kernel/29510/focus=29533
There seems to be some problems, because this patch has not been
accepted to patch-2.6.20-rc5-rt7.patch, but GENERIC_CLOCKEVENTS are
set already for i.MX and this results in a problems to run RT kernel
on this architecture.
i've added your patch to -rt, but note that there's a new, slightly
incompatible clockevents code in -rt now so you'll need to do some more
(hopefully trivial) fixups for this to build and work.
Ingo
Hello Ingo,
thanks for reply. I am attaching updated version of the patch at the end of
e-mail.
There is problem with missing include in tick-sched.c
CC kernel/time/tick-sched.o
/usr/src/linux-2.6.20-rc5/kernel/time/tick-sched.c: In function
`tick_nohz_handler':
/usr/src/linux-2.6.20-rc5/kernel/time/tick-sched.c:330: warning: implicit
declaration of function `get_irq_regs'
/usr/src/linux-2.6.20-rc5/kernel/time/tick-sched.c:330: warning: initialization
makes pointer from integer without a cast
/usr/src/linux-2.6.20-rc5/kernel/time/tick-sched.c: In function
`tick_sched_timer':
/usr/src/linux-2.6.20-rc5/kernel/time/tick-sched.c:425: warning: initialization
makes pointer from integer without a cast
LD kernel/time/built-in.o
--- linux-2.6.20-rc5.orig/kernel/time/tick-sched.c
+++ linux-2.6.20-rc5/kernel/time/tick-sched.c
@@ -20,6 +20,7 @@
#include linux/profile.h
#include linux/sched.h
#include linux/tick.h
+#include asm/irq_regs.h
#include tick-internal.h
And
CC arch/arm/kernel/process.o
/usr/src/linux-2.6.20-rc5/arch/arm/kernel/process.c: In function `cpu_idle':
/usr/src/linux-2.6.20-rc5/arch/arm/kernel/process.c:157: warning: implicit
declaration of function `hrtimer_stop_sched_tick'
/usr/src/linux-2.6.20-rc5/arch/arm/kernel/process.c:161: warning: implicit
declaration of function `hrtimer_restart_sched_tick'
--- linux-2.6.20-rc5.orig/arch/arm/kernel/process.c
+++ linux-2.6.20-rc5/arch/arm/kernel/process.c
@@ -154,11 +154,11 @@ void cpu_idle(void)
if (!idle)
idle = default_idle;
leds_event(led_idle_start);
- hrtimer_stop_sched_tick();
+ tick_nohz_stop_sched_tick();
while (!need_resched() !need_resched_delayed())
idle();
leds_event(led_idle_end);
- hrtimer_restart_sched_tick();
+ tick_nohz_restart_sched_tick();
local_irq_disable();
__preempt_enable_no_resched();
__schedule();
Unfortunately, even with these corrections boot stuck at
Memory: 18972KB available (2488K code, 358K data, 92K init)
I have not time now to start JTAG debugging session, so I look at that
tomorrow or on Friday.
It seems, that the interrupts are not coming from device.
Best wishes
Pavel
==
Subject: arm: i.MX/MX1 clock event source
Support clock event source based on i.MX general purpose
timer in free running timer mode.
Signed-off-by: Pavel Pisa [EMAIL PROTECTED]
arch/arm/mach-imx/time.c | 112 ---
1 file changed, 107 insertions(+), 5 deletions(-)
Index: linux-2.6.20-rc5/arch/arm/mach-imx/time.c
===
--- linux-2.6.20-rc5.orig/arch/arm/mach-imx/time.c
+++ linux-2.6.20-rc5/arch/arm/mach-imx/time.c
@@ -15,6 +15,9 @@
#include linux/irq.h
#include linux/time.h
#include linux/clocksource.h
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#include linux/clockchips.h
+#endif
#include asm/hardware.h
#include asm/io.h
@@ -25,6 +28,11 @@
/* Use timer 1 as system timer */
#define TIMER_BASE IMX_TIM1_BASE
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+static struct clock_event_device clockevent_imx;
+static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_PERIODIC;
+#endif
+
static unsigned long evt_diff;
/*
@@ -33,6 +41,7 @@ static unsigned long evt_diff;
static irqreturn_t
imx_timer_interrupt(int irq, void *dev_id)
{
+ unsigned long tcmp;
uint32_t tstat;
/* clear the interrupt */
@@ -42,13 +51,20 @@ imx_timer_interrupt(int irq, void *dev_i
if (tstat TSTAT_COMP) {
do {
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+ if (clockevent_imx.event_handler)
+ clockevent_imx.event_handler(clockevent_imx);
+ if (likely(clockevent_mode != CLOCK_EVT_MODE_PERIODIC))
+ break;
+#else
write_seqlock(xtime_lock);
timer_tick
Re: Realtime-preemption for 2.6.20-rc5 ?
On Sunday 21 January 2007 10:10, Peter Zijlstra wrote: > > I preffer > > to stay on "stable" kernel on boxes which I use daily until next stable > > appears. > > This is a very weird statement, the -rt kernel includes so much > experimental work it cannot be called 'stable' by a long shot. > > Sure its not known unstable, but neither is .20-rc5. There are no security fixes for rc and our own experience is, that RT patch has very low impact on base system stability. The rc-s contains much more experimental stuff all over the kernel which needs to be stabilized till next (hopefully) stable release. > If you want -rt, just run with the latest unless you have a very > specific need not to. We have run successfully 2.6.16.1-rt12 over last summer semester on students diskless stations without much problems. (Main problem has been some NFS FS problem with 1GB/s server, 100MB/s stations and switches in between, but it has been same for non-RT kernel. We solved that by switching NFS over TCP.) We would like to upgrade to something which would not cause us much troubles for next course run. We teach real time control in X35POS course and we need fast responses and timing (100 usec) for direct PWM and IO control. On the other hand, I agree that for own experimentation and development it is better to build on latest released version. Best wishes Pavel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime-preemption for 2.6.20-rc5 ?
On Sunday 21 January 2007 10:10, Peter Zijlstra wrote: I preffer to stay on stable kernel on boxes which I use daily until next stable appears. This is a very weird statement, the -rt kernel includes so much experimental work it cannot be called 'stable' by a long shot. Sure its not known unstable, but neither is .20-rc5. There are no security fixes for rc and our own experience is, that RT patch has very low impact on base system stability. The rc-s contains much more experimental stuff all over the kernel which needs to be stabilized till next (hopefully) stable release. If you want -rt, just run with the latest unless you have a very specific need not to. We have run successfully 2.6.16.1-rt12 over last summer semester on students diskless stations without much problems. (Main problem has been some NFS FS problem with 1GB/s server, 100MB/s stations and switches in between, but it has been same for non-RT kernel. We solved that by switching NFS over TCP.) We would like to upgrade to something which would not cause us much troubles for next course run. We teach real time control in X35POS course and we need fast responses and timing (100 usec) for direct PWM and IO control. On the other hand, I agree that for own experimentation and development it is better to build on latest released version. Best wishes Pavel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime-preemption for 2.6.20-rc5 ?
Hello Sunil and Ingo, Date: 2007-01-20 02:56:40 GMT (20 hours and 26 minutes ago) > 2007-01-20, Sunil Naidu <[EMAIL PROTECTED]> wrote: > I did refer the same. Is it necessary to use only base kernel, say > 2.6.19? Or, can I go ahead with 2.6.19 + 2.6.19.2 patch + 2.6.19-rt > patch? > > If yes, any reason why we need to apply rt patch only to a base kernel? according to my observation 2.6.19-rt15 is based/includes 2.6.19.1 changes. But there has been that nasty clear_page_dirty_for_io() bug causing corruption of ext3. Even that I have tested more 2.6.20-rc + rt, I preffer to stay on "stable" kernel on boxes which I use daily until next stable appears. I have backported clear_page_dirty_for_io() to 2.6.19-rt15 and it worked fine. I have tried to update 2.6.19-rt15 to 2.6.19.2 base. There is result of my attempt Unofficial incremental patch from 2.6.19-rt15 to 2.6.19.2 + rt http://rtime.felk.cvut.cz/repos/ppisa-linux-devel/kernel-patches/current/patch-2.6.19.2-incr.patch Kernel seems to work correctly. I have checked the patch contents and I have not noticed any RT problematic changes in the code according to my dumb knowledge. I would be very happy, if Ingo would be so kind and could confirm my findings, because I am not sure, if final 2.6.20+rt would be ready before we need to prepare setup for our next semester classes at university. Best wishes Pavel Pisa e-mail: [EMAIL PROTECTED] www:http://cmp.felk.cvut.cz/~pisa work: http://www.pikron.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH query] arm: i.MX/MX1 clock event source
Hello Thomas, Sascha and Ingo
please can you find some time to review next patch
arm: i.MX/MX1 clock event source
which has been sent to you and to the ALKML at 2007-01-13.
http://thread.gmane.org/gmane.linux.ports.arm.kernel/29510/focus=29533
There seems to be some problems, because this patch has not been
accepted to patch-2.6.20-rc5-rt7.patch, but GENERIC_CLOCKEVENTS
are set already for i.MX and this results in a problems to run
RT kernel on this architecture.
config ARCH_IMX
bool "IMX"
+ select GENERIC_TIME
+ select GENERIC_CLOCKEVENTS
Thanks for review and your time
Pavel
-
Subject: arm: i.MX/MX1 clock event source
Support clock event source based on i.MX general purpose
timer in free running timer mode.
Signed-off-by: Pavel Pisa <[EMAIL PROTECTED]>
arch/arm/mach-imx/time.c | 92 +++
1 file changed, 92 insertions(+)
Index: linux-2.6.20-rc4/arch/arm/mach-imx/time.c
===
--- linux-2.6.20-rc4.orig/arch/arm/mach-imx/time.c
+++ linux-2.6.20-rc4/arch/arm/mach-imx/time.c
@@ -15,6 +15,9 @@
#include
#include
#include
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#include
+#endif
#include
#include
@@ -25,6 +28,11 @@
/* Use timer 1 as system timer */
#define TIMER_BASE IMX_TIM1_BASE
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+static struct clock_event_device clockevent_imx;
+static enum clock_event_mode clockevent_mode = CLOCK_EVT_PERIODIC;
+#endif
+
static unsigned long evt_diff;
/*
@@ -42,9 +50,16 @@ imx_timer_interrupt(int irq, void *dev_i
if (tstat & TSTAT_COMP) {
do {
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+ if (clockevent_imx.event_handler)
+ clockevent_imx.event_handler();
+ if (likely(clockevent_mode != CLOCK_EVT_PERIODIC))
+ break;
+#else
write_seqlock(_lock);
timer_tick();
write_sequnlock(_lock);
+#endif
IMX_TCMP(TIMER_BASE) += evt_diff;
} while (unlikely((int32_t)(IMX_TCMP(TIMER_BASE)
@@ -99,11 +114,88 @@ static int __init imx_clocksource_init(v
return 0;
}
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+
+static void imx_set_next_event(unsigned long evt,
+ struct clock_event_device *unused)
+{
+ evt_diff = evt;
+ IMX_TCMP(TIMER_BASE) = IMX_TCN(TIMER_BASE) + evt;
+}
+
+static void imx_set_mode(enum clock_event_mode mode, struct clock_event_device
*evt)
+{
+ unsigned long flags;
+
+ /*
+* The timer interrupt generation is disabled at least
+* for enough time to call imx_set_next_event()
+*/
+ local_irq_save(flags);
+ /* Disable interrupt in GPT module */
+ IMX_TCTL(TIMER_BASE) &= ~TCTL_IRQEN;
+ if ((mode != CLOCK_EVT_PERIODIC) || (mode != clockevent_mode)) {
+ /* Set event time into far-far future */
+ IMX_TCMP(TIMER_BASE) = IMX_TCN(TIMER_BASE) - 3;
+ /* Clear pending interrupt */
+ IMX_TSTAT(TIMER_BASE) &= ~TSTAT_COMP;
+ }
+ /* Remember timer mode */
+ clockevent_mode = mode;
+ local_irq_restore(flags);
+
+ switch (mode) {
+ case CLOCK_EVT_PERIODIC:
+ case CLOCK_EVT_ONESHOT:
+ /*
+* Do not put overhead of interrupt enable/disable into
+* imx_set_next_event(), the core has about 4 minutes
+* to call imx_set_next_event() or shutdown clock after
+* mode switching
+*/
+ local_irq_save(flags);
+ IMX_TCTL(TIMER_BASE) |= TCTL_IRQEN;
+ local_irq_restore(flags);
+ break;
+ case CLOCK_EVT_SHUTDOWN:
+ /* Left event sources disabled, no more interrupts appears */
+ break;
+ }
+}
+
+static struct clock_event_device clockevent_imx = {
+ .name = "imx_timer1",
+ .capabilities = CLOCK_CAP_NEXTEVT | CLOCK_CAP_TICK |
+ CLOCK_CAP_UPDATE | CLOCK_CAP_PROFILE,
+ .shift = 32,
+ .set_mode = imx_set_mode,
+ .set_next_event = imx_set_next_event,
+};
+
+static int __init imx_clockevent_init(void)
+{
+ clockevent_imx.mult = div_sc(imx_get_perclk1(), NSEC_PER_SEC,
+ clockevent_imx.shift);
+ clockevent_imx.max_delta_ns =
+ clockevent_delta2ns(0xfffe, _imx);
+ clockevent_imx.min_delta_ns =
+ clockevent_delta2ns(0xf, _imx);
+ register_local_clockevent(_imx);
+
+ return 0;
+}
+#endif
+
+
static void __init imx_timer_init(vo
[PATCH query] arm: i.MX/MX1 clock event source
Hello Thomas, Sascha and Ingo
please can you find some time to review next patch
arm: i.MX/MX1 clock event source
which has been sent to you and to the ALKML at 2007-01-13.
http://thread.gmane.org/gmane.linux.ports.arm.kernel/29510/focus=29533
There seems to be some problems, because this patch has not been
accepted to patch-2.6.20-rc5-rt7.patch, but GENERIC_CLOCKEVENTS
are set already for i.MX and this results in a problems to run
RT kernel on this architecture.
config ARCH_IMX
bool IMX
+ select GENERIC_TIME
+ select GENERIC_CLOCKEVENTS
Thanks for review and your time
Pavel
-
Subject: arm: i.MX/MX1 clock event source
Support clock event source based on i.MX general purpose
timer in free running timer mode.
Signed-off-by: Pavel Pisa [EMAIL PROTECTED]
arch/arm/mach-imx/time.c | 92 +++
1 file changed, 92 insertions(+)
Index: linux-2.6.20-rc4/arch/arm/mach-imx/time.c
===
--- linux-2.6.20-rc4.orig/arch/arm/mach-imx/time.c
+++ linux-2.6.20-rc4/arch/arm/mach-imx/time.c
@@ -15,6 +15,9 @@
#include linux/irq.h
#include linux/time.h
#include linux/clocksource.h
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#include linux/clockchips.h
+#endif
#include asm/hardware.h
#include asm/io.h
@@ -25,6 +28,11 @@
/* Use timer 1 as system timer */
#define TIMER_BASE IMX_TIM1_BASE
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+static struct clock_event_device clockevent_imx;
+static enum clock_event_mode clockevent_mode = CLOCK_EVT_PERIODIC;
+#endif
+
static unsigned long evt_diff;
/*
@@ -42,9 +50,16 @@ imx_timer_interrupt(int irq, void *dev_i
if (tstat TSTAT_COMP) {
do {
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+ if (clockevent_imx.event_handler)
+ clockevent_imx.event_handler();
+ if (likely(clockevent_mode != CLOCK_EVT_PERIODIC))
+ break;
+#else
write_seqlock(xtime_lock);
timer_tick();
write_sequnlock(xtime_lock);
+#endif
IMX_TCMP(TIMER_BASE) += evt_diff;
} while (unlikely((int32_t)(IMX_TCMP(TIMER_BASE)
@@ -99,11 +114,88 @@ static int __init imx_clocksource_init(v
return 0;
}
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+
+static void imx_set_next_event(unsigned long evt,
+ struct clock_event_device *unused)
+{
+ evt_diff = evt;
+ IMX_TCMP(TIMER_BASE) = IMX_TCN(TIMER_BASE) + evt;
+}
+
+static void imx_set_mode(enum clock_event_mode mode, struct clock_event_device
*evt)
+{
+ unsigned long flags;
+
+ /*
+* The timer interrupt generation is disabled at least
+* for enough time to call imx_set_next_event()
+*/
+ local_irq_save(flags);
+ /* Disable interrupt in GPT module */
+ IMX_TCTL(TIMER_BASE) = ~TCTL_IRQEN;
+ if ((mode != CLOCK_EVT_PERIODIC) || (mode != clockevent_mode)) {
+ /* Set event time into far-far future */
+ IMX_TCMP(TIMER_BASE) = IMX_TCN(TIMER_BASE) - 3;
+ /* Clear pending interrupt */
+ IMX_TSTAT(TIMER_BASE) = ~TSTAT_COMP;
+ }
+ /* Remember timer mode */
+ clockevent_mode = mode;
+ local_irq_restore(flags);
+
+ switch (mode) {
+ case CLOCK_EVT_PERIODIC:
+ case CLOCK_EVT_ONESHOT:
+ /*
+* Do not put overhead of interrupt enable/disable into
+* imx_set_next_event(), the core has about 4 minutes
+* to call imx_set_next_event() or shutdown clock after
+* mode switching
+*/
+ local_irq_save(flags);
+ IMX_TCTL(TIMER_BASE) |= TCTL_IRQEN;
+ local_irq_restore(flags);
+ break;
+ case CLOCK_EVT_SHUTDOWN:
+ /* Left event sources disabled, no more interrupts appears */
+ break;
+ }
+}
+
+static struct clock_event_device clockevent_imx = {
+ .name = imx_timer1,
+ .capabilities = CLOCK_CAP_NEXTEVT | CLOCK_CAP_TICK |
+ CLOCK_CAP_UPDATE | CLOCK_CAP_PROFILE,
+ .shift = 32,
+ .set_mode = imx_set_mode,
+ .set_next_event = imx_set_next_event,
+};
+
+static int __init imx_clockevent_init(void)
+{
+ clockevent_imx.mult = div_sc(imx_get_perclk1(), NSEC_PER_SEC,
+ clockevent_imx.shift);
+ clockevent_imx.max_delta_ns =
+ clockevent_delta2ns(0xfffe, clockevent_imx);
+ clockevent_imx.min_delta_ns =
+ clockevent_delta2ns(0xf, clockevent_imx);
+ register_local_clockevent(clockevent_imx);
+
+ return 0
Re: Realtime-preemption for 2.6.20-rc5 ?
Hello Sunil and Ingo, Date: 2007-01-20 02:56:40 GMT (20 hours and 26 minutes ago) 2007-01-20, Sunil Naidu [EMAIL PROTECTED] wrote: I did refer the same. Is it necessary to use only base kernel, say 2.6.19? Or, can I go ahead with 2.6.19 + 2.6.19.2 patch + 2.6.19-rt patch? If yes, any reason why we need to apply rt patch only to a base kernel? according to my observation 2.6.19-rt15 is based/includes 2.6.19.1 changes. But there has been that nasty clear_page_dirty_for_io() bug causing corruption of ext3. Even that I have tested more 2.6.20-rc + rt, I preffer to stay on stable kernel on boxes which I use daily until next stable appears. I have backported clear_page_dirty_for_io() to 2.6.19-rt15 and it worked fine. I have tried to update 2.6.19-rt15 to 2.6.19.2 base. There is result of my attempt Unofficial incremental patch from 2.6.19-rt15 to 2.6.19.2 + rt http://rtime.felk.cvut.cz/repos/ppisa-linux-devel/kernel-patches/current/patch-2.6.19.2-incr.patch Kernel seems to work correctly. I have checked the patch contents and I have not noticed any RT problematic changes in the code according to my dumb knowledge. I would be very happy, if Ingo would be so kind and could confirm my findings, because I am not sure, if final 2.6.20+rt would be ready before we need to prepare setup for our next semester classes at university. Best wishes Pavel Pisa e-mail: [EMAIL PROTECTED] www:http://cmp.felk.cvut.cz/~pisa work: http://www.pikron.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] DocBook/HTML: correction of recursive A tags in HTML output
The malformed HTML was generated after switch to XSLTPROC
from SGML tools. The reference title
struct x
is converted into two recursive tags
struct x
There is more possible solutions for this problem.
One can be found at
http://darkk.livejournal.com/
The proposed solution is based on suggestion provided by Jiri Kosek.
Signed-off-by: Pavel Pisa <[EMAIL PROTECTED]>
---
scripts/kernel-doc | 16
1 file changed, 8 insertions(+), 8 deletions(-)
Index: linux-2.6.19/scripts/kernel-doc
===
--- linux-2.6.19.orig/scripts/kernel-doc
+++ linux-2.6.19/scripts/kernel-doc
@@ -583,14 +583,14 @@ sub output_function_xml(%) {
$id = "API-".$args{'function'};
$id =~ s/[^A-Za-z0-9]/-/g;
-print "\n";
+print "\n";
print "\n";
print " LINUX\n";
print " Kernel Hackers Manual\n";
print " $man_date\n";
print "\n";
print "\n";
-print " ".$args{'function'}."\n";
+print "
".$args{'function'}."\n";
print " 9\n";
print "\n";
print "\n";
@@ -659,14 +659,14 @@ sub output_struct_xml(%) {
$id = "API-struct-".$args{'struct'};
$id =~ s/[^A-Za-z0-9]/-/g;
-print "\n";
+print "\n";
print "\n";
print " LINUX\n";
print " Kernel Hackers Manual\n";
print " $man_date\n";
print "\n";
print "\n";
-print " ".$args{'type'}."
".$args{'struct'}."\n";
+print " ".$args{'type'}."
".$args{'struct'}."\n";
print " 9\n";
print "\n";
print "\n";
@@ -743,14 +743,14 @@ sub output_enum_xml(%) {
$id = "API-enum-".$args{'enum'};
$id =~ s/[^A-Za-z0-9]/-/g;
-print "\n";
+print "\n";
print "\n";
print " LINUX\n";
print " Kernel Hackers Manual\n";
print " $man_date\n";
print "\n";
print "\n";
-print " enum
".$args{'enum'}."\n";
+print " enum
".$args{'enum'}."\n";
print " 9\n";
print "\n";
print "\n";
@@ -809,14 +809,14 @@ sub output_typedef_xml(%) {
$id = "API-typedef-".$args{'typedef'};
$id =~ s/[^A-Za-z0-9]/-/g;
-print "\n";
+print "\n";
print "\n";
print " LINUX\n";
print " Kernel Hackers Manual\n";
print " $man_date\n";
print "\n";
print "\n";
-print " typedef
".$args{'typedef'}."\n";
+print " typedef
".$args{'typedef'}."\n";
print " 9\n";
print "\n";
print "\n";
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19] mmc: Fix handling of response types in imxmmc and tifm drivers
Hello Philip, On Thursday 04 January 2007 16:04, Philip Langdale wrote: > This change depends on my SDHC patch and fixes a bug that was revealed > during the development of that patch. The R6 response type should be > identical to R1 (and R7) but was incorrectly defined differently. Fixing > the R6 definition breaks assumptions in these two drivers that response > type flags are unique. Pierre and Alex both believe that treating R6 and R7 > as R1 will be sufficient. ie: The controllers do not care about the > differences between them. Due to lack of hardware, I have done no testing. I have tested your patch. Kernel builds. I have not found much time for testing. But I would not like to block changes and I am going for next week to project meeting in Spain, so there is my reply. I have 2.6.19 + realtime-patches rt14 on the hand. I have been able to mount and use some cards, but it I have observed some problems probably related to timing when I have tried to change CPU frequency. I need to find time to do more checking on vanilla and RT kernels when I return. I have some ideas what could be enhanced to ensure better MX1 SDHC cards recognition under RT kernels. I am not sure, what causes other seen problems, but I have observed these things on RT even without your patch. Conclusion: I knowledge your patch and admit, that I need to find time for my homeworks. Best wishes Pavel Pisa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19] mmc: Fix handling of response types in imxmmc and tifm drivers
Hello Philip, On Thursday 04 January 2007 16:04, Philip Langdale wrote: This change depends on my SDHC patch and fixes a bug that was revealed during the development of that patch. The R6 response type should be identical to R1 (and R7) but was incorrectly defined differently. Fixing the R6 definition breaks assumptions in these two drivers that response type flags are unique. Pierre and Alex both believe that treating R6 and R7 as R1 will be sufficient. ie: The controllers do not care about the differences between them. Due to lack of hardware, I have done no testing. I have tested your patch. Kernel builds. I have not found much time for testing. But I would not like to block changes and I am going for next week to project meeting in Spain, so there is my reply. I have 2.6.19 + realtime-patches rt14 on the hand. I have been able to mount and use some cards, but it I have observed some problems probably related to timing when I have tried to change CPU frequency. I need to find time to do more checking on vanilla and RT kernels when I return. I have some ideas what could be enhanced to ensure better MX1 SDHC cards recognition under RT kernels. I am not sure, what causes other seen problems, but I have observed these things on RT even without your patch. Conclusion: I knowledge your patch and admit, that I need to find time for my homeworks. Best wishes Pavel Pisa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] DocBook/HTML: correction of recursive A tags in HTML output
The malformed HTML was generated after switch to XSLTPROC
from SGML tools. The reference title
refentrytitlephrase id=API-struct-xstruct x/phrase/refentrytitle
is converted into two recursive a tags
a href=re02.htmlspana id=API-struct-x/astruct x/span/a
There is more possible solutions for this problem.
One can be found at
http://darkk.livejournal.com/
The proposed solution is based on suggestion provided by Jiri Kosek.
Signed-off-by: Pavel Pisa [EMAIL PROTECTED]
---
scripts/kernel-doc | 16
1 file changed, 8 insertions(+), 8 deletions(-)
Index: linux-2.6.19/scripts/kernel-doc
===
--- linux-2.6.19.orig/scripts/kernel-doc
+++ linux-2.6.19/scripts/kernel-doc
@@ -583,14 +583,14 @@ sub output_function_xml(%) {
$id = API-.$args{'function'};
$id =~ s/[^A-Za-z0-9]/-/g;
-print refentry\n;
+print refentry id=\$id\\n;
print refentryinfo\n;
print titleLINUX/title\n;
print productnameKernel Hackers Manual/productname\n;
print date$man_date/date\n;
print /refentryinfo\n;
print refmeta\n;
-print refentrytitlephrase
id=\$id\.$args{'function'}./phrase/refentrytitle\n;
+print
refentrytitlephrase.$args{'function'}./phrase/refentrytitle\n;
print manvolnum9/manvolnum\n;
print /refmeta\n;
print refnamediv\n;
@@ -659,14 +659,14 @@ sub output_struct_xml(%) {
$id = API-struct-.$args{'struct'};
$id =~ s/[^A-Za-z0-9]/-/g;
-print refentry\n;
+print refentry id=\$id\\n;
print refentryinfo\n;
print titleLINUX/title\n;
print productnameKernel Hackers Manual/productname\n;
print date$man_date/date\n;
print /refentryinfo\n;
print refmeta\n;
-print refentrytitlephrase id=\$id\.$args{'type'}.
.$args{'struct'}./phrase/refentrytitle\n;
+print refentrytitlephrase.$args{'type'}.
.$args{'struct'}./phrase/refentrytitle\n;
print manvolnum9/manvolnum\n;
print /refmeta\n;
print refnamediv\n;
@@ -743,14 +743,14 @@ sub output_enum_xml(%) {
$id = API-enum-.$args{'enum'};
$id =~ s/[^A-Za-z0-9]/-/g;
-print refentry\n;
+print refentry id=\$id\\n;
print refentryinfo\n;
print titleLINUX/title\n;
print productnameKernel Hackers Manual/productname\n;
print date$man_date/date\n;
print /refentryinfo\n;
print refmeta\n;
-print refentrytitlephrase id=\$id\enum
.$args{'enum'}./phrase/refentrytitle\n;
+print refentrytitlephraseenum
.$args{'enum'}./phrase/refentrytitle\n;
print manvolnum9/manvolnum\n;
print /refmeta\n;
print refnamediv\n;
@@ -809,14 +809,14 @@ sub output_typedef_xml(%) {
$id = API-typedef-.$args{'typedef'};
$id =~ s/[^A-Za-z0-9]/-/g;
-print refentry\n;
+print refentry id=\$id\\n;
print refentryinfo\n;
print titleLINUX/title\n;
print productnameKernel Hackers Manual/productname\n;
print date$man_date/date\n;
print /refentryinfo\n;
print refmeta\n;
-print refentrytitlephrase id=\$id\typedef
.$args{'typedef'}./phrase/refentrytitle\n;
+print refentrytitlephrasetypedef
.$args{'typedef'}./phrase/refentrytitle\n;
print manvolnum9/manvolnum\n;
print /refmeta\n;
print refnamediv\n;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ARM i.MX serial: fix tx buffer overflows
On Friday 05 January 2007 16:51, Sascha Hauer wrote:
> This patch fixes occasional tx buffer overflows in the i.MX serial
> driver which came from the fact that space in the buffer was checked
> after sending the first byte. Also, fifosize is 32 bytes, not 8.
>
> Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]
Acked-by: Pavel Pisa <[EMAIL PROTECTED]>
Hello Sascha,
I have tested your change on 2.6.19-rt14 kernel
which I have on hand there. It is only very short
test, but I have not noticed any problems.
In the fact, I think, that it is possible, that
I have noticed some mentioned problem during
my CPU-Freq testing on RT kernels before.
I have noticed some problems sometimes with BusyBox
shell history editing during frequency throttling.
May it be, that RT+changed frequency invoked the problem.
I have some other small fix for i.MX uart there.
Can you add it into patch, or should I send it
as separate one-liner?
If RTS interrupt is caused by RTS senzing logic inside
i.MX UART module the IRQ type cannot be set.
It applies only for interrupts going through GPIO layer.
The problem has been noticed by Konstantin Kletschke
some time ago.
No IRQF_TRIGGER set_type function for IRQ 26 (MPU)
I would not change type to fixed 0, because it could
be possible to use different GPIO MX1 pin for RTS
in the theory. On the other hand it is only for documentation
purposes now, because RTS read code would have to be adjusted
in such case.
Health and success wishes
in year 2007 from
Pavel Pisa
---
drivers/serial/imx.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.19-rt/drivers/serial/imx.c
===
--- linux-2.6.19-rt.orig/drivers/serial/imx.c
+++ linux-2.6.19-rt/drivers/serial/imx.c
@@ -403,7 +403,8 @@ static int imx_startup(struct uart_port
if (retval) goto error_out2;
retval = request_irq(sport->rtsirq, imx_rtsint,
-IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
+(sport->rtsirq < IMX_IRQS) ? 0 :
+ IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
DRIVER_NAME, sport);
if (retval) goto error_out3;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ARM i.MX serial: fix tx buffer overflows
On Friday 05 January 2007 16:51, Sascha Hauer wrote: This patch fixes occasional tx buffer overflows in the i.MX serial driver which came from the fact that space in the buffer was checked after sending the first byte. Also, fifosize is 32 bytes, not 8. Signed-off-by: Sascha Hauer [EMAIL PROTECTED] Acked-by: Pavel Pisa [EMAIL PROTECTED] Hello Sascha, I have tested your change on 2.6.19-rt14 kernel which I have on hand there. It is only very short test, but I have not noticed any problems. In the fact, I think, that it is possible, that I have noticed some mentioned problem during my CPU-Freq testing on RT kernels before. I have noticed some problems sometimes with BusyBox shell history editing during frequency throttling. May it be, that RT+changed frequency invoked the problem. I have some other small fix for i.MX uart there. Can you add it into patch, or should I send it as separate one-liner? If RTS interrupt is caused by RTS senzing logic inside i.MX UART module the IRQ type cannot be set. It applies only for interrupts going through GPIO layer. The problem has been noticed by Konstantin Kletschke some time ago. No IRQF_TRIGGER set_type function for IRQ 26 (MPU) I would not change type to fixed 0, because it could be possible to use different GPIO MX1 pin for RTS in the theory. On the other hand it is only for documentation purposes now, because RTS read code would have to be adjusted in such case. Health and success wishes in year 2007 from Pavel Pisa --- drivers/serial/imx.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: linux-2.6.19-rt/drivers/serial/imx.c === --- linux-2.6.19-rt.orig/drivers/serial/imx.c +++ linux-2.6.19-rt/drivers/serial/imx.c @@ -403,7 +403,8 @@ static int imx_startup(struct uart_port if (retval) goto error_out2; retval = request_irq(sport-rtsirq, imx_rtsint, -IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, +(sport-rtsirq IMX_IRQS) ? 0 : + IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, DRIVER_NAME, sport); if (retval) goto error_out3; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DocBook/HTML: Generate chapter/section level TOCs for functions
On Tuesday 02 January 2007 01:41, Randy Dunlap wrote:
> On Sun, 31 Dec 2006 02:27:46 +0100 Pavel Pisa wrote:
> > Simple increase of section TOC level generation significantly
> > enhances navigation experience through generated kernel
> > API documentation.
> >
> > This change restores back state from SGML tools time.
> >
> > Signed-off-by: Pavel Pisa <[EMAIL PROTECTED]>
> >
> > Index: linux-2.6.19/Documentation/DocBook/stylesheet.xsl
> > ===
> > --- linux-2.6.19.orig/Documentation/DocBook/stylesheet.xsl
> > +++ linux-2.6.19/Documentation/DocBook/stylesheet.xsl
> > @@ -4,4 +4,5 @@
> > ansi
> > 80
> >
> > +2
> >
>
> Hi,
> Is it possible to make the TOC contain active links to their
> sections/functions? That would be even better, wouldn't it?
Hello Randy,
this is another sort of the problem.
This problem has been probably introduced
by switch from OpenJade to xsltproc for HTML
generation as well.
I have found temporarily workaround on next
pages
http://darkk.livejournal.com/
http://darkk.livejournal.com/7429.html
I am attaching copy of the patch.
The copy of generated HTML documentation can be seen there
http://cmp.felk.cvut.cz/~pisa/linux/lkdb-2.6.19.tar.gz
The problem is caused by nested tags.
XML source:
struct x
Generates next malformed HTML with nested anchor sections,
which is interpreted as link with empty text by most browsers:
struct x
I do not know, if nesting of is on the
border of DocBook specification (but it seems, that it is not
against DocBook DTD) or if this is bug of xsltproc / XML -> HTML
DocBook formater. The valid HTML should read as
struct x
I has not been sure, if it is only problem of my tools set.
But is seems, that links are broken even on Free-Electrons
from 2.6.14 or may it be 2.6.12 days
http://free-electrons.com/kerneldoc/latest/DocBook/kernel-api/
It would be good if somebody with more knowledge about
xsltproc and DocBook could help there to find clean
solution. May it be, that somebody from
http://docbook.sourceforge.net/
could help there.
Best wishes
Pavel Pisa
Index: linux-2.6.19/scripts/kernel-doc
===
--- linux-2.6.19.orig/scripts/kernel-doc
+++ linux-2.6.19/scripts/kernel-doc
@@ -590,7 +590,7 @@ sub output_function_xml(%) {
print " $man_date\n";
print "\n";
print "\n";
-print " ".$args{'function'}."\n";
+print " ".$args{'function'}."\n";
print " 9\n";
print "\n";
print "\n";
@@ -666,7 +666,7 @@ sub output_struct_xml(%) {
print " $man_date\n";
print "\n";
print "\n";
-print " ".$args{'type'}."
".$args{'struct'}."\n";
+print " ".$args{'type'}."
".$args{'struct'}."\n";
print " 9\n";
print "\n";
print "\n";
@@ -750,7 +750,7 @@ sub output_enum_xml(%) {
print " $man_date\n";
print "\n";
print "\n";
-print " enum
".$args{'enum'}."\n";
+print " enum ".$args{'enum'}."\n";
print " 9\n";
print "\n";
print "\n";
@@ -816,7 +816,7 @@ sub output_typedef_xml(%) {
print " $man_date\n";
print "\n";
print "\n";
-print " typedef
".$args{'typedef'}."\n";
+print " typedef ".$args{'typedef'}."\n";
print " 9\n";
print "\n";
print "\n";
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DocBook/HTML: Generate chapter/section level TOCs for functions
On Tuesday 02 January 2007 01:41, Randy Dunlap wrote:
On Sun, 31 Dec 2006 02:27:46 +0100 Pavel Pisa wrote:
Simple increase of section TOC level generation significantly
enhances navigation experience through generated kernel
API documentation.
This change restores back state from SGML tools time.
Signed-off-by: Pavel Pisa [EMAIL PROTECTED]
Index: linux-2.6.19/Documentation/DocBook/stylesheet.xsl
===
--- linux-2.6.19.orig/Documentation/DocBook/stylesheet.xsl
+++ linux-2.6.19/Documentation/DocBook/stylesheet.xsl
@@ -4,4 +4,5 @@
param name=funcsynopsis.styleansi/param
param name=funcsynopsis.tabular.threshold80/param
!-- param name=paper.typeA4/param --
+param name=generate.section.toc.level2/param
/stylesheet
Hi,
Is it possible to make the TOC contain active links to their
sections/functions? That would be even better, wouldn't it?
Hello Randy,
this is another sort of the problem.
This problem has been probably introduced
by switch from OpenJade to xsltproc for HTML
generation as well.
I have found temporarily workaround on next
pages
http://darkk.livejournal.com/
http://darkk.livejournal.com/7429.html
I am attaching copy of the patch.
The copy of generated HTML documentation can be seen there
http://cmp.felk.cvut.cz/~pisa/linux/lkdb-2.6.19.tar.gz
The problem is caused by nested refentrytitlephrase tags.
XML source:
refentrytitlephrase id=API-struct-xstruct x/phrase/refentrytitle
Generates next malformed HTML with nested anchor a sections,
which is interpreted as link with empty text by most browsers:
a href=re02.htmlspana id=API-struct-x/astruct x/span/a
I do not know, if nesting of refentrytitlephrase is on the
border of DocBook specification (but it seems, that it is not
against DocBook DTD) or if this is bug of xsltproc / XML - HTML
DocBook formater. The valid HTML should read as
a href=re02.html id=API-struct-xstruct x/span/a
I has not been sure, if it is only problem of my tools set.
But is seems, that links are broken even on Free-Electrons
from 2.6.14 or may it be 2.6.12 days
http://free-electrons.com/kerneldoc/latest/DocBook/kernel-api/
It would be good if somebody with more knowledge about
xsltproc and DocBook could help there to find clean
solution. May it be, that somebody from
http://docbook.sourceforge.net/
could help there.
Best wishes
Pavel Pisa
Index: linux-2.6.19/scripts/kernel-doc
===
--- linux-2.6.19.orig/scripts/kernel-doc
+++ linux-2.6.19/scripts/kernel-doc
@@ -590,7 +590,7 @@ sub output_function_xml(%) {
print date$man_date/date\n;
print /refentryinfo\n;
print refmeta\n;
-print refentrytitlephrase
id=\$id\.$args{'function'}./phrase/refentrytitle\n;
+print refentrytitle.$args{'function'}./refentrytitle\n;
print manvolnum9/manvolnum\n;
print /refmeta\n;
print refnamediv\n;
@@ -666,7 +666,7 @@ sub output_struct_xml(%) {
print date$man_date/date\n;
print /refentryinfo\n;
print refmeta\n;
-print refentrytitlephrase id=\$id\.$args{'type'}.
.$args{'struct'}./phrase/refentrytitle\n;
+print refentrytitle.$args{'type'}.
.$args{'struct'}./refentrytitle\n;
print manvolnum9/manvolnum\n;
print /refmeta\n;
print refnamediv\n;
@@ -750,7 +750,7 @@ sub output_enum_xml(%) {
print date$man_date/date\n;
print /refentryinfo\n;
print refmeta\n;
-print refentrytitlephrase id=\$id\enum
.$args{'enum'}./phrase/refentrytitle\n;
+print refentrytitleenum .$args{'enum'}./refentrytitle\n;
print manvolnum9/manvolnum\n;
print /refmeta\n;
print refnamediv\n;
@@ -816,7 +816,7 @@ sub output_typedef_xml(%) {
print date$man_date/date\n;
print /refentryinfo\n;
print refmeta\n;
-print refentrytitlephrase id=\$id\typedef
.$args{'typedef'}./phrase/refentrytitle\n;
+print refentrytitletypedef .$args{'typedef'}./refentrytitle\n;
print manvolnum9/manvolnum\n;
print /refmeta\n;
print refnamediv\n;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] DocBook/HTML: Generate chapter/section level TOCs for functions
Simple increase of section TOC level generation significantly enhances navigation experience through generated kernel API documentation. This change restores back state from SGML tools time. Signed-off-by: Pavel Pisa <[EMAIL PROTECTED]> Index: linux-2.6.19/Documentation/DocBook/stylesheet.xsl === --- linux-2.6.19.orig/Documentation/DocBook/stylesheet.xsl +++ linux-2.6.19/Documentation/DocBook/stylesheet.xsl @@ -4,4 +4,5 @@ ansi 80 +2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] DocBook/HTML: Generate chapter/section level TOCs for functions
Simple increase of section TOC level generation significantly enhances navigation experience through generated kernel API documentation. This change restores back state from SGML tools time. Signed-off-by: Pavel Pisa [EMAIL PROTECTED] Index: linux-2.6.19/Documentation/DocBook/stylesheet.xsl === --- linux-2.6.19.orig/Documentation/DocBook/stylesheet.xsl +++ linux-2.6.19/Documentation/DocBook/stylesheet.xsl @@ -4,4 +4,5 @@ param name=funcsynopsis.styleansi/param param name=funcsynopsis.tabular.threshold80/param !-- param name=paper.typeA4/param -- +param name=generate.section.toc.level2/param /stylesheet - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Some (unqualified) changes and extensions to the Kernel documentation
Hello All,
excuse me for taking your time.
I have tried to send patch below to the [EMAIL PROTECTED],
where I think it belongs more than there, but because
there has not been any reaction, I am sending it
to whole community. I have not found who is right
target for DocBook changes in MAINTAINERS.
Please redirect me, to the right list, if you do not like
patch there.
I have recompiled Linux kernel 2.6.11.5 documentation
for me and our university students again.
The documentation could be extended for more sources
which are equipped by structured comments for recent 2.6
kernels. I have tried to proceed with that task.
I have done that more times from 2.6.0 time and it gets
boring to do same changes again and again.
Linux kernel compiles after changes for i386 and ARM targets.
I have added references to some more files into kernel-api book,
I have added some section names as well.
So please, check that changes do not break something
and that categories are not too much skewed.
I have changed kernel-doc to accept "fastcall" and "asmlinkage"
words reserved by kernel convention.
Most of the other changes are modifications in the comments to make
kernel-doc happy, accept some parameters description and do
not bail out on errors. Changed to @pid in the description,
moved some #ifdef before comments to correct function to comments
bindings, etc.
You can see result of the modified documentation build at
http://cmp.felk.cvut.cz/~pisa/linux/lkdb-2.6.11.tar.gz
Best wishes
Pavel Pisa
e-mail: [EMAIL PROTECTED]
www:http://cmp.felk.cvut.cz/~pisa
Some more sources are ready to be included into kernel-doc
generated documentation. Sources has been added into
kernel-api for now. Some more section names added
and probably some more chaos introduced as result
of quick cleanup work.
Signed-off-by: Pavel Pisa <[EMAIL PROTECTED]>
---
diff -puN include/linux/skbuff.h~docbook-fix include/linux/skbuff.h
--- linux-2.6.11.5/include/linux/skbuff.h~docbook-fix 2005-03-27
22:19:29.0 +0200
+++ linux-2.6.11.5-root/include/linux/skbuff.h 2005-03-27 22:20:18.0
+0200
@@ -921,6 +921,7 @@ static inline void __skb_queue_purge(str
kfree_skb(skb);
}
+#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
/**
* __dev_alloc_skb - allocate an skbuff for sending
* @length: length to allocate
@@ -933,7 +934,6 @@ static inline void __skb_queue_purge(str
*
* %NULL is returned in there is no free memory.
*/
-#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
static inline struct sk_buff *__dev_alloc_skb(unsigned int length,
int gfp_mask)
{
diff -puN drivers/video/fbmem.c~docbook-fix drivers/video/fbmem.c
--- linux-2.6.11.5/drivers/video/fbmem.c~docbook-fix2005-03-27
22:21:08.0 +0200
+++ linux-2.6.11.5-root/drivers/video/fbmem.c 2005-03-27 22:21:52.0
+0200
@@ -1248,6 +1248,8 @@ int fb_get_options(char *name, char **op
return retval;
}
+extern const char *global_mode_option;
+
/**
* video_setup - process command line options
* @options: string of options
@@ -1262,8 +1264,6 @@ int fb_get_options(char *name, char **op
*
*/
-extern const char *global_mode_option;
-
int __init video_setup(char *options)
{
int i, global = 0;
diff -puN Documentation/DocBook/kernel-api.tmpl~docbook-fix
Documentation/DocBook/kernel-api.tmpl
--- linux-2.6.11.5/Documentation/DocBook/kernel-api.tmpl~docbook-fix
2005-03-27 22:22:45.0 +0200
+++ linux-2.6.11.5-root/Documentation/DocBook/kernel-api.tmpl 2005-03-28
12:20:44.0 +0200
@@ -46,13 +46,33 @@
!Iinclude/asm-i386/unaligned.h
-
+
+ Kernel objects manipulation
+
+!Elib/kobject.c
+
+
+ Kernel utility functions
+!Iinclude/linux/kernel.h
+
+!Ekernel/panic.c
+!Ekernel/sys.c
+!Ekernel/rcupdate.c
+
+
@@ -78,7 +98,9 @@ KAO -->
!Elib/vsprintf.c
String Manipulation
-!Ilib/string.c
+
!Elib/string.c
Bit Operations
@@ -95,6 +117,25 @@ KAO -->
!Iinclude/asm-i386/uaccess.h
!Iarch/i386/lib/usercopy.c
+ More Memory Management Functions
+!Iinclude/linux/rmap.h
+!Emm/readahead.c
+!Emm/filemap.c
+!Emm/memory.c
+!Emm/vmalloc.c
+!Emm/mempool.c
+!Emm/page-writeback.c
+!Emm/truncate.c
+
+
+
+
+
+ Kernel IPC facilities
+
+ IPC utilities
+!Iipc/util.c
+
@@ -103,6 +144,10 @@ KAO -->
sysctl interface
!Ekernel/sysctl.c
+
+ proc filesystem interface
+!Ifs/proc/base.c
+
@@ -116,6 +161,10 @@ KAO -->
The Linux VFS
+ The Filesystem types
+!Iinclude/linux/fs.h
+!Einclude/linux/fs.h
+
The Directory Cache
!Efs/dcache.c
!Iinclude/linux/dcache.h
@@ -131,13 +180,31 @@ KAO -->
!Efs/locks.c
!Ifs/locks.c
+ Other Functions
+!Efs/mpage.c
+!Efs/namei.c
+!Efs/buffer.c
+!Efs/bio.c
+!Efs/seq_file.c
+!Efs/filesystems
Some (unqualified) changes and extensions to the Kernel documentation
Hello All,
excuse me for taking your time.
I have tried to send patch below to the [EMAIL PROTECTED],
where I think it belongs more than there, but because
there has not been any reaction, I am sending it
to whole community. I have not found who is right
target for DocBook changes in MAINTAINERS.
Please redirect me, to the right list, if you do not like
patch there.
I have recompiled Linux kernel 2.6.11.5 documentation
for me and our university students again.
The documentation could be extended for more sources
which are equipped by structured comments for recent 2.6
kernels. I have tried to proceed with that task.
I have done that more times from 2.6.0 time and it gets
boring to do same changes again and again.
Linux kernel compiles after changes for i386 and ARM targets.
I have added references to some more files into kernel-api book,
I have added some section names as well.
So please, check that changes do not break something
and that categories are not too much skewed.
I have changed kernel-doc to accept fastcall and asmlinkage
words reserved by kernel convention.
Most of the other changes are modifications in the comments to make
kernel-doc happy, accept some parameters description and do
not bail out on errors. Changed pid to @pid in the description,
moved some #ifdef before comments to correct function to comments
bindings, etc.
You can see result of the modified documentation build at
http://cmp.felk.cvut.cz/~pisa/linux/lkdb-2.6.11.tar.gz
Best wishes
Pavel Pisa
e-mail: [EMAIL PROTECTED]
www:http://cmp.felk.cvut.cz/~pisa
Some more sources are ready to be included into kernel-doc
generated documentation. Sources has been added into
kernel-api for now. Some more section names added
and probably some more chaos introduced as result
of quick cleanup work.
Signed-off-by: Pavel Pisa [EMAIL PROTECTED]
---
diff -puN include/linux/skbuff.h~docbook-fix include/linux/skbuff.h
--- linux-2.6.11.5/include/linux/skbuff.h~docbook-fix 2005-03-27
22:19:29.0 +0200
+++ linux-2.6.11.5-root/include/linux/skbuff.h 2005-03-27 22:20:18.0
+0200
@@ -921,6 +921,7 @@ static inline void __skb_queue_purge(str
kfree_skb(skb);
}
+#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
/**
* __dev_alloc_skb - allocate an skbuff for sending
* @length: length to allocate
@@ -933,7 +934,6 @@ static inline void __skb_queue_purge(str
*
* %NULL is returned in there is no free memory.
*/
-#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
static inline struct sk_buff *__dev_alloc_skb(unsigned int length,
int gfp_mask)
{
diff -puN drivers/video/fbmem.c~docbook-fix drivers/video/fbmem.c
--- linux-2.6.11.5/drivers/video/fbmem.c~docbook-fix2005-03-27
22:21:08.0 +0200
+++ linux-2.6.11.5-root/drivers/video/fbmem.c 2005-03-27 22:21:52.0
+0200
@@ -1248,6 +1248,8 @@ int fb_get_options(char *name, char **op
return retval;
}
+extern const char *global_mode_option;
+
/**
* video_setup - process command line options
* @options: string of options
@@ -1262,8 +1264,6 @@ int fb_get_options(char *name, char **op
*
*/
-extern const char *global_mode_option;
-
int __init video_setup(char *options)
{
int i, global = 0;
diff -puN Documentation/DocBook/kernel-api.tmpl~docbook-fix
Documentation/DocBook/kernel-api.tmpl
--- linux-2.6.11.5/Documentation/DocBook/kernel-api.tmpl~docbook-fix
2005-03-27 22:22:45.0 +0200
+++ linux-2.6.11.5-root/Documentation/DocBook/kernel-api.tmpl 2005-03-28
12:20:44.0 +0200
@@ -46,13 +46,33 @@
!Iinclude/asm-i386/unaligned.h
/sect1
-!-- FIXME:
- kernel/sched.c has no docs, which stuffs up the sgml. Comment
- out until somebody adds docs. KAO
sect1titleDelaying, scheduling, and timer routines/title
-X!Ekernel/sched.c
+!Iinclude/linux/sched.h
+!Ekernel/sched.c
+!Ekernel/timer.c
+ /sect1
+ sect1titleInternal Functions/title
+!Ikernel/exit.c
+!Ikernel/signal.c
/sect1
-KAO --
+
+ sect1titleKernel objects manipulation/title
+!--
+X!Iinclude/linux/kobject.h
+--
+!Elib/kobject.c
+ /sect1
+
+ sect1titleKernel utility functions/title
+!Iinclude/linux/kernel.h
+!-- This needs to clean up to make kernel-doc happy
+X!Ekernel/printk.c
+ --
+!Ekernel/panic.c
+!Ekernel/sys.c
+!Ekernel/rcupdate.c
+ /sect1
+
/chapter
chapter id=adt
@@ -78,7 +98,9 @@ KAO --
!Elib/vsprintf.c
/sect1
sect1titleString Manipulation/title
-!Ilib/string.c
+!-- All functions are exported at now
+X!Ilib/string.c
+ --
!Elib/string.c
/sect1
sect1titleBit Operations/title
@@ -95,6 +117,25 @@ KAO --
!Iinclude/asm-i386/uaccess.h
!Iarch/i386/lib/usercopy.c
/sect1
+ sect1titleMore Memory Management Functions/title
+!Iinclude/linux/rmap.h
+!Emm/readahead.c
+!Emm/filemap.c
+!Emm/memory.c
+!Emm/vmalloc.c
+!Emm/mempool.c
+!Emm/page-writeback.c
+!Emm/truncate.c
+ /sect1
Re: gcc-2.95.2-51 is buggy
Hello all, I have used patch from GCC-PATCHES list posted by Bernd Schmidt . Because of high importance I am forwarding this patch to Linux-Kernel. Patch seems to solve problem. I have added warning print for case of problem, to find which parts of Linux kernel could be affected by this GCC bug. There are results: linux-2.4.0-test10-pre? compiled for K7 make[2]: Entering directory `/usr/src/linux-2.4.0-t9/fs' gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-t9/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fno-strict-aliasing-c -o block_dev.o block_dev.c block_dev.c: In function `block_read': block_dev.c:311: warning: possible original gcc 2.95.2 error c/877 make[2]: Entering directory `/usr/src/linux-2.4.0-t9/ipc' gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-t9/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fno-strict-aliasing-c -o msg.o msg.c msg.c: In function `sys_msgctl': msg.c:576: warning: possible original gcc 2.95.2 error c/877 gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-t9/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fno-strict-aliasing-c -o sem.o sem.c I have run same compilation for 2.2.15 kernel compiled for K6 make[2]: Entering directory `/usr/src/linux-2.2.15/fs' block_dev.c: In function `block_read': block_dev.c:304: warning: possible original gcc 2.95.2 error c/877 I hope that my mail is not only waste of your time. These possible wrong compiled files could be sources of other false kernel related bugs. If you have interest I will to try to compile 2.2.x and 2.4.0-x kernels for bare i586 to find more such problematic places. Best wishes Pavel Pisa PS: For faster response CC any reply directly to my address, please. - To: aeb at cwi dot nl Subject: Re: c/877: gcc 2.95.2 generates incorrect code on i386 From: Bernd Schmidt Date: Fri, 24 Nov 2000 15:40:05 + (GMT) cc: gcc-gnats at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org On 24 Nov 2000 [EMAIL PROTECTED] wrote: > >Synopsis: gcc 2.95.2 generates incorrect code on i386 > It seems that a variable length shift of a long long > is miscompiled. This causes Linux kernel bugs. This is (as usual) a bug in reload. We have two insns: (insn 69 67 70 (set (reg:QI 46) (subreg:QI (reg:SI 43) 0)) (insn 70 69 72 (set (reg:DI 44) (ashiftrt:DI (reg:DI 44) (reg:QI 46))) (expr_list:REG_DEAD 46) Neither reg 46 nor reg 44 gets a hard register. While processing insn 70, reload decides that it will need reg 2 (%cl) for reg 46, and reg 3/4 (%ebx/%esi) for reg 44. It also notices that the value of reg 44 is already available in reg 1/2 (%edx/%ecx), so it can avoid loading it from the stack and instead use reg 1/2 as overriding input. It then notices that reg 46 dies in insn 70 and is set in insn 69, so it would be possible simply to replace the destination of insn 69 with the reload reg (%cl). The problem is that by changing insn 69 to store into %cl, the input override for the other reload gets clobbered. Oops. The function reload_reg_free_for_value_p doesn't test for this case. I'm currently bootstrapping with the patch below; I'll check it in (along with a testcase) once that finishes. It won't apply cleanly to 2.95, but it should be quite easy to figure out how to apply it. This is an obvious candidate should we decide to make a 2.95.3 release. (As a side note, this bug has nothing to do with the fact that there's a long long shift in this testcase, although I think I've noticed a bunch of potential bugs related to multiword values in the reload inheritance code while looking at this testcase...) Bernd * reload1.c (conflicts_with_override): New function. (emit_input_reload_insns): Use it to tighten test for validity of substituting into output of previous insn. Index: reload1.c === RCS file: /cvs/gcc/egcs/gcc/reload1.c,v retrieving revision 1.241 diff -u -p -r1.241 reload1.c --- reload1.c 2000/11/14 10:23:37 1.241 +++ reload1.c 2000/11/24 15:11:43 @@ -417,6 +417,7 @@ static int reload_reg_reaches_end_p PARA enum reload_type)); static int allocate_reload_reg PARAMS ((struct insn_chain *, int, int)); +static int conflicts_with_override PARAMS ((rtx)); static void failed_reload PARAMS ((rtx, int)); static int set_reload_reg PARAMS ((int, int)); static void choose_reload_regs_initPARAMS ((struct insn_chain *, rtx *))
Re: gcc-2.95.2-51 is buggy
Hello all, I have used patch from GCC-PATCHES list posted by Bernd Schmidt bernds at redhat dot com. Because of high importance I am forwarding this patch to Linux-Kernel. Patch seems to solve problem. I have added warning print for case of problem, to find which parts of Linux kernel could be affected by this GCC bug. There are results: linux-2.4.0-test10-pre? compiled for K7 make[2]: Entering directory `/usr/src/linux-2.4.0-t9/fs' gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-t9/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fno-strict-aliasing-c -o block_dev.o block_dev.c block_dev.c: In function `block_read': block_dev.c:311: warning: possible original gcc 2.95.2 error c/877 make[2]: Entering directory `/usr/src/linux-2.4.0-t9/ipc' gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-t9/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fno-strict-aliasing-c -o msg.o msg.c msg.c: In function `sys_msgctl': msg.c:576: warning: possible original gcc 2.95.2 error c/877 gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-t9/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fno-strict-aliasing-c -o sem.o sem.c I have run same compilation for 2.2.15 kernel compiled for K6 make[2]: Entering directory `/usr/src/linux-2.2.15/fs' block_dev.c: In function `block_read': block_dev.c:304: warning: possible original gcc 2.95.2 error c/877 I hope that my mail is not only waste of your time. These possible wrong compiled files could be sources of other false kernel related bugs. If you have interest I will to try to compile 2.2.x and 2.4.0-x kernels for bare i586 to find more such problematic places. Best wishes Pavel Pisa PS: For faster response CC any reply directly to my address, please. - To: aeb at cwi dot nl Subject: Re: c/877: gcc 2.95.2 generates incorrect code on i386 From: Bernd Schmidt bernds at redhat dot com Date: Fri, 24 Nov 2000 15:40:05 + (GMT) cc: gcc-gnats at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org On 24 Nov 2000 [EMAIL PROTECTED] wrote: Synopsis: gcc 2.95.2 generates incorrect code on i386 It seems that a variable length shift of a long long is miscompiled. This causes Linux kernel bugs. This is (as usual) a bug in reload. We have two insns: (insn 69 67 70 (set (reg:QI 46) (subreg:QI (reg:SI 43) 0)) (insn 70 69 72 (set (reg:DI 44) (ashiftrt:DI (reg:DI 44) (reg:QI 46))) (expr_list:REG_DEAD 46) Neither reg 46 nor reg 44 gets a hard register. While processing insn 70, reload decides that it will need reg 2 (%cl) for reg 46, and reg 3/4 (%ebx/%esi) for reg 44. It also notices that the value of reg 44 is already available in reg 1/2 (%edx/%ecx), so it can avoid loading it from the stack and instead use reg 1/2 as overriding input. It then notices that reg 46 dies in insn 70 and is set in insn 69, so it would be possible simply to replace the destination of insn 69 with the reload reg (%cl). The problem is that by changing insn 69 to store into %cl, the input override for the other reload gets clobbered. Oops. The function reload_reg_free_for_value_p doesn't test for this case. I'm currently bootstrapping with the patch below; I'll check it in (along with a testcase) once that finishes. It won't apply cleanly to 2.95, but it should be quite easy to figure out how to apply it. This is an obvious candidate should we decide to make a 2.95.3 release. (As a side note, this bug has nothing to do with the fact that there's a long long shift in this testcase, although I think I've noticed a bunch of potential bugs related to multiword values in the reload inheritance code while looking at this testcase...) Bernd * reload1.c (conflicts_with_override): New function. (emit_input_reload_insns): Use it to tighten test for validity of substituting into output of previous insn. Index: reload1.c === RCS file: /cvs/gcc/egcs/gcc/reload1.c,v retrieving revision 1.241 diff -u -p -r1.241 reload1.c --- reload1.c 2000/11/14 10:23:37 1.241 +++ reload1.c 2000/11/24 15:11:43 @@ -417,6 +417,7 @@ static int reload_reg_reaches_end_p PARA enum reload_type)); static int allocate_reload_reg PARAMS ((struct insn_chain *, int, int)); +static int conflicts_with_override PARAMS ((rtx)); static void failed_reload PARAMS ((rtx, int)); static int set_reload_reg PARAMS ((int, int)); static void choose_reload_regs_init
