[PATCH v3] iio: adc: Add Maxim MAX11100 driver
From: Jacopo Mondi
Add IIO driver for Maxim MAX11100 single-channel ADC.
Add DT bindings documentation.
Signed-off-by: Jacopo Mondi
Tested-by: Marek Vasut
---
Sending v3 incorporating last comments from review and from testing.
One final thing I would like to be clarified is about the measure unit
returned by read_raw().
Currently (value_raw * value_scale) return the ADC input value in mV.
While testing the patch I've been questioned if that should not actually
be in uV. This is easily achievable making _scale return a value in uV.
I have found no mention of this in the ABI documentation as it speaks of
generic voltage.
Can we have a final word on this?
Thanks Marek for having tested this.
v1 -> v2:
- incorporated pmeerw's review comments
- retrieve vref from dts and use that to convert read_raw result
to mV
- add device tree bindings documentation
v2 -> v3:
- add _SCALE bit of read_raw function and change _RAW bit accordingly
- call regulator_get_voltage when accessing the _SCALE part of read_raw
and not during probe
- add back remove function as regulator has to be disabled when detaching
the module. Do not use devm_ version of iio_register/unregister functions
anymore but do unregister in the remove.
- remove mutex as access to SPI bus is protected by SPI core. Thanks marex
---
.../devicetree/bindings/iio/adc/max11100.txt | 17 ++
drivers/iio/adc/Kconfig| 9 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/max11100.c | 187 +
4 files changed, 214 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/max11100.txt
create mode 100644 drivers/iio/adc/max11100.c
diff --git a/Documentation/devicetree/bindings/iio/adc/max11100.txt
b/Documentation/devicetree/bindings/iio/adc/max11100.txt
new file mode 100644
index 000..6877c11
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/max11100.txt
@@ -0,0 +1,17 @@
+* Maxim max11100 Analog to Digital Converter (ADC)
+
+Required properties:
+ - compatible: Should be "maxim,max11100"
+ - vref-supply: phandle to the regulator that provides reference voltage
+
+Optional properties:
+ - spi-max-frequency: SPI maximum frequency
+
+Example:
+
+adc0: max11100@0 {
+compatible = "maxim,max11100";
+vref-supply = <&adc0_vref>;
+spi-max-frequency = <24>;
+};
+
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 38bc319..c32bc7a 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -307,6 +307,15 @@ config MAX1027
To compile this driver as a module, choose M here: the module will be
called max1027.
+config MAX11100
+ tristate "Maxim max11100 ADC driver"
+ depends on SPI_MASTER
+ help
+ Say yes here to build support for Maxim max11100 SPI ADC
+
+ To compile this driver as a module, choose M here: the module will be
+ called max11100.
+
config MAX1363
tristate "Maxim max1363 ADC driver"
depends on I2C
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index d36c4be..5684369 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
obj-$(CONFIG_LTC2485) += ltc2485.o
obj-$(CONFIG_MAX1027) += max1027.o
+obj-$(CONFIG_MAX11100) += max11100.o
obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
diff --git a/drivers/iio/adc/max11100.c b/drivers/iio/adc/max11100.c
new file mode 100644
index 000..78e2a45
--- /dev/null
+++ b/drivers/iio/adc/max11100.c
@@ -0,0 +1,187 @@
+/*
+ * iio/adc/max11100.c
+ * Maxim max11100 ADC Driver with IIO interface
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ * Copyright (C) 2016 Jacopo Mondi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/*
+ * LSB is the ADC single digital step
+ * 1 LSB = (vref_mv / 2 ^ 16)
+ *
+ * LSB is used to calculate analog voltage value
+ * from the number of ADC steps count
+ *
+ * Ain = (count * LSB)
+ */
+#define MAX11100_LSB_DIV (1 << 16)
+
+struct max11100_state {
+ const struct max11100_chip_desc *desc;
+ struct regulator *vref_reg;
+ struct spi_device *spi;
+};
+
+static struct iio_chan_spec max11100_channels[] = {
+ { /* [0] */
+ .type = IIO_VOLTAGE,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static struct max11100_chip_desc {
+ unsigned int num_chan;
+ const struct iio_chan
Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT
On Wed, Jan 04, 2017 at 06:39:52PM +0100, Wolfram Sang wrote: > Simon, > > as Ulf picked up the driver patches for HS200 support, it is now safe to pick > up the DTS patches, I'd say? I rebased them to the dt-for-4.11 branch. > > All the best, > >Wolfram > > > Wolfram Sang (2): > arm64: dts: r8a7795: enable HS200 for eMMC > arm64: dts: r8a7796: enable HS200 for eMMC > > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 1 + > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 1 + > 2 files changed, 2 insertions(+) Ping :) signature.asc Description: PGP signature
RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define
Hi Geert, On Thursday, January 12, 2017, Geert Uytterhoeven wrote: > This is strange. There are two SDHI channels, but the STBCR12 > documentation (all versions up to rev. 3.00) says the register has MSTP > bits for four SD host interfaces? > > Can you please enlighten me? Thanks! Ya, I saw that. There are 2 bits per SDHI channel. I did check and just enabling the one works fine. Honestly, I'm not sure why there are two clock enables. I'll go back and ask the design team if they can tell me why there are 2. As I said, I just re-tested and it works fine, but you can hold off on the patch if you want until I come up with a real explanation. Chris
Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define
Hi Chris,
On Thu, Jan 12, 2017 at 7:11 PM, Chris Brandt wrote:
> Now that all the clocks in the boot loader are disabled before booting
> the kernel, and the mstp driver has been fixed for RZ/A1, here is a typo
> that was missed during original testing.
>
> Fixes: 7c8522b7047c ("ARM: dts: r7s72100: add sdhi clock to device tree")
> Signed-off-by: Chris Brandt
> ---
> include/dt-bindings/clock/r7s72100-clock.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/dt-bindings/clock/r7s72100-clock.h
> b/include/dt-bindings/clock/r7s72100-clock.h
> index 29e01ed..318ab14 100644
> --- a/include/dt-bindings/clock/r7s72100-clock.h
> +++ b/include/dt-bindings/clock/r7s72100-clock.h
> @@ -46,6 +46,6 @@
>
> /* MSTP12 */
> #define R7S72100_CLK_SDHI0 3
> -#define R7S72100_CLK_SDHI1 2
> +#define R7S72100_CLK_SDHI1 1
This is strange. There are two SDHI channels, but the STBCR12 documentation
(all versions up to rev. 3.00) says the register has MSTP bits for four SD
host interfaces?
Can you please enlighten me? Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [PATCH 2/3] gpio: gpio-rz: GPIO driver for Renesas RZ series
Hi Jacopo, On Thursday, January 12, 2017, jacopo mondi wrote: > Oh! That's weird I don't have that statement in my manual (public version > R01UH0403EJ0060 Rev.0.60) If you go to www.renesas.com and search for "RZ/A1H User Manual", you will see that a new version 3.0 manual was recently posted. This new version contains many new descriptions and precautions. It also now includes the SDHI chapter which previously was always omitted because of legal reasons. There is a separate manual for the RZ/A1L. The peripherals are all the same, but the function pinouts are different because the packages are smaller. Hence, all the existing upstream drivers for RZ/A1H work fine for RZ/A1M and RZ/A1L without modification...except the pins comes out on different ports...and the sh-pfc driver won't work well in this situation. Chris
Re: [PATCH 2/3] gpio: gpio-rz: GPIO driver for Renesas RZ series
Hi Chris, On 12/01/2017 15:39, Chris Brandt wrote: Hi Jacopo, On Thursday, January 12, 2017, jacopo mondi wrote: To read the pin direction I would need to add one more register to the "reg" property range provided in the DTS. This is of course doable, but I would have two questions here: - why did you chose to use PMSR register instead of reading/writing directly to PM? Am I missing something? I guess you can still use the PMSR register to get the current direction of the I/O pin. According to the HW manual: "When reading, the higher 16 bits are read as H. The lower 16 bits are read as the value of the PMn register." Oh! That's weird I don't have that statement in my manual (public version R01UH0403EJ0060 Rev.0.60) The only description for PMSR I have is: "This register provides an alternative method for writing data to the PMn register. The higher 16 bits of the PMSRn register specify whether data can be written to the PMn.PMnm bit specified by the lower 16 bits of the PMSRn register." So I assumed it was one direction only While the PMSR register is a cool idea of having a special register that can change a single port pin direction without doing a read-modify-write by the CPU, it doesn't seem to be a standard option in Renesas SoCs (well, except for the older NEC V850 parts where this PFC HW came from). So a more traditional method of just using the Pmn register seems to be more compatible across Renesas SoCs. Chris
[PATCH 0/2] clocksource: Add renesas-ostm timer driver
This patch set adds a new clocksource driver that uses the OS Timer (OSTM) that exists in the R7S72100 (RZ/A1) SoC. The operation of the driver was tested with a simple user application that does multiple calls to nanosleep() and gettimeofday(). The purpose of adding this driver is to get better time keeping accuracy over the default MTU2 clocksource timer. Chris Brandt (2): dt-bindings: document renesas-ostm timer clocksource: Add renesas-ostm timer driver .../devicetree/bindings/timer/renesas,ostm.txt | 36 ++ arch/arm/mach-shmobile/Kconfig | 1 + drivers/clocksource/Kconfig| 12 + drivers/clocksource/Makefile | 1 + drivers/clocksource/renesas-ostm.c | 389 + 5 files changed, 439 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt create mode 100644 drivers/clocksource/renesas-ostm.c -- 2.10.1
[PATCH 1/2] dt-bindings: document renesas-ostm timer
Signed-off-by: Chris Brandt
---
.../devicetree/bindings/timer/renesas,ostm.txt | 36 ++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt
diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.txt
b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
new file mode 100644
index 000..46e1f27
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
@@ -0,0 +1,36 @@
+* Renesas OS Timer (OSTM)
+
+The OSTM comes with 2 independent channels.
+We will use the first channel (OSTM0) as a free running clocksource and the
+second channel (OSTM1) as a interrupt driven clock event.
+
+Additionally we will use the clocksource channel (OTSM0) for the system
+schedule timer sched_clock().
+
+Required Properties:
+
+ - compatible: must be one or more of the following:
+- "renesas,ostm-r7s72100" for the r7s72100 OSTM
+- "renesas,ostm" for any OSTM
+ This is a fallback for the above renesas,ostm-* entries
+
+ - reg: base address and length of the registers block for each timer channel.
+There should be 2 sets of addresses, one for each channel.
+
+ - interrupts: interrupt specifiers for the timers. There should be 2
+interupts, one for each channel.
+
+ - clocks: a list of phandle + clock-specifier pairs, one for each entry
+channel. There should be 2 sets, one for each channel.
+
+Example: R7S72100 (RZ/A1H) OSTM node
+
+ ostm: ostm@fcfec000 {
+ compatible = "renesas,ostm-r7s72100", "renesas,ostm";
+ reg = <0xfcfec000 0x30>,
+ <0xfcfec400 0x30>;
+ interrupts = ;
+
+ clocks = <&mstp5_clks R7S72100_CLK_OSTM0>, <&mstp5_clks
R7S72100_CLK_OSTM1>;
+ };
--
2.10.1
[PATCH 2/2] clocksource: Add renesas-ostm timer driver
This patch adds a OSTM driver for the Renesas architecture.
Signed-off-by: Chris Brandt
---
arch/arm/mach-shmobile/Kconfig | 1 +
drivers/clocksource/Kconfig| 12 ++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/renesas-ostm.c | 389 +
4 files changed, 403 insertions(+)
create mode 100644 drivers/clocksource/renesas-ostm.c
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 2bb4b09..b928634 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -57,6 +57,7 @@ config ARCH_R7S72100
select PM
select PM_GENERIC_DOMAINS
select SYS_SUPPORTS_SH_MTU2
+ select SYS_SUPPORTS_RENESAS_OSTM
config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 4866f7a..95c8d56 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -431,6 +431,9 @@ config MTK_TIMER
config SYS_SUPPORTS_SH_MTU2
bool
+config SYS_SUPPORTS_RENESAS_OSTM
+bool
+
config SYS_SUPPORTS_SH_TMU
bool
@@ -467,6 +470,15 @@ config SH_TIMER_MTU2
Timer Pulse Unit 2 (MTU2) hardware available on SoCs from Renesas.
This hardware comes with 16 bit-timer registers.
+config RENESAS_OSTM
+ bool "Renesas OSTM timer driver" if COMPILE_TEST
+ depends on GENERIC_CLOCKEVENTS
+ select CLKSRC_MMIO
+ default SYS_SUPPORTS_RENESAS_OSTM
+ help
+ This enables the build of the OSTM timer driver.
+ It creates a clock source and clock event device.
+
config SH_TIMER_TMU
bool "Renesas TMU timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index a14111e..bbd163b 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)+= cs5535-clockevt.o
obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
+obj-$(CONFIG_RENESAS_OSTM) += renesas-ostm.o
obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
obj-$(CONFIG_EM_TIMER_STI) += em_sti.o
obj-$(CONFIG_CLKBLD_I8253) += i8253.o
diff --git a/drivers/clocksource/renesas-ostm.c
b/drivers/clocksource/renesas-ostm.c
new file mode 100644
index 000..3b417b9
--- /dev/null
+++ b/drivers/clocksource/renesas-ostm.c
@@ -0,0 +1,389 @@
+/*
+ * Renesas Timer Support - OSTM
+ *
+ * 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
+ *
+ * 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
+#include
+#include
+
+/*
+ * The OSTM comes with 2 independent channels.
+ * We will use the first channel (OSTM0) as a free running clocksource and the
+ * second channel (OSTM1) as a interrupt driven clock event.
+ *
+ * Additionally we will use the clocksource channel (OTSM0) for the system
+ * schedule timer sched_clock().
+ */
+
+struct ostm_channel {
+ int irq;
+ struct clk *clk;
+ unsigned long rate;
+ void __iomem *base;
+ unsigned long ticks_per_jiffy;
+ struct clock_event_device ced;
+ struct clocksource cs;
+};
+
+struct ostm_device {
+ struct platform_device *pdev;
+ struct ostm_channel clksrc; /* clock source ostm0 */
+ struct ostm_channel clkevt; /* clock event ostm1 */
+};
+
+static void __iomem *system_clock; /* For sched_clock() */
+
+/* OSTM REGISTERS */
+#defineOSTM_CMP0x000 /* RW,32 */
+#defineOSTM_CNT0x004 /* R,32 */
+#defineOSTM_TE 0x010 /* R,8 */
+#defineOSTM_TS 0x014 /* W,8 */
+#defineOSTM_TT 0x018 /* W,8 */
+#defineOSTM_CTL0x020 /* RW,8 */
+
+#defineTE 0x01
+#defineTS 0x01
+#defineTT 0x01
+#defineCTL_PERIODIC0x00
+#defineCTL_ONESHOT 0x02
+#defineCTL_FREERUN 0x02
+
+static struct ostm_channel *ced_to_ostm_ch(struct clock_event_device *ced)
+{
+ return container_of(ced, struct ostm_channel, ced);
+}
+
+static int __init ostm_init_clksrc(struct ostm_device *ostm)
+{
+ struct ostm_channel *cs = &ostm->clksrc;
+ struct resource *res;
+ int ret = -ENXIO;
+
+ res = platform_get_resource(ostm->pdev, IORESOURCE_MEM, 0
[PATCH 0/3] ARM: dts: add ostm support for r7s72100
This patch set enables the use of the newly created driver renesas-ostm.c for the r7s72100 SoC. This patch set depends on the acceptance of: [PATCH 1/2] dt-bindings: document renesas-ostm timer [PATCH 2/2] clocksource: Add renesas-ostm timer driver Chris Brandt (3): ARM: dts: r7s72100: add ostm clock to device tree ARM: dts: r7s72100: add ostm to device tree ARM: dts: rskrza1: add ostm DT support arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 arch/arm/boot/dts/r7s72100.dtsi| 21 + include/dt-bindings/clock/r7s72100-clock.h | 4 3 files changed, 29 insertions(+) -- 2.10.1
[PATCH 3/3] ARM: dts: rskrza1: add ostm DT support
Signed-off-by: Chris Brandt
---
arch/arm/boot/dts/r7s72100-rskrza1.dts | 4
arch/arm/boot/dts/r7s72100.dtsi| 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts
b/arch/arm/boot/dts/r7s72100-rskrza1.dts
index dd44181..e7b6afa 100644
--- a/arch/arm/boot/dts/r7s72100-rskrza1.dts
+++ b/arch/arm/boot/dts/r7s72100-rskrza1.dts
@@ -61,6 +61,10 @@
status = "okay";
};
+&ostm {
+ status = "okay";
+};
+
&scif2 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 247bbe0..974c084 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -513,7 +513,8 @@
interrupts = ;
- clocks = <&mstp5_clks R7S72100_CLK_OSTM0>, <&mstp5_clks
R7S72100_CLK_OSTM1>;
+ clocks = <&mstp5_clks R7S72100_CLK_OSTM0>,
+<&mstp5_clks R7S72100_CLK_OSTM1>;
status = "disabled";
};
};
--
2.10.1
[PATCH 2/3] ARM: dts: r7s72100: add ostm to device tree
Signed-off-by: Chris Brandt
---
arch/arm/boot/dts/r7s72100.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index d5946df..247bbe0 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -505,4 +505,15 @@
cap-sdio-irq;
status = "disabled";
};
+
+ ostm: ostm@fcfec000 {
+ compatible = "renesas,ostm-r7s72100", "renesas,ostm";
+ reg = <0xfcfec000 0x30>,
+ <0xfcfec400 0x30>;
+ interrupts = ;
+
+ clocks = <&mstp5_clks R7S72100_CLK_OSTM0>, <&mstp5_clks
R7S72100_CLK_OSTM1>;
+ status = "disabled";
+ };
};
--
2.10.1
[PATCH 1/3] ARM: dts: r7s72100: add ostm clock to device tree
Signed-off-by: Chris Brandt
---
arch/arm/boot/dts/r7s72100.dtsi| 9 +
include/dt-bindings/clock/r7s72100-clock.h | 4
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 3dd427d..d5946df 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -108,6 +108,15 @@
clock-output-names = "scif0", "scif1", "scif2",
"scif3", "scif4", "scif5", "scif6", "scif7";
};
+ mstp5_clks: mstp5_clks@fcfe0428 {
+ #clock-cells = <1>;
+ compatible = "renesas,r7s72100-mstp-clocks",
"renesas,cpg-mstp-clocks";
+ reg = <0xfcfe0428 4>;
+ clocks = <&p0_clk>, <&p0_clk>;
+ clock-indices = ;
+ clock-output-names = "ostm0", "ostm1";
+ };
+
mstp7_clks: mstp7_clks@fcfe0430 {
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks",
"renesas,cpg-mstp-clocks";
diff --git a/include/dt-bindings/clock/r7s72100-clock.h
b/include/dt-bindings/clock/r7s72100-clock.h
index 29e01ed..ce09915 100644
--- a/include/dt-bindings/clock/r7s72100-clock.h
+++ b/include/dt-bindings/clock/r7s72100-clock.h
@@ -25,6 +25,10 @@
#define R7S72100_CLK_SCIF6 1
#define R7S72100_CLK_SCIF7 0
+/* MSTP5 */
+#define R7S72100_CLK_OSTM0 1
+#define R7S72100_CLK_OSTM1 0
+
/* MSTP7 */
#define R7S72100_CLK_ETHER 4
--
2.10.1
[PATCH] ARM: dts: r7s72100: fix sdhi clock define
Now that all the clocks in the boot loader are disabled before booting
the kernel, and the mstp driver has been fixed for RZ/A1, here is a typo
that was missed during original testing.
Fixes: 7c8522b7047c ("ARM: dts: r7s72100: add sdhi clock to device tree")
Signed-off-by: Chris Brandt
---
include/dt-bindings/clock/r7s72100-clock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/dt-bindings/clock/r7s72100-clock.h
b/include/dt-bindings/clock/r7s72100-clock.h
index 29e01ed..318ab14 100644
--- a/include/dt-bindings/clock/r7s72100-clock.h
+++ b/include/dt-bindings/clock/r7s72100-clock.h
@@ -46,6 +46,6 @@
/* MSTP12 */
#define R7S72100_CLK_SDHI0 3
-#define R7S72100_CLK_SDHI1 2
+#define R7S72100_CLK_SDHI1 1
#endif /* __DT_BINDINGS_CLOCK_R7S72100_H__ */
--
2.10.1
Re: [EXT] Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
On 01/12/2017 07:55 PM, Lino Sanfilippo wrote:
+
+for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
BTW: How can this work correctly when cur_tx wraps and dirty_tx is greater?
{cur|dirty}_tx never wrap.
Both values are 32 bit and AFAICS they are only incremented (and never reset or
decremented).
Yeah, sorry, O thought you mean the TX ring size wrapping.
So what prevents them from wrapping every 2^32 processed tx descriptors? Am I
missing
something?
The math should still work all right IIUC.
Regards,
Lino
MBR, Sergei
Re: [EXT] Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
Hi,
On 12.01.2017 17:37, Sergei Shtylyov wrote:
External Email
--
On 01/12/2017 04:23 PM, Lino Sanfilippo wrote:
+
+for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
BTW: How can this work correctly when cur_tx wraps and dirty_tx is greater?
{cur|dirty}_tx never wrap.
Both values are 32 bit and AFAICS they are only incremented (and never reset or
decremented).
So what prevents them from wrapping every 2^32 processed tx descriptors? Am I
missing
something?
Regards,
Lino
Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
On 01/12/2017 04:23 PM, Lino Sanfilippo wrote:
+
+for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
BTW: How can this work correctly when cur_tx wraps and dirty_tx is greater?
{cur|dirty}_tx never wrap.
Regards,
Lino
MBR, Sergei
Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
On 01/12/2017 04:18 PM, Simon Horman wrote:
...
Here, it stop once an untransmitted buffer is encountered...
Yes, I see that now.
I wonder if we should:
a) paramatise ravb_tx_free() so it may either clear all transmitted buffers
(current behaviour) or all buffers (new behaviour).
b) provide a different version of this loop in ravb_ring_free()
What are your thoughts?
I'm voting for (b).
Ok, something like this?
@@ -215,6 +225,30 @@ static void ravb_ring_free(struct net_device *ndev, int q)
}
if (priv->tx_ring[q]) {
+ for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0;
priv->dirty_tx[q]++) {
You're still copying the loop logic from ravb_tx_free() while we (I think)
need a simple loop over all the descriptor ring.
[...]
MBR, Sergei
Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request
On 01/12/2017 07:04 PM, David Miller wrote: What I now see is that a few lines further up there is: if (skb_put_padto(skb, ETH_ZLEN)) goto drop; where ETH_ZLEN is 60. So I don't think we need to worry about skb->len being less than 60 and this patch can be simplified to: if (len == 0) len = 4; I'd say this might deserve a comment... Sure. And the one better than the original "quick fix"... :-) MBR, Sergei
Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request
From: Simon Horman Date: Thu, 12 Jan 2017 16:46:47 +0100 > What I now see is that a few lines further up there is: > >if (skb_put_padto(skb, ETH_ZLEN)) > goto drop; > > where ETH_ZLEN is 60. > > So I don't think we need to worry about skb->len being less than 60 and > this patch can be simplified to: > > if (len == 0) > len = 4; I'd say this might deserve a comment...
Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request
On 01/12/2017 04:53 PM, Simon Horman wrote: From: Masaru Nagai Due to alignment requirements of the hardware transmissions are split into two DMA requests, Rather DMA descriptors. a small padding request of 0 - 4 bytes in length 0..3 currently. followed by the a request for rest of the packet. In the case of IP packets the first request will never be zero due to the way that the stack aligns buffers for IP packets. However, for non-IP packets it may be zero. In this case it has been reported that timeouts occur, presumably because transmission stops at the first zero-length DMA request and thus the packet is not transmitted. However, in my environment a BUG is triggered as follows: [ 20.381417] [ cut here ] [ 20.386054] kernel BUG at lib/swiotlb.c:495! [ 20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 20.395805] Modules linked in: [ 20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-1-gf13ad2db193f #162 [ 20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT) [ 20.413474] task: 80063b1f1900 task.stack: 80063a71c000 [ 20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec [ 20.424625] LR is at map_single+0x4c/0x98 [ 20.428629] pc : [] lr : [] pstate: 81c5 [ 20.436019] sp : 80063a71f9b0 [ 20.439327] x29: 80063a71f9b0 x28: 80063a20d500 [ 20.444636] x27: 08ed5000 x26: [ 20.449944] x25: 00067abe2adc x24: [ 20.455252] x23: 0020 x22: 0001 [ 20.460559] x21: 00175ffe x20: 80063b2a0010 [ 20.465866] x19: x18: cae6fb20 [ 20.471173] x17: a09ba018 x16: 087c8b70 [ 20.476480] x15: a084f588 x14: a09cfa14 [ 20.481787] x13: cae87ff0 x12: 0063abe2 [ 20.487098] x11: 08096360 x10: 80063abe2adc [ 20.492407] x9 : x8 : [ 20.497718] x7 : x6 : 08ed50d0 [ 20.503028] x5 : x4 : 0001 [ 20.508338] x3 : x2 : 00067abe2adc [ 20.513648] x1 : bafff000 x0 : [ 20.518958] [ 20.520446] Process mz (pid: 2089, stack limit = 0x80063a71c000) [ 20.526798] Stack: (0x80063a71f9b0 to 0x80063a72) [ 20.532543] f9a0: 80063a71fa30 0839c680 [ 20.540374] f9c0: 80063b2a0010 80063b2a0010 0001 [ 20.548204] f9e0: 006e 80063b23c000 80063b23c000 [ 20.556034] fa00: 80063b23c000 80063a20d500 00013b1f1900 [ 20.563864] fa20: 80063ffd18e0 80063b2a0010 80063a71fa60 0839cd10 [ 20.571694] fa40: 80063b2a0010 80063ffd18e0 00067abe2adc [ 20.579524] fa60: 80063a71fa90 08096380 80063b2a0010 [ 20.587353] fa80: 0001 80063a71fac0 0864f770 [ 20.595184] faa0: 80063b23caf0 0140 [ 20.603014] fac0: 80063a71fb60 087e6498 80063a20d500 80063b23c000 [ 20.610843] fae0: 08daeaf0 08daeb00 [ 20.618673] fb00: 80063a71fc0c 08da7000 80063b23c090 80063a44f000 [ 20.626503] fb20: 08daeb00 80063a71fc0c 08da7000 [ 20.634333] fb40: 80063b23c090 80060037 087e63d8 [ 20.642163] fb60: 80063a71fbc0 08807510 80063a692400 80063a20d500 [ 20.649993] fb80: 80063a44f000 80063b23c000 80063a69249c [ 20.657823] fba0: 80063a087800 80063b23c000 80063a20d500 [ 20.665653] fbc0: 80063a71fc10 087e67dc 80063a20d500 80063a692400 [ 20.673483] fbe0: 80063b23c000 80063a44f000 80063a69249c [ 20.681312] fc00: 80063a5f1a10 00103a087800 80063a71fc70 087e6b24 [ 20.689142] fc20: 80063a5f1a80 80063a71fde8 000f 05ea [ 20.696972] fc40: 80063a5f1a10 000f 0887fbd0 [ 20.704802] fc60: fff43a5f1a80 80063a71fc80 08880240 [ 20.712632] fc80: 80063a71fd90 087c7a34 80063afc7180 [ 20.720462] fca0: cae6fe18 0014 6000 0015 [ 20.728292] fcc0: 0123 00ce 088d2000 80063b1f1900 [ 20.736122] fce0: 8933 08e7cb80 80063a71fd80 087c50a4 [ 20.743951] fd00: 8933 08e7cb80 08e7cb80 001e [ 20.751781] fd20: 80063a71fe4c 0300 0123 [ 20.759611] fd40
Re: [PATCH] pinctrl: core: Fix regression caused by delayed work for hogs
* Geert Uytterhoeven [170112 00:44]:
> Hi Tony,
>
> On Wed, Jan 11, 2017 at 11:13 PM, Tony Lindgren wrote:
> > Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
> > regression at least with sh-pfc that is also a GPIO controller as
> > noted by Geert Uytterhoeven .
> >
> > As the original pinctrl_register() has issues calling pin controller
> > driver functions early before the controller has finished registering,
> > we can't just revert commit df61b366af26. That would break the drivers
> > using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.
> >
> > So let's fix the issue with the following steps as a single patch:
> >
> > 1. Revert the late_init parts of commit df61b366af26.
> >
> >The late_init clearly won't work and we have to just give up
> >on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
> >GENERIC_PINMUX_FUNCTIONS.
> >
> > 2. Split pinctrl_register() into two parts
> >
> >By splitting pinctrl_register() into pinctrl_init_controller()
> >and pinctrl_create_and_start() we have better control over when
> >it's safe to call pinctrl_create().
> >
> > 3. Introduce a new pinctrl_register_and_init() function
> >
> >As suggested by Linus Walleij , we
> >can just introduce a new function for the controllers that need
> >pinctrl_create() called later.
> >
> > 4. Convert the four known problem cases to use new function
> >
> >Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
> >to use the new function to fix the issues. The rest of the drivers
> >can be converted later. Let's also update Documentation/pinctrl.txt
> >accordingly because of the known issues with pinctrl_register().
> >
> > Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
> > Reported-by: Geert Uytterhoeven
> > Cc: Gary Bisson
> > Signed-off-by: Tony Lindgren
>
> Thanks, this fixes r8a7740/armadillo.
>
> Tested-by: Geert Uytterhoeven
OK thanks for testing, good to hear it works for you.
Thanks,
Tony
Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request
On Thu, Jan 12, 2017 at 10:21:02AM -0500, David Miller wrote: > From: Simon Horman > Date: Thu, 12 Jan 2017 14:53:37 +0100 > > > diff --git a/drivers/net/ethernet/renesas/ravb_main.c > > b/drivers/net/ethernet/renesas/ravb_main.c > > index 92d7692c840d..3b4d2504285e 100644 > > --- a/drivers/net/ethernet/renesas/ravb_main.c > > +++ b/drivers/net/ethernet/renesas/ravb_main.c > > @@ -1508,6 +1508,8 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff > > *skb, struct net_device *ndev) > > buffer = PTR_ALIGN(priv->tx_align[q], DPTR_ALIGN) + > > entry / NUM_TX_DESC * DPTR_ALIGN; > > len = PTR_ALIGN(skb->data, DPTR_ALIGN) - skb->data; > > + if (len == 0) > > + len = skb->len > 4 ? 4 : skb->len; > > memcpy(buffer, skb->data, len); > > dma_addr = dma_map_single(ndev->dev.parent, buffer, len, DMA_TO_DEVICE); > > if (dma_mapping_error(ndev->dev.parent, dma_addr)) > > Assume len ends up being skb->len, then the second DMA mapping will be > made of zero length. > > This code needs a bit of TLC. Thanks, I realised that after sending this patch. What I now see is that a few lines further up there is: if (skb_put_padto(skb, ETH_ZLEN)) goto drop; where ETH_ZLEN is 60. So I don't think we need to worry about skb->len being less than 60 and this patch can be simplified to: if (len == 0) len = 4;
Re: [PATCH] arm64: Add support for DMA_ATTR_SKIP_CPU_SYNC attribute to swiotlb
On Wed, Jan 11, 2017 at 11:11:17AM +0100, Geert Uytterhoeven wrote:
> From: Takeshi Kihara
>
> This patch adds support for DMA_ATTR_SKIP_CPU_SYNC attribute for
> dma_{un}map_{page,sg} functions family to swiotlb.
>
> DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
> the CPU cache for the given buffer assuming that it has been already
> transferred to 'device' domain.
>
> Ported from IOMMU .{un}map_{sg,page} ops.
>
> Signed-off-by: Takeshi Kihara
> Acked-by: Laurent Pinchart
> Signed-off-by: Geert Uytterhoeven
> ---
> v2:
> - Add Acked-by.
>
> Support for DMA_ATTR_SKIP_CPU_SYNC was included when porting the IOMMU
> ops from arm to arm64 in commit 13b8629f651164d7 ("arm64: Add IOMMU
> dma_ops").
>
> Presumably it was an oversight that the existing swiotlb based
> implementation didn't have support for DMA_ATTR_SKIP_CPU_SYNC yet?
> ---
> arch/arm64/mm/dma-mapping.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
Thanks. Applied for 4.11, with Robin's Reviewed-by.
Will
Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request
From: Simon Horman Date: Thu, 12 Jan 2017 14:53:37 +0100 > diff --git a/drivers/net/ethernet/renesas/ravb_main.c > b/drivers/net/ethernet/renesas/ravb_main.c > index 92d7692c840d..3b4d2504285e 100644 > --- a/drivers/net/ethernet/renesas/ravb_main.c > +++ b/drivers/net/ethernet/renesas/ravb_main.c > @@ -1508,6 +1508,8 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, > struct net_device *ndev) > buffer = PTR_ALIGN(priv->tx_align[q], DPTR_ALIGN) + >entry / NUM_TX_DESC * DPTR_ALIGN; > len = PTR_ALIGN(skb->data, DPTR_ALIGN) - skb->data; > + if (len == 0) > + len = skb->len > 4 ? 4 : skb->len; > memcpy(buffer, skb->data, len); > dma_addr = dma_map_single(ndev->dev.parent, buffer, len, DMA_TO_DEVICE); > if (dma_mapping_error(ndev->dev.parent, dma_addr)) Assume len ends up being skb->len, then the second DMA mapping will be made of zero length. This code needs a bit of TLC.
Re: [PATCH 04/04] arm64: dts: r8a7795: Connect Ethernet AVB to IPMMU
Hi Magnus,
On Fri, Oct 28, 2016 at 2:40 PM, Geert Uytterhoeven
wrote:
> On Thu, Oct 27, 2016 at 12:29 PM, Magnus Damm wrote:
>> From: Magnus Damm
>>
>> Add IPMMU-DS0 to the Ethernet-AVB device node.
>>
>> Signed-off-by: Magnus Damm
>
> Thanks for your patch!
>
>> ---
>>
>> arch/arm64/boot/dts/renesas/r8a7795.dtsi |1 +
>> 1 file changed, 1 insertion(+)
>>
>> --- 0006/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> +++ work/arch/arm64/boot/dts/renesas/r8a7795.dtsi 2016-10-27
>> 18:08:09.590607110 +0900
>> @@ -706,6 +706,7 @@
>> phy-mode = "rgmii-id";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + iommus = <&ipmmu_ds0 16>;
>> };
>
> I've applied the same to r8a7796.dtsi, and enabled the ipmmu_ds0 and
> ipmmu_mm nodes.
>
> With CONFIG_DMA_API_DEBUG=y, I get:
>
> ipmmu-vmsa e67b.mmu: DMA-API: device driver tries to sync DMA
> memory it has not allocated [device address=0x00067b9d2018]
> [size=8 bytes]
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at lib/dma-debug.c:1234 check_sync+0xcc/0x568
> Modules linked in:
>
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.9.0-rc2-salvator-x-01968-g5193fb91213b0165-dirty #61
> Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
> task: ffc63b860080 task.stack: ffc63b864000
> PC is at check_sync+0xcc/0x568
> LR is at check_sync+0xcc/0x568
> pc : [] lr : [] pstate: 60c5
> sp : ffc63b8677f0
> x29: ffc63b8677f0 x28: ffc63b98f910
> x27: x26: 1000
> x25: ffc63b9d2018 x24: 0001
> x23: f000 x22:
> x21: ff8008c05000 x20: ffc63b867850
> x19: ffc63b991810 x18: e5b7a57f
> x17: a2deee83 x16: 3ed9b3b5
> x15: 578b233a x14: 796220383d657a69
> x13: 735b205d38313032 x12: 6439623736303030
> x11: 3030303078303d73 x10: 7365726464612065
> x9 : 63697665645b2064 x8 : 657461636f6c6c61
> x7 : 20746f6e20736168 x6 : ff8008c6a5b7
> x5 : 0022 x4 : 0010
> x3 : x2 : dead4ead
> x1 : ff8008c19370 x0 : 0090
>
> ---[ end trace 9e4d7153ac803e17 ]---
> Call trace:
> Exception stack(0xffc63b867620 to 0xffc63b867750)
> 7620: ffc63b991810 0080 ffc63b8677f0 ff8008234a58
> 7640: ff8008c05838 ff8008c058e0 ff800877cb09 0007080d869c
> 7660: 01c7 0001 ffc63b867710 ff80080d8884
> 7680: ffc63b991810 ffc63b867850 ff8008c05000
> 76a0: f000 0001 ffc63b9d2018 1000
> 76c0: 0090 ff8008c19370 dead4ead
> 76e0: 0010 0022 ff8008c6a5b7 20746f6e20736168
> 7700: 657461636f6c6c61 63697665645b2064 7365726464612065 3030303078303d73
> 7720: 6439623736303030 735b205d38313032 796220383d657a69 578b233a
> 7740: 3ed9b3b5 a2deee83
> [] check_sync+0xcc/0x568
> [] debug_dma_sync_single_for_device+0x44/0x4c
> [] __arm_lpae_set_pte.isra.3+0x8c/0x98
> [] __arm_lpae_map+0x280/0x2dc
> [] arm_lpae_map+0xb0/0xc4
> [] ipmmu_map+0x20/0x30
I found another issue when booting with swiotlb=force.
In that case, ipmmu_map() crashes with a NULL pointer deference, as
domain->iop is NULL due to a failed call to alloc_io_pgtable_ops() in
ipmmu_domain_init_context() before.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH net] ravb: Remove Rx overflow log messages
From: Simon Horman
Date: Thu, 12 Jan 2017 13:21:06 +0100
> From: Kazuya Mizuguchi
>
> Remove Rx overflow log messages as in an environment where logging results
> in network traffic logging may cause further overflows.
>
> Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
> Signed-off-by: Kazuya Mizuguchi
> [simon: reworked changelog]
> Signed-off-by: Simon Horman
> Acked-by: Sergei Shtylyov
Applied, thanks.
RE: [PATCH 2/3] gpio: gpio-rz: GPIO driver for Renesas RZ series
Hi Jacopo, On Thursday, January 12, 2017, jacopo mondi wrote: > To read the pin direction I would need to add one more register to the > "reg" property range provided in the DTS. > This is of course doable, but I would have two questions here: > - why did you chose to use PMSR register instead of reading/writing > directly to PM? Am I missing something? I guess you can still use the PMSR register to get the current direction of the I/O pin. According to the HW manual: "When reading, the higher 16 bits are read as H. The lower 16 bits are read as the value of the PMn register." While the PMSR register is a cool idea of having a special register that can change a single port pin direction without doing a read-modify-write by the CPU, it doesn't seem to be a standard option in Renesas SoCs (well, except for the older NEC V850 parts where this PFC HW came from). So a more traditional method of just using the Pmn register seems to be more compatible across Renesas SoCs. Chris
[PATCH/RFC net] ravb: do not use zero-length alighment DMA request
From: Masaru Nagai Due to alignment requirements of the hardware transmissions are split into two DMA requests, a small padding request of 0 - 4 bytes in length followed by the a request for rest of the packet. In the case of IP packets the first request will never be zero due to the way that the stack aligns buffers for IP packets. However, for non-IP packets it may be zero. In this case it has been reported that timeouts occur, presumably because transmission stops at the first zero-length DMA request and thus the packet is not transmitted. However, in my environment a BUG is triggered as follows: [ 20.381417] [ cut here ] [ 20.386054] kernel BUG at lib/swiotlb.c:495! [ 20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 20.395805] Modules linked in: [ 20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-1-gf13ad2db193f #162 [ 20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT) [ 20.413474] task: 80063b1f1900 task.stack: 80063a71c000 [ 20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec [ 20.424625] LR is at map_single+0x4c/0x98 [ 20.428629] pc : [] lr : [] pstate: 81c5 [ 20.436019] sp : 80063a71f9b0 [ 20.439327] x29: 80063a71f9b0 x28: 80063a20d500 [ 20.444636] x27: 08ed5000 x26: [ 20.449944] x25: 00067abe2adc x24: [ 20.455252] x23: 0020 x22: 0001 [ 20.460559] x21: 00175ffe x20: 80063b2a0010 [ 20.465866] x19: x18: cae6fb20 [ 20.471173] x17: a09ba018 x16: 087c8b70 [ 20.476480] x15: a084f588 x14: a09cfa14 [ 20.481787] x13: cae87ff0 x12: 0063abe2 [ 20.487098] x11: 08096360 x10: 80063abe2adc [ 20.492407] x9 : x8 : [ 20.497718] x7 : x6 : 08ed50d0 [ 20.503028] x5 : x4 : 0001 [ 20.508338] x3 : x2 : 00067abe2adc [ 20.513648] x1 : bafff000 x0 : [ 20.518958] [ 20.520446] Process mz (pid: 2089, stack limit = 0x80063a71c000) [ 20.526798] Stack: (0x80063a71f9b0 to 0x80063a72) [ 20.532543] f9a0: 80063a71fa30 0839c680 [ 20.540374] f9c0: 80063b2a0010 80063b2a0010 0001 [ 20.548204] f9e0: 006e 80063b23c000 80063b23c000 [ 20.556034] fa00: 80063b23c000 80063a20d500 00013b1f1900 [ 20.563864] fa20: 80063ffd18e0 80063b2a0010 80063a71fa60 0839cd10 [ 20.571694] fa40: 80063b2a0010 80063ffd18e0 00067abe2adc [ 20.579524] fa60: 80063a71fa90 08096380 80063b2a0010 [ 20.587353] fa80: 0001 80063a71fac0 0864f770 [ 20.595184] faa0: 80063b23caf0 0140 [ 20.603014] fac0: 80063a71fb60 087e6498 80063a20d500 80063b23c000 [ 20.610843] fae0: 08daeaf0 08daeb00 [ 20.618673] fb00: 80063a71fc0c 08da7000 80063b23c090 80063a44f000 [ 20.626503] fb20: 08daeb00 80063a71fc0c 08da7000 [ 20.634333] fb40: 80063b23c090 80060037 087e63d8 [ 20.642163] fb60: 80063a71fbc0 08807510 80063a692400 80063a20d500 [ 20.649993] fb80: 80063a44f000 80063b23c000 80063a69249c [ 20.657823] fba0: 80063a087800 80063b23c000 80063a20d500 [ 20.665653] fbc0: 80063a71fc10 087e67dc 80063a20d500 80063a692400 [ 20.673483] fbe0: 80063b23c000 80063a44f000 80063a69249c [ 20.681312] fc00: 80063a5f1a10 00103a087800 80063a71fc70 087e6b24 [ 20.689142] fc20: 80063a5f1a80 80063a71fde8 000f 05ea [ 20.696972] fc40: 80063a5f1a10 000f 0887fbd0 [ 20.704802] fc60: fff43a5f1a80 80063a71fc80 08880240 [ 20.712632] fc80: 80063a71fd90 087c7a34 80063afc7180 [ 20.720462] fca0: cae6fe18 0014 6000 0015 [ 20.728292] fcc0: 0123 00ce 088d2000 80063b1f1900 [ 20.736122] fce0: 8933 08e7cb80 80063a71fd80 087c50a4 [ 20.743951] fd00: 8933 08e7cb80 08e7cb80 001e [ 20.751781] fd20: 80063a71fe4c 0300 0123 [ 20.759611] fd40: 80063b1f 000e 0300 [ 20.767441] fd60: 0
Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
Hmm, I think when the dma-ranges are missing, we should either enforce a 32-bit mask, or disallow DMA completely. It's probably too late for the latter, I wish we had done this earlier in order to force everyone on ARM64 to have a valid dma-ranges property for any DMA master. >>> >>> This can be done over time. >>> >>> However the very idea of this version of patch is - keep working pieces >>> as-is, thus for now setting enforce_range to false in case of no defined >>> dma-ranges is intentional. >> >> What we can do is - check bus width (as it is defined in DT) and set >> enforce_range to true if bus is 32-bit >> >>> What I should re-check is - does rcar dtsi set dma-ranges, and add it if >>> it does not. >> >> It does not, will have to add. >> >> In DT bus is defined as 64-bit. But looks like physically it is 32-bit. >> Maybe DT needs fixing. > > I think we always assumed that the lack of a dma-ranges property > implied a 32-bit width, as that is the safe fallback as well as the > most common case. Yes we assumed that, but that was combined with blindly accepting wider dma_mask per driver's request. Later is being changed. > AFAICT, this means you are actually fine on rcar, and all other > platforms will keep working as we enforce it, but might get slowed > down if they relied on the unintended behavior of allowing 64-bit > DMA. Yesterday Robin raised issue that a change starting to enforce default dma_mask will break existing setups - i.e. those that depend in 64bit DMA being implicitly supported without manually declaring such support. In reply to that, I suggested this version of patchset that should keep existing behavior by default. I'm fine with both approaches regarding behavior on hw that I don't have - but I'm not in position to make any decisions on that.
Re: [PATCH V2 1/2] clk: vc5: Add bindings for IDT VersaClock 5P49V5923 and 5P49V5933
On 01/12/2017 09:25 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi!
> On Thu, Jan 12, 2017 at 2:03 AM, Marek Vasut wrote:
>> Add bindings for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips.
>> These are I2C clock generators with optional clock source from
>> either XTal or dedicated clock generator and, depending on the
>> model, two or more clock outputs.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Michael Turquette
>> Cc: Stephen Boyd
>> Cc: Laurent Pinchart
>> Cc: Rob Herring
>> Cc: devicet...@vger.kernel.org
>> Cc: linux-renesas-soc@vger.kernel.org
>> ---
>> V2: Add mapping between the clock specifier and physical pins of the chip
>> ---
>> .../devicetree/bindings/clock/idt,versaclock5.txt | 65
>> ++
>> 1 file changed, 65 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/clock/idt,versaclock5.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
>> b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
>> new file mode 100644
>> index ..87e9c47a89a3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
>> @@ -0,0 +1,65 @@
>
>> +==Mapping between clock specifier and physical pins==
>> +
>> +When referencing the provided clock in the DT using phandle and
>> +clock specifier, the following mapping applies:
>> +
>> +5P49V5923:
>> + 0 -- OUT0_SEL_I2CB
>> + 1 -- OUT1
>> + 2 -- OUT2
>> +
>> +5P49V5933:
>> + 0 -- OUT0_SEL_I2CB
>> + 1 -- OUT1
>> + 2 -- OUT4
>
> I'm a bit puzzled by the use of "OUT4".
You're not the only one, but at least you're not the one banging your
head against the desk while glaring into the scope and seeing nonsense
on one of the channels :-)
> According to the datasheets, both '5923 and '5933 have OUT1 and OUT2.
> The '5933 datasheet has a single reference to OUT4 ("The OUT1 to OUT4 clock
> outputs"), but that may be a copy and paste error from a datasheet for a part
> with 4 outputs.
The physical VC5 5P49V5933 devkit has OUT0 , OUT1 and OUT4 . At first, I
thought it was laziness in the PCB design -- because there are VC5s with
up to 4 outputs and the devkit PCB is identical for all of them,
except some components are not populated -- but that is not correct.
They actually use (inside of the chip) output1 with fod1 and output4
with fod4 for the 5933 and they use output1 with fod1 and output2 with
fod2 on the 5923 . This became obvious after I took a look into the IDT
clock commander software, which has a visualization of the chip and
there are two "unpopulated" positions between out1 and out4 in case of
the 5933 while on 5923 the unpopulated positions are below out2 .
I have no explanation as for why they did this, it's just unsystematic.
> Apart from that:
> Reviewed-by: Geert Uytterhoeven
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
--
Best regards,
Marek Vasut
Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
On 12/01/17 13:25, Arnd Bergmann wrote: > On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote: >> On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote: > diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > index 5ac373c..480b644 100644 > --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc, > >/* Objects are coherent, unless 'no shareability' flag set. */ >if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY)) > - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true); > + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true); > >/* > * The device-specific probe callback will get invoked by device_add() Why are these actually calling arch_setup_dma_ops() here in the first place? Are these all devices that are DMA masters without an OF node? >>> >>> I don't know, but that's a different topic. This patch just adds >>> argument and sets it to false everywhere but in the location when range >>> should be definitely enforced. >> >> I also wouldn't lose any sleep over a staging driver. > > I think this is in the process of being moved out of staging, and > my question was about the other two as well: The fsl-mc is actually a sort-of-bus-controller probing and configuring its (directly DMA-capable) child devices, so is in fact legitimate here. > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c That one is completely bogus, and should just go away. > drivers/iommu/rockchip-iommu.c That one is part of some ugly trickery involving creating a fake device to represent multiple separate IOMMU devices. The driver could probably be reworked to not need it (the Exynos IOMMU handles a similar situation without such tricks), but it's non-trivial. Robin. > > Arnd >
Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
Hi,
On 12.01.2017 10:11, Simon Horman wrote:
+
+ for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
BTW: How can this work correctly when cur_tx wraps and dirty_tx is greater?
Regards,
Lino
Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
On Thursday, January 12, 2017 9:33:32 AM CET Nikita Yushchenko wrote: > >> Hmm, I think when the dma-ranges are missing, we should either enforce > >> a 32-bit mask, or disallow DMA completely. It's probably too late for > >> the latter, I wish we had done this earlier in order to force everyone > >> on ARM64 to have a valid dma-ranges property for any DMA master. > > > > This can be done over time. > > > > However the very idea of this version of patch is - keep working pieces > > as-is, thus for now setting enforce_range to false in case of no defined > > dma-ranges is intentional. > > What we can do is - check bus width (as it is defined in DT) and set > enforce_range to true if bus is 32-bit > > > What I should re-check is - does rcar dtsi set dma-ranges, and add it if > > it does not. > > It does not, will have to add. > > In DT bus is defined as 64-bit. But looks like physically it is 32-bit. > Maybe DT needs fixing. I think we always assumed that the lack of a dma-ranges property implied a 32-bit width, as that is the safe fallback as well as the most common case. AFAICT, this means you are actually fine on rcar, and all other platforms will keep working as we enforce it, but might get slowed down if they relied on the unintended behavior of allowing 64-bit DMA. Arnd
Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote: > On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote: > > >> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > > >> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > > >> index 5ac373c..480b644 100644 > > >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > > >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > > >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc, > > >> > > >>/* Objects are coherent, unless 'no shareability' flag set. */ > > >>if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY)) > > >> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true); > > >> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true); > > >> > > >>/* > > >> * The device-specific probe callback will get invoked by device_add() > > > > > > Why are these actually calling arch_setup_dma_ops() here in the first > > > place? Are these all devices that are DMA masters without an OF node? > > > > I don't know, but that's a different topic. This patch just adds > > argument and sets it to false everywhere but in the location when range > > should be definitely enforced. > > I also wouldn't lose any sleep over a staging driver. I think this is in the process of being moved out of staging, and my question was about the other two as well: drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/iommu/rockchip-iommu.c Arnd
Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
On Thu, Jan 12, 2017 at 03:03:05PM +0300, Sergei Shtylyov wrote:
> On 01/12/2017 12:11 PM, Simon Horman wrote:
...
> >> Here, it stop once an untransmitted buffer is encountered...
> >
> >Yes, I see that now.
> >
> >I wonder if we should:
> >
> >a) paramatise ravb_tx_free() so it may either clear all transmitted buffers
> > (current behaviour) or all buffers (new behaviour).
> >b) provide a different version of this loop in ravb_ring_free()
> >
> >What are your thoughts?
>
>I'm voting for (b).
Ok, something like this?
@@ -215,6 +225,30 @@ static void ravb_ring_free(struct net_device *ndev, int q)
}
if (priv->tx_ring[q]) {
+ for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0;
priv->dirty_tx[q]++) {
+ struct ravb_tx_desc *desc;
+ int entry;
+
+ entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
+NUM_TX_DESC);
+ desc = &priv->tx_ring[q][entry];
+
+ /* Free the original skb. */
+ if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
+ u32 size = le16_to_cpu(desc->ds_tagl) & TX_DS;
+
+ dma_unmap_single(ndev->dev.parent,
+le32_to_cpu(desc->dptr),
+size, DMA_TO_DEVICE);
+ /* Last packet descriptor? */
+ if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
+ entry /= NUM_TX_DESC;
+
dev_kfree_skb_any(priv->tx_skb[q][entry]);
+ priv->tx_skb[q][entry] = NULL;
+ }
+ }
+ }
+
ring_size = sizeof(struct ravb_tx_desc) *
(priv->num_tx_ring[q] * NUM_TX_DESC + 1);
dma_free_coherent(ndev->dev.parent, ring_size, priv->tx_ring[q],
Re: NVMe vs DMA addressing limitations
On Thu, Jan 12, 2017 at 12:56:07PM +0100, Arnd Bergmann wrote: > That is an interesting question: We actually have the > "DMA_ATTR_NO_KERNEL_MAPPING" for this case, and ARM implements > it in the coherent interface, so that might be a good fit. Yes. my WIP HMB patch uses DMA_ATTR_NO_KERNEL_MAPPING, although I'm workin on x86 at the moment where it's a no-op. > Implementing it in the streaming API makes no sense since we > already have a kernel mapping here, but using a normal allocation > (possibly with DMA_ATTR_NON_CONSISTENT or DMA_ATTR_SKIP_CPU_SYNC, > need to check) might help on other architectures that have > limited amounts of coherent memory and no CMA. Though about that - but in the end DMA_ATTR_NO_KERNEL_MAPPING implies those, so instead of using lots of flags in driver I'd rather fix up more dma_ops implementations to take advantage of DMA_ATTR_NO_KERNEL_MAPPING.
Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support
> I'll bring my Koelsch. Great. I *think* one Koelsch will do, but if it is not too much of a problem, double-checking with a second board won't hurt. So, since Geert will probably bring all necessary cables and supplies, maybe you can pack the board nonetheless? But having one Koelsch already is really good! > AFAIK, Wolfram is interested in "as many SD cards", not "as many Koelsch > boards". 1st: as many Gen2 boards as possible (one per Gen2 SoC version would be awesome!) Gose, Alt anyone? For those, I'll bring my SanDisk card which causes issues when ejecting on all my boards. This is my main target. 2nd: as many SD cards as possible This is a secondary target, but trying to find other issues/other type of cards with same issues will be helpful, too. Thanks, Wolfram signature.asc Description: PGP signature
Re: [PATCHv3 2/6] sh_eth: add generic wake-on-lan support via magic packet
Hello!
On 01/09/2017 06:34 PM, Niklas Söderlund wrote:
Add generic functionality to support Wake-on-LAN using MagicPacket which
are supported by at least a few versions of sh_eth. Only add
functionality for WoL, no specific sh_eth versions are marked to support
WoL yet.
WoL is enabled in the suspend callback by setting MagicPacket detection
and disabling all interrupts expect MagicPacket. In the resume path the
driver needs to reset the hardware to rearm the WoL logic, this prevents
the driver from simply restoring the registers and to take advantage of
that sh_eth was not suspended to reduce resume time. To reset the
hardware the driver closes and reopens the device just like it would do
in a normal suspend/resume scenario without WoL enabled, but it both
closes and opens the device in the resume callback since the device
needs to be open for WoL to work.
One quirk needed for WoL is that the module clock needs to be prevented
from being switched off by Runtime PM. To keep the clock alive the
suspend callback need to call clk_enable() directly to increase the
usage count of the clock. Then when Runtime PM decreases the clock usage
count it won't reach 0 and be switched off.
Signed-off-by: Niklas Söderlund
---
drivers/net/ethernet/renesas/sh_eth.c | 114 +++---
drivers/net/ethernet/renesas/sh_eth.h | 3 +
2 files changed, 109 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c
b/drivers/net/ethernet/renesas/sh_eth.c
index 8a784dce45fa..542c92b57b35 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1552,6 +1552,8 @@ static void sh_eth_emac_interrupt(struct net_device *ndev)
sh_eth_rcv_snd_enable(ndev);
}
}
+ if (felic_stat & ECSR_MPD)
+ pm_wakeup_event(&mdp->pdev->dev, 0);
Hum, seeing a corner case: if we're ignoring the link interrupt (and it
does occur along with ECSR.MPD, we'll return and miss this check. It would
have been preferable to add this code above the ECSR.LCHNG handler...
[...]
@@ -3150,15 +3189,67 @@ static int sh_eth_drv_remove(struct platform_device
*pdev)
#ifdef CONFIG_PM
#ifdef CONFIG_PM_SLEEP
+static int sh_eth_wol_setup(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+
+ /* Only allow ECI interrupts */
+ synchronize_irq(ndev->irq);
+ napi_disable(&mdp->napi);
+ sh_eth_write(ndev, DMAC_M_ECI, EESIPR);
+
+ /* Enable MagicPacket */
+ sh_eth_modify(ndev, ECMR, 0, ECMR_MPDE);
I'd prefer sh_eth_modify(ndev, ECMR, ECMR_MPDE, ECMR_MPDE) to be
consistent with my other code...
[...]
MBR, Sergei
[PATCH net] ravb: Remove Rx overflow log messages
From: Kazuya Mizuguchi
Remove Rx overflow log messages as in an environment where logging results
in network traffic logging may cause further overflows.
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Kazuya Mizuguchi
[simon: reworked changelog]
Signed-off-by: Simon Horman
Acked-by: Sergei Shtylyov
---
Changes since RFC:
* Added Ack from Sergei
---
drivers/net/ethernet/renesas/ravb_main.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index 92d7692c840d..5e5ad978eab9 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -926,14 +926,10 @@ static int ravb_poll(struct napi_struct *napi, int budget)
/* Receive error message handling */
priv->rx_over_errors = priv->stats[RAVB_BE].rx_over_errors;
priv->rx_over_errors += priv->stats[RAVB_NC].rx_over_errors;
- if (priv->rx_over_errors != ndev->stats.rx_over_errors) {
+ if (priv->rx_over_errors != ndev->stats.rx_over_errors)
ndev->stats.rx_over_errors = priv->rx_over_errors;
- netif_err(priv, rx_err, ndev, "Receive Descriptor Empty\n");
- }
- if (priv->rx_fifo_errors != ndev->stats.rx_fifo_errors) {
+ if (priv->rx_fifo_errors != ndev->stats.rx_fifo_errors)
ndev->stats.rx_fifo_errors = priv->rx_fifo_errors;
- netif_err(priv, rx_err, ndev, "Receive FIFO Overflow\n");
- }
out:
return budget - quota;
}
--
2.7.0.rc3.207.g0ac5344
Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote: > >> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > >> b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > >> index 5ac373c..480b644 100644 > >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc, > >> > >>/* Objects are coherent, unless 'no shareability' flag set. */ > >>if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY)) > >> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true); > >> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true); > >> > >>/* > >> * The device-specific probe callback will get invoked by device_add() > > > > Why are these actually calling arch_setup_dma_ops() here in the first > > place? Are these all devices that are DMA masters without an OF node? > > I don't know, but that's a different topic. This patch just adds > argument and sets it to false everywhere but in the location when range > should be definitely enforced. I also wouldn't lose any sleep over a staging driver. Will
Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
On 01/12/2017 12:11 PM, Simon Horman wrote:
From: Kazuya Mizuguchi
"swiotlb buffer is full" errors occur after repeated initialisation of a
device - f.e. suspend/resume or ip link set up/down. This is because memory
mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
is not released. Resolve this problem by unmapping descriptors when
freeing rings.
Note, ravb_tx_free() is moved but not otherwise modified by this patch.
Signed-off-by: Kazuya Mizuguchi
[simon: reworked]
Signed-off-by: Simon Horman
--
v1 [Kazuya Mizuguchi]
v2 [Simon Horman]
* As suggested by Sergei Shtylyov
- Use dma_mapping_error() and rx_desc->ds_cc when unmapping RX descriptors;
this is consistent with the way that they are mapped
- Use ravb_tx_free() to clear TX descriptors
Not sure that was good idea (sorry)... ravb_tx_ring() only unmaps the
transmitted buffers, while we need to unmap everything...
* Reduce scope of new local variable
---
drivers/net/ethernet/renesas/ravb_main.c | 89 ++--
1 file changed, 51 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index 92d7692c840d..1797c48e3176 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -179,6 +179,44 @@ static struct mdiobb_ops bb_ops = {
.get_mdio_data = ravb_get_mdio_data,
};
+/* Free TX skb function for AVB-IP */
+static int ravb_tx_free(struct net_device *ndev, int q)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+ struct net_device_stats *stats = &priv->stats[q];
+ struct ravb_tx_desc *desc;
+ int free_num = 0;
+ int entry;
+ u32 size;
+
+ for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
+ entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
+NUM_TX_DESC);
+ desc = &priv->tx_ring[q][entry];
+ if (desc->die_dt != DT_FEMPTY)
Here, it stop once an untransmitted buffer is encountered...
Yes, I see that now.
I wonder if we should:
a) paramatise ravb_tx_free() so it may either clear all transmitted buffers
(current behaviour) or all buffers (new behaviour).
b) provide a different version of this loop in ravb_ring_free()
What are your thoughts?
I'm voting for (b).
[...]
MBR, Sergei
Re: [PATCH] mmc: host: tmio: drop superfluous exit path
On 6 January 2017 at 09:38, Wolfram Sang
wrote:
> The probe exit path on error does nothing since commit 94b110aff8679b
> ("mmc: tmio: add tmio_mmc_host_alloc/free()"), so we can bail out
> immediately.
>
> Signed-off-by: Wolfram Sang
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/tmio_mmc_pio.c | 20 ++--
> 1 file changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
> index d0d1743b1c002b..2e2df63ce92658 100644
> --- a/drivers/mmc/host/tmio_mmc_pio.c
> +++ b/drivers/mmc/host/tmio_mmc_pio.c
> @@ -1151,7 +1151,7 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
>
> ret = mmc_of_parse(mmc);
> if (ret < 0)
> - goto host_free;
> + return ret;
>
> _host->pdata = pdata;
> platform_set_drvdata(pdev, mmc);
> @@ -1161,14 +1161,12 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
>
> ret = tmio_mmc_init_ocr(_host);
> if (ret < 0)
> - goto host_free;
> + return ret;
>
> _host->ctl = devm_ioremap(&pdev->dev,
> res_ctl->start, resource_size(res_ctl));
> - if (!_host->ctl) {
> - ret = -ENOMEM;
> - goto host_free;
> - }
> + if (!_host->ctl)
> + return -ENOMEM;
>
> tmio_mmc_ops.card_busy = _host->card_busy;
> tmio_mmc_ops.start_signal_voltage_switch =
> _host->start_signal_voltage_switch;
> @@ -1206,10 +1204,8 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
> * Check the sanity of mmc->f_min to prevent tmio_mmc_set_clock() from
> * looping forever...
> */
> - if (mmc->f_min == 0) {
> - ret = -EINVAL;
> - goto host_free;
> - }
> + if (mmc->f_min == 0)
> + return -EINVAL;
>
> /*
> * While using internal tmio hardware logic for card detection, we
> need
> @@ -1274,10 +1270,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
> }
>
> return 0;
> -
> -host_free:
> -
> - return ret;
> }
> EXPORT_SYMBOL(tmio_mmc_host_probe);
>
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NVMe vs DMA addressing limitations
On Thursday, January 12, 2017 12:09:11 PM CET Sagi Grimberg wrote: > >> Another workaround me might need is to limit amount of concurrent DMA > >> in the NVMe driver based on some platform quirk. The way that NVMe works, > >> it can have very large amounts of data that is concurrently mapped into > >> the device. > > > > That's not really just NVMe - other storage and network controllers also > > can DMA map giant amounts of memory. There are a couple aspects to it: > > > > - dma coherent memoery - right now NVMe doesn't use too much of it, > >but upcoming low-end NVMe controllers will soon start to require > >fairl large amounts of it for the host memory buffer feature that > >allows for DRAM-less controller designs. As an interesting quirk > >that is memory only used by the PCIe devices, and never accessed > >by the Linux host at all. > > Would it make sense to convert the nvme driver to use normal allocations > and use the DMA streaming APIs (dma_sync_single_for_[cpu|device]) for > both queues and future HMB? That is an interesting question: We actually have the "DMA_ATTR_NO_KERNEL_MAPPING" for this case, and ARM implements it in the coherent interface, so that might be a good fit. Implementing it in the streaming API makes no sense since we already have a kernel mapping here, but using a normal allocation (possibly with DMA_ATTR_NON_CONSISTENT or DMA_ATTR_SKIP_CPU_SYNC, need to check) might help on other architectures that have limited amounts of coherent memory and no CMA. Another benefit of the coherent API for this kind of buffer is that we can use CMA where available to get a large consecutive chunk of RAM on architectures without an IOMMU when normal memory is no longer available because of fragmentation. Arnd
Re: [PATCH/RFC net] ravb: Remove Rx overflow log messages
On 01/12/2017 11:41 AM, Simon Horman wrote:
From: Kazuya Mizuguchi
Remove Rx overflow log messages as in an environment where logging results
in network traffic logging may cause further overflows.
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Kazuya Mizuguchi
[simon: reworked changelog]
Signed-off-by: Simon Horman
Acked-by: Sergei Shtylyov
MBR, Sergei
Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support
On Thu, Jan 12, 2017 at 12:17 PM, Niklas Söderlund
wrote:
> On 2017-01-11 18:34:32 +0100, Wolfram Sang wrote:
>> > I also have a koelsch, so no need to take one on a plane ;-)
>>
>> I thought yours was so heavily hooked up that it was a bit cumbersome to
>> bring it somewhere. Happy to be wrong here :)
>
> To be super clear, Geert you can bring your Koelsch and Wolfram you only
> want to do testing on one Koelsch board and not as many as you can get
> your hands on?
>
> If so I be happy to leave my board at home and not have to take it on
> the plane, please confirm so there are no misunderstandings :-)
I'll bring my Koelsch.
AFAIK, Wolfram is interested in "as many SD cards", not "as many Koelsch
boards".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support
On 2017-01-11 18:34:32 +0100, Wolfram Sang wrote: > > > I also have a koelsch, so no need to take one on a plane ;-) > > I thought yours was so heavily hooked up that it was a bit cumbersome to > bring it somewhere. Happy to be wrong here :) > To be super clear, Geert you can bring your Koelsch and Wolfram you only want to do testing on one Koelsch board and not as many as you can get your hands on? If so I be happy to leave my board at home and not have to take it on the plane, please confirm so there are no misunderstandings :-) -- Regards, Niklas Söderlund
Re: [PATCH 2/3] gpio: gpio-rz: GPIO driver for Renesas RZ series
Hi Linus,
thanks for review
On 11/01/2017 15:55, Linus Walleij wrote:
On Mon, Jan 9, 2017 at 8:31 PM, Jacopo Mondi wrote:
+static void rz_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+ pinctrl_free_gpio(chip->base + offset);
+
+ /* Set the GPIO as an input to ensure that the next GPIO request won't
+ * drive the GPIO pin as an output.
+ */
+ rz_gpio_direction_input(chip, offset);
+}
Very close to gpiochip_generic_free()
Maybe we should actually set lines as input in the
generic routine!
Is it ok then to simply substitute "pinctrl_free_gpio" with
"gpiochip_generic_free" and keep rz_gpio_direction_input here?
+ gpio_chip = &p->gpio_chip;
+ gpio_chip->direction_input = rz_gpio_direction_input;
+ gpio_chip->get = rz_gpio_get;
+ gpio_chip->direction_output = rz_gpio_direction_output;
Please implement .get_direction() as well.
That's funny how a simple addition like this one would require several
changes (possibly even in the dts ABI defined by this driver).
This is more a question for the original driver author I hope is
listening here:
To read the pin direction I would need to add one more register to the
"reg" property range provided in the DTS.
This is of course doable, but I would have two questions here:
- why did you chose to use PMSR register instead of reading/writing
directly to PM? Am I missing something?
- wouldn't it be better to just receive the port base address from the
"reg" property and offset from that instead of having the 3 register
addresses specified in the dts?
See, the dts now looks like this:
reg = <0xfcfe3100 0x4>, /* PSR */
<0xfcfe3200 0x2>, /* PPR */
<0xfcfe3800 0x4>; /* PMSR */
Shouldn't we just receive the gpiochip base address and the offset as we
like?
Thanks
j
Re: NVMe vs DMA addressing limitations
Another workaround me might need is to limit amount of concurrent DMA in the NVMe driver based on some platform quirk. The way that NVMe works, it can have very large amounts of data that is concurrently mapped into the device. That's not really just NVMe - other storage and network controllers also can DMA map giant amounts of memory. There are a couple aspects to it: - dma coherent memoery - right now NVMe doesn't use too much of it, but upcoming low-end NVMe controllers will soon start to require fairl large amounts of it for the host memory buffer feature that allows for DRAM-less controller designs. As an interesting quirk that is memory only used by the PCIe devices, and never accessed by the Linux host at all. Would it make sense to convert the nvme driver to use normal allocations and use the DMA streaming APIs (dma_sync_single_for_[cpu|device]) for both queues and future HMB? - size vs number of the dynamic mapping. We probably want the dma_ops specify a maximum mapping size for a given device. As long as we can make progress with a few mappings swiotlb / the iommu can just fail mapping and the driver will propagate that to the block layer that throttles I/O. Isn't max mapping size per device too restrictive? it is possible that not all devices posses active mappings concurrently.
Re: [PATCH v2] arm64: dts: r8a7795: salvator-x: Add DU0 and DU3 external dot clocks
On Thu, Jan 12, 2017 at 11:23:57AM +0200, Laurent Pinchart wrote: > Hi Simon, > > On Thursday 12 Jan 2017 10:04:34 Simon Horman wrote: > > On Thu, Jan 12, 2017 at 03:51:21AM +0200, Laurent Pinchart wrote: > > > The clocks are generated by an I2C-controlled programmable clock > > > generator. > > > > > > Signed-off-by: Laurent Pinchart > > > > > > --- > > > > > > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 26 +++-- > > > 1 file changed, 24 insertions(+), 2 deletions(-) > > > > > > This patch depends on the clk-versaclock5 driver posted by Marek. > > > > Can the patch be safely applied without the above driver present? > > It will result in DU probing being deferred forever, so I'd say no :-) Agreed. > > FWIW, this patch does not seem to apply cleanly on > > renesas-next-20170110-v4.10-rc2. > > I'll fix the conflicts and resubmit when the driver lands. Thanks.
Re: [PATCH v2] arm64: dts: r8a7795: salvator-x: Add DU0 and DU3 external dot clocks
Hi Simon, On Thursday 12 Jan 2017 10:04:34 Simon Horman wrote: > On Thu, Jan 12, 2017 at 03:51:21AM +0200, Laurent Pinchart wrote: > > The clocks are generated by an I2C-controlled programmable clock > > generator. > > > > Signed-off-by: Laurent Pinchart > > > > --- > > > > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 26 +++-- > > 1 file changed, 24 insertions(+), 2 deletions(-) > > > > This patch depends on the clk-versaclock5 driver posted by Marek. > > Can the patch be safely applied without the above driver present? It will result in DU probing being deferred forever, so I'd say no :-) > FWIW, this patch does not seem to apply cleanly on > renesas-next-20170110-v4.10-rc2. I'll fix the conflicts and resubmit when the driver lands. -- Regards, Laurent Pinchart
Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings
On Fri, Jan 06, 2017 at 10:02:36PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 01/05/2017 01:43 PM, Simon Horman wrote:
>
> >From: Kazuya Mizuguchi
> >
> >"swiotlb buffer is full" errors occur after repeated initialisation of a
> >device - f.e. suspend/resume or ip link set up/down. This is because memory
> >mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
> >is not released. Resolve this problem by unmapping descriptors when
> >freeing rings.
> >
> >Note, ravb_tx_free() is moved but not otherwise modified by this patch.
> >
> >Signed-off-by: Kazuya Mizuguchi
> >[simon: reworked]
> >Signed-off-by: Simon Horman
> >--
> >v1 [Kazuya Mizuguchi]
> >
> >v2 [Simon Horman]
> >* As suggested by Sergei Shtylyov
> > - Use dma_mapping_error() and rx_desc->ds_cc when unmapping RX descriptors;
> >this is consistent with the way that they are mapped
> > - Use ravb_tx_free() to clear TX descriptors
>
>Not sure that was good idea (sorry)... ravb_tx_ring() only unmaps the
> transmitted buffers, while we need to unmap everything...
>
> >* Reduce scope of new local variable
> >---
> > drivers/net/ethernet/renesas/ravb_main.c | 89
> > ++--
> > 1 file changed, 51 insertions(+), 38 deletions(-)
> >
> >diff --git a/drivers/net/ethernet/renesas/ravb_main.c
> >b/drivers/net/ethernet/renesas/ravb_main.c
> >index 92d7692c840d..1797c48e3176 100644
> >--- a/drivers/net/ethernet/renesas/ravb_main.c
> >+++ b/drivers/net/ethernet/renesas/ravb_main.c
> >@@ -179,6 +179,44 @@ static struct mdiobb_ops bb_ops = {
> > .get_mdio_data = ravb_get_mdio_data,
> > };
> >
> >+/* Free TX skb function for AVB-IP */
> >+static int ravb_tx_free(struct net_device *ndev, int q)
> >+{
> >+struct ravb_private *priv = netdev_priv(ndev);
> >+struct net_device_stats *stats = &priv->stats[q];
> >+struct ravb_tx_desc *desc;
> >+int free_num = 0;
> >+int entry;
> >+u32 size;
> >+
> >+for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
> >+entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
> >+ NUM_TX_DESC);
> >+desc = &priv->tx_ring[q][entry];
> >+if (desc->die_dt != DT_FEMPTY)
>
>Here, it stop once an untransmitted buffer is encountered...
Yes, I see that now.
I wonder if we should:
a) paramatise ravb_tx_free() so it may either clear all transmitted buffers
(current behaviour) or all buffers (new behaviour).
b) provide a different version of this loop in ravb_ring_free()
What are your thoughts?
> >+break;
> >+/* Descriptor type must be checked before all other reads */
> >+dma_rmb();
> >+size = le16_to_cpu(desc->ds_tagl) & TX_DS;
> >+/* Free the original skb. */
> >+if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
> >+dma_unmap_single(ndev->dev.parent,
> >le32_to_cpu(desc->dptr),
> >+ size, DMA_TO_DEVICE);
> >+/* Last packet descriptor? */
> >+if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
> >+entry /= NUM_TX_DESC;
> >+dev_kfree_skb_any(priv->tx_skb[q][entry]);
> >+priv->tx_skb[q][entry] = NULL;
> >+stats->tx_packets++;
> >+}
> >+free_num++;
> >+}
> >+stats->tx_bytes += size;
> >+desc->die_dt = DT_EEMPTY;
> >+}
> >+return free_num;
> >+}
> >+
> > /* Free skb's and DMA buffers for Ethernet AVB */
> > static void ravb_ring_free(struct net_device *ndev, int q)
> > {
> >@@ -207,6 +245,18 @@ static void ravb_ring_free(struct net_device *ndev, int
> >q)
> > priv->tx_align[q] = NULL;
> >
> > if (priv->rx_ring[q]) {
> >+for (i = 0; i < priv->num_rx_ring[q]; i++) {
> >+struct ravb_ex_rx_desc *rx_desc = &priv->rx_ring[q][i];
> >+
> >+if (!dma_mapping_error(ndev->dev.parent,
> >+ rx_desc->dptr)) {
>
> You forgot le32_to_cpu() here, we can't use the raw descriptor fields.
Thanks, I will fix that.
> >+dma_unmap_single(ndev->dev.parent,
> >+ le32_to_cpu(rx_desc->dptr),
> >+ PKT_BUF_SZ,
> >+ DMA_FROM_DEVICE);
> >+rx_desc->ds_cc = cpu_to_le16(0);
>
>You don't check it anyway, not sure what that buys...
Thanks, I will see about dropping that.
Re: [PATCH v3] mmc: sh_mmcif: Document r7s72100 DT bindings
On Thu, Jan 12, 2017 at 08:36:10AM +0100, Geert Uytterhoeven wrote: > Hi Chris, > > On Thu, Jan 12, 2017 at 5:14 AM, Chris Brandt > wrote: > > Signed-off-by: Chris Brandt > > > > --- > > v3: > > * added list of how many interrupts each SOC has > > v2: > > * added interrupt description > > Thanks or the update! > > Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman
Re: [PATCH v2] arm64: dts: r8a7795: salvator-x: Add DU0 and DU3 external dot clocks
On Thu, Jan 12, 2017 at 03:51:21AM +0200, Laurent Pinchart wrote: > The clocks are generated by an I2C-controlled programmable clock > generator. > > Signed-off-by: Laurent Pinchart > --- > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 26 > -- > 1 file changed, 24 insertions(+), 2 deletions(-) > > This patch depends on the clk-versaclock5 driver posted by Marek. Can the patch be safely applied without the above driver present? FWIW, this patch does not seem to apply cleanly on renesas-next-20170110-v4.10-rc2.
Re: [PATCH] pinctrl: core: Fix regression caused by delayed work for hogs
Hi Tony,
On Wed, Jan 11, 2017 at 11:13 PM, Tony Lindgren wrote:
> Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
> regression at least with sh-pfc that is also a GPIO controller as
> noted by Geert Uytterhoeven .
>
> As the original pinctrl_register() has issues calling pin controller
> driver functions early before the controller has finished registering,
> we can't just revert commit df61b366af26. That would break the drivers
> using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.
>
> So let's fix the issue with the following steps as a single patch:
>
> 1. Revert the late_init parts of commit df61b366af26.
>
>The late_init clearly won't work and we have to just give up
>on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
>GENERIC_PINMUX_FUNCTIONS.
>
> 2. Split pinctrl_register() into two parts
>
>By splitting pinctrl_register() into pinctrl_init_controller()
>and pinctrl_create_and_start() we have better control over when
>it's safe to call pinctrl_create().
>
> 3. Introduce a new pinctrl_register_and_init() function
>
>As suggested by Linus Walleij , we
>can just introduce a new function for the controllers that need
>pinctrl_create() called later.
>
> 4. Convert the four known problem cases to use new function
>
>Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
>to use the new function to fix the issues. The rest of the drivers
>can be converted later. Let's also update Documentation/pinctrl.txt
>accordingly because of the known issues with pinctrl_register().
>
> Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
> Reported-by: Geert Uytterhoeven
> Cc: Gary Bisson
> Signed-off-by: Tony Lindgren
Thanks, this fixes r8a7740/armadillo.
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH/RFC net] ravb: Remove Rx overflow log messages
From: Kazuya Mizuguchi
Remove Rx overflow log messages as in an environment where logging results
in network traffic logging may cause further overflows.
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Kazuya Mizuguchi
[simon: reworked changelog]
Signed-off-by: Simon Horman
---
drivers/net/ethernet/renesas/ravb_main.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index 92d7692c840d..5e5ad978eab9 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -926,14 +926,10 @@ static int ravb_poll(struct napi_struct *napi, int budget)
/* Receive error message handling */
priv->rx_over_errors = priv->stats[RAVB_BE].rx_over_errors;
priv->rx_over_errors += priv->stats[RAVB_NC].rx_over_errors;
- if (priv->rx_over_errors != ndev->stats.rx_over_errors) {
+ if (priv->rx_over_errors != ndev->stats.rx_over_errors)
ndev->stats.rx_over_errors = priv->rx_over_errors;
- netif_err(priv, rx_err, ndev, "Receive Descriptor Empty\n");
- }
- if (priv->rx_fifo_errors != ndev->stats.rx_fifo_errors) {
+ if (priv->rx_fifo_errors != ndev->stats.rx_fifo_errors)
ndev->stats.rx_fifo_errors = priv->rx_fifo_errors;
- netif_err(priv, rx_err, ndev, "Receive FIFO Overflow\n");
- }
out:
return budget - quota;
}
--
2.7.0.rc3.207.g0ac5344
Re: [PATCH v2] arm64: dts: r8a7795: salvator-x: Add DU0 and DU3 external dot clocks
On Thu, Jan 12, 2017 at 2:51 AM, Laurent Pinchart
wrote:
> The clocks are generated by an I2C-controlled programmable clock
> generator.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH V2 1/2] clk: vc5: Add bindings for IDT VersaClock 5P49V5923 and 5P49V5933
Hi Marek,
On Thu, Jan 12, 2017 at 2:03 AM, Marek Vasut wrote:
> Add bindings for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips.
> These are I2C clock generators with optional clock source from
> either XTal or dedicated clock generator and, depending on the
> model, two or more clock outputs.
>
> Signed-off-by: Marek Vasut
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: Laurent Pinchart
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Add mapping between the clock specifier and physical pins of the chip
> ---
> .../devicetree/bindings/clock/idt,versaclock5.txt | 65
> ++
> 1 file changed, 65 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/idt,versaclock5.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> new file mode 100644
> index ..87e9c47a89a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> @@ -0,0 +1,65 @@
> +==Mapping between clock specifier and physical pins==
> +
> +When referencing the provided clock in the DT using phandle and
> +clock specifier, the following mapping applies:
> +
> +5P49V5923:
> + 0 -- OUT0_SEL_I2CB
> + 1 -- OUT1
> + 2 -- OUT2
> +
> +5P49V5933:
> + 0 -- OUT0_SEL_I2CB
> + 1 -- OUT1
> + 2 -- OUT4
I'm a bit puzzled by the use of "OUT4".
According to the datasheets, both '5923 and '5933 have OUT1 and OUT2.
The '5933 datasheet has a single reference to OUT4 ("The OUT1 to OUT4 clock
outputs"), but that may be a copy and paste error from a datasheet for a part
with 4 outputs.
Apart from that:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
