* [PATCH v3 24/27] can: replace devm_ioremap_nocache with devm_ioremap
From: Yisheng Xie @ 2017-12-23 11:02 UTC (permalink / raw)
To: linux-kernel, gregkh
Cc: ysxie, Yisheng Xie, Wolfgang Grandegger, Marc Kleine-Budde,
linux-can, netdev
Default ioremap is ioremap_nocache, so devm_ioremap has the same
function with devm_ioremap_nocache, which can just be killed to
save the size of devres.o
This patch is to use use devm_ioremap instead of devm_ioremap_nocache,
which should not have any function change but prepare for killing
devm_ioremap_nocache.
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
---
drivers/net/can/sja1000/sja1000_platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/sja1000/sja1000_platform.c b/drivers/net/can/sja1000/sja1000_platform.c
index dc9c6db..c59500c 100644
--- a/drivers/net/can/sja1000/sja1000_platform.c
+++ b/drivers/net/can/sja1000/sja1000_platform.c
@@ -240,8 +240,8 @@ static int sp_probe(struct platform_device *pdev)
resource_size(res_mem), DRV_NAME))
return -EBUSY;
- addr = devm_ioremap_nocache(&pdev->dev, res_mem->start,
- resource_size(res_mem));
+ addr = devm_ioremap(&pdev->dev, res_mem->start,
+ resource_size(res_mem));
if (!addr)
return -ENOMEM;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 00/27] kill devm_ioremap_nocache
From: Yisheng Xie @ 2017-12-23 10:55 UTC (permalink / raw)
To: linux-kernel, gregkh
Cc: ysxie, ulf.hansson, linux-mmc, boris.brezillon, richard,
marek.vasut, cyrille.pitchen, linux-mtd, alsa-devel, wim, linux,
linux-watchdog, b.zolnierkie, linux-fbdev, linus.walleij,
linux-gpio, ralf, linux-mips, lgirdwood, broonie, tglx, jason,
marc.zyngier, arnd, andriy.shevchenko, industrypack-devel, wg,
mkl, linux-can, mcheh
Hi all,
When I tried to use devm_ioremap function and review related code, I found
devm_ioremap and devm_ioremap_nocache is almost the same with each other,
except one use ioremap while the other use ioremap_nocache. While ioremap's
default function is ioremap_nocache, so devm_ioremap_nocache also have the
same function with devm_ioremap, which can just be killed to reduce the size
of devres.o(from 20304 bytes to 18992 bytes in my compile environment).
I have posted two versions, which use macro instead of function for
devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
devm_ioremap_nocache for no need to keep a macro around for the duplicate
thing. So here comes v3 and please help to review.
Thanks so much!
Yisheng Xie
[1] https://lkml.org/lkml/2017/11/20/135
[2] https://lkml.org/lkml/2017/11/25/21
Yisheng Xie (27):
ASOC: replace devm_ioremap_nocache with devm_ioremap
spi: replace devm_ioremap_nocache with devm_ioremap
staging: replace devm_ioremap_nocache with devm_ioremap
ipack: replace devm_ioremap_nocache with devm_ioremap
media: replace devm_ioremap_nocache with devm_ioremap
gpio: replace devm_ioremap_nocache with devm_ioremap
mmc: replace devm_ioremap_nocache with devm_ioremap
PCI: replace devm_ioremap_nocache with devm_ioremap
platform/x86: replace devm_ioremap_nocache with devm_ioremap
tty: replace devm_ioremap_nocache with devm_ioremap
video: replace devm_ioremap_nocache with devm_ioremap
rtc: replace devm_ioremap_nocache with devm_ioremap
char: replace devm_ioremap_nocache with devm_ioremap
mtd: nand: replace devm_ioremap_nocache with devm_ioremap
dmaengine: replace devm_ioremap_nocache with devm_ioremap
ata: replace devm_ioremap_nocache with devm_ioremap
irqchip: replace devm_ioremap_nocache with devm_ioremap
pinctrl: replace devm_ioremap_nocache with devm_ioremap
drm: replace devm_ioremap_nocache with devm_ioremap
regulator: replace devm_ioremap_nocache with devm_ioremap
watchdog: replace devm_ioremap_nocache with devm_ioremap
tools/testing/nvdimm: replace devm_ioremap_nocache with devm_ioremap
MIPS: pci: replace devm_ioremap_nocache with devm_ioremap
can: replace devm_ioremap_nocache with devm_ioremap
wireless: replace devm_ioremap_nocache with devm_ioremap
ethernet: replace devm_ioremap_nocache with devm_ioremap
devres: kill devm_ioremap_nocache
Documentation/driver-model/devres.txt | 1 -
arch/mips/pci/pci-ar2315.c | 3 +--
drivers/ata/pata_arasan_cf.c | 3 +--
drivers/ata/pata_octeon_cf.c | 9 ++++----
drivers/ata/pata_rb532_cf.c | 2 +-
drivers/char/hw_random/bcm63xx-rng.c | 3 +--
drivers/char/hw_random/octeon-rng.c | 10 ++++-----
drivers/dma/altera-msgdma.c | 3 +--
drivers/dma/sprd-dma.c | 4 ++--
drivers/gpio/gpio-ath79.c | 3 +--
drivers/gpio/gpio-em.c | 6 ++---
drivers/gpio/gpio-htc-egpio.c | 4 ++--
drivers/gpio/gpio-xgene.c | 3 +--
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
drivers/gpu/drm/msm/msm_drv.c | 2 +-
drivers/gpu/drm/sti/sti_dvo.c | 3 +--
drivers/gpu/drm/sti/sti_hda.c | 4 ++--
drivers/gpu/drm/sti/sti_hdmi.c | 2 +-
drivers/gpu/drm/sti/sti_tvout.c | 2 +-
drivers/gpu/drm/sti/sti_vtg.c | 2 +-
drivers/ipack/devices/ipoctal.c | 13 +++++------
drivers/irqchip/irq-renesas-intc-irqpin.c | 4 ++--
drivers/media/platform/tegra-cec/tegra_cec.c | 4 ++--
drivers/mmc/host/sdhci-acpi.c | 3 +--
drivers/mtd/nand/fsl_upm.c | 4 ++--
drivers/net/can/sja1000/sja1000_platform.c | 4 ++--
drivers/net/ethernet/altera/altera_tse_main.c | 3 +--
drivers/net/ethernet/ethoc.c | 8 +++----
drivers/net/ethernet/lantiq_etop.c | 4 ++--
drivers/net/ethernet/ti/netcp_core.c | 2 +-
drivers/net/wireless/ath/ath9k/ahb.c | 2 +-
drivers/pci/dwc/pci-dra7xx.c | 2 +-
drivers/pinctrl/bcm/pinctrl-ns2-mux.c | 2 +-
drivers/pinctrl/bcm/pinctrl-nsp-mux.c | 4 ++--
drivers/pinctrl/freescale/pinctrl-imx1-core.c | 2 +-
drivers/pinctrl/pinctrl-amd.c | 4 ++--
drivers/platform/x86/intel_pmc_core.c | 5 ++---
drivers/regulator/ti-abb-regulator.c | 6 ++---
drivers/rtc/rtc-sh.c | 4 ++--
drivers/spi/spi-jcore.c | 3 +--
drivers/staging/fsl-mc/bus/mc-io.c | 8 +++----
drivers/tty/mips_ejtag_fdc.c | 4 ++--
drivers/tty/serial/8250/8250_omap.c | 3 +--
drivers/tty/serial/lantiq.c | 3 +--
drivers/tty/serial/meson_uart.c | 3 +--
drivers/tty/serial/owl-uart.c | 2 +-
drivers/tty/serial/pic32_uart.c | 4 ++--
drivers/video/fbdev/mbx/mbxfb.c | 9 ++++----
drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 2 +-
drivers/video/fbdev/pxa168fb.c | 4 ++--
drivers/watchdog/bcm63xx_wdt.c | 4 ++--
drivers/watchdog/rc32434_wdt.c | 4 ++--
include/linux/io.h | 2 --
lib/devres.c | 29 -------------------------
scripts/coccinelle/free/devm_free.cocci | 2 --
sound/soc/au1x/ac97c.c | 4 ++--
sound/soc/au1x/i2sc.c | 4 ++--
sound/soc/intel/atom/sst/sst_acpi.c | 20 ++++++++---------
sound/soc/intel/boards/mfld_machine.c | 4 ++--
sound/soc/sh/fsi.c | 4 ++--
tools/testing/nvdimm/Kbuild | 2 +-
tools/testing/nvdimm/test/iomap.c | 2 +-
62 files changed, 109 insertions(+), 168 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH 1/2] dt-binding: can: mcp2517fd: document device tree bindings
From: Patrick Menschel @ 2017-12-22 15:50 UTC (permalink / raw)
To: kernel-TqfNSX0MhmxHKSADF0wUEw
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA, devicetree
In-Reply-To: <4E2DB518-A148-46CE-8267-73D292991BD2-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]
Hi Martin,
as I wrote earlier, I would save the GPIO_LIB part for a driver update
later on as to me there seems to be no daily use case.
I think SLEEP is the preferred solution.
If the device is in SLEEP after probing, the logical step would be to
disable GPIO functions and configure INT0/GPIO0/XSTBY to XSTBY thus the
transceiver is also sleeping.
Best practice usually comes from practical usage.
If there already is a reference design PCB with the mcp2517fd, it would
make sense to see what the designer did connect to the optional GPIO
pins and then guess what additional use cases could be of interest.
Without that knowledge, you're prone to do over-engineering.
Regards,
Patrick
Am 17.12.2017 um 15:34 schrieb kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org:
> Hi Patrick!
>
> So I started implementing the GPIO_LIB implementation but
> I have hit an issue where I would like to get some feedback.
>
> So in principle the gpiolib works, but only if the device is
> not asleep and the clock is enabled, which at this very moment means
> that the can interface has to be up and running.
>
> So at this very moment the only option that I see would be to
> disable the sleep mode which the device enters after probing until
> the can-network interface is enabled (which enables the clock and
> start the oscillator) - with SLEEP enabled when GPIOLIB support
> is disabled.
>
> This is obviously not optimal from the power perspective…
>
> The other option would be starting the clock and oscillator
> as soon as a set_direction* (or reques/free) function is called.
> (where I would need to start using locks to avoid race conditions
> as well as clock usage counters...).
>
> Which of the above is the preferred solution? Are there other ideas
> how I could solve this dilemma?
>
>
> Martin
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3992 bytes --]
^ permalink raw reply
* [PATCH v6 6/6] dt-bindings: can: can-transceiver: Document new binding
From: Faiz Abbas @ 2017-12-22 13:31 UTC (permalink / raw)
To: wg, mkl, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, faiz_abbas, nsekhar,
fcooper, robh, Wenyou.Yang, sergei.shtylyov
In-Reply-To: <1513949488-13026-1-git-send-email-faiz_abbas@ti.com>
From: Franklin S Cooper Jr <fcooper@ti.com>
Add documentation to describe usage of the new can-transceiver binding.
This new binding is applicable for any CAN device therefore it exists as
its own document.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
.../bindings/net/can/can-transceiver.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/can/can-transceiver.txt
diff --git a/Documentation/devicetree/bindings/net/can/can-transceiver.txt b/Documentation/devicetree/bindings/net/can/can-transceiver.txt
new file mode 100644
index 0000000..0011f53
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/can-transceiver.txt
@@ -0,0 +1,24 @@
+Generic CAN transceiver Device Tree binding
+------------------------------
+
+CAN transceiver typically limits the max speed in standard CAN and CAN FD
+modes. Typically these limitations are static and the transceivers themselves
+provide no way to detect this limitation at runtime. For this situation,
+the "can-transceiver" node can be used.
+
+Required Properties:
+ max-bitrate: a positive non 0 value that determines the max
+ speed that CAN/CAN-FD can run. Any other value
+ will be ignored.
+
+Examples:
+
+Based on Texas Instrument's TCAN1042HGV CAN Transceiver
+
+m_can0 {
+ ....
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
+ ...
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v6 5/6] dt-bindings: can: m_can: Document new can transceiver binding
From: Faiz Abbas @ 2017-12-22 13:31 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, faiz_abbas-l0cyMroinI0,
nsekhar-l0cyMroinI0, fcooper-l0cyMroinI0,
robh-DgEjT+Ai2ygdnm+yROfE0A, Wenyou.Yang-UWL1GkI3JZL3oGB3hsPCZA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8
In-Reply-To: <1513949488-13026-1-git-send-email-faiz_abbas-l0cyMroinI0@public.gmane.org>
From: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
Add information regarding can-transceiver binding. This is especially
important for MCAN since the IP allows CAN FD mode to run significantly
faster than what most transceivers are capable of.
Signed-off-by: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Faiz Abbas <faiz_abbas-l0cyMroinI0@public.gmane.org>
---
Documentation/devicetree/bindings/net/can/m_can.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt b/Documentation/devicetree/bindings/net/can/m_can.txt
index 63e9042..ed61438 100644
--- a/Documentation/devicetree/bindings/net/can/m_can.txt
+++ b/Documentation/devicetree/bindings/net/can/m_can.txt
@@ -43,6 +43,11 @@ Required properties:
Please refer to 2.4.1 Message RAM Configuration in
Bosch M_CAN user manual for details.
+Optional Subnode:
+- can-transceiver : Can-transceiver subnode describing maximum speed
+ that can be used for CAN/CAN-FD modes. See
+ Documentation/devicetree/bindings/net/can/can-transceiver.txt
+ for details.
Example:
SoC dtsi:
m_can1: can@20e8000 {
@@ -63,4 +68,8 @@ Board dts:
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_m_can1>;
status = "enabled";
+
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v6 3/6] can: m_can: Add PM Runtime
From: Faiz Abbas @ 2017-12-22 13:31 UTC (permalink / raw)
To: wg, mkl, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, faiz_abbas, nsekhar,
fcooper, robh, Wenyou.Yang, sergei.shtylyov
In-Reply-To: <1513949488-13026-1-git-send-email-faiz_abbas@ti.com>
From: Franklin S Cooper Jr <fcooper@ti.com>
Add support for PM Runtime which is the new way to handle managing clocks.
However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk
management approach in place.
PM_RUNTIME is required by OMAP based devices to handle clock management.
Therefore, this allows future Texas Instruments SoCs that have the MCAN IP
to work with this driver.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
[nsekhar@ti.com: handle pm_runtime_get_sync() failure, fix some bugs]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
drivers/net/can/m_can/m_can.c | 38 ++++++++++++++++++++++++++++++++++----
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index f72116e..53e764f 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -23,6 +23,7 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/iopoll.h>
#include <linux/can/dev.h>
@@ -625,19 +626,33 @@ static int m_can_clk_start(struct m_can_priv *priv)
{
int err;
+ err = pm_runtime_get_sync(priv->device);
+ if (err) {
+ pm_runtime_put_noidle(priv->device);
+ return err;
+ }
+
err = clk_prepare_enable(priv->hclk);
if (err)
- return err;
+ goto pm_runtime_put;
err = clk_prepare_enable(priv->cclk);
if (err)
- clk_disable_unprepare(priv->hclk);
+ goto disable_hclk;
return err;
+
+disable_hclk:
+ clk_disable_unprepare(priv->hclk);
+pm_runtime_put:
+ pm_runtime_put_sync(priv->device);
+ return err;
}
static void m_can_clk_stop(struct m_can_priv *priv)
{
+ pm_runtime_put_sync(priv->device);
+
clk_disable_unprepare(priv->cclk);
clk_disable_unprepare(priv->hclk);
}
@@ -1577,13 +1592,20 @@ static int m_can_plat_probe(struct platform_device *pdev)
/* Enable clocks. Necessary to read Core Release in order to determine
* M_CAN version
*/
+ pm_runtime_enable(&pdev->dev);
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret) {
+ pm_runtime_put_noidle(&pdev->dev);
+ goto pm_runtime_fail;
+ }
+
ret = clk_prepare_enable(hclk);
if (ret)
- goto disable_hclk_ret;
+ goto pm_runtime_put;
ret = clk_prepare_enable(cclk);
if (ret)
- goto disable_cclk_ret;
+ goto disable_hclk_ret;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "m_can");
addr = devm_ioremap_resource(&pdev->dev, res);
@@ -1666,6 +1688,11 @@ static int m_can_plat_probe(struct platform_device *pdev)
clk_disable_unprepare(cclk);
disable_hclk_ret:
clk_disable_unprepare(hclk);
+pm_runtime_put:
+ pm_runtime_put_sync(&pdev->dev);
+pm_runtime_fail:
+ if (ret)
+ pm_runtime_disable(&pdev->dev);
failed_ret:
return ret;
}
@@ -1723,6 +1750,9 @@ static int m_can_plat_remove(struct platform_device *pdev)
struct net_device *dev = platform_get_drvdata(pdev);
unregister_m_can_dev(dev);
+
+ pm_runtime_disable(&pdev->dev);
+
platform_set_drvdata(pdev, NULL);
free_m_can_dev(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH v6 2/6] can: m_can: Add call to of_can_transceiver
From: Faiz Abbas @ 2017-12-22 13:31 UTC (permalink / raw)
To: wg, mkl, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, faiz_abbas, nsekhar,
fcooper, robh, Wenyou.Yang, sergei.shtylyov
In-Reply-To: <1513949488-13026-1-git-send-email-faiz_abbas@ti.com>
From: Franklin S Cooper Jr <fcooper@ti.com>
Add call to new generic functions that provides support via a binding
to limit the arbitration rate and/or data rate imposed by the physical
transceiver connected to the MCAN peripheral.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index f4947a7..f72116e 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1649,6 +1649,8 @@ static int m_can_plat_probe(struct platform_device *pdev)
devm_can_led_init(dev);
+ of_can_transceiver(dev);
+
dev_info(&pdev->dev, "%s device registered (irq=%d, version=%d)\n",
KBUILD_MODNAME, dev->irq, priv->version);
--
2.7.4
^ permalink raw reply related
* [PATCH v6 1/6] can: dev: Add support for limiting configured bitrate
From: Faiz Abbas @ 2017-12-22 13:31 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, faiz_abbas-l0cyMroinI0,
nsekhar-l0cyMroinI0, fcooper-l0cyMroinI0,
robh-DgEjT+Ai2ygdnm+yROfE0A, Wenyou.Yang-UWL1GkI3JZL3oGB3hsPCZA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8
In-Reply-To: <1513949488-13026-1-git-send-email-faiz_abbas-l0cyMroinI0@public.gmane.org>
From: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
Various CAN or CAN-FD IP may be able to run at a faster rate than
what the transceiver the CAN node is connected to. This can lead to
unexpected errors. However, CAN transceivers typically have fixed
limitations and provide no means to discover these limitations at
runtime. Therefore, add support for a can-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.
Signed-off-by: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
[nsekhar-l0cyMroinI0@public.gmane.org: fix build error with !CONFIG_OF]
Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
Signed-off-by: Faiz Abbas <faiz_abbas-l0cyMroinI0@public.gmane.org>
---
v6 changes:
fix build error with !CONFIG_OF
drivers/net/can/dev.c | 39 +++++++++++++++++++++++++++++++++++++++
include/linux/can/dev.h | 8 ++++++++
2 files changed, 47 insertions(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 365a8cc..007cfc0 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -27,6 +27,7 @@
#include <linux/can/skb.h>
#include <linux/can/netlink.h>
#include <linux/can/led.h>
+#include <linux/of.h>
#include <net/rtnetlink.h>
#define MOD_DESC "CAN device driver interface"
@@ -814,6 +815,30 @@ int open_candev(struct net_device *dev)
}
EXPORT_SYMBOL_GPL(open_candev);
+#ifdef CONFIG_OF
+/*
+ * Common function that can be used to understand the limitation of
+ * a transceiver when it provides no means to determine these limitations
+ * at runtime.
+ */
+void of_can_transceiver(struct net_device *dev)
+{
+ struct device_node *dn;
+ struct can_priv *priv = netdev_priv(dev);
+ struct device_node *np = dev->dev.parent->of_node;
+ int ret;
+
+ dn = of_get_child_by_name(np, "can-transceiver");
+ if (!dn)
+ return;
+
+ ret = of_property_read_u32(dn, "max-bitrate", &priv->max_bitrate);
+ if ((ret && ret != -EINVAL) || (!ret && !priv->max_bitrate))
+ netdev_warn(dev, "Invalid value for transceiver max bitrate. Ignoring bitrate limit.\n");
+}
+EXPORT_SYMBOL_GPL(of_can_transceiver);
+#endif
+
/*
* Common close function for cleanup before the device gets closed.
*
@@ -913,6 +938,13 @@ static int can_changelink(struct net_device *dev, struct nlattr *tb[],
priv->bitrate_const_cnt);
if (err)
return err;
+
+ if (priv->max_bitrate && bt.bitrate > priv->max_bitrate) {
+ netdev_err(dev, "arbitration bitrate surpasses transceiver capabilities of %d bps\n",
+ priv->max_bitrate);
+ return -EINVAL;
+ }
+
memcpy(&priv->bittiming, &bt, sizeof(bt));
if (priv->do_set_bittiming) {
@@ -997,6 +1029,13 @@ static int can_changelink(struct net_device *dev, struct nlattr *tb[],
priv->data_bitrate_const_cnt);
if (err)
return err;
+
+ if (priv->max_bitrate && dbt.bitrate > priv->max_bitrate) {
+ netdev_err(dev, "canfd data bitrate surpasses transceiver capabilities of %d bps\n",
+ priv->max_bitrate);
+ return -EINVAL;
+ }
+
memcpy(&priv->data_bittiming, &dbt, sizeof(dbt));
if (priv->do_set_data_bittiming) {
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 61f1cf2..fbb7810 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -48,6 +48,8 @@ struct can_priv {
unsigned int data_bitrate_const_cnt;
struct can_clock clock;
+ unsigned int max_bitrate;
+
enum can_state state;
/* CAN controller features - see include/uapi/linux/can/netlink.h */
@@ -166,6 +168,12 @@ void can_put_echo_skb(struct sk_buff *skb, struct net_device *dev,
unsigned int can_get_echo_skb(struct net_device *dev, unsigned int idx);
void can_free_echo_skb(struct net_device *dev, unsigned int idx);
+#ifdef CONFIG_OF
+void of_can_transceiver(struct net_device *dev);
+#else
+static inline void of_can_transceiver(struct net_device *dev) { }
+#endif
+
struct sk_buff *alloc_can_skb(struct net_device *dev, struct can_frame **cf);
struct sk_buff *alloc_canfd_skb(struct net_device *dev,
struct canfd_frame **cfd);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v6 0/6] Add M_CAN Support for Dra76 platform
From: Faiz Abbas @ 2017-12-22 13:31 UTC (permalink / raw)
To: wg, mkl, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, faiz_abbas, nsekhar,
fcooper, robh, Wenyou.Yang, sergei.shtylyov
This patch series adds support for M_CAN on the TI Dra76
platform. Device tree patches will be sent separately.
A bunch of patches were sent before by
Franklin Cooper <fcooper@ti.com>. I have clubbed the
series together and rebased to the latest kernel.
v6 changes:
Dropped the patches to make hclk optional. Drivers
which enable hclk as the interface clock using
pm_runtime calls must still provide a hclk in the
clocks property.
Support higher speed CAN-FD bitrate:
The community decided that data sampling point be used
for the secondary sampling point here
https://patchwork.kernel.org/patch/9909845/
Franklin S Cooper Jr (6):
can: dev: Add support for limiting configured bitrate
can: m_can: Add call to of_can_transceiver
can: m_can: Add PM Runtime
can: m_can: Support higher speed CAN-FD bitrates
dt-bindings: can: m_can: Document new can transceiver binding
dt-bindings: can: can-transceiver: Document new binding
.../bindings/net/can/can-transceiver.txt | 24 +++++++
.../devicetree/bindings/net/can/m_can.txt | 9 +++
drivers/net/can/dev.c | 39 +++++++++++
drivers/net/can/m_can/m_can.c | 81 ++++++++++++++++++++--
include/linux/can/dev.h | 8 +++
5 files changed, 156 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/can-transceiver.txt
--
2.7.4
^ permalink raw reply
* [PATCH v6 4/6] can: m_can: Support higher speed CAN-FD bitrates
From: Faiz Abbas @ 2017-12-22 13:31 UTC (permalink / raw)
To: wg, mkl, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, faiz_abbas, nsekhar,
fcooper, robh, Wenyou.Yang, sergei.shtylyov
In-Reply-To: <1513949488-13026-1-git-send-email-faiz_abbas@ti.com>
From: Franklin S Cooper Jr <fcooper@ti.com>
During test transmitting using CAN-FD at high bitrates (> 2 Mbps)
would fail. Scoping the signals I noticed that only a single bit
was being transmitted and with a bit more investigation realized the actual
MCAN IP would go back to initialization mode automatically.
It appears this issue is due to the MCAN needing to use the Transmitter
Delay Compensation Mode with the correct value for the transmitter delay
compensation offset (tdco). What impacts the tdco value isn't 100% clear
but to calculate it you use an equation defined in the MCAN User's Guide.
The user guide mentions that this register needs to be set based on clock
values, secondary sample point and the data bitrate. One of the key
variables that can't automatically be determined is the secondary
sample point (ssp). This ssp is similar to the sp but is specific to this
transmitter delay compensation mode. The guidelines for configuring
ssp is rather vague but via some CAN test it appears for DRA76x that putting
the value same as data sampling point works.
The CAN-CIA's "Bit Time Requirements for CAN FD" paper presented at
the International CAN Conference 2013 indicates that this TDC mode is
only needed for data bit rates above 2.5 Mbps. Therefore, only enable
this mode when the data bit rate is above 2.5 Mbps.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
drivers/net/can/m_can/m_can.c | 41 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 53e764f..371ffc1 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -127,6 +127,12 @@ enum m_can_mram_cfg {
#define DBTP_DSJW_SHIFT 0
#define DBTP_DSJW_MASK (0xf << DBTP_DSJW_SHIFT)
+/* Transmitter Delay Compensation Register (TDCR) */
+#define TDCR_TDCO_SHIFT 8
+#define TDCR_TDCO_MASK (0x7F << TDCR_TDCO_SHIFT)
+#define TDCR_TDCF_SHIFT 0
+#define TDCR_TDCF_MASK (0x7F << TDCR_TDCF_SHIFT)
+
/* Test Register (TEST) */
#define TEST_LBCK BIT(4)
@@ -991,7 +997,8 @@ static int m_can_set_bittiming(struct net_device *dev)
const struct can_bittiming *bt = &priv->can.bittiming;
const struct can_bittiming *dbt = &priv->can.data_bittiming;
u16 brp, sjw, tseg1, tseg2;
- u32 reg_btp;
+ u32 reg_btp, tdco, ssp;
+ bool enable_tdc = false;
brp = bt->brp - 1;
sjw = bt->sjw - 1;
@@ -1006,9 +1013,41 @@ static int m_can_set_bittiming(struct net_device *dev)
sjw = dbt->sjw - 1;
tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
tseg2 = dbt->phase_seg2 - 1;
+
+ /* TDC is only needed for bitrates beyond 2.5 MBit/s.
+ * This is mentioned in the "Bit Time Requirements for CAN FD"
+ * paper presented at the International CAN Conference 2013
+ */
+ if (dbt->bitrate > 2500000) {
+ /* Use the same value of secondary sampling point
+ * as the data sampling point
+ */
+ ssp = dbt->sample_point;
+
+ /* Equation based on Bosch's M_CAN User Manual's
+ * Transmitter Delay Compensation Section
+ */
+ tdco = (priv->can.clock.freq / 1000) *
+ ssp / dbt->bitrate;
+
+ /* Max valid TDCO value is 127 */
+ if (tdco > 127) {
+ netdev_warn(dev, "TDCO value of %u is beyond maximum limit. Disabling Transmitter Delay Compensation mode\n",
+ tdco);
+ } else {
+ enable_tdc = true;
+ m_can_write(priv, M_CAN_TDCR,
+ tdco << TDCR_TDCO_SHIFT);
+ }
+ }
+
reg_btp = (brp << DBTP_DBRP_SHIFT) | (sjw << DBTP_DSJW_SHIFT) |
(tseg1 << DBTP_DTSEG1_SHIFT) |
(tseg2 << DBTP_DTSEG2_SHIFT);
+
+ if (enable_tdc)
+ reg_btp |= DBTP_TDC;
+
m_can_write(priv, M_CAN_DBTP, reg_btp);
}
--
2.7.4
^ permalink raw reply related
* [PATCH] CAN NETWORK DRIVERS: set cf->can_id to CAN_ERR_CRTL when cf->data[1] is filled with either CAN_STATE_ERROR_WARNING or CAN_STATE_ERROR_PASSIVE
From: Lederhilger Martin @ 2017-12-21 14:42 UTC (permalink / raw)
To: wg@grandegger.com, mkl@pengutronix.de; +Cc: linux-can@vger.kernel.org
This patch improves error reporting of the CAN driver for EMS Dr. Thomas Wuensche CPC-USB/ARM7.
Signed-off-by: Martin Lederhilger <m.lederhilger@ds-automotion.com>
---
diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
index b3d02759c226..cd8f26333e0f 100644
--- a/drivers/net/can/usb/ems_usb.c
+++ b/drivers/net/can/usb/ems_usb.c
@@ -393,6 +393,7 @@ static void ems_usb_rx_err(struct ems_usb *dev, struct ems_cpc_msg *msg)
if (dev->can.state == CAN_STATE_ERROR_WARNING ||
dev->can.state == CAN_STATE_ERROR_PASSIVE) {
+ cf->can_id |= CAN_ERR_CRTL;
cf->data[1] = (txerr > rxerr) ?
CAN_ERR_CRTL_TX_PASSIVE : CAN_ERR_CRTL_RX_PASSIVE;
}
^ permalink raw reply related
* [PATCH v4 30/36] can/bcm: Replace hrtimer_tasklet with softirq based hrtimer
From: Anna-Maria Gleixner @ 2017-12-21 10:41 UTC (permalink / raw)
To: LKML
Cc: Thomas Gleixner, Peter Zijlstra, Ingo Molnar, keescook,
Christoph Hellwig, John Stultz, Anna-Maria Gleixner,
Oliver Hartkopp, linux-can, Marc Kleine-Budde
In-Reply-To: <20171221104205.7269-1-anna-maria@linutronix.de>
From: Thomas Gleixner <tglx@linutronix.de>
Switch the timer to HRTIMER_MODE_SOFT, which executed the timer
callback in softirq context and remove the hrtimer_tasklet.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
---
net/can/bcm.c | 156 ++++++++++++++++++++--------------------------------------
1 file changed, 52 insertions(+), 104 deletions(-)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 13690334efa3..9cc67ac257f1 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -102,7 +102,6 @@ struct bcm_op {
unsigned long frames_abs, frames_filtered;
struct bcm_timeval ival1, ival2;
struct hrtimer timer, thrtimer;
- struct tasklet_struct tsklet, thrtsklet;
ktime_t rx_stamp, kt_ival1, kt_ival2, kt_lastmsg;
int rx_ifindex;
int cfsiz;
@@ -364,25 +363,34 @@ static void bcm_send_to_user(struct bcm_op *op, struct bcm_msg_head *head,
}
}
-static void bcm_tx_start_timer(struct bcm_op *op)
+static bool bcm_tx_set_expiry(struct bcm_op *op, struct hrtimer *hrt)
{
+ ktime_t ival;
+
if (op->kt_ival1 && op->count)
- hrtimer_start(&op->timer,
- ktime_add(ktime_get(), op->kt_ival1),
- HRTIMER_MODE_ABS);
+ ival = op->kt_ival1;
else if (op->kt_ival2)
- hrtimer_start(&op->timer,
- ktime_add(ktime_get(), op->kt_ival2),
- HRTIMER_MODE_ABS);
+ ival = op->kt_ival2;
+ else
+ return false;
+
+ hrtimer_set_expires(hrt, ktime_add(ktime_get(), ival));
+ return true;
}
-static void bcm_tx_timeout_tsklet(unsigned long data)
+static void bcm_tx_start_timer(struct bcm_op *op)
{
- struct bcm_op *op = (struct bcm_op *)data;
+ if (bcm_tx_set_expiry(op, &op->timer))
+ hrtimer_start_expires(&op->timer, HRTIMER_MODE_ABS_SOFT);
+}
+
+/* bcm_tx_timeout_handler - performs cyclic CAN frame transmissions */
+static enum hrtimer_restart bcm_tx_timeout_handler(struct hrtimer *hrtimer)
+{
+ struct bcm_op *op = container_of(hrtimer, struct bcm_op, timer);
struct bcm_msg_head msg_head;
if (op->kt_ival1 && (op->count > 0)) {
-
op->count--;
if (!op->count && (op->flags & TX_COUNTEVT)) {
@@ -399,22 +407,12 @@ static void bcm_tx_timeout_tsklet(unsigned long data)
}
bcm_can_tx(op);
- } else if (op->kt_ival2)
+ } else if (op->kt_ival2) {
bcm_can_tx(op);
+ }
- bcm_tx_start_timer(op);
-}
-
-/*
- * bcm_tx_timeout_handler - performs cyclic CAN frame transmissions
- */
-static enum hrtimer_restart bcm_tx_timeout_handler(struct hrtimer *hrtimer)
-{
- struct bcm_op *op = container_of(hrtimer, struct bcm_op, timer);
-
- tasklet_schedule(&op->tsklet);
-
- return HRTIMER_NORESTART;
+ return bcm_tx_set_expiry(op, &op->timer) ?
+ HRTIMER_RESTART : HRTIMER_NORESTART;
}
/*
@@ -480,7 +478,7 @@ static void bcm_rx_update_and_send(struct bcm_op *op,
/* do not send the saved data - only start throttle timer */
hrtimer_start(&op->thrtimer,
ktime_add(op->kt_lastmsg, op->kt_ival2),
- HRTIMER_MODE_ABS);
+ HRTIMER_MODE_ABS_SOFT);
return;
}
@@ -539,14 +537,21 @@ static void bcm_rx_starttimer(struct bcm_op *op)
return;
if (op->kt_ival1)
- hrtimer_start(&op->timer, op->kt_ival1, HRTIMER_MODE_REL);
+ hrtimer_start(&op->timer, op->kt_ival1, HRTIMER_MODE_REL_SOFT);
}
-static void bcm_rx_timeout_tsklet(unsigned long data)
+/* bcm_rx_timeout_handler - when the (cyclic) CAN frame reception timed out */
+static enum hrtimer_restart bcm_rx_timeout_handler(struct hrtimer *hrtimer)
{
- struct bcm_op *op = (struct bcm_op *)data;
+ struct bcm_op *op = container_of(hrtimer, struct bcm_op, timer);
struct bcm_msg_head msg_head;
+ /* if user wants to be informed, when cyclic CAN-Messages come back */
+ if ((op->flags & RX_ANNOUNCE_RESUME) && op->last_frames) {
+ /* clear received CAN frames to indicate 'nothing received' */
+ memset(op->last_frames, 0, op->nframes * op->cfsiz);
+ }
+
/* create notification to user */
msg_head.opcode = RX_TIMEOUT;
msg_head.flags = op->flags;
@@ -557,25 +562,6 @@ static void bcm_rx_timeout_tsklet(unsigned long data)
msg_head.nframes = 0;
bcm_send_to_user(op, &msg_head, NULL, 0);
-}
-
-/*
- * bcm_rx_timeout_handler - when the (cyclic) CAN frame reception timed out
- */
-static enum hrtimer_restart bcm_rx_timeout_handler(struct hrtimer *hrtimer)
-{
- struct bcm_op *op = container_of(hrtimer, struct bcm_op, timer);
-
- /* schedule before NET_RX_SOFTIRQ */
- tasklet_hi_schedule(&op->tsklet);
-
- /* no restart of the timer is done here! */
-
- /* if user wants to be informed, when cyclic CAN-Messages come back */
- if ((op->flags & RX_ANNOUNCE_RESUME) && op->last_frames) {
- /* clear received CAN frames to indicate 'nothing received' */
- memset(op->last_frames, 0, op->nframes * op->cfsiz);
- }
return HRTIMER_NORESTART;
}
@@ -583,14 +569,12 @@ static enum hrtimer_restart bcm_rx_timeout_handler(struct hrtimer *hrtimer)
/*
* bcm_rx_do_flush - helper for bcm_rx_thr_flush
*/
-static inline int bcm_rx_do_flush(struct bcm_op *op, int update,
- unsigned int index)
+static inline int bcm_rx_do_flush(struct bcm_op *op, unsigned int index)
{
struct canfd_frame *lcf = op->last_frames + op->cfsiz * index;
if ((op->last_frames) && (lcf->flags & RX_THR)) {
- if (update)
- bcm_rx_changed(op, lcf);
+ bcm_rx_changed(op, lcf);
return 1;
}
return 0;
@@ -598,11 +582,8 @@ static inline int bcm_rx_do_flush(struct bcm_op *op, int update,
/*
* bcm_rx_thr_flush - Check for throttled data and send it to the userspace
- *
- * update == 0 : just check if throttled data is available (any irq context)
- * update == 1 : check and send throttled data to userspace (soft_irq context)
*/
-static int bcm_rx_thr_flush(struct bcm_op *op, int update)
+static int bcm_rx_thr_flush(struct bcm_op *op)
{
int updated = 0;
@@ -611,24 +592,16 @@ static int bcm_rx_thr_flush(struct bcm_op *op, int update)
/* for MUX filter we start at index 1 */
for (i = 1; i < op->nframes; i++)
- updated += bcm_rx_do_flush(op, update, i);
+ updated += bcm_rx_do_flush(op, i);
} else {
/* for RX_FILTER_ID and simple filter */
- updated += bcm_rx_do_flush(op, update, 0);
+ updated += bcm_rx_do_flush(op, 0);
}
return updated;
}
-static void bcm_rx_thr_tsklet(unsigned long data)
-{
- struct bcm_op *op = (struct bcm_op *)data;
-
- /* push the changed data to the userspace */
- bcm_rx_thr_flush(op, 1);
-}
-
/*
* bcm_rx_thr_handler - the time for blocked content updates is over now:
* Check for throttled data and send it to the userspace
@@ -637,9 +610,7 @@ static enum hrtimer_restart bcm_rx_thr_handler(struct hrtimer *hrtimer)
{
struct bcm_op *op = container_of(hrtimer, struct bcm_op, thrtimer);
- tasklet_schedule(&op->thrtsklet);
-
- if (bcm_rx_thr_flush(op, 0)) {
+ if (bcm_rx_thr_flush(op)) {
hrtimer_forward(hrtimer, ktime_get(), op->kt_ival2);
return HRTIMER_RESTART;
} else {
@@ -735,23 +706,8 @@ static struct bcm_op *bcm_find_op(struct list_head *ops,
static void bcm_remove_op(struct bcm_op *op)
{
- if (op->tsklet.func) {
- while (test_bit(TASKLET_STATE_SCHED, &op->tsklet.state) ||
- test_bit(TASKLET_STATE_RUN, &op->tsklet.state) ||
- hrtimer_active(&op->timer)) {
- hrtimer_cancel(&op->timer);
- tasklet_kill(&op->tsklet);
- }
- }
-
- if (op->thrtsklet.func) {
- while (test_bit(TASKLET_STATE_SCHED, &op->thrtsklet.state) ||
- test_bit(TASKLET_STATE_RUN, &op->thrtsklet.state) ||
- hrtimer_active(&op->thrtimer)) {
- hrtimer_cancel(&op->thrtimer);
- tasklet_kill(&op->thrtsklet);
- }
- }
+ hrtimer_cancel(&op->timer);
+ hrtimer_cancel(&op->thrtimer);
if ((op->frames) && (op->frames != &op->sframe))
kfree(op->frames);
@@ -979,15 +935,13 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
op->ifindex = ifindex;
/* initialize uninitialized (kzalloc) structure */
- hrtimer_init(&op->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ hrtimer_init(&op->timer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL_SOFT);
op->timer.function = bcm_tx_timeout_handler;
- /* initialize tasklet for tx countevent notification */
- tasklet_init(&op->tsklet, bcm_tx_timeout_tsklet,
- (unsigned long) op);
-
/* currently unused in tx_ops */
- hrtimer_init(&op->thrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ hrtimer_init(&op->thrtimer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL_SOFT);
/* add this bcm_op to the list of the tx_ops */
list_add(&op->list, &bo->tx_ops);
@@ -1150,20 +1104,14 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
op->rx_ifindex = ifindex;
/* initialize uninitialized (kzalloc) structure */
- hrtimer_init(&op->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ hrtimer_init(&op->timer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL_SOFT);
op->timer.function = bcm_rx_timeout_handler;
- /* initialize tasklet for rx timeout notification */
- tasklet_init(&op->tsklet, bcm_rx_timeout_tsklet,
- (unsigned long) op);
-
- hrtimer_init(&op->thrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ hrtimer_init(&op->thrtimer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL_SOFT);
op->thrtimer.function = bcm_rx_thr_handler;
- /* initialize tasklet for rx throttle handling */
- tasklet_init(&op->thrtsklet, bcm_rx_thr_tsklet,
- (unsigned long) op);
-
/* add this bcm_op to the list of the rx_ops */
list_add(&op->list, &bo->rx_ops);
@@ -1209,12 +1157,12 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
*/
op->kt_lastmsg = 0;
hrtimer_cancel(&op->thrtimer);
- bcm_rx_thr_flush(op, 1);
+ bcm_rx_thr_flush(op);
}
if ((op->flags & STARTTIMER) && op->kt_ival1)
hrtimer_start(&op->timer, op->kt_ival1,
- HRTIMER_MODE_REL);
+ HRTIMER_MODE_REL_SOFT);
}
/* now we can register for can_ids, if we added a new bcm_op */
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings
From: Simon Horman @ 2017-12-20 9:38 UTC (permalink / raw)
To: Ulrich Hecht
Cc: linux-renesas-soc, linux-can, devicetree, wsa, geert, magnus.damm,
chris.paterson2, ramesh.shanmugasundaram, robh
In-Reply-To: <1513612297-10173-3-git-send-email-ulrich.hecht+renesas@gmail.com>
On Mon, Dec 18, 2017 at 04:51:37PM +0100, Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v2 1/2] can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
From: Simon Horman @ 2017-12-20 9:38 UTC (permalink / raw)
To: Ulrich Hecht
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-can-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, wsa-z923LK4zBo2bacvFa/9K2g,
geert-Td1EMuHUCqxL1ZNQvxDV9g, magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ,
ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ,
robh-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1513612297-10173-2-git-send-email-ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Dec 18, 2017 at 04:51:36PM +0100, Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Reviewed-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [mkl-can-next:j1939 89/121] net/can/j1939/transport.c:1309 j1939_session_fresh_new() error: use kfree_skb() here instead of kfree(skb)
From: Marc Kleine-Budde @ 2017-12-19 11:53 UTC (permalink / raw)
To: Dan Carpenter, kbuild, Kurt Van Dijck; +Cc: kbuild-all, linux-can
In-Reply-To: <20171216120827.ztws3ez5maqox7hx@mwanda>
[-- Attachment #1.1: Type: text/plain, Size: 647 bytes --]
On 12/16/2017 01:08 PM, Dan Carpenter wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git j1939
> head: 31a3a5b6afa815d144da2d01940e493fb7b625f2
> commit: dbdee3fe09a691eb4ddfedd349be5ffe5e866fb9 [89/121] j1939: transport: use common prefix j1939_session{,list}_ for all session{,list} related functions
Fixed.
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support
From: Marc Kleine-Budde @ 2017-12-19 10:47 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Simon Horman, Geert Uytterhoeven, linux-can@vger.kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Chris Paterson, Biju Das,
Wolfgang Grandegger, Rob Herring, Mark Rutland
In-Reply-To: <TY1PR06MB08953B33F245840430CD3DABC00F0@TY1PR06MB0895.apcprd06.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 444 bytes --]
On 12/19/2017 11:17 AM, Fabrizio Castro wrote:
> Hello Marc,
>
> does this patch look ok to you?
Yes, Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support
From: Fabrizio Castro @ 2017-12-19 10:17 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Simon Horman, Geert Uytterhoeven, linux-can@vger.kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Chris Paterson, Biju Das,
Fabrizio Castro, Wolfgang Grandegger, Rob Herring, Mark Rutland
In-Reply-To: <1510067449-17017-2-git-send-email-fabrizio.castro@bp.renesas.com>
Hello Marc,
does this patch look ok to you?
Thanks,
Fab
> Subject: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support
>
> Document "renesas,can-r8a7743" and "renesas,can-r8a7745" compatible
> strings. Since the fallback compatible string ("renesas,rcar-gen2-can")
> activates the right code in the driver, no driver change is needed.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/net/can/rcar_can.txt | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> index 06bb7cc..94a7f33 100644
> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> @@ -2,7 +2,9 @@ Renesas R-Car CAN controller Device Tree Bindings
> -------------------------------------------------
>
> Required properties:
> -- compatible: "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
> +- compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
> + "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
> + "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
> "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
> "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC.
> "renesas,can-r8a7791" if CAN controller is a part of R8A7791 SoC.
> @@ -12,7 +14,8 @@ Required properties:
> "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
> "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
> "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
> - "renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible device.
> + "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
> + compatible device.
> "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
> When compatible with the generic version, nodes must list the
> SoC-specific version corresponding to the platform first
> --
> 2.7.4
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [PATCH] flex_can: Fix checking can_dlc
From: Luu An Phu @ 2017-12-19 8:40 UTC (permalink / raw)
To: wg, mkl; +Cc: linux-can, netdev, stefan-gabriel.mirea, phu.luuan
From: "phu.luuan" <phu.luuan@nxp.com>
flexcan_start_xmit should write data to register when can_dlc > 4.
Because can_dlc is data length and it has value from 1 to 8. But CAN data
index has value from 0 to 7. So in case we have data in cf->data[4],
the can_dlc has value is more than 4.
Signed-off-by: Luu An Phu <phu.luuan@nxp.com>
---
drivers/net/can/flexcan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 0626dcf..0e3ff13 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -5,6 +5,7 @@
* Copyright (c) 2009 Sascha Hauer, Pengutronix
* Copyright (c) 2010-2017 Pengutronix, Marc Kleine-Budde <kernel@pengutronix.de>
* Copyright (c) 2014 David Jander, Protonic Holland
+ * Copyright 2017 NXP
*
* Based on code originally by Andrey Volkov <avolkov@varma-el.com>
*
@@ -526,7 +527,7 @@ static int flexcan_start_xmit(struct sk_buff *skb, struct net_device *dev)
data = be32_to_cpup((__be32 *)&cf->data[0]);
flexcan_write(data, &priv->tx_mb->data[0]);
}
- if (cf->can_dlc > 3) {
+ if (cf->can_dlc > 4) {
data = be32_to_cpup((__be32 *)&cf->data[4]);
flexcan_write(data, &priv->tx_mb->data[1]);
}
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
From: Ulrich Hecht @ 2017-12-18 15:51 UTC (permalink / raw)
To: linux-renesas-soc
Cc: linux-can, devicetree, wsa, horms, geert, magnus.damm,
chris.paterson2, ramesh.shanmugasundaram, robh, Ulrich Hecht
In-Reply-To: <1513612297-10173-1-git-send-email-ulrich.hecht+renesas@gmail.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 06bb7cc..f7d0358 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -11,6 +11,7 @@ Required properties:
"renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
"renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
"renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
+ "renesas,can-r8a77995" if CAN controller is a part of R8A77995 SoC.
"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible device.
"renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
@@ -25,12 +26,12 @@ Required properties:
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".
-Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
-compatible:
-In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
-and can be used by both CAN and CAN FD controller at the same time. It needs to
-be scaled to maximum frequency if any of these controllers use it. This is done
-using the below properties:
+Required properties for "renesas,can-r8a7795", "renesas,can-r8a7796" and
+"renesas,can-r8a77995" compatible:
+In R8A7795, R8A7796 and R8A77995 SoCs, "clkp2" can be CANFD clock. This is a
+div6 clock and can be used by both CAN and CAN FD controller at the same
+time. It needs to be scaled to maximum frequency if any of these
+controllers use it. This is done using the below properties:
- assigned-clocks: phandle of clkp2(CANFD) clock.
- assigned-clock-rates: maximum frequency of this clock.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings
From: Ulrich Hecht @ 2017-12-18 15:51 UTC (permalink / raw)
To: linux-renesas-soc
Cc: linux-can, devicetree, wsa, horms, geert, magnus.damm,
chris.paterson2, ramesh.shanmugasundaram, robh, Ulrich Hecht
In-Reply-To: <1513612297-10173-1-git-send-email-ulrich.hecht+renesas@gmail.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 93c3a6a..eeb9fec 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -6,6 +6,7 @@ Required properties:
- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
- "renesas,r8a7796-canfd" for R8A7796 (R-Car M3) compatible controller.
+ - "renesas,r8a77995-canfd" for R8A77995 (R-Car D3) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
@@ -24,12 +25,12 @@ The name of the child nodes are "channel0" and "channel1" respectively. Each
child node supports the "status" property only, which is used to
enable/disable the respective channel.
-Required properties for "renesas,r8a7795-canfd" and "renesas,r8a7796-canfd"
-compatible:
-In R8A7795 and R8A7796 SoCs, canfd clock is a div6 clock and can be used by both
-CAN and CAN FD controller at the same time. It needs to be scaled to maximum
-frequency if any of these controllers use it. This is done using the below
-properties:
+Required properties for "renesas,r8a7795-canfd", "renesas,r8a7796-canfd" and
+"renesas,r8a77995-canfd" compatible:
+In R8A7795, R8A7796 and R8A77995 SoCs, canfd clock is a div6 clock and can
+be used by both CAN and CAN FD controller at the same time. It needs to be
+scaled to maximum frequency if any of these controllers use it. This is
+done using the below properties:
- assigned-clocks: phandle of canfd clock.
- assigned-clock-rates: maximum frequency of this clock.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/2] R-Car D3 (r8a77995) CAN support
From: Ulrich Hecht @ 2017-12-18 15:51 UTC (permalink / raw)
To: linux-renesas-soc
Cc: linux-can, devicetree, wsa, horms, geert, magnus.damm,
chris.paterson2, ramesh.shanmugasundaram, robh, Ulrich Hecht
Hi!
These two patches are the leftovers of the "CAN for D3" series; as far
as I can tell, everything else has been picked up.
This revision fixes a copy/paste error and adds Acks and Reviewed-Bys.
CU
Uli
Ulrich Hecht (2):
can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings
Documentation/devicetree/bindings/net/can/rcar_can.txt | 13 +++++++------
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 13 +++++++------
2 files changed, 14 insertions(+), 12 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 1/2] dt-binding: can: mcp2517fd: document device tree bindings
From: kernel-TqfNSX0MhmxHKSADF0wUEw @ 2017-12-17 14:34 UTC (permalink / raw)
To: Patrick Menschel; +Cc: linux-can-u79uwXL29TY76Z2rM5mHXA, devicetree
In-Reply-To: <d79ee9eb-8b36-0086-8d76-ec6bca224fe5-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>
Hi Patrick!
So I started implementing the GPIO_LIB implementation but
I have hit an issue where I would like to get some feedback.
So in principle the gpiolib works, but only if the device is
not asleep and the clock is enabled, which at this very moment means
that the can interface has to be up and running.
So at this very moment the only option that I see would be to
disable the sleep mode which the device enters after probing until
the can-network interface is enabled (which enables the clock and
start the oscillator) - with SLEEP enabled when GPIOLIB support
is disabled.
This is obviously not optimal from the power perspective…
The other option would be starting the clock and oscillator
as soon as a set_direction* (or reques/free) function is called.
(where I would need to start using locks to avoid race conditions
as well as clock usage counters...).
Which of the above is the preferred solution? Are there other ideas
how I could solve this dilemma?
Martin
> On 05.12.2017, at 19:28, Patrick Menschel <menschel.p-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org> wrote:
>
> Hi Martin,
>
> it depends on the daily usage of those alternate functions.
> I just took a quick glimpse on the datasheet and if you check appendix B table 9-1 , you'll see that some functions are optional because ISO suggested them, not because there is a practical reason for it.
>
> CLKO/SOF does make little to no sense with a higher grade embedded system. CLKO is meant to share the osc with the microcontroller.
>> The CLKO pin provides the clock to the
>> microcontroller.
> SOF makes sense for testing in lab configuration, not for regular operation.
>
> TXCAN also does make little sense as you can only use it in the lab.
>> TXCANOD: TXCAN can be configured as Push-
>> Pull or as Open Drain out
>> put. Open Drain outputs
>> allows the user to connect multiple controllers
>> together to build a CAN network without using a
>> transceiver.
>
> INTOD is initialized as Push/Pull. Configuring it open drain would be processor specific when the microcontroller has limited options for pin-ctrl, e.g. some PICs.
>> INTOD:
>> Interrupt pins Open Drain Mode
>> 1
>> = Open Drain Output
>> 0
>> = Push/Pull Output
>
> To sum it up, I would drop:
> - CLKO/SOF
> - TXCAN
> - INTOD
>
> I would implement higher level functions in a second step for INT0/GPIO0/XSTBY and INT1/GPIO1.
> Such functions can be:
> - power saving via XSTBY
> - RX / TX LEDs via INT0 / INT1
>
> Actually this second step would wait until a request for feature arises.
>
> Regards,
> Patrick
>
> Am 05.12.2017 um 11:26 schrieb Martin Sperl:
>> Hi Patrick!
>>
>>
>> I had a quick look starting to implement gpiolib,
>>
>> but I believe I would need to implement pin-ctrl on top to
>>
>> make the Alternate functions work propperly.
>>
>> I wonder if this effort is really worth it.
>>
>> Martin
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Can: FD: configure transmitter delay
From: Oliver Hartkopp @ 2017-12-16 20:15 UTC (permalink / raw)
To: kernel; +Cc: linux-can
In-Reply-To: <CABC43F0-0119-483E-BBBC-8693946036A9@martin.sperl.org>
Hello Martin,
I took a look at the M_CAN manual e.g. at
https://github.com/hartkopp/M_CAN-User-Manual-History/blob/master/mcan_users_manual_v3212.pdf
and there's a switch in register Data Bit Timing & Prescaler Register
(DBTP) on PDF page 16 and some Transmitter Delay Compensation Offset in
the TDCR register (PDF page 27).
So IMO it looks like we need to introduce some additional netlink
attribute for the Transmitter Delay Compensation in
linux/include/uapi/linux/can/netlink.h , e.g.:
struct can_trx_delay_compensation {
__u8 mode; /* enum off=0, on=1 , auto=2 */
__u8 offset; /* 0 to 127 mtq */
__u8 filter_window_length; /* 0 to 127 mtq */
}
and introduce a new
IFLA_CAN_TRX_DELAY_COMPENSATION,
netlink command.
The idea for struct can_trx_delay_compensation is roughly picked from
the M_CAN register API as I personally would prefer unsigned values to
signed offsets that are suggested in the TDCO value from mcp2517fd.
But this would be just a suggestion.
Any comments/ideas on this?
Best regards,
Oliver
On 12/15/2017 07:31 PM, kernel@martin.sperl.org wrote:
> Maybe one observation that I have made that may be of interest is
> that changing the sample-point from .75 to .80 makes the reception work
> again.
>
> But that only works when the sample points are changed to the same value!
> e.g: sample-point .8 dsample-point .8
>
> Otherwise things show errors and the message is eventually received.
>
> So it seems that the sample-points really becomes sensitive
> (at least on the mcp2517fd) and a different default than .75 may be
> “recommended” when using CanFD.
>
> Martin
>
>
>
>> On 09.12.2017, at 19:48, Martin Sperl <kernel@martin.sperl.org> wrote:
>>
>>
>> As far as I can tell dsample-point is the definition of the first
>> sample point of a data bit (in % of the bit length). It would not
>> define the 2nd sample point that would be defined by
>> transmitter delay.
>>
>> Also how would one parametrize: off, fixed or auto with this
>> parameter(where with auto part of the parameter would be
>> Automatic, but parts would be fixed?
>>
>> I understand we need to come to a common denominator.
>>
>> So maybe it would help summarize the parameters for each
>> Device to figure out what is common.
>>
>> Here the info for the mcp2517fd:
>>
>> bit 17-16 TDCMOD<1:0>: Transmitter Delay Compensation Mode bits; Secondary Sample Point (SSP) 10-11 = Auto; measure delay and add TDCO. 01 = Manual; Don't measure, use TDCV + TDCO from register 00 = TDC Disabled
>> bit 14-8 TDCO<6:0>: Transmitter Delay Compensation Offset bits; Secondary Sample Point (SSP) Two's complement; offset can be positive, zero, or negative. 011 1111 = 63 x TSYSCLK ... 000 0000 = 0 x TSYSCLK ... 111 1111 = –64 x TSYSCLK
>> bit 5-0 TDCV<5:0>: Transmitter Delay Compensation Value bits; Secondary Sample Point (SSP) 11 1111 = 63 x TSYSCLK ... 00 0000 = 0 x TSYSCLK
>>
>> What the microchip reference implementation does is define auto
>> and setting vdco while keeping vdcv=0
>>
>> My initial implementation did set tdc to disabled, but then the
>> communication with (for example) PCAN-usb is failing - have
>> this information from someone who has access to this (which
>> makes it hard for me to reproduce...)
>>
>> Martin
>>
>>> On 09.12.2017, at 19:01, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>>
>>> Hello Martin,
>>>
>>> we had a discussion on this topic recently which ended here:
>>>
>>> https://marc.info/?l=linux-can&m=150850171310828&w=2
>>>
>>> There was no further discussion since then.
>>>
>>> What is you opinion about using the 'data sample-point' aka dsample-point for transmitter delay configuration?
>>>
>>> $ ip link set can0 type can help
>>> Usage: ip link set DEVICE type can
>>> [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
>>> [ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
>>> phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
>>>
>>> [ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] | <<---
>>> [ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
>>> dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
>>>
>>> Best regards,
>>> Oliver
>>>
>>>> On 12/09/2017 06:01 PM, Martin Sperl wrote:
>>>> Hi!
>>>> The mcp2517fd that I am finishing the driver for has some specific
>>>> settings to configure the transmitter delay which is used with can fd
>>>> frames (essentially it configures 2nd sample point that takes the
>>>> delay /latency of the transceiver into account - can be off, fixed, or
>>>> automatic).
>>>> Compatibility tests have already shown that some can fd communication
>>>> is quite sensitive to these settings - especially between different types
>>>> of devices - which may result in BUS off situations...
>>>> So I am wondering how to best allow for configuration of these
>>>> parameters - module parameters is ugly similarly debugfs or sysfs.
>>>> I guess there must be other fd devices with similar requirements,
>>>> so I wonder how it is handled there...
>>>> Thanks,
>>>> Martin
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-can" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] ip: add vxcan/veth to ip-link man page
From: Stephen Hemminger @ 2017-12-16 18:08 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can, netdev
In-Reply-To: <20171216113857.2397-1-socketcan@hartkopp.net>
On Sat, 16 Dec 2017 12:38:57 +0100
Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> veth and vxcan both create a vitual tunnel between a pair of virtual network
> devices. This patch adds the content for the now supported vxcan netdevices
> and the documentation to create peer devices for vxcan and veth.
>
> Additional remove 'can' that accidently was on the list of link types which
> can be created by 'ip link add' as 'can' devices are real network devices.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied. Thanks for the doing this.
^ permalink raw reply
* [mkl-can-next:j1939 89/121] net/can/j1939/transport.c:1309 j1939_session_fresh_new() error: use kfree_skb() here instead of kfree(skb)
From: Dan Carpenter @ 2017-12-16 12:08 UTC (permalink / raw)
To: kbuild, Kurt Van Dijck, Marc Kleine-Budde; +Cc: kbuild-all, linux-can
tree: https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git j1939
head: 31a3a5b6afa815d144da2d01940e493fb7b625f2
commit: dbdee3fe09a691eb4ddfedd349be5ffe5e866fb9 [89/121] j1939: transport: use common prefix j1939_session{,list}_ for all session{,list} related functions
smatch warnings:
show-warning-context "warning-lines" files
# https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/commit/?id=dbdee3fe09a691eb4ddfedd349be5ffe5e866fb9
git remote add mkl-can-next https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
git remote update mkl-can-next
git checkout dbdee3fe09a691eb4ddfedd349be5ffe5e866fb9
vim +1309 net/can/j1939/transport.c
b99eb71b Kurt Van Dijck 2011-05-23 1285
dbdee3fe Marc Kleine-Budde 2017-08-16 1286 static struct session *j1939_session_fresh_new(int size,
827881d3 Marc Kleine-Budde 2016-09-08 1287 struct sk_buff *rel_skb,
827881d3 Marc Kleine-Budde 2016-09-08 1288 pgn_t pgn)
b99eb71b Kurt Van Dijck 2011-05-23 1289 {
b99eb71b Kurt Van Dijck 2011-05-23 1290 struct sk_buff *skb;
b99eb71b Kurt Van Dijck 2011-05-23 1291 struct j1939_sk_buff_cb *cb;
b99eb71b Kurt Van Dijck 2011-05-23 1292 struct session *session;
b99eb71b Kurt Van Dijck 2011-05-23 1293
b99eb71b Kurt Van Dijck 2011-05-23 1294 /* this SKB is allocated without headroom for CAN skb's.
b99eb71b Kurt Van Dijck 2011-05-23 1295 * This may not pose a problem, this SKB will never
b99eb71b Kurt Van Dijck 2011-05-23 1296 * enter generic CAN functions
b99eb71b Kurt Van Dijck 2011-05-23 1297 */
b99eb71b Kurt Van Dijck 2011-05-23 1298 skb = alloc_skb(size, GFP_ATOMIC);
b99eb71b Kurt Van Dijck 2011-05-23 1299 if (!skb)
b99eb71b Kurt Van Dijck 2011-05-23 1300 return NULL;
b99eb71b Kurt Van Dijck 2011-05-23 1301
15c8a9f1 Marc Kleine-Budde 2017-06-01 1302 cb = j1939_get_cb(skb);
b99eb71b Kurt Van Dijck 2011-05-23 1303 memcpy(cb, rel_skb->cb, sizeof(*cb));
b99eb71b Kurt Van Dijck 2011-05-23 1304 fix_cb(cb);
669cff46 Marc Kleine-Budde 2017-08-16 1305 cb->addr.pgn = pgn;
b99eb71b Kurt Van Dijck 2011-05-23 1306
dbdee3fe Marc Kleine-Budde 2017-08-16 1307 session = j1939_session_new(skb);
b99eb71b Kurt Van Dijck 2011-05-23 1308 if (!session) {
b99eb71b Kurt Van Dijck 2011-05-23 @1309 kfree(skb);
b99eb71b Kurt Van Dijck 2011-05-23 1310 return NULL;
b99eb71b Kurt Van Dijck 2011-05-23 1311 }
b99eb71b Kurt Van Dijck 2011-05-23 1312 session->skb_iif = rel_skb->skb_iif;
b99eb71b Kurt Van Dijck 2011-05-23 1313 skb->dev = rel_skb->dev;
70bbb5ad Marc Kleine-Budde 2016-09-08 1314
b99eb71b Kurt Van Dijck 2011-05-23 1315 /* alloc data area */
b99eb71b Kurt Van Dijck 2011-05-23 1316 skb_put(skb, size);
b99eb71b Kurt Van Dijck 2011-05-23 1317 return session;
b99eb71b Kurt Van Dijck 2011-05-23 1318 }
70bbb5ad Marc Kleine-Budde 2016-09-08 1319
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox