Re: [PATCH v4 1/2] pinctrl: Add RZ/A2 pin and gpio controller
Hi Chris,
On Tue, Nov 13, 2018 at 8:26 PM Chris Brandt wrote:
> On Tuesday, November 13, 2018, Geert Uytterhoeven wrote:
> > > It makes the files show up under /sys look nice.
> > >
> > > For example, P5_6 is button SW4:
> > >
> > > $ echo 912 > /sys/class/gpio/export
> > >
> > > Then you end up with "/sys/class/gpio/P5_6/"
> > >
> > > $ echo in > /sys/class/gpio/P5_6/direction
> > > $ cat /sys/class/gpio/P5_6/direction
> > > $ cat /sys/class/gpio/P5_6/value
> >
> > (Ah, the legacy and deprecated sysfs GPIO interface, being replaced
> > by /dev/gpiochip[0-9]+ and https://github.com/brgl/libgpiod)
> >
> > Cool, I didn't know that.
> > But you still need to know which number to write to the export file
> > in the first place?
>
> True, meaning the table does not help you as much as you want.
> Jacopo also mentioned the new libgpiod.
> So, I think I might just drop this table in the next revision.
>
> What I really want to do is just say "make P5_6 an input" and
> not have to convert to a global ID number. But, I'm not sure how
> libgpiod is going to know what "P5_6" is.
There are two parts:
1. New kernel /dev/gpiochip[0-9]+ interface
Sample code comes with the kernel under tools/gpio/.
E.g.
root@koelsch:~# lsgpio -n gpiochip7
GPIO chip: gpiochip7, "e6055800.gpio", 26 GPIO lines
line 0: unnamed "SW30" [kernel active-low]
line 1: unnamed "SW31" [kernel active-low]
line 2: unnamed "SW32" [kernel active-low]
line 3: unnamed "SW33" [kernel active-low]
line 4: unnamed "SW34" [kernel active-low]
line 5: unnamed "SW35" [kernel active-low]
line 6: unnamed "SW36" [kernel active-low]
line 7: unnamed unused
line 8: unnamed unused
line 9: unnamed unused
line 10: unnamed unused
line 11: unnamed unused
line 12: unnamed unused
line 13: unnamed unused
line 14: unnamed unused
line 15: unnamed unused
line 16: unnamed unused
line 17: unnamed "regulator-vcc-sdhi0" [kernel output]
line 18: unnamed "regulator-vcc-sdhi1" [kernel output]
line 19: unnamed "regulator-vcc-sdhi2" [kernel output]
line 20: unnamed unused
line 21: unnamed unused
line 22: unnamed unused
line 23: unnamed unused
line 24: unnamed unused
line 25: unnamed unused
2. Userspace library libgpiod, incl. a few tools like
gpioinfo/gpioset/gpioget.
These accept whatever reference to identify a GPIO.
As your driver fills in pins[i].name, I expect you can pass names
like P5_6.
Have fun! ;-)
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/RFC] dmaengine: sh: Remove R-Mobile APE6 support
Hi Rob,
On Tue, Nov 13, 2018 at 8:32 PM Rob Landley wrote:
> On 11/12/18 9:30 AM, Geert Uytterhoeven wrote:
> > CC SuperH
> >
> > On Mon, Nov 12, 2018 at 4:22 PM Geert Uytterhoeven
> > wrote:
> >> Renesas R-Mobile APE6 support is currently unused:
> >> - DMA slaves were never enabled in r8a73a4.dtsi,
> >> - The driver relies on legacy filter matching and describing all
> >> slaves and MID/RIDs in a table, unlike modern DMA engine drivers for
> >> similar hardware like rcar-dmac,
> >> - The driver doesn't seem to work well.
> >>
> >> Remove the driver, it can be resurrected from git history when needed.
> >>
> >> As this was the last user of SH_DMAE_BASE on Renesas ARM SoCs, the
> >> sh-dma-engine driver core is now used on SuperH only.
>
> I'm trying to add dma support to smc91x on an sh7760 board:
>
> https://www.spinics.net/lists/linux-sh/msg53400.html
>
> I missed the ship window for the previous iteration so we had to use PIO, but
> DMA's a huge speedup and it's cycling back around on my todo list...
>
> Unfortunately due to a flash corruption bug we were stuck at 4.14 for that
> release. I'm trying to track that down now, then need to redo this work on top
> of 4.20 or 4.21.
>
> Kernel board support patches are at the lawyers being frowned at expensively
> before release, but it won't include DMA this time because I only got the
> first
> half of it working. (Board's hooked up and can do memory-to-memory, but the
> ethernet card couldn't use it because the smc91x claims of using dmaengine are
> lies, it's hardwired to a specific arm chip ("mainstone" I think?), and when I
> got QEMU to emulate that ARM board and tried to enable DMA: packet timeouts. I
> dunno if it's broken in the kernel or QEMU doesn't emulate the DMA...)
>
> >> Notes:
> >> 1. As Renesas ARM SoCs no longer use drivers/dma/sh/shdma-base.c, the
> >> task to remove use of the deprecated dma_slave_config.direction
> >> field gets thrown into the SuperH maintainers' basket ;-)
>
> At least in 4.14 there were two DMA apis, once of which is obsolete and
> unused,
> and the other is modern dmaengine support which at least passes its self-test.
>
> I left off boggling at the "slave API", I think...
Yes, there's SH_DMA_API and the "new" DMA_ENGINE API.
> >> 3. I tried to get SCIFA DMA to work by:
> >>- Applying the DT and driver patches below,
> >>- Reverting 219fb0c1436e4893 ("serial: sh-sci: Remove the
> >> platform data dma slave rx/tx channel IDs").
>
> The board I'm using is platform data, never got converted to device tree. (If
> I
> can ever convince them to mail a board to Rich Felker I might try to hire him
> to
> convert it _myself_. Or I could just get him an old board on ebay, current
> cheapest one looks like
> https://www.ebay.com/p/Johnson-Controls-Ms-nae3511-2-Metasys-Controller-NAE-and-2x-Unt1108/567230953?iid=283254042308
> at the moment? Dead battery's fine for a dev/test system...)
>
> But it's not happening this month.
>
> >> After that, serial console output using DMA seems to work, but the
> >> system locks up when receiving any serial console input.
> >> Probably it is easier to add r8a73a4 support to rcar-dmac.
>
> What _is_ the status of dmaengine? I thought it was the generic dma API the
> kernel was moving towards? (The youtube videos suggested such...)
Dmaengine is working on the Renesas R-Car Gen2 and Gen3 SoCs, using
rcar-dmac and usb-dmac. But that's ARM (32/64-bit), not SuperH.
I'm afraid you're on your own on SuperH... Good luck!
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 v4 1/2] pinctrl: Add RZ/A2 pin and gpio controller
Hi Chris,
a few more notes on top of what Geert said. Thanks for addressing
comments on the previous version.
On Wed, Nov 07, 2018 at 01:27:32PM -0500, Chris Brandt wrote:
> Adds support for the pin and gpio controller found in R7S9210 (RZ/A2) SoCs.
>
> Signed-off-by: Chris Brandt
> ---
> v3:
> - Changed names from Px to PORTx because "PC" is already defined
> v2:
> - fixed SOC part number in comments
> - sorted #includes
> - removed spaces in pfc_pin_port_name enum
> - put RZA2_NPORTS at the end of pfc_pin_port_name enum
> - added RZA2_ to the beginning of all #define macros
> - put ( ) around all passed arguments in #define macros
> - made helper macros to get register address easier
> - use defines for pin direction bit settings
> ---
> drivers/pinctrl/Kconfig| 11 +
> drivers/pinctrl/Makefile | 1 +
> drivers/pinctrl/pinctrl-rza2.c | 530
> +
> 3 files changed, 542 insertions(+)
> create mode 100644 drivers/pinctrl/pinctrl-rza2.c
>
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index 4d8c00eac742..3e4d890d4bd9 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -195,6 +195,17 @@ config PINCTRL_RZA1
> help
> This selects pinctrl driver for Renesas RZ/A1 platforms.
>
> +config PINCTRL_RZA2
> + bool "Renesas RZ/A2 gpio and pinctrl driver"
> + depends on OF
> + depends on ARCH_R7S9210 || COMPILE_TEST
> + select GPIOLIB
> + select GENERIC_PINCTRL_GROUPS
> + select GENERIC_PINMUX_FUNCTIONS
> + select GENERIC_PINCONF
> + help
> + This selects pinctrl driver for Renesas RZ/A2 platforms.
> +
> config PINCTRL_RZN1
> bool "Renesas RZ/N1 pinctrl driver"
> depends on OF
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index 18a13c1e2c21..712184b74a5c 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_PINCTRL_PIC32) += pinctrl-pic32.o
> obj-$(CONFIG_PINCTRL_PISTACHIO) += pinctrl-pistachio.o
> obj-$(CONFIG_PINCTRL_ROCKCHIP) += pinctrl-rockchip.o
> obj-$(CONFIG_PINCTRL_RZA1) += pinctrl-rza1.o
> +obj-$(CONFIG_PINCTRL_RZA2) += pinctrl-rza2.o
> obj-$(CONFIG_PINCTRL_RZN1) += pinctrl-rzn1.o
> obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
> obj-$(CONFIG_PINCTRL_SIRF) += sirf/
> diff --git a/drivers/pinctrl/pinctrl-rza2.c b/drivers/pinctrl/pinctrl-rza2.c
> new file mode 100644
> index ..3781c3f693e8
> --- /dev/null
> +++ b/drivers/pinctrl/pinctrl-rza2.c
> @@ -0,0 +1,530 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Combined GPIO and pin controller support for Renesas RZ/A2 (R7S9210) SoC
> + *
> + * Copyright (C) 2018 Chris Brandt
> + */
> +
> +/*
> + * This pin controller/gpio combined driver supports Renesas devices of RZ/A2
> + * family.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "core.h"
> +#include "pinmux.h"
> +
> +#define DRIVER_NAME "pinctrl-rza2"
> +
> +#define RZA2_PINS_PER_PORT 8
> +#define RZA2_NPINS (RZA2_PINS_PER_PORT * RZA2_NPORTS)
> +#define RZA2_PIN_ID_TO_PORT(id) ((id) / RZA2_PINS_PER_PORT)
> +#define RZA2_PIN_ID_TO_PIN(id) ((id) % RZA2_PINS_PER_PORT)
> +
> +/*
> + * Use 16 lower bits [15:0] for pin identifier
> + * Use 16 higher bits [31:16] for pin mux function
> + */
> +#define MUX_PIN_ID_MASK GENMASK(15, 0)
> +#define MUX_FUNC_MASKGENMASK(31, 16)
> +#define MUX_FUNC_OFFS16
> +#define MUX_FUNC(pinconf)((pinconf & MUX_FUNC_MASK) >> MUX_FUNC_OFFS)
> +
> +enum pfc_pin_port_name {PORT0, PORT1, PORT2, PORT3, PORT4, PORT5, PORT6,
> PORT7,
> + PORT8, PORT9, PORTA, PORTB, PORTC, PORTD, PORTE, PORTF,
> + PORTG, PORTH, PORTJ, PORTK, PORTL, PORTM, RZA2_NPORTS};
> +static const char port_names[] = "0123456789ABCDEFGHJKLM";
> +
> +struct rza2_pinctrl_priv {
> + struct device *dev;
> + void __iomem *base;
> +
> + struct pinctrl_pin_desc *pins;
> + struct pinctrl_desc desc;
> + struct pinctrl_dev *pctl;
> +};
> +
> +#define RZA2_PDR_BASE(_b)((_b) + 0x) /* 16-bit, 2 bytes apart */
> +#define RZA2_PODR_BASE(_b) ((_b) + 0x0040) /* 8-bit, 1 byte apart */
> +#define RZA2_PIDR_BASE(_b) ((_b) + 0x0060) /* 8-bit, 1 byte apart */
> +#define RZA2_PMR_BASE(_b)((_b) + 0x0080) /* 8-bit, 1 byte apart */
> +#define RZA2_DSCR_BASE(_b) ((_b) + 0x0140) /* 16-bit, 2 bytes apart */
> +#define RZA2_PFS_BASE(_b)((_b) + 0x0200) /* 8-bit, 8 bytes apart */
> +#define RZA2_PWPR(_b)((_b) + 0x02FF) /* 8-bit */
0x2ff
> +#define RZA2_PFENET(_b) ((_b) + 0x0820) /* 8-bit */
> +#define RZA2_PPOC(_b)((_b) + 0x0900) /* 32-bit */
> +#define RZA2_PHMOMO(_b) ((_b) + 0x0980) /* 32-bit */
> +#define RZA2_PCKIO(_b) ((_b) + 0x09D0) /* 8-bit */
> +
0x09d0
> +#define
RE: [PATCH v4 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO
On Tuesday, November 13, 2018, jacopo mondi wrote: > Just two minor things, so please add my > Reviewed-by: Jacopo Mondi Thanks Jacopo! Chris
Re: [PATCH/RFC] dmaengine: sh: Remove R-Mobile APE6 support
On 11/12/18 9:30 AM, Geert Uytterhoeven wrote:
> CC SuperH
>
> On Mon, Nov 12, 2018 at 4:22 PM Geert Uytterhoeven
> wrote:
>> Renesas R-Mobile APE6 support is currently unused:
>> - DMA slaves were never enabled in r8a73a4.dtsi,
>> - The driver relies on legacy filter matching and describing all
>> slaves and MID/RIDs in a table, unlike modern DMA engine drivers for
>> similar hardware like rcar-dmac,
>> - The driver doesn't seem to work well.
>>
>> Remove the driver, it can be resurrected from git history when needed.
>>
>> As this was the last user of SH_DMAE_BASE on Renesas ARM SoCs, the
>> sh-dma-engine driver core is now used on SuperH only.
I'm trying to add dma support to smc91x on an sh7760 board:
https://www.spinics.net/lists/linux-sh/msg53400.html
I missed the ship window for the previous iteration so we had to use PIO, but
DMA's a huge speedup and it's cycling back around on my todo list...
Unfortunately due to a flash corruption bug we were stuck at 4.14 for that
release. I'm trying to track that down now, then need to redo this work on top
of 4.20 or 4.21.
Kernel board support patches are at the lawyers being frowned at expensively
before release, but it won't include DMA this time because I only got the first
half of it working. (Board's hooked up and can do memory-to-memory, but the
ethernet card couldn't use it because the smc91x claims of using dmaengine are
lies, it's hardwired to a specific arm chip ("mainstone" I think?), and when I
got QEMU to emulate that ARM board and tried to enable DMA: packet timeouts. I
dunno if it's broken in the kernel or QEMU doesn't emulate the DMA...)
>> Notes:
>> 1. As Renesas ARM SoCs no longer use drivers/dma/sh/shdma-base.c, the
>> task to remove use of the deprecated dma_slave_config.direction
>> field gets thrown into the SuperH maintainers' basket ;-)
At least in 4.14 there were two DMA apis, once of which is obsolete and unused,
and the other is modern dmaengine support which at least passes its self-test.
I left off boggling at the "slave API", I think...
>> 3. I tried to get SCIFA DMA to work by:
>>- Applying the DT and driver patches below,
>>- Reverting 219fb0c1436e4893 ("serial: sh-sci: Remove the
>> platform data dma slave rx/tx channel IDs").
The board I'm using is platform data, never got converted to device tree. (If I
can ever convince them to mail a board to Rich Felker I might try to hire him to
convert it _myself_. Or I could just get him an old board on ebay, current
cheapest one looks like
https://www.ebay.com/p/Johnson-Controls-Ms-nae3511-2-Metasys-Controller-NAE-and-2x-Unt1108/567230953?iid=283254042308
at the moment? Dead battery's fine for a dev/test system...)
But it's not happening this month.
>> After that, serial console output using DMA seems to work, but the
>> system locks up when receiving any serial console input.
>> Probably it is easier to add r8a73a4 support to rcar-dmac.
What _is_ the status of dmaengine? I thought it was the generic dma API the
kernel was moving towards? (The youtube videos suggested such...)
Rob
RE: [PATCH v4 1/2] pinctrl: Add RZ/A2 pin and gpio controller
Hi Geert, On Tuesday, November 13, 2018, Geert Uytterhoeven wrote: > > It makes the files show up under /sys look nice. > > > > For example, P5_6 is button SW4: > > > > $ echo 912 > /sys/class/gpio/export > > > > Then you end up with "/sys/class/gpio/P5_6/" > > > > $ echo in > /sys/class/gpio/P5_6/direction > > $ cat /sys/class/gpio/P5_6/direction > > $ cat /sys/class/gpio/P5_6/value > > (Ah, the legacy and deprecated sysfs GPIO interface, being replaced > by /dev/gpiochip[0-9]+ and https://github.com/brgl/libgpiod) > > Cool, I didn't know that. > But you still need to know which number to write to the export file > in the first place? True, meaning the table does not help you as much as you want. Jacopo also mentioned the new libgpiod. So, I think I might just drop this table in the next revision. What I really want to do is just say "make P5_6 an input" and not have to convert to a global ID number. But, I'm not sure how libgpiod is going to know what "P5_6" is. > > > Some people prefer "reverse Xmas tree ordering" i.e. sorted by > decreasing > > > declaration length. > > > > https://lwn.net/Articles/758552/ > > > > "only a few maintainers insist on that, while most really do not care or > > think that it's actively silly." > > > > So are you one of those maintainers? :) > > Sorry, got baptised by Laurent... (insert picture of Laurent handing out Kool-Aid here) Chris
[PATCH] arm64: dts: renesas: r8a77990: ebisu: Add and enable PCIe device node
From: Takeshi Kihara
This patch adds PCI express channel 0 device node to the R8A77990 SoC
and enables PCIEC0 PCI express controller on the Ebisu board.
Signed-off-by: Takeshi Kihara
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
To: devicet...@vger.kernel.org
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 8 +
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 34 +++
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 447e9831104a..2ef9067616ee 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -444,6 +444,14 @@
status = "okay";
};
+_bus_clk {
+ clock-frequency = <1>;
+};
+
+ {
+ status = "okay";
+};
+
{
avb_pins: avb {
mux {
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index a2524fc138a2..46868dacbeef 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -85,6 +85,13 @@
clock-frequency = <0>;
};
+ /* External PCIe clock - can be overridden by the board */
+ pcie_bus_clk: pcie_bus {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
pmu_a53 {
compatible = "arm,cortex-a53-pmu";
interrupts-extended = < GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
@@ -1610,6 +1617,33 @@
};
};
+ pciec0: pcie@fe00 {
+ compatible = "renesas,pcie-r8a77990",
+"renesas,pcie-rcar-gen3";
+ reg = <0 0xfe00 0 0x8>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ ranges = <0x0100 0 0x 0 0xfe10 0
0x0010
+ 0x0200 0 0xfe20 0 0xfe20 0
0x0020
+ 0x0200 0 0x3000 0 0x3000 0
0x0800
+ 0x4200 0 0x3800 0 0x3800 0
0x0800>;
+ /* Map all possible DDR as inbound ranges */
+ dma-ranges = <0x4200 0 0x4000 0 0x4000 0
0x4000>;
+ interrupts = ,
+ ,
+ ;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 GIC_SPI 116
IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < CPG_MOD 319>, <_bus_clk>;
+ clock-names = "pcie", "pcie_bus";
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 319>;
+ status = "disabled";
+ };
+
prr: chipid@fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
--
2.18.0
Re: [PATCH v4 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO
Hi Chris,
thanks for the patch
Just two minor things, so please add my
Reviewed-by: Jacopo Mondi
On Wed, Nov 07, 2018 at 01:27:33PM -0500, Chris Brandt wrote:
> Add device tree binding documentation and header file for Renesas R7S9210
> (RZ/A2) SoCs.
>
> Signed-off-by: Chris Brandt
> Reviewed-by: Rob Herring
> ---
> v3:
> - Added Reviewed-by
> v2:
> * Moved gpio-controller to required
> * Wrote a better description of what the sub-nodes are for
> * Added pinmux property description
> * Changed macro RZA2_PIN_ID to RZA2_PIN
> ---
> .../bindings/pinctrl/renesas,rza2-pinctrl.txt | 88
> ++
> include/dt-bindings/pinctrl/r7s9210-pinctrl.h | 47
> 2 files changed, 135 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> create mode 100644 include/dt-bindings/pinctrl/r7s9210-pinctrl.h
>
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> new file mode 100644
> index ..622d37a7225b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> @@ -0,0 +1,88 @@
> +Renesas RZ/A2 combined Pin and GPIO controller
> +
> +The Renesas SoCs of the RZ/A2 series feature a combined Pin and GPIO
> controller.
> +Pin multiplexing and GPIO configuration is performed on a per-pin basis.
> +Each port features up to 8 pins, each of them configurable for GPIO
> +function (port mode) or in alternate function mode.
> +Up to 8 different alternate function modes exist for each single pin.
> +
> +Pin controller node
> +---
> +
> +Required properties:
> + - compatible: should be:
s/should/shall ?
> +- "renesas,r7s9210-pinctrl": for RZ/A2M
> + - reg
> +Address base and length of the memory area where the pin controller
> +hardware is mapped to.
> + - gpio-controller
> +This pin controller also controls pins as GPIO
> + - #gpio-cells
> +Must be 2
> + - gpio-ranges
> +Expresses the total number GPIO ports/pins in this SoC
> +
> +
Two empty lines.
Thanks
j
> +Example: Pin controller node for RZ/A2M SoC (r7s9210)
> +
> + pinctrl: pin-controller@fcffe000 {
> + compatible = "renesas,r7s9210-pinctrl";
> + reg = <0xfcffe000 0x9D1>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = < 0 0 176>;
> + };
> +
> +Sub-nodes
> +-
> +
> +The child nodes of the pin controller designate pins to be used for
> +specific peripheral functions or as GPIO.
> +
> +- Pin multiplexing sub-nodes:
> + A pin multiplexing sub-node describes how to configure a set of
> + (or a single) pin in some desired alternate function mode.
> + The values for the pinmux properties are a combination of port name, pin
> + number and the desired function index. Use the RZA2_PINMUX macro located
> + in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily define these.
> + For assigning GPIO pins, use the macro RZA2_PIN_ID also in
> r7s9210-pinctrl.h
> + to express the desired port pin.
> +
> + Required properties:
> +- pinmux:
> + integer array representing pin number and pin multiplexing
> configuration.
> + When a pin has to be configured in alternate function mode, use this
> + property to identify the pin by its global index, and provide its
> + alternate function configuration number along with it.
> + When multiple pins are required to be configured as part of the same
> + alternate function they shall be specified as members of the same
> + argument list of a single "pinmux" property.
> + Helper macros to ease assembling the pin index from its position
> + (port where it sits on and pin number) and alternate function
> identifier
> + are provided by the pin controller header file at:
> +
> + Integers values in "pinmux" argument list are assembled as:
> + ((PORT * 8 + PIN) | MUX_FUNC << 16)
> +
> + Example: Board specific pins configuration
> +
> + {
> + /* Serial Console */
> + scif4_pins: serial4 {
> + pinmux = , /* TxD4 */
> + ; /* RxD4 */
> + };
> + };
> +
> + Example: Assigning a GPIO:
> +
> + leds {
> + status = "okay";
> + compatible = "gpio-leds";
> +
> + led0 {
> + /* P6_0 */
> + gpios = < RZA2_PIN(P6, 0) GPIO_ACTIVE_HIGH>;
> + };
> + };
> diff --git a/include/dt-bindings/pinctrl/r7s9210-pinctrl.h
> b/include/dt-bindings/pinctrl/r7s9210-pinctrl.h
> new file mode 100644
> index ..1e2671b61c0a
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/r7s9210-pinctrl.h
> @@ -0,0 +1,47 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Defines macros and constants for Renesas
Re: [PATCH v4 1/2] pinctrl: Add RZ/A2 pin and gpio controller
Hi Chris,
On Tue, Nov 13, 2018 at 7:43 PM Chris Brandt wrote:
> On Monday, November 12, 2018, Geert Uytterhoeven wrote:
> > > +static const char * const rza2_gpio_names[] = {
> > > + "P0_0", "P0_1", "P0_2", "P0_3", "P0_4", "P0_5", "P0_6", "P0_7",
> > > + "P1_0", "P1_1", "P1_2", "P1_3", "P1_4", "P1_5", "P1_6", "P1_7",
> > > + "P2_0", "P2_1", "P2_2", "P2_3", "P2_4", "P2_5", "P2_6", "P2_7",
> > > + "P3_0", "P3_1", "P3_2", "P3_3", "P3_4", "P3_5", "P3_6", "P3_7",
> > > + "P4_0", "P4_1", "P4_2", "P4_3", "P4_4", "P4_5", "P4_6", "P4_7",
> > > + "P5_0", "P5_1", "P5_2", "P5_3", "P5_4", "P5_5", "P5_6", "P5_7",
> > > + "P6_0", "P6_1", "P6_2", "P6_3", "P6_4", "P6_5", "P6_6", "P6_7",
> > > + "P7_0", "P7_1", "P7_2", "P7_3", "P7_4", "P7_5", "P7_6", "P7_7",
> > > + "P8_0", "P8_1", "P8_2", "P8_3", "P8_4", "P8_5", "P8_6", "P8_7",
> > > + "P9_0", "P9_1", "P9_2", "P9_3", "P9_4", "P9_5", "P9_6", "P9_7",
> > > + "PA_0", "PA_1", "PA_2", "PA_3", "PA_4", "PA_5", "PA_6", "PA_7",
> > > + "PB_0", "PB_1", "PB_2", "PB_3", "PB_4", "PB_5", "PB_6", "PB_7",
> > > + "PC_0", "PC_1", "PC_2", "PC_3", "PC_4", "PC_5", "PC_6", "PC_7",
> > > + "PD_0", "PD_1", "PD_2", "PD_3", "PD_4", "PD_5", "PD_6", "PD_7",
> > > + "PE_0", "PE_1", "PE_2", "PE_3", "PE_4", "PE_5", "PE_6", "PE_7",
> > > + "PF_0", "PF_1", "PF_2", "PF_3", "P0_4", "PF_5", "PF_6", "PF_7",
> > > + "PG_0", "PG_1", "PG_2", "P0_3", "PG_4", "PG_5", "PG_6", "PG_7",
> > > + "PH_0", "PH_1", "PH_2", "PH_3", "PH_4", "PH_5", "PH_6", "PH_7",
> > > + /* port I does not exist */
> >
> > Hence shouldn't you have 8 NULL entries here?
>
> But there is no such port named "I". And even in the dt-bindings and other
> documentation, the global pin ID is based off and a world where "I" is not
> in the alphabet. So if I put 8 NULLs here, wouldn't that screw up all the
> indexing??
I'd swear there's an "I" in port_names[], but upon checking again, it must
have been my eyes that mislead me. Sorry for that.
Hence please forget my comment above.
> > > +static struct gpio_chip chip = {
> > > + .names = rza2_gpio_names,
> >
> > BTW, is their much value in filling gpio_chip.names[]?
> > I had never seen that before.
>
> It makes the files show up under /sys look nice.
>
> For example, P5_6 is button SW4:
>
> $ echo 912 > /sys/class/gpio/export
>
> Then you end up with "/sys/class/gpio/P5_6/"
>
> $ echo in > /sys/class/gpio/P5_6/direction
> $ cat /sys/class/gpio/P5_6/direction
> $ cat /sys/class/gpio/P5_6/value
(Ah, the legacy and deprecated sysfs GPIO interface, being replaced
by /dev/gpiochip[0-9]+ and https://github.com/brgl/libgpiod)
Cool, I didn't know that.
But you still need to know which number to write to the export file
in the first place?
> > > + .get = rza2_chip_get,
> > > + .set = rza2_chip_set,
> >
> > You may want to implement .[gs]et_multiple(), too.
>
> OK, I will have a look.
You can add that later. It doesn't add functionality, but may improve
performance for bitbanging multiple pins.
> > > +{
> > > + struct rza2_pinctrl_priv *priv =
> > pinctrl_dev_get_drvdata(pctldev);
> > > + struct property *of_pins;
> > > + int i;
> > > + unsigned int *pins;
> > > + unsigned int *psel_val;
> > > + const char **pin_fn;
> > > + int ret, npins;
> > > + int gsel, fsel;
> >
> > Some people prefer "reverse Xmas tree ordering" i.e. sorted by decreasing
> > declaration length.
>
> https://lwn.net/Articles/758552/
>
> "only a few maintainers insist on that, while most really do not care or
> think that it's actively silly."
>
> So are you one of those maintainers? :)
Sorry, got baptised by Laurent...
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 v4 1/2] pinctrl: Add RZ/A2 pin and gpio controller
Hi Geert,
As always, thank you for your review!
On Monday, November 12, 2018, Geert Uytterhoeven wrote:
> > +config PINCTRL_RZA2
> > + bool "Renesas RZ/A2 gpio and pinctrl driver"
> > + depends on OF
> > + depends on ARCH_R7S9210 || COMPILE_TEST
> > + select GPIOLIB
> > + select GENERIC_PINCTRL_GROUPS
> > + select GENERIC_PINMUX_FUNCTIONS
> > + select GENERIC_PINCONF
>
> Given the PFS_ISEL bit, I think you can select GPIOLIB_IRQCHIP, and
> implement interrupt support on GPIOs.
> Of course that can be added later...
Yes, I was thinking that too.
I have had user ask about that before, so maybe that will be a 2019
task.
> > + help
> > + This selects pinctrl driver for Renesas RZ/A2 platforms.
>
> GPIO and pinctrl?
True.
> > +enum pfc_pin_port_name {PORT0, PORT1, PORT2, PORT3, PORT4, PORT5, PORT6,
> PORT7,
> > + PORT8, PORT9, PORTA, PORTB, PORTC, PORTD, PORTE,
> PORTF,
> > + PORTG, PORTH, PORTJ, PORTK, PORTL, PORTM,
> RZA2_NPORTS};
>
> The only reason for this enum is to fix the value of RZA2_NPORTS, right?
At the moment, yes.
Originally I thought I would need these. But in the end, I did not.
So I can just define RZA2_NPORTS for now. Maybe for future SoCs,
That value will change depending on the SoC.
> The above two sets of macros split information in two locations, and
> partially
> duplicates it. I think it becomes easier to read if you combine them, and
> factor
> out the addition of the base address. E.g.
>
> #define RZA2_PDR(port)(0x + (port) * 2) /* Port
> Direction, 16-bit */
>
> Then you can write:
>
> reg16 = readw(pfc_base + RZA2_PDR(port));
> mask16 = RZA2_PDR_MASK << (pin * 2);
> reg16 &= ~mask16;
> writew(reg16, pfc_base + RZA2_PDR(port));
>
> > +static void rza2_set_pin_function(void __iomem *pfc_base, u8 port, u8
> pin,
OK. I'm all for 'easier to read'!
> > + mask16 = 0x03 << (pin * 2);
>
> mask16 = RZA2_PDR_MASK << (pin * 2);
OK.
> > + /* PFS Register Write Protect : OFF */
> > + writeb(0x00, RZA2_PWPR(pfc_base)); /* B0WI=0, PFSWE=0 */
> > + writeb(0x40, RZA2_PWPR(pfc_base)); /* B0WI=0, PFSWE=1 */
>
> #define PWPR_B0WIBIT(7)/* Bit Write Disable */
> #define PWPR_PFSWE BIT(6)/* PFS Register Write Enable */
OK.
> > + /* Set Pin function (interrupt disabled, ISEL=0) */
> > + writeb(func, RZA2_PFS(pfc_base, port, pin));
>
> #define PFS_ISELBIT(6)/* Interrupt Select */
OK.
> > +static int rza2_chip_get_direction(struct gpio_chip *chip, unsigned int
> offset)
> > +{
> > + struct rza2_pinctrl_priv *priv = gpiochip_get_data(chip);
> > + u8 port = offset / 8;
> > + u8 pin = offset % 8;
>
> GPIO offset numbers are identical to PIN numbers, right?
> So you can use RZA2_PIN_ID_TO_PORT(), RZA2_PIN_ID_TO_PIN()
> for consistency.
Good point!
> > +static int rza2_chip_direction_input(struct gpio_chip *chip,
> > +unsigned int offset)
> > +{
> > + struct rza2_pinctrl_priv *priv = gpiochip_get_data(chip);
> > + u8 port = offset / 8;
> > + u8 pin = offset % 8;
> > +
> > + rza2_pin_to_gpio(priv->base, port, pin, GPIOF_DIR_IN);
>
> Perhaps pass offset to rza2_pin_to_gpio() directly?
OK. I can do that. Saves a couple of lines ;)
> > +static int rza2_chip_get(struct gpio_chip *chip, unsigned int offset)
> > +{
> > + struct rza2_pinctrl_priv *priv = gpiochip_get_data(chip);
> > + u8 port = offset / 8;
> > + u8 pin = offset % 8;
> > +
> > + return (readb(RZA2_PIDR(priv->base, port)) >> pin) & 1;
>
> Might be easier to read if you maintain symmetry with below:
>
> return !!(readb(RZA2_PIDR(priv->base, port) & BIT(pin));
Cool.
> > + if (value)
> > + new_value |= (1 << pin);
>
> new_value |= BIT(pin);
>
> > + else
> > + new_value &= ~(1 << pin);
>
> new_value &= ~BIT(pin);
I wondered about using BIT more often in the code.
Thanks.
> > +static const char * const rza2_gpio_names[] = {
> > + "P0_0", "P0_1", "P0_2", "P0_3", "P0_4", "P0_5", "P0_6", "P0_7",
> > + "P1_0", "P1_1", "P1_2", "P1_3", "P1_4", "P1_5", "P1_6", "P1_7",
> > + "P2_0", "P2_1", "P2_2", "P2_3", "P2_4", "P2_5", "P2_6", "P2_7",
> > + "P3_0", "P3_1", "P3_2", "P3_3", "P3_4", "P3_5", "P3_6", "P3_7",
> > + "P4_0", "P4_1", "P4_2", "P4_3", "P4_4", "P4_5", "P4_6", "P4_7",
> > + "P5_0", "P5_1", "P5_2", "P5_3", "P5_4", "P5_5", "P5_6", "P5_7",
> > + "P6_0", "P6_1", "P6_2", "P6_3", "P6_4", "P6_5", "P6_6", "P6_7",
> > + "P7_0", "P7_1", "P7_2", "P7_3", "P7_4", "P7_5", "P7_6", "P7_7",
> > + "P8_0", "P8_1", "P8_2", "P8_3", "P8_4", "P8_5", "P8_6", "P8_7",
> > + "P9_0", "P9_1", "P9_2", "P9_3", "P9_4", "P9_5", "P9_6", "P9_7",
> > + "PA_0", "PA_1", "PA_2", "PA_3", "PA_4", "PA_5",
RE: [PATCH v4 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO
Hi Geert, On Tuesday, November 13, 2018 1, Geert Uytterhoeven wrote: > Perhaps adding a convenience definition > > #define JP PM > > may be a good idea? Or just a comment? > > #define PM 21/* JP */ Either one is OK I guess. I'll see which one makes more sense as I reworked the driver. > Anyway, we're getting closer to bikeshedding, :) Chris
Re: [PATCH v4 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO
Hi Chris,
On Tue, Nov 13, 2018 at 5:38 PM Chris Brandt wrote:
> On Monday, November 12, 2018 1, Geert Uytterhoeven wrote:
> > > +Required properties:
> > > + - compatible: should be:
> > > +- "renesas,r7s9210-pinctrl": for RZ/A2M
> >
> > On RZ/A1, the datasheet called this "Ports", and the corresponding
> > compatible
> > value is "renesas,r7s72100-ports".
> > On RZ/A2, the datasheet calls this "GPIO", so perhaps "renesas,r7s9210-
> > gpio"?
> > Hmm, then you may want to call the single node gpio-controller instead of
> > pin-controller (and all references to it)? It's really both.
> >
> > On RZ/A1, it's different, as you have a single pin-controller node, with
> > GPIO
> > subnodes.
>
> So here's where we get into the interesting discussions.
>
> You're going off the title of the chapters in the hardware manual. But,
> I'm looking at what the IP is (and where it was uses in other SoCs).
>
> For RZ/A1, the pin controller/GPIO is a horrible piece of HW I've never
> seen before and hope to never see again.
>
> For RZ/A2, the controllers came from the RZ/T1. In that manual, the
> chapter was call "Multi-Function Pin Controller (MPC)" (Chapter 18). The
> GPIO was in Chapter 17 called "I/O Ports".
> Then for RZ/A2, they simply combined the two chapters into one since the
> hardware was also 'combined' and just picked a name "GPIO". (they
> basically copy/pasted the text from the two chapters)
>
> So, what's the rule of naming? Does it really have to match exactly what
> it says in the hardware manual?
> I'm assuming an RZ/A3 would use this same pin controller.
Thanks for the explanation!
I'm fine with "renesas,r7s9210-pinctrl".
> > > +Example: Pin controller node for RZ/A2M SoC (r7s9210)
> > > +
> > > + pinctrl: pin-controller@fcffe000 {
> > > + compatible = "renesas,r7s9210-pinctrl";
> > > + reg = <0xfcffe000 0x9D1>;
> >
> > 0x9d1
> >
> > BTW, that's a real odd number. What about rounding up to the hardware
> > granularity, i.e. 0x1000?
>
> I remember us getting into trouble once because numbers were rounded up
> or down and then conflicted with other nodes/register addresses. So, I
> was putting number exactly as they are. But if you want, I can round it
> up.
If you're worried for an overlap with another node in DT, keep on using
(lower case) 0x9d1.
The mapping will be rounded up to PAGE_SIZE anyway :-)
> > > + For assigning GPIO pins, use the macro RZA2_PIN_ID also in r7s9210-
> > pinctrl.h
> >
> > RZA2_PIN
>
> Good catch! Thank you.
Note that you still do have RZA2_PIN_ID_TO_PORT() and
RZA2_PIN_ID_TO_PIN() macros in the driver.
But RZA2_PIN_TO_PIN() sounds really lame...
> > > +/* Port names as labeled in the Hardware Manual */
> > > +#define P0 0
> > > +#define P1 1
> > > +#define P2 2
> > > +#define P3 3
> > > +#define P4 4
> > > +#define P5 5
> > > +#define P6 6
> > > +#define P7 7
> > > +#define P8 8
> > > +#define P9 9
> > > +#define PA 10
> > > +#define PB 11
> > > +#define PC 12
> >
> > This may conflict with MIPS again ;-)
>
> Damn MIPS!
>
>
> > Oh, you don't include the bindings header in the driver source file, and
> > doing
> > so would cause issues with (previous version of) the enum...
> >
> > Still, would it make sense to call these PORTx instead of Px?
> > The register descriptions use PORTx..
>
> I liked Px because it made my lines in the device tree shorter.
> But, I won't argue if you think it would be better to use PORTx (that's
> only 3 more characters).
Any preference from the DT people?
> > > +#define PM 21
> >
> > There's no PM in my datasheet. Should that be JP0?
> > Oh, the register descriptions do use PORTM.
>
> Like you mentioned, they made it confusing because instead of calling
> the on pin on Port M "PM0" they called it "JP0" for 'JTAG PORT'.
> From a hardware IP standpoint, it's a "Port M", so I wanted to call it
> that. I wanted to make it generic because if another SoC uses this same
> controller, it might have more ports, so port M will really be a port M.
OK.
Perhaps adding a convenience definition
#define JP PM
may be a good idea? Or just a comment?
#define PM 21/* JP */
Anyway, we're getting closer to bikeshedding, so with the real issues fixed:
Reviewed-by: Geert Uytterhoeven
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 v4 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO
Hi Geert,
On Monday, November 12, 2018 1, Geert Uytterhoeven wrote:
> > +Required properties:
> > + - compatible: should be:
> > +- "renesas,r7s9210-pinctrl": for RZ/A2M
>
> On RZ/A1, the datasheet called this "Ports", and the corresponding
> compatible
> value is "renesas,r7s72100-ports".
> On RZ/A2, the datasheet calls this "GPIO", so perhaps "renesas,r7s9210-
> gpio"?
> Hmm, then you may want to call the single node gpio-controller instead of
> pin-controller (and all references to it)? It's really both.
>
> On RZ/A1, it's different, as you have a single pin-controller node, with
> GPIO
> subnodes.
So here's where we get into the interesting discussions.
You're going off the title of the chapters in the hardware manual. But,
I'm looking at what the IP is (and where it was uses in other SoCs).
For RZ/A1, the pin controller/GPIO is a horrible piece of HW I've never
seen before and hope to never see again.
For RZ/A2, the controllers came from the RZ/T1. In that manual, the
chapter was call "Multi-Function Pin Controller (MPC)" (Chapter 18). The
GPIO was in Chapter 17 called "I/O Ports".
Then for RZ/A2, they simply combined the two chapters into one since the
hardware was also 'combined' and just picked a name "GPIO". (they
basically copy/pasted the text from the two chapters)
So, what's the rule of naming? Does it really have to match exactly what
it says in the hardware manual?
I'm assuming an RZ/A3 would use this same pin controller.
> > +Example: Pin controller node for RZ/A2M SoC (r7s9210)
> > +
> > + pinctrl: pin-controller@fcffe000 {
> > + compatible = "renesas,r7s9210-pinctrl";
> > + reg = <0xfcffe000 0x9D1>;
>
> 0x9d1
>
> BTW, that's a real odd number. What about rounding up to the hardware
> granularity, i.e. 0x1000?
I remember us getting into trouble once because numbers were rounded up
or down and then conflicted with other nodes/register addresses. So, I
was putting number exactly as they are. But if you want, I can round it
up.
> > + For assigning GPIO pins, use the macro RZA2_PIN_ID also in r7s9210-
> pinctrl.h
>
> RZA2_PIN
Good catch! Thank you.
> > + are provided by the pin controller header file at:
> > +
>
> include/dt-bindings/pinctrl/r7s9210-pinctrl.h (or
> )
Thanks.
> > +/* Port names as labeled in the Hardware Manual */
> > +#define P0 0
> > +#define P1 1
> > +#define P2 2
> > +#define P3 3
> > +#define P4 4
> > +#define P5 5
> > +#define P6 6
> > +#define P7 7
> > +#define P8 8
> > +#define P9 9
> > +#define PA 10
> > +#define PB 11
> > +#define PC 12
>
> This may conflict with MIPS again ;-)
Damn MIPS!
> Oh, you don't include the bindings header in the driver source file, and
> doing
> so would cause issues with (previous version of) the enum...
>
> Still, would it make sense to call these PORTx instead of Px?
> The register descriptions use PORTx..
I liked Px because it made my lines in the device tree shorter.
But, I won't argue if you think it would be better to use PORTx (that's
only 3 more characters).
> > +#define PM 21
>
> There's no PM in my datasheet. Should that be JP0?
> Oh, the register descriptions do use PORTM.
Like you mentioned, they made it confusing because instead of calling
the on pin on Port M "PM0" they called it "JP0" for 'JTAG PORT'.
From a hardware IP standpoint, it's a "Port M", so I wanted to call it
that. I wanted to make it generic because if another SoC uses this same
controller, it might have more ports, so port M will really be a port M.
> > + * Create the pin index from its bank and position numbers and store in
> > + * the upper 8 bits the alternate function identifier
>
> These are not really the upper 8 bits, unless your wordsize is 24-bit ;-)
>
> "upper 16 bits", like on RZ/A1?
Opps. You're correct. Thanks!
Chris
[PATCH] arm64: defconfig: Enable CONFIG_PHY_RCAR_GEN3_PCIE
Enable R-Car Gen3 PCIe PHY support, which is needed for PCIe to function on the Renesas Condor board. Signed-off-by: Geert Uytterhoeven --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 9d0b42d96f03156e..77f98a7e860b8850 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -657,6 +657,7 @@ CONFIG_PHY_HISI_INNO_USB2=y CONFIG_PHY_MVEBU_CP110_COMPHY=y CONFIG_PHY_QCOM_QMP=m CONFIG_PHY_QCOM_USB_HS=y +CONFIG_PHY_RCAR_GEN3_PCIE=y CONFIG_PHY_RCAR_GEN3_USB2=y CONFIG_PHY_RCAR_GEN3_USB3=m CONFIG_PHY_ROCKCHIP_EMMC=y -- 2.17.1
Re: [PATCH 00/03] Connect R-Car Gen3 Ethernet-AVB to IPMMU
Hi Simon,
On Tue, Nov 13, 2018 at 3:31 PM Simon Horman wrote:
> On Wed, Nov 07, 2018 at 12:21:16PM +0100, Simon Horman wrote:
> > On Mon, Oct 22, 2018 at 02:14:34AM +0900, Magnus Damm wrote:
> > > Connect R-Car Gen3 Ethernet-AVB to IPMMU
> > >
> > > [PATCH 01/03] arm64: dts: renesas: r8a77965: Connect R-Car M3-N AVB to
> > > IPMMU
> > > [PATCH 02/03] arm64: dts: renesas: r8a77980: Connect R-Car V3H AVB to
> > > IPMMU
> > > [PATCH 03/03] arm64: dts: renesas: r8a77990: Connect R-Car E3 AVB to IPMMU
> > >
> > > For each SoC describe Ethernet-AVB to IPMMU hardware connection in the
> > > Device Tree. This series affects R-Car M3-N, V3H and E3. Other members
> > > of the R-Car Gen3 family such as H3, M3-W, V3M and D3 already includes
> > > this information in their DT files.
> > >
> > > Signed-off-by: Magnus Damm
> >
> > Hi,
> >
> > I have already queued-up these patches but I noticed that
> > they do the same thing to different SoCs and recently the ARM-SoC
> > maintainers have asked us to consolidate such patches. With that in mind
> > I am considering squashing the three patches that comprise this series into
> > one. Are there any objections?
>
> I have now gone ahead and done so. The result is as follows:
>
> From: Magnus Damm
> Subject: [PATCH] ARM: dts: r8a7740, emev2, sh73a0: Include SoC name in DTSI
>
> Update the R-Mobile A1 (r8a7740), Emma Mobile EV2 (emev2) and
> SH-Mobile AG5 (sh72a0) DTSI to include product name.
>
> Signed-off-by: Magnus Damm
> [simon: squashed similar patches]
> Signed-off-by: Simon Horman
Wrong email thread?
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/2] arm64: dts: renesas: r8a774a1: Replace clock magic numbers
On Tue, Nov 13, 2018 at 09:53:55AM +0100, Geert Uytterhoeven wrote:
> On Wed, Nov 7, 2018 at 4:24 PM Fabrizio Castro
> wrote:
> > Now that include/dt-bindings/clock/r8a774a1-cpg-mssr.h is in Linus'
> > master branch we can replace clock related magic numbers with the
> > corresponding labels.
> >
> > Signed-off-by: Fabrizio Castro
>
> Reviewed-by: Geert Uytterhoeven
>
> > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
>
> > @@ -87,7 +87,7 @@
> > power-domains = < R8A774A1_PD_CA53_CPU0>;
> > next-level-cache = <_CA53>;
> > enable-method = "psci";
> > - clocks =< CPG_CORE 1>;
> > + clocks =< CPG_CORE R8A774A1_CLK_Z2>;
>
> There are a few pre-existing whitespace issues in the CPU nodes' clocks
> properties.
Thanks I have fixed that when applying this patch for v4.21.
The result is as follows:
From: Fabrizio Castro
Subject: [PATCH] arm64: dts: renesas: r8a774a1: Replace clock magic numbers
Now that include/dt-bindings/clock/r8a774a1-cpg-mssr.h is in Linus'
master branch we can replace clock related magic numbers with the
corresponding labels.
Signed-off-by: Fabrizio Castro
Reviewed-by: Geert Uytterhoeven
[simon: corrected whitespace]
Signed-off-by: Simon Horman
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 38 +++
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d549755a4025..20745a8528c5 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -7,7 +7,7 @@
#include
#include
-#include
+#include
#include
/ {
@@ -67,7 +67,7 @@
power-domains = < R8A774A1_PD_CA57_CPU0>;
next-level-cache = <_CA57>;
enable-method = "psci";
- clocks = < CPG_CORE 0>;
+ clocks = < CPG_CORE R8A774A1_CLK_Z>;
};
a57_1: cpu@1 {
@@ -77,7 +77,7 @@
power-domains = < R8A774A1_PD_CA57_CPU1>;
next-level-cache = <_CA57>;
enable-method = "psci";
- clocks = < CPG_CORE 0>;
+ clocks = < CPG_CORE R8A774A1_CLK_Z>;
};
a53_0: cpu@100 {
@@ -87,7 +87,7 @@
power-domains = < R8A774A1_PD_CA53_CPU0>;
next-level-cache = <_CA53>;
enable-method = "psci";
- clocks =< CPG_CORE 1>;
+ clocks = < CPG_CORE R8A774A1_CLK_Z2>;
};
a53_1: cpu@101 {
@@ -97,7 +97,7 @@
power-domains = < R8A774A1_PD_CA53_CPU1>;
next-level-cache = <_CA53>;
enable-method = "psci";
- clocks =< CPG_CORE 1>;
+ clocks = < CPG_CORE R8A774A1_CLK_Z2>;
};
a53_2: cpu@102 {
@@ -107,7 +107,7 @@
power-domains = < R8A774A1_PD_CA53_CPU2>;
next-level-cache = <_CA53>;
enable-method = "psci";
- clocks =< CPG_CORE 1>;
+ clocks = < CPG_CORE R8A774A1_CLK_Z2>;
};
a53_3: cpu@103 {
@@ -117,7 +117,7 @@
power-domains = < R8A774A1_PD_CA53_CPU3>;
next-level-cache = <_CA53>;
enable-method = "psci";
- clocks =< CPG_CORE 1>;
+ clocks = < CPG_CORE R8A774A1_CLK_Z2>;
};
L2_CA57: cache-controller-0 {
@@ -515,7 +515,7 @@
reg = <0 0xe654 0 0x60>;
interrupts = ;
clocks = < CPG_MOD 520>,
-< CPG_CORE 19>,
+< CPG_CORE R8A774A1_CLK_S3D1>,
<_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x31>, < 0x30>,
@@ -533,7 +533,7 @@
reg = <0 0xe655 0 0x60>;
interrupts = ;
clocks = < CPG_MOD 519>,
-< CPG_CORE 19>,
+< CPG_CORE R8A774A1_CLK_S3D1>,
<_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x33>, < 0x32>,
@@ -551,7 +551,7 @@
reg = <0 0xe656 0 0x60>;
interrupts = ;
clocks = < CPG_MOD 518>,
-< CPG_CORE 19>,
+
Re: [PATCH 1/2] arm64: dts: renesas: r8a774a1: Replace power magic numbers
On Tue, Nov 13, 2018 at 09:52:19AM +0100, Geert Uytterhoeven wrote: > On Wed, Nov 7, 2018 at 4:24 PM Fabrizio Castro > wrote: > > Now that include/dt-bindings/power/r8a774a1-sysc.h is in Linus' > > master branch we can replace power related magic numbers with > > the corresponding labels. > > > > Signed-off-by: Fabrizio Castro > > Reviewed-by: Geert Uytterhoeven Thanks, applied for v4.21.
Re: [PATCH/RFC] dmaengine: sh: Remove R-Mobile APE6 support
On Mon, Nov 12, 2018 at 04:30:29PM +0100, Geert Uytterhoeven wrote:
> CC SuperH
>
> On Mon, Nov 12, 2018 at 4:22 PM Geert Uytterhoeven
> wrote:
> > Renesas R-Mobile APE6 support is currently unused:
> > - DMA slaves were never enabled in r8a73a4.dtsi,
> > - The driver relies on legacy filter matching and describing all
> > slaves and MID/RIDs in a table, unlike modern DMA engine drivers for
> > similar hardware like rcar-dmac,
> > - The driver doesn't seem to work well.
> >
> > Remove the driver, it can be resurrected from git history when needed.
> >
> > As this was the last user of SH_DMAE_BASE on Renesas ARM SoCs, the
> > sh-dma-engine driver core is now used on SuperH only.
> >
> > Note that the DT bindings are still present, as r8a73a4.dtsi uses them.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > Notes:
> > 1. As Renesas ARM SoCs no longer use drivers/dma/sh/shdma-base.c, the
> > task to remove use of the deprecated dma_slave_config.direction
> > field gets thrown into the SuperH maintainers' basket ;-)
> > 2. This affects shmobile_defconfig and renesas_defconfig
> > (CONFIG_SH_DMAE_BASE and CONFIG_SH_DMAE are no longer enabled by
> > default).
> > 3. I tried to get SCIFA DMA to work by:
> >- Applying the DT and driver patches below,
> >- Reverting 219fb0c1436e4893 ("serial: sh-sci: Remove the
> > platform data dma slave rx/tx channel IDs").
> > After that, serial console output using DMA seems to work, but the
> > system locks up when receiving any serial console input.
> > Probably it is easier to add r8a73a4 support to rcar-dmac.
Reviewed-by: Simon Horman
Re: [PATCH v2 3/3] ARM: dts: iwg23s-sbc: Add QSPI flash support
On Fri, Nov 09, 2018 at 11:06:07AM +0100, Simon Horman wrote: > On Thu, Nov 08, 2018 at 05:04:43PM +, Fabrizio Castro wrote: > > This commit adds QSPI flash support to the iwg23s board specific > > device tree. > > > > Signed-off-by: Fabrizio Castro > > Thanks, > > This looks fine to me but I will wait to see if there are other reviews > before applying. Thanks again, applied for v4.21.
Re: [PATCH v2 2/3] ARM: dts: r8a77470: Add QSPI support
On Fri, Nov 09, 2018 at 11:05:56AM +0100, Simon Horman wrote: > On Thu, Nov 08, 2018 at 05:04:42PM +, Fabrizio Castro wrote: > > Add QSPI[01] support to the RZ/G1C SoC specific device tree. > > > > Signed-off-by: Fabrizio Castro > > Thanks, > > This looks fine to me but I will wait to see if there are other reviews > before applying. Thanks again, applied for v4.21.
Re: [PATCH LOCAL 2/2] arm64: renesas_defconfig: Enable CONFIG_PHY_RCAR_GEN3_PCIE
On Thu, Nov 08, 2018 at 11:44:24AM +0100, Simon Horman wrote: > On Wed, Nov 07, 2018 at 11:17:18AM +0100, Geert Uytterhoeven wrote: > > Enable R-Car Gen3 PCIe PHY support, which is needed for PCIe to function > > on the Renesas Condor board. > > > > Signed-off-by: Geert Uytterhoeven > > --- > > Not intended for upstream merge. > > Thanks, > > This looks fine to me but I will wait to see if there are other reviews > before applying. Thanks again. I have applied this to topic/renesas-defconfig which it targeted at the devel branch of the renesas tree but not upstream.
Re: [PATCH LOCAL 1/2] arm64: renesas_defconfig: Drop CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
On Thu, Nov 08, 2018 at 11:44:12AM +0100, Simon Horman wrote:
> On Wed, Nov 07, 2018 at 11:17:17AM +0100, Geert Uytterhoeven wrote:
> > CONFIG_ARM_BIG_LITTLE_CPUFREQ was removed on arm64 in commit
> > a7314405d83c8f95 ("cpufreq: drop ARM_BIG_LITTLE_CPUFREQ support for
> > ARM64").
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > Not intended for upstream merge.
>
> Thanks,
>
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
Thanks again. I have applied this to topic/renesas-defconfig which
it targeted at the devel branch of the renesas tree but not upstream.
Re: [PATCH 00/03] Connect R-Car Gen3 Ethernet-AVB to IPMMU
On Wed, Nov 07, 2018 at 12:21:16PM +0100, Simon Horman wrote: > On Mon, Oct 22, 2018 at 02:14:34AM +0900, Magnus Damm wrote: > > Connect R-Car Gen3 Ethernet-AVB to IPMMU > > > > [PATCH 01/03] arm64: dts: renesas: r8a77965: Connect R-Car M3-N AVB to IPMMU > > [PATCH 02/03] arm64: dts: renesas: r8a77980: Connect R-Car V3H AVB to IPMMU > > [PATCH 03/03] arm64: dts: renesas: r8a77990: Connect R-Car E3 AVB to IPMMU > > > > For each SoC describe Ethernet-AVB to IPMMU hardware connection in the > > Device Tree. This series affects R-Car M3-N, V3H and E3. Other members > > of the R-Car Gen3 family such as H3, M3-W, V3M and D3 already includes > > this information in their DT files. > > > > Signed-off-by: Magnus Damm > > Hi, > > I have already queued-up these patches but I noticed that > they do the same thing to different SoCs and recently the ARM-SoC > maintainers have asked us to consolidate such patches. With that in mind > I am considering squashing the three patches that comprise this series into > one. Are there any objections? I have now gone ahead and done so. The result is as follows: From: Magnus Damm Subject: [PATCH] ARM: dts: r8a7740, emev2, sh73a0: Include SoC name in DTSI Update the R-Mobile A1 (r8a7740), Emma Mobile EV2 (emev2) and SH-Mobile AG5 (sh72a0) DTSI to include product name. Signed-off-by: Magnus Damm [simon: squashed similar patches] Signed-off-by: Simon Horman --- arch/arm/boot/dts/emev2.dtsi | 2 +- arch/arm/boot/dts/r8a7740.dtsi | 2 +- arch/arm/boot/dts/sh73a0.dtsi | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/emev2.dtsi b/arch/arm/boot/dts/emev2.dtsi index 373ea8720769..67d86012a85c 100644 --- a/arch/arm/boot/dts/emev2.dtsi +++ b/arch/arm/boot/dts/emev2.dtsi @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the EMEV2 SoC + * Device Tree Source for the Emma Mobile EV2 SoC * * Copyright (C) 2012 Renesas Solutions Corp. */ diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi index 383cba68dbba..12ffe73bf2bc 100644 --- a/arch/arm/boot/dts/r8a7740.dtsi +++ b/arch/arm/boot/dts/r8a7740.dtsi @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the r8a7740 SoC + * Device Tree Source for the R-Mobile A1 (R8A77400) SoC * * Copyright (C) 2012 Renesas Solutions Corp. */ diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi index e8f0a07c4564..33836990b102 100644 --- a/arch/arm/boot/dts/sh73a0.dtsi +++ b/arch/arm/boot/dts/sh73a0.dtsi @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Device Tree Source for the SH73A0 SoC + * Device Tree Source for the SH-Mobile AG5 (R8A73A00/SH73A0) SoC * * Copyright (C) 2012 Renesas Solutions Corp. */ -- 2.11.0
Re: [PATCH/RFT 2/2] thermal: rcar_thermal: add R8A77990 support
Reviewed-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH/RFT 1/2] dt-bindings: thermal: rcar-thermal: add R8A77990 support
Reviewed-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH] thermal: rcar_gen3_thermal: Add supports the hwmon thermal sysfs
> Please run scripts/get_maintainer.pl on your patches, to get the list of
> maintainers.
>
> CC thermal
Thanks, Geert!
Hi Hoan,
> + /* Enable hwmon thermal sysfs */
> + tsc->zone->tzp->no_hwmon = false;
A driver diving so deep into core structures always looks suspicious.
Questions I have:
1)
We have that code also in rcar_thermal.c, but the commit introducing
it[1] has a reason which does not apply for this driver, or?
2)
of_parse_thermal_zones() intentionally sets this flag with this
comment:
/* No hwmon because there might be hwmon drivers registering */
Why does it not apply for us?
3)
If it turns out, we really need it, there should be some thermal core
helper or flag for it, I'd think...
Regards,
Wolfram
[1] 64a411e8042e ("thermal: rcar-thermal: enable hwmon when
thermal_zone_of_sensor_register is used")
signature.asc
Description: PGP signature
Re: [v2 PATCH] thermal: rcar_gen3_thermal: Fix init value of IRQCTL register
> > > Fix setting value for IRQCTL register. We are setting the last 6 bits > > > of (IRQCTL) to be 1 (0x3f), this is only suitable for H3ES1.*, according > > > to new Hardware manual values 1 are "setting prohibited" for Gen3! > > Hum, as you point out this change is not suitable for H3 ES1.x so this > > would introduce a regression, which is not good. I will leave the final > > word to Wolfram but in my view you need to introduce quirk handling to > > keep support for H3 ES1.x or blacklist that SoC in the driver. > > With this patch and current state of the Gen3 thermal driver, H3ES1.* is > still correctly supported. > > priv->thermal_init = rcar_gen3_thermal_init; > if (soc_device_match(r8a7795es1)) > priv->thermal_init = rcar_gen3_thermal_init_r8a7795es1; Makes sense to me. Niklas? signature.asc Description: PGP signature
Re: [PATCH v5 5/6] pinctrl: sh-pfc: r8a7795: Fix VIN versioned groups
Hi Jacopo,
On Thu, Nov 8, 2018 at 5:07 PM Jacopo Mondi wrote:
> Versioned VIN groups can appear on different sets of pins. Use of the
> VIN_DATA_PIN_GROUP macro fix naming of said groups through an optional
> 'version' argument.
I more liked the description from the previous version, which you retained
for PATCH 6/6, so I used that ;-)
> Use the 'version' argument for said macro to fix naming of versioned
> groups for R-Car H3 R8A7795 SoC.
>
> Fixes: 9942a5b52990 ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
> definitions")
> Reviewed-by: Simon Horman
> Reviewed-by: Geert Uytterhoeven
> Signed-off-by: Jacopo Mondi
Queueing in sh-pfc-for-v4.21.
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 v5 6/6] pinctrl: sh-pfc: r8a7796: Fix VIN versioned groups
Hi Jacopo,
On Thu, Nov 8, 2018 at 5:08 PM Jacopo Mondi wrote:
> Versioned VIN groups can appear on different sets of pins. Using the
> VIN_DATA_PIN_GROUP macro now supports proper naming of said groups through
> an optional 'version' argument.
>
> Use the 'version' argument for said macro to fix naming of versioned
> groups for R-Car M3-W R8A7796 SoC.
>
> Fixes: a5c2949ff7bd ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
> definitions")
r8a7796
> Reviewed-by: Simon Horman
> Reviewed-by: Geert Uytterhoeven
> Signed-off-by: Jacopo Mondi
Queuing in sh-pfc-for-v4.21.
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 v5 4/6] pinctrl: sh-pfc: r8a7792: Fix VIN versioned groups
Hi Jacopo,
On Thu, Nov 8, 2018 at 5:07 PM Jacopo Mondi wrote:
> Versioned VIN groups can appear on different sets of pins. Use of the
> VIN_DATA_PIN_GROUP macro fix naming of said groups through an optional
> 'version' argument.
I more liked the description from the previous version, which you retained
in PATCH 6/6, so I used that ;-)
> Use the 'version' argument for said macro to fix naming of versioned
> groups for R-Car V2H R8A7792 SoC.
>
> Fixes: 7dd74bb1f058 ("pinctrl: sh-pfc: r8a7792: Add VIN pin groups")
> Reviewed-by: Simon Horman
> Reviewed-by: Geert Uytterhoeven
> Signed-off-by: Jacopo Mondi
Queuing in sh-pfc-for-v4.21.
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 v5 3/6] pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions
On Thu, Nov 8, 2018 at 5:07 PM Jacopo Mondi wrote:
> Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car E3.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
I.e. queuing in sh-pfc-for-v4.21.
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 v5 2/6] pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions
On Thu, Nov 8, 2018 at 5:07 PM Jacopo Mondi wrote:
> The VIN4 and VIN5 interfaces supports parallel video input.
> Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car M3-N.
>
> Reviewed-by: Ulrich Hecht
> Signed-off-by: Jacopo Mondi
>
> ---
> v4 -> v5:
> - Add definitions for 10, 12 and 20 pin groups for VIN4 as suggested by Geert
> - Add definitions for 10 and 12 pin groups for VIN5 as suggested by Geert
> - s/union vin_data/union vin_data16/ for VIN5 pins and mux as suggested by
> Geert
Reviewed-by: Geert Uytterhoeven
I.e. queuing in sh-pfc-for-v4.21.
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 v5 1/6] pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP
On Thu, Nov 8, 2018 at 5:07 PM Jacopo Mondi wrote:
> VIN data groups may appear on different sets of pins, usually named
> "vinX_data_[a|b]". The existing VIN_DATA_PIN_GROUP() does not support
> appending the '_a' or '_b' suffix, leading to the definition of group
> names not consistent with the ones defined using the SH_PFC_PIN_GROUP()
> macro.
>
> Fix this by making the VIN_DATA_PIN_GROUP macro a variadic one,
> which accepts an optional 'version' argument.
>
> Fixes: 423caa52534f ("pinctrl: sh-pfc: r8a779[01]: Move 'union vin_data' to
> shared header file")
> Reviewed-by: Geert Uytterhoeven
> Signed-off-by: Jacopo Mondi
Queuing in sh-pfc-for-v4.21.
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/2] arm64: dts: renesas: r8a774a1: Replace clock magic numbers
On Wed, Nov 7, 2018 at 4:24 PM Fabrizio Castro
wrote:
> Now that include/dt-bindings/clock/r8a774a1-cpg-mssr.h is in Linus'
> master branch we can replace clock related magic numbers with the
> corresponding labels.
>
> Signed-off-by: Fabrizio Castro
Reviewed-by: Geert Uytterhoeven
> --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> @@ -87,7 +87,7 @@
> power-domains = < R8A774A1_PD_CA53_CPU0>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> - clocks =< CPG_CORE 1>;
> + clocks =< CPG_CORE R8A774A1_CLK_Z2>;
There are a few pre-existing whitespace issues in the CPU nodes' clocks
properties.
> };
>
> a53_1: cpu@101 {
> @@ -97,7 +97,7 @@
> power-domains = < R8A774A1_PD_CA53_CPU1>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> - clocks =< CPG_CORE 1>;
> + clocks =< CPG_CORE R8A774A1_CLK_Z2>;
> };
>
> a53_2: cpu@102 {
> @@ -107,7 +107,7 @@
> power-domains = < R8A774A1_PD_CA53_CPU2>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> - clocks =< CPG_CORE 1>;
> + clocks =< CPG_CORE R8A774A1_CLK_Z2>;
> };
>
> a53_3: cpu@103 {
> @@ -117,7 +117,7 @@
> power-domains = < R8A774A1_PD_CA53_CPU3>;
> next-level-cache = <_CA53>;
> enable-method = "psci";
> - clocks =< CPG_CORE 1>;
> + clocks =< CPG_CORE R8A774A1_CLK_Z2>;
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 1/2] arm64: dts: renesas: r8a774a1: Replace power magic numbers
On Wed, Nov 7, 2018 at 4:24 PM Fabrizio Castro
wrote:
> Now that include/dt-bindings/power/r8a774a1-sysc.h is in Linus'
> master branch we can replace power related magic numbers with
> the corresponding labels.
>
> Signed-off-by: Fabrizio Castro
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] thermal: rcar_gen3_thermal: Add supports the hwmon thermal sysfs
Hi Hoan,
Thanks for your patch!
Please run scripts/get_maintainer.pl on your patches, to get the list of
maintainers.
CC thermal
On Tue, Nov 13, 2018 at 7:46 AM Nguyen An Hoan wrote:
>
> From: Hoan Nguyen An
>
> Gen3 thermal registered by devm_thermal_zone_of_sensor_register()
> and this function does not enable hwmon sysfs extensions.
> This patch enables it to keep compatibility to common systems
>
> Signed-off-by: Hoan Nguyen An
> ---
> drivers/thermal/rcar_gen3_thermal.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/thermal/rcar_gen3_thermal.c
> b/drivers/thermal/rcar_gen3_thermal.c
> index 75786cc..ae172db 100644
> --- a/drivers/thermal/rcar_gen3_thermal.c
> +++ b/drivers/thermal/rcar_gen3_thermal.c
> @@ -19,6 +19,7 @@
> #include
>
> #include "thermal_core.h"
> +#include "thermal_hwmon.h"
>
> /* Register offsets */
> #define REG_GEN3_IRQSTR0x04
> @@ -429,6 +430,12 @@ static int rcar_gen3_thermal_probe(struct
> platform_device *pdev)
> if (ret < 0)
> goto error_unregister;
>
> + /* Enable hwmon thermal sysfs */
> + tsc->zone->tzp->no_hwmon = false;
> + ret = thermal_add_hwmon_sysfs(tsc->zone);
> + if (ret)
> + dev_err(dev, "Can't register hwmon sysfs\n");
> +
> dev_info(dev, "TSC%d: Loaded %d trip points\n", i, ret);
> }
>
You forgot to call thermal_remove_hwmon_sysfs() in the .remove()
callback?
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
