Re: [PATCH v7 0/6] CTU CAN FD open-source IP core SocketCAN driver, PCI, platform integration and documentation

2020-11-03 Thread Pavel Pisa
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.

2020-10-30 Thread Pavel Pisa
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.

2020-10-30 Thread Pavel Pisa
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.

2020-10-30 Thread Pavel Pisa
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.

2020-10-30 Thread Pavel Pisa
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.

2020-10-30 Thread Pavel Pisa
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.

2020-10-30 Thread Pavel Pisa
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

2020-10-30 Thread 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-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.

2020-10-26 Thread Pavel Pisa
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.

2020-10-26 Thread Pavel Pisa
> > +   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.

2020-10-22 Thread Pavel Pisa
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.

2020-10-22 Thread Pavel Pisa
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.

2020-10-22 Thread Pavel Pisa
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.

2020-10-22 Thread Pavel Pisa
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

2020-10-22 Thread 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 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.

2020-10-22 Thread Pavel Pisa
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.

2020-10-22 Thread Pavel Pisa
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.

2020-10-22 Thread Pavel Pisa
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.

2020-10-22 Thread Pavel Pisa
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.

2020-10-22 Thread Pavel Pisa
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

2020-08-25 Thread Pavel Pisa
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.

2020-08-15 Thread Pavel Pisa
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.

2020-08-15 Thread Pavel Pisa
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.

2020-08-15 Thread Pavel Pisa
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.

2020-08-15 Thread Pavel Pisa
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.

2020-08-15 Thread Pavel Pisa
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

2020-08-15 Thread Pavel Pisa
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.

2020-08-06 Thread Pavel Pisa
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.

2020-08-01 Thread Pavel Pisa
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.

2020-07-28 Thread Pavel Pisa
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.

2019-02-22 Thread Pavel Pisa
>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.*

2012-11-24 Thread Pavel Pisa
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.*

2012-11-24 Thread Pavel Pisa
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

2007-08-13 Thread Pavel Pisa
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

2007-08-13 Thread Pavel Pisa
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

2007-05-14 Thread Pavel Pisa
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

2007-05-14 Thread Pavel Pisa
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]

2007-04-16 Thread Pavel Pisa
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]

2007-04-16 Thread Pavel Pisa
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]

2007-04-15 Thread Pavel Pisa
 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]

2007-04-15 Thread Pavel Pisa
 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

2007-03-11 Thread Pavel Pisa
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

2007-03-11 Thread Pavel Pisa
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

2007-02-09 Thread Pavel Pisa
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

2007-02-09 Thread Pavel Pisa
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

2007-02-09 Thread Pavel Pisa
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

2007-02-09 Thread Pavel Pisa
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

2007-01-26 Thread Pavel Pisa
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

2007-01-26 Thread Pavel Pisa
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

2007-01-23 Thread Pavel Pisa
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

2007-01-23 Thread Pavel Pisa
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

2007-01-22 Thread Pavel Pisa
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

2007-01-22 Thread Pavel Pisa
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 ?

2007-01-21 Thread Pavel Pisa
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 ?

2007-01-21 Thread Pavel Pisa
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 ?

2007-01-20 Thread Pavel Pisa
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

2007-01-20 Thread Pavel Pisa
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

2007-01-20 Thread Pavel Pisa
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 ?

2007-01-20 Thread Pavel Pisa
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

2007-01-08 Thread Pavel Pisa
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

2007-01-08 Thread Pavel Pisa
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

2007-01-08 Thread Pavel Pisa
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

2007-01-08 Thread Pavel Pisa
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

2007-01-05 Thread Pavel Pisa
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

2007-01-05 Thread Pavel Pisa
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

2007-01-02 Thread Pavel Pisa
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

2007-01-02 Thread Pavel Pisa
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

2006-12-30 Thread Pavel Pisa
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

2006-12-30 Thread Pavel Pisa
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

2005-04-01 Thread Pavel Pisa
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

2005-04-01 Thread Pavel Pisa
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

2000-11-27 Thread Pavel Pisa;research student

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

2000-11-27 Thread Pavel Pisa;research student

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