[v2 PATCH] thermal: rcar_gen3_thermal: Add Standby/Reset Mode support
From: Hoan Nguyen An
According to the hardware manual, Gen3 supports Standby/Reset mode.
Add this function, and we should use this function while suspend
to reduce the energy consumption.
Signed-off-by: Hoan Nguyen An
---
drivers/thermal/rcar_gen3_thermal.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/rcar_gen3_thermal.c
b/drivers/thermal/rcar_gen3_thermal.c
index 7aed533..e654519 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -447,11 +447,32 @@ static int rcar_gen3_thermal_probe(struct platform_device
*pdev)
return ret;
}
+static int rcar_gen3_thermal_reset(struct rcar_gen3_thermal_priv* priv)
+{
+ unsigned int i;
+ u32 reg_val;
+
+ for (i = 0; i < priv->num_tscs; i++) {
+ struct rcar_gen3_thermal_tsc *tsc = priv->tscs[i];
+
+ rcar_gen3_thermal_write(tsc, REG_GEN3_IRQEN, 0);
+ rcar_gen3_thermal_write(tsc, REG_GEN3_IRQMSK, 0);
+
+ reg_val = rcar_gen3_thermal_read(tsc, REG_GEN3_THCTR);
+ rcar_gen3_thermal_write(tsc, REG_GEN3_THCTR, reg_val &
~THCTR_THSST);
+ }
+
+ usleep_range(1000, 2000);
+
+ return 0;
+}
+
static int __maybe_unused rcar_gen3_thermal_suspend(struct device *dev)
{
struct rcar_gen3_thermal_priv *priv = dev_get_drvdata(dev);
- rcar_thermal_irq_set(priv, false);
+ /* Reset to enter standby mode */
+ rcar_gen3_thermal_reset(priv);
return 0;
}
--
2.7.4
RE: [PATCH 2/2] arm64: dts: r8a77990: ebisu: Enable SDHI interfaces
Hello Marek-san,
> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
>
> From: Takeshi Kihara
>
> This patch enables SD card slot connected to SDHI0, micro SD card slot
> connected to SDHI1 and eMMC connected to SDHI3 on the Ebisu board using
> the R8A77990 SoC.
>
> 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
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
I have a few nit comments below.
> .../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 136 ++
> 1 file changed, 136 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> index 611f0265fcc5..bda1765dcdbd 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> + sdhi3_pins: sd3 {
> + groups = "sdhi3_data8", "sdhi3_ctrl";
> + function = "sdhi3";
> + power-source = <1800>;
> + };
> +
> + sdhi3_pins_uhs: sd3_uhs {
> + groups = "sdhi3_data8", "sdhi3_ctrl";
> + function = "sdhi3";
> + power-source = <1800>;
> + };
I assumed that we will add "sdhi3_ds" into these groups when we add support for
HS400 mode.
Best regards,
Yoshihiro Shimoda
RE: [PATCH 1/2] arm64: dts: r8a77990: Add SDHI device nodes
Hello Marek-san,
> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:41 AM
>
> From: Takeshi Kihara
>
> This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC.
>
> 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
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
I guess this patch and the 2/2 patch for ebisu have to be merged into a patch
though.
Best regards,
Yoshihiro Shimoda
RE: [PATCH 2/2] pinctrl: sh-pfc: r8a77990: Add voltage switch operations for SDHI
Hello Marek-san,
> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:40 AM
>
> From: Takeshi Kihara
>
> This patch supports the {get,set}_io_voltage operations of SDHI.
>
> This operates the IOCTRL30 register on the R8A77990 SoC and makes
> 1.8V/3.3V signal voltage switch possible.
>
> 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
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH 1/2] pinctrl: sh-pfc: r8a77990: Add SDHI pins, groups and functions
Hello Marek-san,
> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:40 AM
>
> From: Takeshi Kihara
>
> This patch adds SDHI{0,1,3} pins, groups and functions to the R8A77990
> SoC.
>
> 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
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH] mmc: renesas_sdhi: Whitelist R8A77990 SDHI
Hello Marek-san, > From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:40 AM > > Whitelist R8A77990 E3 SoC in the SDHI driver. The SDHI core > present in the SoC is an 8tap variant of the Gen3 SDHI core. > > Signed-off-by: Marek Vasut > Cc: Geert Uytterhoeven > Cc: Simon Horman > Cc: Wolfram Sang > Cc: Yoshihiro Shimoda > Cc: Ulf Hansson > Cc: linux-renesas-soc@vger.kernel.org > --- Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
RE: [PATCH] arm64: dts: r8a77990: ebisu: Add serial console pins
Hello Marek-san,
> From: Marek Vasut, Sent: Tuesday, November 6, 2018 6:39 AM
>
> From: Takeshi Kihara
>
> This patch adds pin control for SCIF2 on R8A77990 E3 Ebisu.
>
> 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
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> index f342dd85b152..611f0265fcc5 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -321,6 +321,11 @@
> function = "pwm5";
> };
>
> + scif2_pins: scif2 {
> + groups = "scif2_data_a";
> + function = "scif2";
> + };
> +
> usb0_pins: usb {
> groups = "usb0_b";
> function = "usb0";
> @@ -352,6 +357,9 @@
> };
>
> {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> status = "okay";
> };
>
> --
> 2.18.0
Re: [v2 PATCH] thermal: rcar_gen3_thermal: Fix init value of IRQCTL register
Thank you for your review ! Hoan
Re: [v2 PATCH] thermal: rcar_gen3_thermal: Fix init value of IRQCTL register
Dear Niklas-san Thank you for your review! Niklas Söderlund wrote: > Hi Hoan-san, > > Thanks for your patch. > > On 2018-10-25 11:13:41 +0900, Nguyen An Hoan wrote: > > From: Hoan Nguyen An > > > > 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; General common Gen3(H3, M3) and H3ES1. * using two different thermal_init（） function. As the v1 of this patch "https://patchwork.kernel.org/patch/10654457/; I was to change the init_r8a7795es1() function, but then test again (I used the patch that improves interrupts for testing) and realized (The count of interrupts rising or falling temperature) Unstable with H3ES1.1! So I update v2 I also have re-read the Hardware Manual, with Rev0.5 is consistent with ES1 , but Since Rev0.8 or Rev1.0 HWM is not compatible with H3ES1. So that this update will be correct and consistent with rcar_gen3_thermal_init. H3ES1.1 is already supported correctly at rcar_gen3_thermal_init_r8a7795es1! I'm still thinking this change is correct! Thank you very much :) Hoan. > > > > Signed-off-by: Hoan Nguyen An > > --- > > drivers/thermal/rcar_gen3_thermal.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/thermal/rcar_gen3_thermal.c > > b/drivers/thermal/rcar_gen3_thermal.c > > index 7aed533..fde3fd8 100644 > > --- a/drivers/thermal/rcar_gen3_thermal.c > > +++ b/drivers/thermal/rcar_gen3_thermal.c > > @@ -306,7 +306,7 @@ static void rcar_gen3_thermal_init(struct > > rcar_gen3_thermal_tsc *tsc) > > > > usleep_range(1000, 2000); > > > > - rcar_gen3_thermal_write(tsc, REG_GEN3_IRQCTL, 0x3F); > > + rcar_gen3_thermal_write(tsc, REG_GEN3_IRQCTL, 0); > > rcar_gen3_thermal_write(tsc, REG_GEN3_IRQMSK, 0); > > rcar_gen3_thermal_write(tsc, REG_GEN3_IRQEN, IRQ_TEMPD1 | IRQ_TEMP2); > > > > -- > > 2.7.4 > > > > -- > Regards, > Niklas Söderlund
Re: [PATCH 1/2] dt-bindings: dmaengine: usb-dmac: Add binding for r8a77470
On Thu, 25 Oct 2018 15:53:37 +0100, Biju Das wrote: > This patch adds usb high-speed dmac binding for r8a77470 (RZ/G1C) SoC. > > Signed-off-by: Biju Das > --- > This patch tested against linux-next. > --- > Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring
Re: [PATCH 1/7] dt-bindings: phy: rcar-gen2: Add r8a77470 support
On Thu, Oct 25, 2018 at 02:56:53PM +0100, Biju Das wrote:
> Add USB PHY support for r8a77470 SoC. Renesas RZ/G1C (R8A77470)
> USB PHY is similar to the R-Car Gen2 family, but has the below
> features compared to other RZ/G1 and R-Car Gen2/3 SoCs
>
> It has a shared pll reset for usbphy0/usbphy1 and this register
> reside in usbphy0 block
>
> Each USB2.0 host needs to deassert the pll reset of usbphy0 block.
>
> Signed-off-by: Biju Das
> ---
> .../devicetree/bindings/phy/rcar-gen2-phy.txt | 64
> +++---
> 1 file changed, 55 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> index eeb9e18..0a59971 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> @@ -6,6 +6,7 @@ This file provides information on what the device node for
> the R-Car generation
> Required properties:
> - compatible: "renesas,usb-phy-r8a7743" if the device is a part of R8A7743
> SoC.
> "renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC.
> + "renesas,usb-phy-r8a77470" if the device is a part of R8A77470
> SoC.
> "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC.
> "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC.
> "renesas,usb-phy-r8a7794" if the device is a part of R8A7794 SoC.
> @@ -23,13 +24,23 @@ Required properties:
> - clocks: clock phandle and specifier pair.
> - clock-names: string, clock input name, must be "usbhs".
>
> +Optional properties (r8a77470 SoC Only):
> +To use a USB channel as USB 2.0 Host, the device tree node should set below
> +optional properties. This is because USB2.0 Host needs to deassert pll reset,
> +apart from initializing interrupt enable, OVC detection timer and suspend/
> +resume timer register.
> +
> +- reg: offset and length of the partial USB2.0 Host register block.
USB host registers in the phy node? And somewhere else too? Don't create
overlapping regions in DT. That's not a reflection of the h/w and also
is an error in the kernel's resource handling code (which we work-around
in the DT code).
> +- clocks: clock phandle and specifier pair for usb2.0 host.
> +- clk-names: string, clock input name, must be "usb20_host".
Same with clocks.
> +
> The USB PHY device tree node should have the subnodes corresponding to the
> USB
> channels. These subnodes must contain the following properties:
> - reg: the USB controller selector; see the table below for the values.
> - #phy-cells: see phy-bindings.txt in the same directory, must be <1>.
>
> The phandle's argument in the PHY specifier is the USB controller selector
> for
> -the USB channel; see the selector meanings below:
> +the USB channel other than r8a77470 SoC; see the selector meanings below:
>
> +---+---+---+
> |\ Selector | | |
> @@ -40,22 +51,57 @@ the USB channel; see the selector meanings below:
> | 2 | PCI EHCI/OHCI | xHCI |
> +---+---+---+
>
> +For r8a77470 SoC see the selector meaning below:
> +
> ++---+---+---+
> +|\ Selector | | |
> ++ - + 0 | 1 |
> +| Channel \| | |
> ++---+---+---+
> +| 0 | EHCI/OHCI | HS-USB|
> ++---+---+---+
> +
> Example (Lager board):
>
> - usb-phy@e6590100 {
> - compatible = "renesas,usb-phy-r8a7790",
> "renesas,rcar-gen2-usb-phy";
> + usbphy: usb-phy@e6590100 {
> + compatible = "renesas,usb-phy-r8a7790",
> + "renesas,rcar-gen2-usb-phy";
This change doesn't seem necessary.
> reg = <0 0xe6590100 0 0x100>;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <_clks R8A7790_CLK_HSUSB>;
> + clocks = < CPG_MOD 704>;
> clock-names = "usbhs";
> + power-domains = < R8A7790_PD_ALWAYS_ON>;
> + resets = < 704>;
> + status = "disabled";
Don't show status in examples.
>
> - usb-channel@0 {
> - reg = <0>;
> - #phy-cells = <1>;
> + usb0: usb-channel@0 {
> + reg = <0>;
> + #phy-cells = <1>;
> + };
> + usb2: usb-channel@2 {
> + reg = <2>;
> + #phy-cells = <1>;
> };
> - usb-channel@2 {
> - reg = <2>;
> + };
> +
> +Example (iWave RZ/G1C SBC):
> +
> + usbphy0: usb-phy0@e6590100 {
> + compatible = "renesas,usb-phy-r8a77470",
> +
[RFC][PATCH] PCI: Avoid PCI device removing/rescanning through sysfs triggers a deadlock
From: Tho Vu
This patch fixes deadlock warning in removing/rescanning through sysfs
when CONFIG_PROVE_LOCKING is enabled.
The issue can be reproduced by these steps:
1. Enable CONFIG_PROVE_LOCKING via defconfig or menuconfig
2. Insert Ethernet card into PCIe CH0 and start up.
After kernel starting up, execute the following command.
echo 1 > /sys/class/pci_bus/\:00/device/\:00\:00.0/remove
3. Rescan PCI device by this command
echo 1 > /sys/class/pci_bus/\:00/rescan
The deadlock warnings will occur.
WARNING: possible recursive locking detected
4.14.70-ltsi-yocto-standard #27 Not tainted
sh/3402 is trying to acquire lock:
(kn->count#78){}, at: kernfs_remove_by_name_ns+0x50/0xa8
but task is already holding lock:
(kn->count#78){}, at: kernfs_remove_self+0xe0/0x130
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(kn->count#78);
lock(kn->count#78);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by sh/3402:
#0: (sb_writers#4){.+.+}, at: vfs_write+0x198/0x1b0
#1: (>mutex){+.+.}, at: kernfs_fop_write+0x108/0x210
#2: (kn->count#78){}, at: kernfs_remove_self+0xe0/0x130
#3: (pci_rescan_remove_lock){+.+.}, at: pci_lock_rescan_remove+0x1c/0x28
stack backtrace:
CPU: 3 PID: 3402 Comm: sh Not tainted 4.14.70-ltsi-yocto-standard #27
Hardware name: Renesas Salvator-X 2nd version board based on r8a7795
ES3.0+ with 8GiB (4 x 2 GiB) (DT)
Call trace:
dump_backtrace+0x0/0x3d8
show_stack+0x14/0x20
dump_stack+0xbc/0xf4
__lock_acquire+0x930/0x18a8
lock_acquire+0x48/0x68
__kernfs_remove+0x280/0x2f8
kernfs_remove_by_name_ns+0x50/0xa8
remove_files.isra.0+0x38/0x78
sysfs_remove_group+0x4c/0xa0
sysfs_remove_groups+0x38/0x60
device_remove_attrs+0x54/0x78
device_del+0x1ac/0x308
pci_remove_bus_device+0x78/0xf8
pci_remove_bus_device+0x34/0xf8
pci_stop_and_remove_bus_device_locked+0x24/0x38
remove_store+0x6c/0x78
dev_attr_store+0x18/0x28
sysfs_kf_write+0x4c/0x78
kernfs_fop_write+0x138/0x210
__vfs_write+0x18/0x118
vfs_write+0xa4/0x1b0
SyS_write+0x48/0xb0
This warning occurs due to a self-deletion attribute using in the sysfs
PCI device directory. This kind of attribute is really tricky,
it does not allow pci framework drop this attribute until all active
.show() and .store() callbacks have finished unless
sysfs_break_active_protection() is called.
Hence this patch avoids writing into this attribute triggers a deadlock.
Referrence commit 5b55b24cec4c ("scsi: core: Avoid that SCSI device
removal through sysfs triggers a deadlock")
of scsi driver
Signed-off-by: Tho Vu
---
drivers/pci/pci-sysfs.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 9ecfe13157c0..d522bd8368d9 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -470,12 +470,22 @@ static ssize_t remove_store(struct device *dev, struct
device_attribute *attr,
const char *buf, size_t count)
{
unsigned long val;
+ struct kernfs_node *kn;
+
+ kn = sysfs_break_active_protection(>kobj, >attr);
+ WARN_ON_ONCE(!kn);
if (kstrtoul(buf, 0, ) < 0)
return -EINVAL;
- if (val && device_remove_file_self(dev, attr))
+ if (val) {
+ device_remove_file(dev, attr);
pci_stop_and_remove_bus_device_locked(to_pci_dev(dev));
+ }
+
+ if (kn)
+ sysfs_unbreak_active_protection(kn);
+
return count;
}
static struct device_attribute dev_remove_attr = __ATTR(remove,
@@ -487,11 +497,15 @@ static ssize_t dev_bus_rescan_store(struct device *dev,
const char *buf, size_t count)
{
unsigned long val;
+ struct kernfs_node *kn;
struct pci_bus *bus = to_pci_bus(dev);
if (kstrtoul(buf, 0, ) < 0)
return -EINVAL;
+ kn = sysfs_break_active_protection(>kobj, >attr);
+ WARN_ON_ONCE(!kn);
+
if (val) {
pci_lock_rescan_remove();
if (!pci_is_root_bus(bus) && list_empty(>devices))
@@ -500,6 +514,10 @@ static ssize_t dev_bus_rescan_store(struct device *dev,
pci_rescan_bus(bus);
pci_unlock_rescan_remove();
}
+
+ if (kn)
+ sysfs_unbreak_active_protection(kn);
+
return count;
}
static DEVICE_ATTR(rescan, (S_IWUSR|S_IWGRP), NULL, dev_bus_rescan_store);
--
2.18.0
[PATCH 1/2] arm64: dts: r8a77990: Add SDHI device nodes
From: Takeshi Kihara
This patch adds SDHI{0,1,3} device nodes for the r8a77990 SoC.
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
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 9509dc05665f..fb0818d07cdb 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -826,6 +826,42 @@
status = "disabled";
};
+ sdhi0: sd@ee10 {
+ compatible = "renesas,sdhi-r8a77990",
+"renesas,rcar-gen3-sdhi";
+ reg = <0 0xee10 0 0x2000>;
+ interrupts = ;
+ clocks = < CPG_MOD 314>;
+ max-frequency = <2>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 314>;
+ status = "disabled";
+ };
+
+ sdhi1: sd@ee12 {
+ compatible = "renesas,sdhi-r8a77990",
+"renesas,rcar-gen3-sdhi";
+ reg = <0 0xee12 0 0x2000>;
+ interrupts = ;
+ clocks = < CPG_MOD 313>;
+ max-frequency = <2>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 313>;
+ status = "disabled";
+ };
+
+ sdhi3: sd@ee16 {
+ compatible = "renesas,sdhi-r8a77990",
+"renesas,rcar-gen3-sdhi";
+ reg = <0 0xee16 0 0x2000>;
+ interrupts = ;
+ clocks = < CPG_MOD 311>;
+ max-frequency = <2>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 311>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
2.18.0
[PATCH 2/2] arm64: dts: r8a77990: ebisu: Enable SDHI interfaces
From: Takeshi Kihara
This patch enables SD card slot connected to SDHI0, micro SD card slot
connected to SDHI1 and eMMC connected to SDHI3 on the Ebisu board using
the R8A77990 SoC.
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
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 136 ++
1 file changed, 136 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 611f0265fcc5..bda1765dcdbd 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -119,6 +119,15 @@
};
};
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
reg_3p3v: regulator1 {
compatible = "regulator-fixed";
regulator-name = "fixed-3.3V";
@@ -133,6 +142,54 @@
#clock-cells = <0>;
clock-frequency = <7425>;
};
+
+ vcc_sdhi0: regulator-vcc-sdhi0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI0 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = < 17 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi0: regulator-vccq-sdhi0 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI0 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = < 18 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
+
+ vcc_sdhi1: regulator-vcc-sdhi1 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI1 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = < 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi1: regulator-vccq-sdhi1 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI1 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = < 15 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
{
@@ -326,6 +383,42 @@
function = "scif2";
};
+ sdhi0_pins: sd0 {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
+ };
+
+ sdhi1_pins: sd1 {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <3300>;
+ };
+
+ sdhi1_pins_uhs: sd1_uhs {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <1800>;
+ };
+
+ sdhi3_pins: sd3 {
+ groups = "sdhi3_data8", "sdhi3_ctrl";
+ function = "sdhi3";
+ power-source = <1800>;
+ };
+
+ sdhi3_pins_uhs: sd3_uhs {
+ groups = "sdhi3_data8", "sdhi3_ctrl";
+ function = "sdhi3";
+ power-source = <1800>;
+ };
+
usb0_pins: usb {
groups = "usb0_b";
function = "usb0";
@@ -380,3 +473,46 @@
status = "okay";
};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-1 = <_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <_sdhi0>;
+ vqmmc-supply = <_sdhi0>;
+ cd-gpios = < 12 GPIO_ACTIVE_LOW>;
+ wp-gpios = < 13 GPIO_ACTIVE_HIGH>;
+ bus-width = <4>;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-1 = <_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <_sdhi1>;
+ vqmmc-supply = <_sdhi1>;
+ cd-gpios = < 14 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+
+ {
+ /* used for on-board 8bit eMMC */
+ pinctrl-0 = <_pins>;
+ pinctrl-1 = <_pins_uhs>;
+ pinctrl-names = "default",
[PATCH 2/2] pinctrl: sh-pfc: r8a77990: Add voltage switch operations for SDHI
From: Takeshi Kihara
This patch supports the {get,set}_io_voltage operations of SDHI.
This operates the IOCTRL30 register on the R8A77990 SoC and makes
1.8V/3.3V signal voltage switch possible.
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
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 97aba270a515..95d478353627 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -23,8 +23,12 @@
PORT_GP_CFG_18(0, fn, sfx, CFG_FLAGS), \
PORT_GP_CFG_23(1, fn, sfx, CFG_FLAGS), \
PORT_GP_CFG_26(2, fn, sfx, CFG_FLAGS), \
- PORT_GP_CFG_16(3, fn, sfx, CFG_FLAGS), \
- PORT_GP_CFG_11(4, fn, sfx, CFG_FLAGS), \
+ PORT_GP_CFG_12(3, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE), \
+ PORT_GP_CFG_1(3, 12, fn, sfx, CFG_FLAGS), \
+ PORT_GP_CFG_1(3, 13, fn, sfx, CFG_FLAGS), \
+ PORT_GP_CFG_1(3, 14, fn, sfx, CFG_FLAGS), \
+ PORT_GP_CFG_1(3, 15, fn, sfx, CFG_FLAGS), \
+ PORT_GP_CFG_11(4, fn, sfx, CFG_FLAGS | SH_PFC_PIN_CFG_IO_VOLTAGE), \
PORT_GP_CFG_20(5, fn, sfx, CFG_FLAGS), \
PORT_GP_CFG_18(6, fn, sfx, CFG_FLAGS)
/*
@@ -3494,6 +3498,31 @@ static const struct pinmux_cfg_reg pinmux_config_regs[]
= {
{ },
};
+enum ioctrl_regs {
+ IOCTRL30,
+};
+
+static const struct pinmux_ioctrl_reg pinmux_ioctrl_regs[] = {
+ [IOCTRL30] = { 0xe6060380, },
+ { /* sentinel */ },
+};
+
+static int r8a77990_pin_to_pocctrl(struct sh_pfc *pfc, unsigned int pin,
+ u32 *pocctrl)
+{
+ int bit = -EINVAL;
+
+ *pocctrl = pinmux_ioctrl_regs[IOCTRL30].reg;
+
+ if (pin >= RCAR_GP_PIN(3, 0) && pin <= RCAR_GP_PIN(3, 11))
+ bit = pin & 0x1f;
+
+ if (pin >= RCAR_GP_PIN(4, 0) && pin <= RCAR_GP_PIN(4, 10))
+ bit = (pin & 0x1f) + 19;
+
+ return bit;
+}
+
static const struct pinmux_bias_reg pinmux_bias_regs[] = {
{ PINMUX_BIAS_REG("PUEN0", 0xe6060400, "PUD0", 0xe6060440) {
[0] = RCAR_GP_PIN(2, 23), /* RD# */
@@ -3744,6 +3773,7 @@ static void r8a77990_pinmux_set_bias(struct sh_pfc *pfc,
unsigned int pin,
}
static const struct sh_pfc_soc_operations r8a77990_pinmux_ops = {
+ .pin_to_pocctrl = r8a77990_pin_to_pocctrl,
.get_bias = r8a77990_pinmux_get_bias,
.set_bias = r8a77990_pinmux_set_bias,
};
@@ -3790,6 +3820,7 @@ const struct sh_pfc_soc_info r8a77990_pinmux_info = {
.cfg_regs = pinmux_config_regs,
.bias_regs = pinmux_bias_regs,
+ .ioctrl_regs = pinmux_ioctrl_regs,
.pinmux_data = pinmux_data,
.pinmux_data_size = ARRAY_SIZE(pinmux_data),
--
2.18.0
[PATCH 1/2] pinctrl: sh-pfc: r8a77990: Add SDHI pins, groups and functions
From: Takeshi Kihara
This patch adds SDHI{0,1,3} pins, groups and functions to the R8A77990
SoC.
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
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 218 +-
1 file changed, 216 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 1fdafa48479c..97aba270a515 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -2386,6 +2386,174 @@ static const unsigned int scif_clk_b_mux[] = {
SCIF_CLK_B_MARK,
};
+/* - SDHI0 --
*/
+static const unsigned int sdhi0_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(3, 2),
+};
+
+static const unsigned int sdhi0_data1_mux[] = {
+ SD0_DAT0_MARK,
+};
+
+static const unsigned int sdhi0_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3),
+ RCAR_GP_PIN(3, 4), RCAR_GP_PIN(3, 5),
+};
+
+static const unsigned int sdhi0_data4_mux[] = {
+ SD0_DAT0_MARK, SD0_DAT1_MARK,
+ SD0_DAT2_MARK, SD0_DAT3_MARK,
+};
+
+static const unsigned int sdhi0_ctrl_pins[] = {
+ /* CLK, CMD */
+ RCAR_GP_PIN(3, 0), RCAR_GP_PIN(3, 1),
+};
+
+static const unsigned int sdhi0_ctrl_mux[] = {
+ SD0_CLK_MARK, SD0_CMD_MARK,
+};
+
+static const unsigned int sdhi0_cd_pins[] = {
+ /* CD */
+ RCAR_GP_PIN(3, 12),
+};
+
+static const unsigned int sdhi0_cd_mux[] = {
+ SD0_CD_MARK,
+};
+
+static const unsigned int sdhi0_wp_pins[] = {
+ /* WP */
+ RCAR_GP_PIN(3, 13),
+};
+
+static const unsigned int sdhi0_wp_mux[] = {
+ SD0_WP_MARK,
+};
+
+/* - SDHI1 --
*/
+static const unsigned int sdhi1_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(3, 8),
+};
+
+static const unsigned int sdhi1_data1_mux[] = {
+ SD1_DAT0_MARK,
+};
+
+static const unsigned int sdhi1_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(3, 8), RCAR_GP_PIN(3, 9),
+ RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 11),
+};
+
+static const unsigned int sdhi1_data4_mux[] = {
+ SD1_DAT0_MARK, SD1_DAT1_MARK,
+ SD1_DAT2_MARK, SD1_DAT3_MARK,
+};
+
+static const unsigned int sdhi1_ctrl_pins[] = {
+ /* CLK, CMD */
+ RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
+};
+
+static const unsigned int sdhi1_ctrl_mux[] = {
+ SD1_CLK_MARK, SD1_CMD_MARK,
+};
+
+static const unsigned int sdhi1_cd_pins[] = {
+ /* CD */
+ RCAR_GP_PIN(3, 14),
+};
+
+static const unsigned int sdhi1_cd_mux[] = {
+ SD1_CD_MARK,
+};
+
+static const unsigned int sdhi1_wp_pins[] = {
+ /* WP */
+ RCAR_GP_PIN(3, 15),
+};
+
+static const unsigned int sdhi1_wp_mux[] = {
+ SD1_WP_MARK,
+};
+
+/* - SDHI3 --
*/
+static const unsigned int sdhi3_data1_pins[] = {
+ /* D0 */
+ RCAR_GP_PIN(4, 2),
+};
+
+static const unsigned int sdhi3_data1_mux[] = {
+ SD3_DAT0_MARK,
+};
+
+static const unsigned int sdhi3_data4_pins[] = {
+ /* D[0:3] */
+ RCAR_GP_PIN(4, 2), RCAR_GP_PIN(4, 3),
+ RCAR_GP_PIN(4, 4), RCAR_GP_PIN(4, 5),
+};
+
+static const unsigned int sdhi3_data4_mux[] = {
+ SD3_DAT0_MARK, SD3_DAT1_MARK,
+ SD3_DAT2_MARK, SD3_DAT3_MARK,
+};
+
+static const unsigned int sdhi3_data8_pins[] = {
+ /* D[0:7] */
+ RCAR_GP_PIN(4, 2), RCAR_GP_PIN(4, 3),
+ RCAR_GP_PIN(4, 4), RCAR_GP_PIN(4, 5),
+ RCAR_GP_PIN(4, 6), RCAR_GP_PIN(4, 7),
+ RCAR_GP_PIN(4, 8), RCAR_GP_PIN(4, 9),
+};
+
+static const unsigned int sdhi3_data8_mux[] = {
+ SD3_DAT0_MARK, SD3_DAT1_MARK,
+ SD3_DAT2_MARK, SD3_DAT3_MARK,
+ SD3_DAT4_MARK, SD3_DAT5_MARK,
+ SD3_DAT6_MARK, SD3_DAT7_MARK,
+};
+
+static const unsigned int sdhi3_ctrl_pins[] = {
+ /* CLK, CMD */
+ RCAR_GP_PIN(4, 0), RCAR_GP_PIN(4, 1),
+};
+
+static const unsigned int sdhi3_ctrl_mux[] = {
+ SD3_CLK_MARK, SD3_CMD_MARK,
+};
+
+static const unsigned int sdhi3_cd_pins[] = {
+ /* CD */
+ RCAR_GP_PIN(3, 12),
+};
+
+static const unsigned int sdhi3_cd_mux[] = {
+ SD3_CD_MARK,
+};
+
+static const unsigned int sdhi3_wp_pins[] = {
+ /* WP */
+ RCAR_GP_PIN(3, 13),
+};
+
+static const unsigned int sdhi3_wp_mux[] = {
+ SD3_WP_MARK,
+};
+
+static const unsigned int sdhi3_ds_pins[] = {
+ /* DS */
+ RCAR_GP_PIN(4, 10),
+};
+
+static const unsigned int sdhi3_ds_mux[] = {
+ SD3_DS_MARK,
+};
+
/* - USB0 ---
*/
static const unsigned int usb0_a_pins[] = {
/* PWEN, OVC */
@@ -2434,7 +2602,7 @@ static const unsigned int usb30_id_mux[] = {
};
static const struct {
- struct
[PATCH] mmc: renesas_sdhi: Whitelist R8A77990 SDHI
Whitelist R8A77990 E3 SoC in the SDHI driver. The SDHI core
present in the SoC is an 8tap variant of the Gen3 SDHI core.
Signed-off-by: Marek Vasut
Cc: Geert Uytterhoeven
Cc: Simon Horman
Cc: Wolfram Sang
Cc: Yoshihiro Shimoda
Cc: Ulf Hansson
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index b6f54102bfdd..ede7eec9b9aa 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -304,6 +304,7 @@ static const struct soc_device_attribute soc_whitelist[] = {
{ .soc_id = "r8a77965" },
{ .soc_id = "r8a77970" },
{ .soc_id = "r8a77980" },
+ { .soc_id = "r8a77990" },
{ .soc_id = "r8a77995" },
{ /* sentinel */ }
};
--
2.18.0
[PATCH] arm64: dts: r8a77990: ebisu: Add serial console pins
From: Takeshi Kihara
This patch adds pin control for SCIF2 on R8A77990 E3 Ebisu.
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
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index f342dd85b152..611f0265fcc5 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -321,6 +321,11 @@
function = "pwm5";
};
+ scif2_pins: scif2 {
+ groups = "scif2_data_a";
+ function = "scif2";
+ };
+
usb0_pins: usb {
groups = "usb0_b";
function = "usb0";
@@ -352,6 +357,9 @@
};
{
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
status = "okay";
};
--
2.18.0
Re: [PATCH 0/2] renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Wolfram,
On Mon, Nov 5, 2018 at 7:08 PM Wolfram Sang wrote:
> > Is there any chance this can start to bite us in the future?
>
> Well, there is always a chance but to the best of our current knowledge,
> we can't see it for Gen3. And even then, we can still fix it.
>
> I was entering SDHI hackfest with the attitude of representing the
> hardware which means exposing SDHn. Yet, I got convinced that getting
> and keeping highspeed modes stable means turning a lot of knobs
> currently. This is not only true for HS400, but also HS200 and SDR50 and
> SDR104.
>
> This simple approach here allows us to have a stable base on which we
> can evaluate the other BSP patches on top. Especially those which modify
> the tuning procedure.
>
> So, because this change does not prevent SDHn exposure in the future, I
> suggest to go this way for now, so we can spend our (limited) manpower
> on evaluating the tuning next.
OK. 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 0/2] renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Geert, > Is there any chance this can start to bite us in the future? Well, there is always a chance but to the best of our current knowledge, we can't see it for Gen3. And even then, we can still fix it. I was entering SDHI hackfest with the attitude of representing the hardware which means exposing SDHn. Yet, I got convinced that getting and keeping highspeed modes stable means turning a lot of knobs currently. This is not only true for HS400, but also HS200 and SDR50 and SDR104. This simple approach here allows us to have a stable base on which we can evaluate the other BSP patches on top. Especially those which modify the tuning procedure. So, because this change does not prevent SDHn exposure in the future, I suggest to go this way for now, so we can spend our (limited) manpower on evaluating the tuning next. Kind regards, Wolfram signature.asc Description: PGP signature
Re: [PATCH 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Niklas,
On Mon, Nov 5, 2018 at 4:07 PM Niklas Söderlund
wrote:
> On 2018-11-05 11:43:24 +0100, Geert Uytterhoeven wrote:
> > On Thu, Nov 1, 2018 at 12:26 AM Niklas Söderlund
> > wrote:
> > > From: Niklas Söderlund
> > >
> > > On H3 (ES1.0,ES2.0) and M3-W (ES1.0,ES1.1) the clock setting for HS400
> >
> > H3 (ES1.x, ES2.0) and M3-W (ES1.0, ES1.1)
>
> Thanks.
>
> >
> > > needs a quirk to function properly. The reason for the quirk is that
> > > there are two settings which produces same divider vale for the SDn
> > > clock. On the effected boards the one currently selected results in HS00
> >
> > HS200 or HS400?
>
> Wops, HS400 :-)
>
> >
> > > not working.
> > >
> > > This change uses the same method as the Gen2 CPG driver and simply
> > > ignores the first clock setting as this is the offending one when
> > > selecting the settings. Which of the two possible settings is used have
> > > no effect for SDR104.
> > >
> > > Signed-off-by: Niklas Söderlund
> > > ---
> > > drivers/clk/renesas/rcar-gen3-cpg.c | 28 ++--
> > > 1 file changed, 22 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c
> > > b/drivers/clk/renesas/rcar-gen3-cpg.c
> > > index ff56ac6134111c38..8cc524a29c855dd2 100644
> > > --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> > > +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
> > > @@ -377,6 +382,7 @@ static struct clk * __init cpg_sd_clk_register(const
> > > struct cpg_core_clk *core,
> > > clock->hw.init =
> > > clock->div_table = cpg_sd_div_table;
> > > clock->div_num = ARRAY_SIZE(cpg_sd_div_table);
> > > + clock->skip_first = skip_first;
> >
> > What about
> >
> > if (cpg_quirks & SD_SKIP_FIRST) {
> > clock->div_table++;
> > clock->div_num--;
> > }
> >
> > instead?
>
> This was my first approach as well, unfortunately it won't work :-(
>
> If the bootloader leaves the clock settings in a state which matches the
> first row in the table the clock fails to register as the check in
> cpg_sd_clk_register() makes sure it have a row for the state the
> hardware is in. If it can't find that state the clock fails to register.
> Whit this quirk the limitation of the effected boards only have an
> effect when setting the clock.
IC...
> I thought this solution solved this quiet neatly with the robustness
> principle, 'Be conservative in what you do, be liberal in what you
> accept from others' :-)
Will it ever use the settings as inherited from boot loader or reset state?
If it does, I assume it will fail badly, due to an inconsistency between the
SD and SDH clock rates?
And what if the kernel is ever booted when the SDnSRCFC or SDnFC field
has an invalid value? Then the driver will fail, too?
Hence, isn't it safer to initialize the registers to a known safe value?
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/RFT] arm64: dts: renesas: r8a77990: Add all HSCIF nodes
On Sun, Oct 21, 2018 at 06:30:27AM +0900, Yoshihiro Kaneko wrote: > From: Takeshi Kihara > > This patch adds the device nodes for all HSCIF serial ports to > the R8A77990 SoC. > > Signed-off-by: Takeshi Kihara > Signed-off-by: Yoshihiro Kaneko > --- > > This patch is based on the devel branch of Simon Horman's renesas tree. Thanks. I don't believe this can (easily) be tested as HSCIF does not appear to be exposed on the Ebisu board. I have checked this patch with reference to the documentation and it looks good to me. I have applied if for v4.21.
Re: [PATCH/RFT] pinctrl: sh-pfc: r8a77990: Add HSCIF pins, groups, and functions
Hi Kaneko-san,
On Sat, Oct 20, 2018 at 11:31 PM Yoshihiro Kaneko wrote:
> From: Takeshi Kihara
>
> This patch adds HSCIF{0,1,2,3,4} pins, groups and functions to
> the R8A77990 SoC.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Yoshihiro Kaneko
Thanks for your patch!
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> +static const unsigned int hscif3_data_d_pins[] = {
> + /* RX, TX */
> + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 0),
These two pins are exchanged.
According to the datasheet, it should be:
RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 3),
> +};
> +
> +static const unsigned int hscif3_data_d_mux[] = {
> + HRX3_D_MARK, HTX3_D_MARK,
> +};
> @@ -2454,6 +2738,37 @@ enum {
> SH_PFC_PIN_GROUP(du_disp_cde),
> SH_PFC_PIN_GROUP(du_cde),
> SH_PFC_PIN_GROUP(du_disp),
> + SH_PFC_PIN_GROUP(hscif0_data_a),
> + SH_PFC_PIN_GROUP(hscif0_clk_a),
> + SH_PFC_PIN_GROUP(hscif0_ctrl_a),
> + SH_PFC_PIN_GROUP(hscif0_data_b),
> + SH_PFC_PIN_GROUP(hscif0_clk_b),
> + SH_PFC_PIN_GROUP(hscif1_data_a),
> + SH_PFC_PIN_GROUP(hscif1_clk_a),
> + SH_PFC_PIN_GROUP(hscif1_data_b),
> + SH_PFC_PIN_GROUP(hscif1_clk_b),
> + SH_PFC_PIN_GROUP(hscif1_ctrl_b),
> + SH_PFC_PIN_GROUP(hscif2_data_a),
> + SH_PFC_PIN_GROUP(hscif2_clk_a),
> + SH_PFC_PIN_GROUP(hscif2_ctrl_a),
> + SH_PFC_PIN_GROUP(hscif2_data_b),
> + SH_PFC_PIN_GROUP(hscif3_data_a),
> + SH_PFC_PIN_GROUP(hscif3_data_b),
> + SH_PFC_PIN_GROUP(hscif3_clk_b),
> + SH_PFC_PIN_GROUP(hscif3_data_c),
> + SH_PFC_PIN_GROUP(hscif3_clk_c),
> + SH_PFC_PIN_GROUP(hscif3_ctrl_c),
> + SH_PFC_PIN_GROUP(hscif3_data_d),
> + SH_PFC_PIN_GROUP(hscif3_data_e),
> + SH_PFC_PIN_GROUP(hscif3_ctrl_e),
> + SH_PFC_PIN_GROUP(hscif4_data_a),
> + SH_PFC_PIN_GROUP(hscif4_clk_a),
> + SH_PFC_PIN_GROUP(hscif4_ctrl_a),
> + SH_PFC_PIN_GROUP(hscif4_data_b),
> + SH_PFC_PIN_GROUP(hscif4_clk_b),
> + SH_PFC_PIN_GROUP(hscif4_data_c),
> + SH_PFC_PIN_GROUP(hscif4_data_d),
> + SH_PFC_PIN_GROUP(hscif4_data_e),
> SH_PFC_PIN_GROUP(i2c1_a),
> SH_PFC_PIN_GROUP(i2c1_b),
> SH_PFC_PIN_GROUP(i2c1_c),
The above doesn't compile, as you forgot to update the size of the
pinmux_groups.common[] array.
> @@ -2781,6 +3142,11 @@ enum {
> .common = {
> SH_PFC_FUNCTION(avb),
> SH_PFC_FUNCTION(du),
> + SH_PFC_FUNCTION(hscif0),
> + SH_PFC_FUNCTION(hscif1),
> + SH_PFC_FUNCTION(hscif2),
> + SH_PFC_FUNCTION(hscif3),
> + SH_PFC_FUNCTION(hscif4),
> SH_PFC_FUNCTION(i2c1),
> SH_PFC_FUNCTION(i2c2),
> SH_PFC_FUNCTION(i2c4),
The above doesn't compile, as you forgot to update the size of the
pinmux_functions.common[] array.
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] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Geert,
Thanks for your feedback.
On 2018-11-05 11:43:24 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> Thanks for your patch!
>
> On Thu, Nov 1, 2018 at 12:26 AM Niklas Söderlund
> wrote:
> > From: Niklas Söderlund
> >
> > On H3 (ES1.0,ES2.0) and M3-W (ES1.0,ES1.1) the clock setting for HS400
>
> H3 (ES1.x, ES2.0) and M3-W (ES1.0, ES1.1)
Thanks.
>
> > needs a quirk to function properly. The reason for the quirk is that
> > there are two settings which produces same divider vale for the SDn
> > clock. On the effected boards the one currently selected results in HS00
>
> HS200 or HS400?
Wops, HS400 :-)
>
> > not working.
> >
> > This change uses the same method as the Gen2 CPG driver and simply
> > ignores the first clock setting as this is the offending one when
> > selecting the settings. Which of the two possible settings is used have
> > no effect for SDR104.
> >
> > Signed-off-by: Niklas Söderlund
> > ---
> > drivers/clk/renesas/rcar-gen3-cpg.c | 28 ++--
> > 1 file changed, 22 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c
> > b/drivers/clk/renesas/rcar-gen3-cpg.c
> > index ff56ac6134111c38..8cc524a29c855dd2 100644
> > --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> > +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
> > @@ -227,6 +227,7 @@ struct sd_clock {
> > unsigned int div_min;
> > unsigned int div_max;
> > unsigned int cur_div_idx;
> > + bool skip_first;
>
> I think you can do without adding this field...
>
> > };
> >
> > /* SDn divider
> > @@ -243,6 +244,10 @@ struct sd_clock {
> > * 1 0 2 (4) 0 (2) 8
> > * 1 0 3 (8) 0 (2) 16
> > * 1 0 4 (16) 0 (2) 32
> > + *
> > + * NOTE: There is a quirk option to ignore the first row of the dividers
> > + * table when searching for suitable settings. This is because HS400 on
> > + * early ES versions of H3 and M3-W requires a specific setting to work.
> > */
> > static const struct sd_div_table cpg_sd_div_table[] = {
> > /* CPG_SD_DIV_TABLE_DATA(stp_hck, stp_ck, sd_srcfc, sd_fc,
> > sd_div) */
> > @@ -327,7 +332,7 @@ static int cpg_sd_clock_set_rate(struct clk_hw *hw,
> > unsigned long rate,
> > u32 val;
> > unsigned int i;
> >
> > - for (i = 0; i < clock->div_num; i++)
> > + for (i = clock->skip_first ? 1 : 0; i < clock->div_num; i++)
>
> ... and without this change (see below)
>
> > if (div == clock->div_table[i].div)
> > break;
> >
> > @@ -355,7 +360,7 @@ static const struct clk_ops cpg_sd_clock_ops = {
> >
> > static struct clk * __init cpg_sd_clk_register(const struct cpg_core_clk
> > *core,
> > void __iomem *base, const char *parent_name,
> > - struct raw_notifier_head *notifiers)
> > + struct raw_notifier_head *notifiers, bool skip_first)
>
> I think you can do without adding this parameter.
>
> > {
> > struct clk_init_data init;
> > struct sd_clock *clock;
> > @@ -377,6 +382,7 @@ static struct clk * __init cpg_sd_clk_register(const
> > struct cpg_core_clk *core,
> > clock->hw.init =
> > clock->div_table = cpg_sd_div_table;
> > clock->div_num = ARRAY_SIZE(cpg_sd_div_table);
> > + clock->skip_first = skip_first;
>
> What about
>
> if (cpg_quirks & SD_SKIP_FIRST) {
> clock->div_table++;
> clock->div_num--;
> }
>
> instead?
This was my first approach as well, unfortunately it won't work :-(
If the bootloader leaves the clock settings in a state which matches the
first row in the table the clock fails to register as the check in
cpg_sd_clk_register() makes sure it have a row for the state the
hardware is in. If it can't find that state the clock fails to register.
Whit this quirk the limitation of the effected boards only have an
effect when setting the clock.
I thought this solution solved this quiet neatly with the robustness
principle, 'Be conservative in what you do, be liberal in what you
accept from others' :-)
I will wait for your feedback on this before sending a updated version
of this series addressing the other comments.
>
> It does require moving cpg_quirks and the quirk definitions up, but reduces
> the actual code change, and makes the code easier to follow.
>
> >
> > sd_fc = readl(clock->csn.reg) & CPG_SD_FC_MASK;
> > for (i = 0; i < clock->div_num; i++)
> > @@ -417,19 +423,28 @@ static u32 cpg_quirks __initdata;
> >
> > #define PLL_ERRATA BIT(0) /* Missing PLL0/2/4 post-divider */
> > #define RCKCR_CKSELBIT(1) /* Manual RCLK parent selection */
> > +#define SD_SKIP_FIRST BIT(2) /* Skip first clock in SD table */
> >
> > static const struct soc_device_attribute cpg_quirks_match[] __initconst = {
> > {
> > .soc_id = "r8a7795", .revision = "ES1.0",
> > -
Re: [PATCH 0/2] renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Geert,
Thanks for your feedback.
On 2018-11-05 11:32:15 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Thu, Nov 1, 2018 at 12:26 AM Niklas Söderlund
> wrote:
> > This is the result of the SDHI hackathon for a possible solution to the
> > clock issue on early ES versions. It is based on the Gen2 solution where
> > a row of the possible clock settings are ignored on the effected SoC+ES
> > versions. The first row is not effected when reading settings left by
> > the bootloader, only when the setting the clock.
>
> To clarify, you decided not to describe the SDH clock in DT, but went for
> heuristics with a quirk instead?
>
> Is there any chance this can start to bite us in the future?
We discussed this at the SDHI hackfest and we could not think of any
future situation where this could come back and bite us.
>
> 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
--
Regards,
Niklas Söderlund
Re: [v2 PATCH] thermal: rcar_gen3_thermal: Fix init value of IRQCTL register
Hi Hoan-san, Thanks for your patch. On 2018-10-25 11:13:41 +0900, Nguyen An Hoan wrote: > From: Hoan Nguyen An > > 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. > > Signed-off-by: Hoan Nguyen An > --- > drivers/thermal/rcar_gen3_thermal.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/thermal/rcar_gen3_thermal.c > b/drivers/thermal/rcar_gen3_thermal.c > index 7aed533..fde3fd8 100644 > --- a/drivers/thermal/rcar_gen3_thermal.c > +++ b/drivers/thermal/rcar_gen3_thermal.c > @@ -306,7 +306,7 @@ static void rcar_gen3_thermal_init(struct > rcar_gen3_thermal_tsc *tsc) > > usleep_range(1000, 2000); > > - rcar_gen3_thermal_write(tsc, REG_GEN3_IRQCTL, 0x3F); > + rcar_gen3_thermal_write(tsc, REG_GEN3_IRQCTL, 0); > rcar_gen3_thermal_write(tsc, REG_GEN3_IRQMSK, 0); > rcar_gen3_thermal_write(tsc, REG_GEN3_IRQEN, IRQ_TEMPD1 | IRQ_TEMP2); > > -- > 2.7.4 > -- Regards, Niklas Söderlund
Re: [PATCH 2/2] pinctrl: sh-pfc: r8a77990: Add Audio SSI pins, groups and functions
On Mon, Oct 15, 2018 at 11:58 AM Simon Horman
wrote:
> From: Takeshi Kihara
>
> This patch adds Audio SSI{0,1,2,3,4,5,6,7,8,9} pins, groups
> and functions to the R8A77990 SoC.
>
> Signed-off-by: Takeshi Kihara
> [simon: rebase]
> Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
i.e. will queue 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 1/2] pinctrl: sh-pfc: r8a77990: Add Audio clock pins, groups and functions
On Mon, Oct 15, 2018 at 11:58 AM Simon Horman
wrote:
> From: Takeshi Kihara
>
> This patch adds AUDIO_CLK{A,B,C}, AUDIO_CLKOUT, AUDIO_CLKOUT{1,2,3}
> pins, groups and functions to the R8A77990 SoC.
>
> Signed-off-by: Takeshi Kihara
> [simon: rebase]
> Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
i.e. will queue 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] clk: renesas: r8a77970: add RPC clock
On Fri, Nov 2, 2018 at 8:25 PM Sergei Shtylyov
wrote:
> On R-Car V3M (R8A77970), the RPC/RPCD2 clocks are output by the common
> divider. Describe them, as well as the RPC-IF module clock.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Geert Uytterhoeven
i.e. will queue in clk-renesas-for-v4.21, with s/add/Add/ and s/clock/clocks/.
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 v2] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
The VIN driver bindings dictates fixed numbering for VIN endpoints connected
to CSI-2 endpoints, even when a single endpoint exists.
Without proper endpoint numbering the VIN driver fails to probe.
Based on a patch in BSP from Koji Matsuoka
Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2 device
nodes")
Signed-off-by: Koji Matsuoka
Signed-off-by: Takeshi Kihara
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 9509dc0..106a574 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -745,9 +745,13 @@
#size-cells = <0>;
port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
reg = <1>;
- vin4csi40: endpoint {
+ vin4csi40: endpoint@2 {
+ reg = <2>;
remote-endpoint= <>;
};
};
@@ -769,9 +773,13 @@
#size-cells = <0>;
port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
reg = <1>;
- vin5csi40: endpoint {
+ vin5csi40: endpoint@2 {
+ reg = <2>;
remote-endpoint= <>;
};
};
--
2.7.4
Re: [PATCH] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
Hi Geert,
On Mon, Nov 05, 2018 at 01:57:07PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Nov 5, 2018 at 1:46 PM jacopo mondi wrote:
> > On Mon, Nov 05, 2018 at 01:07:58PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Nov 5, 2018 at 12:49 PM Jacopo Mondi
> > > wrote:
> > > > The VIN driver bindings dictates fixed numbering for VIN endpoints
> > > > connected
> > > > to CSI-2 endpoints, even when a single endpoint exists.
> > > >
> > > > Without proper endpoint numbering the VIN driver fails to probe.
> > > >
> > > > Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2
> > > > device nodes")
> > > > Signed-off-by: Koji Matsuoka
> > >
> > > Was this patch authored by you or by Matsuoka-san?
> >
> > The original patch didn't apply
> >
> > $git am index.html\?id\=1b1b73f7558d867d72e198901b84bec1e6ef1405
> > Applying: arm64: dts: r8a77990: Fix csi2 endpoint number in VIN node
> > error: patch failed: arch/arm64/boot/dts/renesas/r8a77990.dtsi:811
> > error: arch/arm64/boot/dts/renesas/r8a77990.dtsi: patch does not apply
>
> Right, the BSP had the unit address and reg property, while upstream hadn't.
>
> So don't you need to re-add:
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> else dtc complains:
>
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (reg_format): /soc/video@e6ef4000/ports/port@1/endpoint@2:reg:
> property has invalid length (4 bytes) (#address-cells == 2,
> #size-cells == 1)
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (pci_device_bus_num): Failed prerequisite 'reg_format'
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (simple_bus_reg): Failed prerequisite 'reg_format'
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (i2c_bus_reg): Failed prerequisite 'reg_format'
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (spi_bus_reg): Failed prerequisite 'reg_format'
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (avoid_default_addr_size):
> /soc/video@e6ef4000/ports/port@1/endpoint@2: Relying on default
> #address-cells value
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (avoid_default_addr_size):
> /soc/video@e6ef4000/ports/port@1/endpoint@2: Relying on default
> #size-cells value
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (graph_endpoint): /soc/video@e6ef4000/ports/port@1/endpoint@2: graph
> node '#address-cells' is -1, must be 1
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (graph_endpoint): /soc/video@e6ef4000/ports/port@1/endpoint@2: graph
> node '#size-cells' is -1, must be 0
Oh, sorry I didn't notice. I assumed the partent's ones were used.
I have now fixed that and will send v2.
Thanks
j
>
> > So I made a new one, changing the commit message and adding the Fixes
> > tag.
> >
> > I can change author if you want to.
>
> In such a case, I usually add "based on a patch in the BSP by ...", instead of
> the original SoB-chain.
>
> > > > Signed-off-by: Takeshi Kihara
> > > > Signed-off-by: Jacopo Mondi
>
> 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
signature.asc
Description: PGP signature
Re: [PATCH] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
Hi Jacopo,
On Mon, Nov 5, 2018 at 1:46 PM jacopo mondi wrote:
> On Mon, Nov 05, 2018 at 01:07:58PM +0100, Geert Uytterhoeven wrote:
> > On Mon, Nov 5, 2018 at 12:49 PM Jacopo Mondi
> > wrote:
> > > The VIN driver bindings dictates fixed numbering for VIN endpoints
> > > connected
> > > to CSI-2 endpoints, even when a single endpoint exists.
> > >
> > > Without proper endpoint numbering the VIN driver fails to probe.
> > >
> > > Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2
> > > device nodes")
> > > Signed-off-by: Koji Matsuoka
> >
> > Was this patch authored by you or by Matsuoka-san?
>
> The original patch didn't apply
>
> $git am index.html\?id\=1b1b73f7558d867d72e198901b84bec1e6ef1405
> Applying: arm64: dts: r8a77990: Fix csi2 endpoint number in VIN node
> error: patch failed: arch/arm64/boot/dts/renesas/r8a77990.dtsi:811
> error: arch/arm64/boot/dts/renesas/r8a77990.dtsi: patch does not apply
Right, the BSP had the unit address and reg property, while upstream hadn't.
So don't you need to re-add:
#address-cells = <1>;
#size-cells = <0>;
else dtc complains:
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
(reg_format): /soc/video@e6ef4000/ports/port@1/endpoint@2:reg:
property has invalid length (4 bytes) (#address-cells == 2,
#size-cells == 1)
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
(pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
(simple_bus_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
(i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
(spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
(avoid_default_addr_size):
/soc/video@e6ef4000/ports/port@1/endpoint@2: Relying on default
#address-cells value
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
(avoid_default_addr_size):
/soc/video@e6ef4000/ports/port@1/endpoint@2: Relying on default
#size-cells value
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
(graph_endpoint): /soc/video@e6ef4000/ports/port@1/endpoint@2: graph
node '#address-cells' is -1, must be 1
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
(graph_endpoint): /soc/video@e6ef4000/ports/port@1/endpoint@2: graph
node '#size-cells' is -1, must be 0
> So I made a new one, changing the commit message and adding the Fixes
> tag.
>
> I can change author if you want to.
In such a case, I usually add "based on a patch in the BSP by ...", instead of
the original SoB-chain.
> > > Signed-off-by: Takeshi Kihara
> > > Signed-off-by: Jacopo Mondi
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] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
Hi Geert,
On Mon, Nov 05, 2018 at 01:07:58PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> Thanks for your patch!
>
> On Mon, Nov 5, 2018 at 12:49 PM Jacopo Mondi
> wrote:
> > The VIN driver bindings dictates fixed numbering for VIN endpoints connected
> > to CSI-2 endpoints, even when a single endpoint exists.
> >
> > Without proper endpoint numbering the VIN driver fails to probe.
> >
> > Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2
> > device nodes")
> > Signed-off-by: Koji Matsuoka
>
> Was this patch authored by you or by Matsuoka-san?
The original patch didn't apply
$git am index.html\?id\=1b1b73f7558d867d72e198901b84bec1e6ef1405
Applying: arm64: dts: r8a77990: Fix csi2 endpoint number in VIN node
error: patch failed: arch/arm64/boot/dts/renesas/r8a77990.dtsi:811
error: arch/arm64/boot/dts/renesas/r8a77990.dtsi: patch does not apply
So I made a new one, changing the commit message and adding the Fixes
tag.
I can change author if you want to.
>
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Jacopo Mondi
>
> 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
signature.asc
Description: PGP signature
Re: [PATCH v2 3/3] mmc: renesas_sdhi: disable HS400 on H3 ES1.x and M3-W ES1.x
Hi Niklas,
Thanks for your patch!
On Thu, Nov 1, 2018 at 12:15 AM Niklas Söderlund
wrote:
> From: Niklas Söderlund
>
> The Renesas BSP confirms that H3 ES1.x and M3-W ES1.x do not properly
M3-W ES1.[012] (also in the subject)? (ES1.2 is indistinguishable from ES1.1)
Or does this apply to M3-W ES1.3, too?
> support HS400. Add a quirk to indicate this and disable HS400 in the MMC
> capabilities if the quirk is set.
>
> Signed-off-by: Niklas Söderlund
> @@ -607,15 +608,21 @@ static void renesas_sdhi_enable_dma(struct
> tmio_mmc_host *host, bool enable)
> renesas_sdhi_sdbuf_width(host, enable ? width : 16);
> }
>
> -static const struct renesas_sdhi_quirks sdhi_quirks_h3_m3w = {
> +static const struct renesas_sdhi_quirks sdhi_quirks_h3_m3w_es1 = {
> + .hs400_disabled = true,
> + .hs400_4taps = true,
> +};
> +
> +static const struct renesas_sdhi_quirks sdhi_quirks_h3_es2 = {
> + .hs400_disabled = false,
> .hs400_4taps = true,
> };
>
> static const struct soc_device_attribute sdhi_quirks_match[] = {
> - { .soc_id = "r8a7795", .revision = "ES1.*", .data =
> _quirks_h3_m3w },
> - { .soc_id = "r8a7795", .revision = "ES2.0", .data =
> _quirks_h3_m3w },
> - { .soc_id = "r8a7796", .revision = "ES1.0", .data =
> _quirks_h3_m3w },
> - { .soc_id = "r8a7796", .revision = "ES1.1", .data =
> _quirks_h3_m3w },
> + { .soc_id = "r8a7795", .revision = "ES1.*", .data =
> _quirks_h3_m3w_es1 },
> + { .soc_id = "r8a7795", .revision = "ES2.0", .data =
> _quirks_h3_es2 },
> + { .soc_id = "r8a7796", .revision = "ES1.0", .data =
> _quirks_h3_m3w_es1 },
> + { .soc_id = "r8a7796", .revision = "ES1.1", .data =
> _quirks_h3_m3w_es1 },
> { /* Sentinel. */ },
> };
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/3] mmc: renesas_sdhi: handle 4tap hs400 mode quirk based on SoC revision
Hi Niklas,
On Thu, Nov 1, 2018 at 12:15 AM Niklas Söderlund
wrote:
> From: Niklas Söderlund
>
> Latest datasheet makes it clear that not all ES revisions of the H3 and
> M3-W have the 4-tap HS400 mode quirk, currently the quirk is set
> unconditionally for these two SoCs. Prepare to handle the quirk based on
> SoC revision instead of compatibility value by using soc_device_match()
> and set the TMIO_MMC_HAVE_4TAP_HS400 flag explicitly.
>
> The reason for adding a new quirks struct instead of just a flag is that
> looking ahead it seems more quirks needs to be handled in a SoC revision
> basis.
>
> Signed-off-by: Niklas Söderlund
Thanks for your patch!
> @@ -602,11 +607,25 @@ static void renesas_sdhi_enable_dma(struct
> tmio_mmc_host *host, bool enable)
> renesas_sdhi_sdbuf_width(host, enable ? width : 16);
> }
>
> +static const struct renesas_sdhi_quirks sdhi_quirks_h3_m3w = {
I know this variable is renamed later, but sdhi_quirks_h3_m3w gives the
impression it applies to all H3/M3-W variants.
What about sdhi_quirks_4tap instead?
> + .hs400_4taps = true,
> +};
> +
> +static const struct soc_device_attribute sdhi_quirks_match[] = {
> + { .soc_id = "r8a7795", .revision = "ES1.*", .data =
> _quirks_h3_m3w },
> + { .soc_id = "r8a7795", .revision = "ES2.0", .data =
> _quirks_h3_m3w },
> + { .soc_id = "r8a7796", .revision = "ES1.0", .data =
> _quirks_h3_m3w },
> + { .soc_id = "r8a7796", .revision = "ES1.1", .data =
> _quirks_h3_m3w },
> + { /* Sentinel. */ },
> +};
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] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
Hi Jacopo,
Thanks for your patch!
On Mon, Nov 5, 2018 at 12:49 PM Jacopo Mondi wrote:
> The VIN driver bindings dictates fixed numbering for VIN endpoints connected
> to CSI-2 endpoints, even when a single endpoint exists.
>
> Without proper endpoint numbering the VIN driver fails to probe.
>
> Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2 device
> nodes")
> Signed-off-by: Koji Matsuoka
Was this patch authored by you or by Matsuoka-san?
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
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] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
Hi Jacopo,
Thank you for the patch.
On Monday, 5 November 2018 13:49:21 EET Jacopo Mondi wrote:
> The VIN driver bindings dictates fixed numbering for VIN endpoints connected
> to CSI-2 endpoints, even when a single endpoint exists.
>
> Without proper endpoint numbering the VIN driver fails to probe.
>
> Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2
> device nodes") Signed-off-by: Koji Matsuoka
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index 9509dc0..97f7e0c 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -747,7 +747,8 @@
> port@1 {
> reg = <1>;
>
> - vin4csi40: endpoint {
> + vin4csi40: endpoint@2 {
> + reg = <2>;
> remote-endpoint= <>;
> };
> };
> @@ -771,7 +772,8 @@
> port@1 {
> reg = <1>;
>
> - vin5csi40: endpoint {
> + vin5csi40: endpoint@2 {
> + reg = <2>;
> remote-endpoint= <>;
> };
> };
> --
> 2.7.4
--
Regards,
Laurent Pinchart
[PATCH] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
Signed-off-by: Jacopo Mondi
---
This patch requires the VIN_DATA_PIN_GROUP_VER macro introduced by patch:
[PATCH 1/2] pinctrl: sh-pfc: Introduce VIN_DATA_PIN_GROUP_VER
Patch based on v4.20-rc1
v2 -> v3:
- Rebased on v4.20-rc1
- Use the newly introduced VIN_DATA_PIN_GROUP_VER macro
Incorporate Geert's comments:
- vin5_data8_b is only used with 8 pins: use regular SH_PFC_PIN_GROUP()
- remove stf groups for vin4/vin5
- confirmed that pins [23-8] of vin4's groups 'a' and 'b' are shared
- confirmed with HW team the synchronism pins in vin5 are only for group 'a'
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 244 ++
1 file changed, 244 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 1fdafa4..16fd139 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -2433,6 +2433,190 @@ static const unsigned int usb30_id_mux[] = {
USB3HS0_ID_MARK,
};
+/* - VIN4 ---
*/
+static const union vin_data vin4_data_a_pins = {
+ .data24 = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_a_mux = {
+ .data24 = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const union vin_data vin4_data_b_pins = {
+ .data24 = {
+ RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
+ RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+ RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 15),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_b_mux = {
+ .data24 = {
+ VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const unsigned int vin4_sync_pins[] = {
+ /* HSYNC, VSYNC */
+ RCAR_GP_PIN(2, 25), RCAR_GP_PIN(2, 24),
+};
+
+static const unsigned int vin4_sync_mux[] = {
+ VI4_HSYNC_N_MARK, VI4_VSYNC_N_MARK,
+};
+
+static const unsigned int vin4_field_pins[] = {
+ RCAR_GP_PIN(2, 23),
+};
+
+static const unsigned int vin4_field_mux[] = {
+ VI4_FIELD_MARK,
+};
+
+static const unsigned int vin4_clkenb_pins[] = {
+ RCAR_GP_PIN(1, 2),
+};
+
+static const unsigned int vin4_clkenb_mux[] = {
+ VI4_CLKENB_MARK,
+};
+
+static const unsigned int vin4_clk_pins[] = {
+ RCAR_GP_PIN(2, 22),
+};
+
+static const unsigned int vin4_clk_mux[] = {
+ VI4_CLK_MARK,
+};
+
+/* - VIN5 ---
*/
+static const union vin_data vin5_data_a_pins = {
+ .data16 = {
+ RCAR_GP_PIN(1, 1), RCAR_GP_PIN(1, 2),
+
[PATCH] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
The VIN driver bindings dictates fixed numbering for VIN endpoints connected
to CSI-2 endpoints, even when a single endpoint exists.
Without proper endpoint numbering the VIN driver fails to probe.
Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2 device
nodes")
Signed-off-by: Koji Matsuoka
Signed-off-by: Takeshi Kihara
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 9509dc0..97f7e0c 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -747,7 +747,8 @@
port@1 {
reg = <1>;
- vin4csi40: endpoint {
+ vin4csi40: endpoint@2 {
+ reg = <2>;
remote-endpoint= <>;
};
};
@@ -771,7 +772,8 @@
port@1 {
reg = <1>;
- vin5csi40: endpoint {
+ vin5csi40: endpoint@2 {
+ reg = <2>;
remote-endpoint= <>;
};
};
--
2.7.4
[PATCH v2] watchdog: renesas_wdt: Fix typos
Do not use "," but ";" to separate instructions. Signed-off-by: Fabrizio Castro Reviewed-by: Guenter Roeck --- v1->v2: * Added changelog as suggested by Guenter Roeck drivers/watchdog/renesas_wdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c index 0d74c3e..b570962 100644 --- a/drivers/watchdog/renesas_wdt.c +++ b/drivers/watchdog/renesas_wdt.c @@ -220,8 +220,8 @@ static int rwdt_probe(struct platform_device *pdev) goto out_pm_disable; } - priv->wdev.info = _ident, - priv->wdev.ops = _ops, + priv->wdev.info = _ident; + priv->wdev.ops = _ops; priv->wdev.parent = >dev; priv->wdev.min_timeout = 1; priv->wdev.max_timeout = DIV_BY_CLKS_PER_SEC(priv, 65536); -- 2.7.4
Re: [PATCH 2/2] clk: renesas: rcar-gen3: add HS400 quirk for SD clock
Hi Niklas,
Thanks for your patch!
On Thu, Nov 1, 2018 at 12:26 AM Niklas Söderlund
wrote:
> From: Niklas Söderlund
>
> On H3 (ES1.0,ES2.0) and M3-W (ES1.0,ES1.1) the clock setting for HS400
H3 (ES1.x, ES2.0) and M3-W (ES1.0, ES1.1)
> needs a quirk to function properly. The reason for the quirk is that
> there are two settings which produces same divider vale for the SDn
> clock. On the effected boards the one currently selected results in HS00
HS200 or HS400?
> not working.
>
> This change uses the same method as the Gen2 CPG driver and simply
> ignores the first clock setting as this is the offending one when
> selecting the settings. Which of the two possible settings is used have
> no effect for SDR104.
>
> Signed-off-by: Niklas Söderlund
> ---
> drivers/clk/renesas/rcar-gen3-cpg.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c
> b/drivers/clk/renesas/rcar-gen3-cpg.c
> index ff56ac6134111c38..8cc524a29c855dd2 100644
> --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
> @@ -227,6 +227,7 @@ struct sd_clock {
> unsigned int div_min;
> unsigned int div_max;
> unsigned int cur_div_idx;
> + bool skip_first;
I think you can do without adding this field...
> };
>
> /* SDn divider
> @@ -243,6 +244,10 @@ struct sd_clock {
> * 1 0 2 (4) 0 (2) 8
> * 1 0 3 (8) 0 (2) 16
> * 1 0 4 (16) 0 (2) 32
> + *
> + * NOTE: There is a quirk option to ignore the first row of the dividers
> + * table when searching for suitable settings. This is because HS400 on
> + * early ES versions of H3 and M3-W requires a specific setting to work.
> */
> static const struct sd_div_table cpg_sd_div_table[] = {
> /* CPG_SD_DIV_TABLE_DATA(stp_hck, stp_ck, sd_srcfc, sd_fc, sd_div)
> */
> @@ -327,7 +332,7 @@ static int cpg_sd_clock_set_rate(struct clk_hw *hw,
> unsigned long rate,
> u32 val;
> unsigned int i;
>
> - for (i = 0; i < clock->div_num; i++)
> + for (i = clock->skip_first ? 1 : 0; i < clock->div_num; i++)
... and without this change (see below)
> if (div == clock->div_table[i].div)
> break;
>
> @@ -355,7 +360,7 @@ static const struct clk_ops cpg_sd_clock_ops = {
>
> static struct clk * __init cpg_sd_clk_register(const struct cpg_core_clk
> *core,
> void __iomem *base, const char *parent_name,
> - struct raw_notifier_head *notifiers)
> + struct raw_notifier_head *notifiers, bool skip_first)
I think you can do without adding this parameter.
> {
> struct clk_init_data init;
> struct sd_clock *clock;
> @@ -377,6 +382,7 @@ static struct clk * __init cpg_sd_clk_register(const
> struct cpg_core_clk *core,
> clock->hw.init =
> clock->div_table = cpg_sd_div_table;
> clock->div_num = ARRAY_SIZE(cpg_sd_div_table);
> + clock->skip_first = skip_first;
What about
if (cpg_quirks & SD_SKIP_FIRST) {
clock->div_table++;
clock->div_num--;
}
instead?
It does require moving cpg_quirks and the quirk definitions up, but reduces
the actual code change, and makes the code easier to follow.
>
> sd_fc = readl(clock->csn.reg) & CPG_SD_FC_MASK;
> for (i = 0; i < clock->div_num; i++)
> @@ -417,19 +423,28 @@ static u32 cpg_quirks __initdata;
>
> #define PLL_ERRATA BIT(0) /* Missing PLL0/2/4 post-divider */
> #define RCKCR_CKSELBIT(1) /* Manual RCLK parent selection */
> +#define SD_SKIP_FIRST BIT(2) /* Skip first clock in SD table */
>
> static const struct soc_device_attribute cpg_quirks_match[] __initconst = {
> {
> .soc_id = "r8a7795", .revision = "ES1.0",
> - .data = (void *)(PLL_ERRATA | RCKCR_CKSEL),
> + .data = (void *)(PLL_ERRATA | RCKCR_CKSEL | SD_SKIP_FIRST),
> },
> {
> .soc_id = "r8a7795", .revision = "ES1.*",
> - .data = (void *)RCKCR_CKSEL,
> + .data = (void *)(RCKCR_CKSEL | SD_SKIP_FIRST),
> + },
> + {
> + .soc_id = "r8a7795", .revision = "ES2.0",
> + .data = (void *)SD_SKIP_FIRST,
> },
> {
> .soc_id = "r8a7796", .revision = "ES1.0",
> - .data = (void *)RCKCR_CKSEL,
> + .data = (void *)(RCKCR_CKSEL | SD_SKIP_FIRST),
> + },
> + {
> + .soc_id = "r8a7796", .revision = "ES1.1",
> + .data = (void *)SD_SKIP_FIRST,
> },
> { /* sentinel */ }
> };
> @@ -504,7 +519,8 @@ struct clk * __init rcar_gen3_cpg_clk_register(struct
> device *dev,
>
> case CLK_TYPE_GEN3_SD:
> return cpg_sd_clk_register(core, base, __clk_get_name(parent),
> -
RE: [PATCH] watchdog: renesas_wdt: Fix typos
> Subject: Re: [PATCH] watchdog: renesas_wdt: Fix typos > > On Fri, Nov 02, 2018 at 07:21:11PM +, Fabrizio Castro wrote: > > Do not use "," but ";" to separate instructions. I agree, will send a v2 for this. Thanks, Fab > > > Signed-off-by: Fabrizio Castro > > Reviewed-by: Guenter Roeck > > > --- > > drivers/watchdog/renesas_wdt.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c > > index 0d74c3e..b570962 100644 > > --- a/drivers/watchdog/renesas_wdt.c > > +++ b/drivers/watchdog/renesas_wdt.c > > @@ -220,8 +220,8 @@ static int rwdt_probe(struct platform_device *pdev) > > goto out_pm_disable; > > } > > > > -priv->wdev.info = _ident, > > -priv->wdev.ops = _ops, > > +priv->wdev.info = _ident; > > +priv->wdev.ops = _ops; > > priv->wdev.parent = >dev; > > priv->wdev.min_timeout = 1; > > priv->wdev.max_timeout = DIV_BY_CLKS_PER_SEC(priv, 65536); > > -- > > 2.7.4 > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
Hi Simon,
On Wed, Oct 31, 2018 at 03:37:39PM +0100, Simon Horman wrote:
> On Wed, Oct 31, 2018 at 02:18:40PM +0100, jacopo mondi wrote:
> > Hi Simon,
> >
> > On Wed, Oct 31, 2018 at 01:48:13PM +0100, Simon Horman wrote:
> > > On Tue, Oct 30, 2018 at 02:57:59PM +0200, Laurent Pinchart wrote:
> > > > Hi Jacopo,
> > > >
> > > > On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi wrote:
> > > > > On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
> > > > > > On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> > > > > >> From: Koji Matsuoka
> > > > > >>
> > > > > >> Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990
> > > > > >> device
> > > > > >> tree.
> > > > > >>
> > > > > >> Signed-off-by: Koji Matsuoka
> > > > > >> Signed-off-by: Takeshi Kihara
> > > > > >> Signed-off-by: Jacopo Mondi
> > > > > >> ---
> > > > > >>
> > > > > >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> > > > > >>
> > > > > >> 1 file changed, 79 insertions(+)
> > > > > >>
> > > > > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > >> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe
> > > > > >> 100644
> > > > > >> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > >> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > >> @@ -337,6 +337,85 @@
> > > > > >>
> > > > > >>status = "disabled";
> > > > > >>
> > > > > >>};
> > > > > >>
> > > > > >> + csi40: csi2@feaa {
> > > > > >
> > > > > > I believe Simon would like to keep the nodes sorted by address
> > > > > >
> > > > > >> + compatible = "renesas,r8a77990-csi2",
> > > > > >> "renesas,rcar-gen3-csi2";
> > > > > >> + reg = <0 0xfeaa 0 0x1>;
> > > > > >
> > > > > > 0x1 seems pretty large to me.
> > > > >
> > > > > It seems to me that all Gen3 SoC have this lenght specified
> > > > >
> > > > > $git grep -A 10 'csi[2|4][0|1]: csi' arch/arm64/boot/dts/renesas/ |
> > > > > grep reg
> > > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfea8 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeab 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfea8 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfea8 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77970.dtsi- reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeab 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77990.dtsi- reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > >
> > > > > Am I missing something?
> > > >
> > > > Cargo-cult programming ? :-) This will likely not hurt, but such a large
> > > > memory area is not required, and we'll save a bit of memory if we
> > > > reduce the
> > > > mapping from 64kB to 4kB (or less)
> > >
> > > Can we please update this patch, and existing dtsi files,
> > > to use an appropriately small register window?
> > >
> >
> > What if we keep this one as it is and we change all the DTSIs in one
> > go?
>
> I would rather we correct this patch than add it with a known problem.
Sorry, I was confused. This patch is already in v4.20.
If we want to fix this, a single follow-up patch that changes the
memory area size for all SoCs is required.
Thanks
j
>
> >
> > > >
> > > > > > Apart from that,
> > > > >
> > > > > I will include the upporting of the following patch to fix the VIN
> > > > > endpoint numbering in forthcoming v3:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit
> > > > > /?id=1b1b73f7558d867d72e198901b84bec1e6ef1405
> > > > >
> > > > > As this has already been applied to simon's tree.
> > > > >
> > > > > > Reviewed-by: Laurent Pinchart
> > > > > >
> > > > > >> + interrupts = ;
> > > > > >> + clocks = < CPG_MOD 716>;
> > > > > >> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > > >> + resets = < 716>;
> > > > > >> + status = "disabled";
> > > > > >> +
> > > > > >> + ports {
> > > > > >> + #address-cells = <1>;
> > > > > >> + #size-cells = <0>;
> > > > > >> +
> > > > > >> + port@1 {
> > > > > >> + #address-cells = <1>;
> > > > > >> + #size-cells = <0>;
> > > > > >> +
> > > >
Re: [PATCH 1/2] clk: renesas: rcar-gen3: add documentation for SD clocks
Hi Wolfram,
On Thu, Nov 1, 2018 at 8:37 PM Wolfram Sang wrote:
> On Thu, Nov 01, 2018 at 12:25:17AM +0100, Niklas Söderlund wrote:
> > From: Niklas Söderlund
> >
> > Document the known use cases of the different clock settings. This is
> > useful as different SoC and ES versions uses different settings to do
> > the same thing as there are more then one combination to achieve the
> > same SDn clock speed.
> >
> > Signed-off-by: Niklas Söderlund
>
> Reviewed-by: Wolfram Sang
> Tested-by: Wolfram Sang
Is a Tested-by appropriate for a comment-only patch?
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] gpio: rcar: Request GPIO while enabling interrupt
Hi Fabrizio,
On Fri, Nov 2, 2018 at 8:10 PM Fabrizio Castro
wrote:
> There are cases when the bootloader configures a pin to work
> as a function rather than GPIO, and other cases when the pin
> is configured as a function at POR.
> This commit makes sure the pin is configured as a GPIO the
> moment we need it to work as an interrupt.
>
> Signed-off-by: Fabrizio Castro
> ---
> RFC->PATCH:
> * Moved gc->request to the bottom of gpio_rcar_irq_set_type
Thanks for the update!
> --- a/drivers/gpio/gpio-rcar.c
> +++ b/drivers/gpio/gpio-rcar.c
> @@ -147,6 +147,7 @@ static int gpio_rcar_irq_set_type(struct irq_data *d,
> unsigned int type)
> struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> struct gpio_rcar_priv *p = gpiochip_get_data(gc);
> unsigned int hwirq = irqd_to_hwirq(d);
> + int err;
>
> dev_dbg(>pdev->dev, "sense irq = %d, type = %d\n", hwirq, type);
>
> @@ -176,6 +177,13 @@ static int gpio_rcar_irq_set_type(struct irq_data *d,
> unsigned int type)
> default:
> return -EINVAL;
> }
> +
> + err = gc->request(gc, hwirq);
Call gpio_rcar_request() directly?
Where should the matching gpio_rcar_free() be called?
> + if (err) {
> + dev_err(>pdev->dev, "Can't request GPIO %d from %s\n",
> hwirq,
%u for unsigned int
> + gc->label);
> + return err;
> + }
> return 0;
> }
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: [RFC] gpio: rcar: Request GPIO before enabling interrupt
Hi Fabrizio,
On Fri, Nov 2, 2018 at 8:00 PM Fabrizio Castro
wrote:
> I am sorry for the delay of my answer, I was hoping others
> would jump in the discussion as well.
>
> > > + err = gc->request(gc, hwirq);
> >
> > This is done in some drivers when what you want is exactly
> > the work carried out by that callback. But can't you just call
> > gpio_rcar_request() directly in this case so it is clear that
> > the driver is meddling with the internal state of the hardware
> > and not really intending to loop out into the external
> > API or external callbacks?
>
> gpio_rcar_request is static unfortunately, maybe I should
> export the symbol?
I think Linus meant calling gpio_rcar_request() instead of gc->request()
from gpio_rcar_irq_set_type(), i.e. from the GPIO driver, not from the
HDMI driver. So static is fine.
> > You're not on one of these platforms that prefer setting up
> > the pin as GPIO using a pin control hog in the device tree?
>
> My personal preference would be to deal with this from
> within irqchip, as when you hook up a gpio as interrupt
> from the DT the kernel should do everything that's necessary
> to make it happen, but that is just a personal opinion.
> Anyway, I did give gpio-hog a try and it works for me.
Isn't the purpose of an input GPIO hog to configure the GPIO to not
drive the line, in the absence of any other driver with a need to read
the line value?
In this case there is another driver (via the interrupt subsystem), so using
an input GPIO doesn't look like the real solution to me.
> > Geert will know what is best.
People put way too much faith in me ;-)
> Yeah, I am really keen in hearing from him about this, in the meantime
> I went through a bunch of manuals, and moving the gpio request to the
> bottom of gpio_rcar_irq_set_type seems to be okay for RCar devices in
> general, but Geert knows definitely better.
Moving it down, after all other checks, is indeed better.
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: [RFC] gpio: rcar: Request GPIO before enabling interrupt
Hi Fabrizio,
On Fri, Oct 26, 2018 at 9:57 PM Fabrizio Castro
wrote:
> There are cases when the bootloader configures a pin to work
> as a function rather than GPIO, and other cases when the pin
> is configured as a function at POR.
> This commit makes sure the pin is configured as a GPIO the
> moment we need it to work as an interrupt.
>
> Signed-off-by: Fabrizio Castro
> ---
>
> Dear All,
>
> we have got some issues while trying to bring up the interrupt
> line of the HDMI transmitter on the iwg23s, as GP2_29 is configured
> as a function when the kernel starts, and therefore setting up the
> interrupt from the driver won't have the desired effect.
> This patch makes sure the pinctrl driver sets GP2[29] to GP-2-29
> before enabling the interrupt, but it doesn't addresses the
> "direction problem", as in the pin will be a GPIO after calling
> gc->request, but the direction would be whatever was previously
> configured. There could be the option of moving the additional
> code added by this patch to the bottom of function
> gpio_rcar_irq_set_type, but is that going to behave properly on
> every SoC this driver is supporting?
> Is configuring every gpio with direction input while probing
> something that should be looked into to reduce concerns over
> switching from function to GPIO?
Configuring everything to input may cause issues where a GPIO is connected
to the reset line of an external device, and where the bootloader configured the
line to deassert the reset.
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] watchdog: renesas_wdt: Fix typos
On Fri, Nov 2, 2018 at 8:48 PM Guenter Roeck wrote:
> On Fri, Nov 02, 2018 at 07:21:11PM +, Fabrizio Castro wrote:
>
> Do not use "," but ";" to separate instructions.
+1
Thanks, my eyes had a hard time finding out what had been changed ;-)
> > Signed-off-by: Fabrizio Castro
>
> Reviewed-by: Guenter Roeck
>
> > ---
> > drivers/watchdog/renesas_wdt.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> > index 0d74c3e..b570962 100644
> > --- a/drivers/watchdog/renesas_wdt.c
> > +++ b/drivers/watchdog/renesas_wdt.c
> > @@ -220,8 +220,8 @@ static int rwdt_probe(struct platform_device *pdev)
> > goto out_pm_disable;
> > }
> >
> > - priv->wdev.info = _ident,
> > - priv->wdev.ops = _ops,
> > + priv->wdev.info = _ident;
> > + priv->wdev.ops = _ops;
> > priv->wdev.parent = >dev;
> > priv->wdev.min_timeout = 1;
> > priv->wdev.max_timeout = DIV_BY_CLKS_PER_SEC(priv, 65536);
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: Fix does not have interrupts counting
Dear Niklas-san
On 2018/11/02 18:31, Niklas Söderlund wrote:
Hi Hoan-san,
Thanks for your patch.
On 2018-10-30 18:10:01 +0900, Nguyen An Hoan wrote:
From: Hoan Nguyen An
This patch fixes thermal interrupts that did not happen when temprature changed.
Add the function rcar_gen3_thermal_update_threshold(), this function is used to
calculate the value written to the threshold registers REG_GEN3_IRQTEMP1 and
REG_GEN3_IRQTEMP2.
Is it really a error if the IRQ don't happen and the thermal framework
use the .set_trip() callback to move the window due to the polling
instead of a IRQ due to a rapid thermal increase? I think not. I do not
like this patch but I'm not expert on thermal subsystem so I'm open to
be proven wrong :-)
I'm investigating more about this issue!
This patch is based on renesas-bsp/rcar-3.5.4.rc2 !
Signed-off-by: Hoan Nguyen An
---
drivers/thermal/rcar_gen3_thermal.c | 45 +
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/thermal/rcar_gen3_thermal.c
b/drivers/thermal/rcar_gen3_thermal.c
index 7aed533..009c0db 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -185,37 +185,39 @@ static int rcar_gen3_thermal_get_temp(void *devdata, int
*temp)
static int rcar_gen3_thermal_mcelsius_to_temp(struct rcar_gen3_thermal_tsc
*tsc,
int mcelsius)
{
- int celsius, val1, val2;
+ int val1, val2;
- celsius = DIV_ROUND_CLOSEST(mcelsius, 1000);
- val1 = celsius * tsc->coef.a1 + tsc->coef.b1;
- val2 = celsius * tsc->coef.a2 + tsc->coef.b2;
+ val1 = (mcelsius * tsc->coef.a1)/1000 + tsc->coef.b1;
+ val2 = (mcelsius * tsc->coef.a2)/1000 + tsc->coef.b2;
This won't work I'm afraid as it can overflow. As the thcodes and ptat
values can be read from hardware there theoretical max size is 0xfff
according to the documentation. Those values are then used to calculate
a1, b1, a2 and b2 constants. If you can prove that no overflow can
happen I'm happy for this change as it increases accuracy. If so this
should be posted as a separate patch.
With this patch, when rcar_gen3_thermal_mcelsius_to_temp () is called,
since the mcelsius value was passed is calculated from the previous formula:
rcar_gen3_thermal_get_temp():
int mcelsius, val1, val2;
u32 reg;
/* Read register and convert to mili Celsius */
reg = rcar_gen3_thermal_read(tsc, REG_GEN3_TEMP) & CTEMP_MASK;
val1 = FIXPT_DIV(FIXPT_INT(reg) - tsc->coef.b1, tsc->coef.a1);
val2 = FIXPT_DIV(FIXPT_INT(reg) - tsc->coef.b2, tsc->coef.a2);
mcelsius = FIXPT_TO_MCELSIUS((val1 + val2) / 2);
/* Make sure we are inside specifications */
if ((mcelsius < MCELSIUS(-40)) || (mcelsius > MCELSIUS(125)))
return -EIO;
From int mcelsius values, val1, val2;
The reverse calculation I do not think will happen the overflow!
With the current situation, I am not clear about the high, low values
But with (a1, b1), (a2, b2)
tsc1->coef.a1 965 tsc1->coef.a2 953 tsc1->coef.b1 323853 tsc1->coef.b2
324268
tsc2->coef.a1 965 tsc2->coef.a2 954 tsc2->coef.b1 323213 tsc2->coef.b2
323640
tsc3->coef.a1 947 tsc3->coef.a2 932 tsc3->coef.b1 325163 tsc3->coef.b2
325680
with all tscX, aX <=1000.
If the temperature is 1000celsius = 100 mcelsius.
val1 <100 * 1000 + 323853 = 1 000 323 853 <2 147 483 647 (max int value)
(In fact the temperature of the board could not get to 1000 celsius
degrees )
Here the current constant values are used.
But at future THCODE and PLAT values are read from registers
to calculate aX, bX, I do not know whether there really will be overflow
or not.
If you use this patches without this part.
I have received incorrect interrupts with H3ES1.1.
So I need to integrate this part to ensure correctly in testing.
return INT_FIXPT((val1 + val2) / 2);
}
-static int rcar_gen3_thermal_set_trips(void *devdata, int low, int high)
+static int rcar_gen3_thermal_update_threshold(struct rcar_gen3_thermal_tsc
*tsc)
{
- struct rcar_gen3_thermal_tsc *tsc = devdata;
-
- low = clamp_val(low, -4, 12);
- high = clamp_val(high, -4, 12);
-
- rcar_gen3_thermal_write(tsc, REG_GEN3_IRQTEMP1,
- rcar_gen3_thermal_mcelsius_to_temp(tsc, low));
+ u32 ctemp;
+ int temp_code;
+ int mcelsius, val1, val2;
- rcar_gen3_thermal_write(tsc, REG_GEN3_IRQTEMP2,
- rcar_gen3_thermal_mcelsius_to_temp(tsc, high));
+ ctemp = rcar_gen3_thermal_read(tsc, REG_GEN3_TEMP) & CTEMP_MASK;
+ val1 = FIXPT_DIV(FIXPT_INT(ctemp) - tsc->coef.b1, tsc->coef.a1);
+ val2 = FIXPT_DIV(FIXPT_INT(ctemp) - tsc->coef.b2, tsc->coef.a2);
+ mcelsius = FIXPT_TO_MCELSIUS((val1 + val2) / 2);
- tsc->low = low;
- tsc->high = high;
+ /* set the interrupts to exceed the temperature */
+ temp_code =
Re: [PATCH/RFT] arm64: dts: renesas: r8a77990: Add I2C-DVFS device node
Hi Kaneko-san,
On Sat, Oct 20, 2018 at 11:35 PM Yoshihiro Kaneko wrote:
> From: Takeshi Kihara
>
> This patch adds I2C-DVFS device node for the R8A77990 SoC.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Yoshihiro Kaneko
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -22,7 +22,8 @@
> i2c4 =
> i2c5 =
> i2c6 =
> - i2c7 =
> + i2c7 = _dvfs;
> + i2c8 =
Please don't change existing aliases.
While this makes the use of i2c7 for PMIC access uniform across the
range of R-Car Gen3 SoCs that have it, I think this is a bad idea, and that
it is better not to rely on I2C aliases at all.
I guess the BSP did this to configure the BD9571 PMIC for DDR backup
mode using i2cset? Upstream has another method, avoiding the need for
i2cset, cfr. Documentation/ABI/testing/sysfs-driver-bd9571mwv-regulator.
> };
>
> cpus {
> @@ -337,6 +338,22 @@
> reg = <0 0xe606 0 0x508>;
> };
>
> + i2c_dvfs: i2c@e60b {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,iic-r8a77990",
"renesas,iic-r8a77990" is not yet documented.
> +"renesas,rcar-gen3-iic",
> +"renesas,rmobile-iic";
Also, IIC on R-Car E3 does not have the automatic transmission registers.
Does this affect claiming compatibility with the family-specific or generic
compatible values?
> + reg = <0 0xe60b 0 0x34>;
Why 0x34? Last (byte-sized) register documented is at 0x14 => 0x15?
> + interrupts = ;
> + clocks = < CPG_MOD 926>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 926>;
> + dmas = < 0x11>, < 0x10>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
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
