RE: [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
Hello! > From: Sergei Shtylyov > Sent: Thursday, September 14, 2017 1:02 AM > > Hello! > > On 09/13/2017 03:17 PM, Yoshihiro Shimoda wrote: > > > Add a new compatible string for the R8A77995 (R-Car D3) RAVB. > > > > Signed-off-by: Yoshihiro Shimoda > > --- > > Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt > b/Documentation/devicetree/bindings/net/renesas,ravb.txt > > index 1672353..ae2213f 100644 > > --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt > > +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt > > @@ -17,6 +17,7 @@ Required properties: > > > > - "renesas,etheravb-r8a7795" for the R8A7795 SoC. > > - "renesas,etheravb-r8a7796" for the R8A7796 SoC. > > + - "renesas,etheravb-r8a77995" for the R8A77995 SoC. > > That would conflict with the R8A77970 bindings patch posted by me > yesterday. Please respin atop of it. Yes, I submitted v2 patch now. > > - "renesas,etheravb-rcar-gen3" as a fallback for the above > > R-Car Gen3 devices. > > > > One more fragment is needed here, about the mandatory 'interrupt-names" > prop. My patch makes this change unnecessary, however... I understood it. Best regards, Yoshihiro Shimoda > MBR, Sergei
[PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
Add a new compatible string for the R8A77995 (R-Car D3) RAVB. Acked-by: Geert Uytterhoeven Signed-off-by: Yoshihiro Shimoda --- Changes from v1: - Based on r8a77970 patch. https://marc.info/?l=linux-renesas-soc&m=150524655515476 - Add Acked-by (Thanks Geert-san!). Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 2689211..c902261 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -18,6 +18,7 @@ Required properties: - "renesas,etheravb-r8a7795" for the R8A7795 SoC. - "renesas,etheravb-r8a7796" for the R8A7796 SoC. - "renesas,etheravb-r8a77970" for the R8A77970 SoC. + - "renesas,etheravb-r8a77995" for the R8A77995 SoC. - "renesas,etheravb-rcar-gen3" as a fallback for the above R-Car Gen3 devices. -- 1.9.1
RE: [PATCH 2/2] arm64: dts: renesas: r8a77995: draak: enable EthernetAVB
Hi Geert-san,
> From: Geert Uytterhoeven
> Sent: Wednesday, September 13, 2017 11:55 PM
>
> Hi Shimoda-san,
>
> On Wed, Sep 13, 2017 at 2:18 PM, Yoshihiro Shimoda
> wrote:
> > This patch enables EthernetAVB for R-Car D3 draak board.
> >
> > Signed-off-by: Yoshihiro Shimoda
>
> Thanks for your patch!
>
> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
>
> > @@ -37,6 +39,14 @@
> > };
> >
> > &pfc {
> > + avb0_pins: avb {
> > + mux {
> > + groups = "avb0_link", "avb0_phy_int", "avb0_mdc",
> > +"avb0_mii";
> > + function = "avb0";
>
> This part depends on (an updated version of) "[PATCH 5/8] pinctrl: sh-pfc:
> r8a77995: Add EthernetAVB pins, groups and functions", so it may change?
Oops, I fotgot to submit v2 PFC patch yesterday...
Yes, it is changed like other gen3 SoCs. I submitted it now.
> And we will probably have to add driver-strengths later, to avoid a
> dependency on bootloader setup?
Yes, I will do so, if needed.
> Apart from that:
> Reviewed-by: Geert Uytterhoeven
Thank you for your review!
Best regards,
Yoshihiro Shimoda
> 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] pinctrl: sh-pfc: r8a77995: Add EthernetAVB pins, groups and functions
Signed-off-by: Yoshihiro Shimoda
---
About AVB'0', I don't get any feedback from HW team... So, I'd like to follow
the current PFC section in the manual.
Changes from v1:
- Changes the groups like other SoCs (r8a7795 and r8a7796).
drivers/pinctrl/sh-pfc/pfc-r8a77995.c | 119 ++
1 file changed, 119 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
index 4f5ee1d..0e803e9 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
@@ -936,6 +936,99 @@ enum {
PINMUX_GPIO_GP_ALL(),
};
+/* - EtherAVB ---
*/
+static const unsigned int avb0_link_pins[] = {
+ /* AVB0_LINK */
+ RCAR_GP_PIN(5, 20),
+};
+static const unsigned int avb0_link_mux[] = {
+ AVB0_LINK_MARK,
+};
+static const unsigned int avb0_magic_pins[] = {
+ /* AVB0_MAGIC */
+ RCAR_GP_PIN(5, 18),
+};
+static const unsigned int avb0_magic_mux[] = {
+ AVB0_MAGIC_MARK,
+};
+static const unsigned int avb0_phy_int_pins[] = {
+ /* AVB0_PHY_INT */
+ RCAR_GP_PIN(5, 19),
+};
+static const unsigned int avb0_phy_int_mux[] = {
+ AVB0_PHY_INT_MARK,
+};
+static const unsigned int avb0_mdc_pins[] = {
+ /* AVB0_MDC, AVB_MDIO */
+ RCAR_GP_PIN(5, 17), RCAR_GP_PIN(5, 16),
+};
+static const unsigned int avb0_mdc_mux[] = {
+ AVB0_MDC_MARK, AVB0_MDIO_MARK,
+};
+static const unsigned int avb0_mii_pins[] = {
+ /*
+* AVB0_TX_CTL, AVB0_TXC, AVB0_TD0,
+* AVB0_TD1, AVB0_TD2, AVB0_TD3,
+* AVB0_RX_CTL, AVB0_RXC, AVB0_RD0,
+* AVB0_RD1, AVB0_RD2, AVB0_RD3,
+* AVB0_TXCREFCLK
+*/
+ RCAR_GP_PIN(5, 9), RCAR_GP_PIN(5, 10), RCAR_GP_PIN(5, 11),
+ RCAR_GP_PIN(5, 12), RCAR_GP_PIN(5, 13), RCAR_GP_PIN(5, 14),
+ RCAR_GP_PIN(5, 3), RCAR_GP_PIN(5, 4), RCAR_GP_PIN(5, 5),
+ RCAR_GP_PIN(5, 6), RCAR_GP_PIN(5, 7), RCAR_GP_PIN(5, 8),
+ RCAR_GP_PIN(5, 15),
+};
+static const unsigned int avb0_mii_mux[] = {
+ AVB0_TX_CTL_MARK, AVB0_TXC_MARK, AVB0_TD0_MARK,
+ AVB0_TD1_MARK, AVB0_TD2_MARK, AVB0_TD3_MARK,
+ AVB0_RX_CTL_MARK, AVB0_RXC_MARK, AVB0_RD0_MARK,
+ AVB0_RD1_MARK, AVB0_RD2_MARK, AVB0_RD3_MARK,
+ AVB0_TXCREFCLK_MARK,
+};
+static const unsigned int avb0_avtp_pps_a_pins[] = {
+ /* AVB0_AVTP_PPS_A */
+ RCAR_GP_PIN(5, 2),
+};
+static const unsigned int avb0_avtp_pps_a_mux[] = {
+ AVB0_AVTP_PPS_A_MARK,
+};
+static const unsigned int avb0_avtp_match_a_pins[] = {
+ /* AVB0_AVTP_MATCH_A */
+ RCAR_GP_PIN(5, 1),
+};
+static const unsigned int avb0_avtp_match_a_mux[] = {
+ AVB0_AVTP_MATCH_A_MARK,
+};
+static const unsigned int avb0_avtp_capture_a_pins[] = {
+ /* AVB0_AVTP_CAPTURE_A */
+ RCAR_GP_PIN(5, 0),
+};
+static const unsigned int avb0_avtp_capture_a_mux[] = {
+ AVB0_AVTP_CAPTURE_A_MARK,
+};
+static const unsigned int avb0_avtp_pps_b_pins[] = {
+ /* AVB0_AVTP_PPS_B */
+ RCAR_GP_PIN(4, 16),
+};
+static const unsigned int avb0_avtp_pps_b_mux[] = {
+ AVB0_AVTP_PPS_B_MARK,
+};
+static const unsigned int avb0_avtp_match_b_pins[] = {
+ /* AVB0_AVTP_MATCH_B */
+ RCAR_GP_PIN(4, 18),
+};
+static const unsigned int avb0_avtp_match_b_mux[] = {
+ AVB0_AVTP_MATCH_B_MARK,
+};
+static const unsigned int avb0_avtp_capture_b_pins[] = {
+ /* AVB0_AVTP_CAPTURE_B */
+ RCAR_GP_PIN(4, 17),
+};
+static const unsigned int avb0_avtp_capture_b_mux[] = {
+ AVB0_AVTP_CAPTURE_B_MARK,
+};
+
/* - I2C
*/
static const unsigned int i2c0_pins[] = {
/* SCL, SDA */
@@ -1203,6 +1296,17 @@ enum {
};
static const struct sh_pfc_pin_group pinmux_groups[] = {
+ SH_PFC_PIN_GROUP(avb0_link),
+ SH_PFC_PIN_GROUP(avb0_magic),
+ SH_PFC_PIN_GROUP(avb0_phy_int),
+ SH_PFC_PIN_GROUP(avb0_mdc),
+ SH_PFC_PIN_GROUP(avb0_mii),
+ SH_PFC_PIN_GROUP(avb0_avtp_pps_a),
+ SH_PFC_PIN_GROUP(avb0_avtp_match_a),
+ SH_PFC_PIN_GROUP(avb0_avtp_capture_a),
+ SH_PFC_PIN_GROUP(avb0_avtp_pps_b),
+ SH_PFC_PIN_GROUP(avb0_avtp_match_b),
+ SH_PFC_PIN_GROUP(avb0_avtp_capture_b),
SH_PFC_PIN_GROUP(i2c0),
SH_PFC_PIN_GROUP(i2c1),
SH_PFC_PIN_GROUP(i2c2_a),
@@ -1240,6 +1344,20 @@ enum {
SH_PFC_PIN_GROUP(scif_clk),
};
+static const char * const avb0_groups[] = {
+ "avb0_link",
+ "avb0_magic",
+ "avb0_phy_int",
+ "avb0_mdc",
+ "avb0_mii",
+ "avb0_avtp_pps_a",
+ "avb0_avtp_match_a",
+ "avb0_avtp_capture_a",
+ "avb0_avtp_pps_b",
+ "avb0_avtp_match_b",
+ "avb0_avtp_capture_b",
+};
+
static const char * const i2c0_groups[] = {
"i2c0",
};
@@ -1311,6 +1429,7 @@ enum {
};
static const struct sh_pfc_function pinmux_functions[] = {
+ SH_PFC_FUNCTION(a
Re: [PATCH v2] net: smsc911x: Quieten netif during suspend
On 09/13/2017 10:42 AM, Geert Uytterhoeven wrote:
> If the network interface is kept running during suspend, the net core
> may call net_device_ops.ndo_start_xmit() while the Ethernet device is
> still suspended, which may lead to a system crash.
>
> E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is
> driven by a PM controlled clock. If the Ethernet registers are accessed
> while the clock is not running, the system will crash with an imprecise
> external abort.
>
> As this is a race condition with a small time window, it is not so easy
> to trigger at will. Using pm_test may increase your chances:
>
> # echo 0 > /sys/module/printk/parameters/console_suspend
> # echo platform > /sys/power/pm_test
> # echo mem > /sys/power/state
>
> To fix this, make sure the network interface is quietened during
> suspend.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Florian Fainelli
You may want to take the opportunity to suspend the PHY device
(conversely resume it) if WoL is not enabled on this device.
Thanks!
> ---
> This is v2 of the series "[PATCH 0/2] net: Fix crashes due to activity
> during suspend", which degenerated into a single patch after commit
> ebc8254aeae34226 ("Revert "net: phy: Correctly process PHY_HALTED in
> phy_stop_machine()"") made "[PATCH 1/2] net: phy: Freeze PHY polling before
> suspending devices" no longer needed.
>
> v2:
> - Spelling s/quit/quiet/g.
>
> No stacktrace is provided, as the imprecise external abort is usually
> reported from an innocent looking and unrelated function like
> __loop_delay(), cpu_idle_poll(), or arch_timer_read_counter_long().
> ---
> drivers/net/ethernet/smsc/smsc911x.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/smsc/smsc911x.c
> b/drivers/net/ethernet/smsc/smsc911x.c
> index 0b6a39b003a4e188..012fb66eed8dd618 100644
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
> @@ -2595,6 +2595,11 @@ static int smsc911x_suspend(struct device *dev)
> struct net_device *ndev = dev_get_drvdata(dev);
> struct smsc911x_data *pdata = netdev_priv(ndev);
>
> + if (netif_running(ndev)) {
> + netif_stop_queue(ndev);
> + netif_device_detach(ndev);
> + }
> +
> /* enable wake on LAN, energy detection and the external PME
>* signal. */
> smsc911x_reg_write(pdata, PMT_CTRL,
> @@ -2628,7 +2633,15 @@ static int smsc911x_resume(struct device *dev)
> while (!(smsc911x_reg_read(pdata, PMT_CTRL) & PMT_CTRL_READY_) && --to)
> udelay(1000);
>
> - return (to == 0) ? -EIO : 0;
> + if (to == 0)
> + return -EIO;
> +
> + if (netif_running(ndev)) {
> + netif_device_attach(ndev);
> + netif_start_queue(ndev);
> + }
> +
> + return 0;
> }
>
> static const struct dev_pm_ops smsc911x_pm_ops = {
>
--
Florian
Re: [PATCH/RFC 2/3] i2c: gpio: Add support for named gpios in DT
On Wed, Sep 13, 2017 at 10:53:33PM +0200, Wolfram Sang wrote: > > > + /* Try deprecated unnamed gpios */ > > I think adding "(deprecated use)" or sth would be good. Where is my brown paper bag :) signature.asc Description: PGP signature
Re: [PATCH/RFC 2/3] i2c: gpio: Add support for named gpios in DT
> + /* Try deprecated unnamed gpios */ I think adding "(deprecated use)" or sth would be good. signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS: review Renesas DT bindings as well
From: Sergei Shtylyov
Date: Wed, 13 Sep 2017 22:28:53 +0300
> When adding myself as a reviewer for the Renesas Ethernet drivers
> I somehow forgot about the bindings -- I want to review them as well.
>
> Fixes: 8e6569af3a1b ("MAINTAINERS: add myself as Renesas Ethernet drivers
> reviewer")
> Signed-off-by: Sergei Shtylyov
Applied.
[PATCH] MAINTAINERS: review Renesas DT bindings as well
When adding myself as a reviewer for the Renesas Ethernet drivers
I somehow forgot about the bindings -- I want to review them as well.
Fixes: 8e6569af3a1b ("MAINTAINERS: add myself as Renesas Ethernet drivers
reviewer")
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net.git' repo.
MAINTAINERS |2 ++
1 file changed, 2 insertions(+)
Index: net/MAINTAINERS
===
--- net.orig/MAINTAINERS
+++ net/MAINTAINERS
@@ -11379,6 +11379,8 @@ RENESAS ETHERNET DRIVERS
R: Sergei Shtylyov
L: net...@vger.kernel.org
L: linux-renesas-soc@vger.kernel.org
+F: Documentation/devicetree/bindings/net/renesas,*.txt
+F: Documentation/devicetree/bindings/net/sh_eth.txt
F: drivers/net/ethernet/renesas/
F: include/linux/sh_eth.h
Re: [PATCH] dt-bindings: qspi: Add r8a7743/5 to the compatible list
On Fri, Sep 08, 2017 at 09:07:15AM +0100, Fabrizio Castro wrote: > Signed-off-by: Fabrizio Castro > --- > Documentation/devicetree/bindings/spi/spi-rspi.txt | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Acked-by: Rob Herring
Re: [PATCH/RFC net-next] ravb: RX checksum offload
Hello!
On 09/12/2017 04:04 PM, Simon Horman wrote:
Add support for RX checksum offload. This is enabled by default and
may be disabled and re-enabled using ethtool:
# ethtool -K eth0 rx off
# ethtool -K eth0 rx on
The RAVB provides a simple checksumming scheme which appears to be
completely compatible with CHECKSUM_COMPLETE: a 1's complement sum of
Hm, the gen2/3 manuals say calculation doesn't involve bit inversion...
all packet data after the L2 header is appended to packet data; this may
be trivially read by the driver and used to update the skb accordingly.
>
In terms of performance throughput is close to gigabit line-rate both with
and without RX checksum offload enabled. Perf output, however, appears to
indicate that significantly less time is spent in do_csum(). This is as
expected.
[...]
By inspection this also appears to be compatible with the ravb found
on R-Car Gen 2 SoCs, however, this patch is currently untested on such
hardware.
I probably won't be able to test it on gen2 too...
Signed-off-by: Simon Horman
I'm generally OK with the patch but have some questions/comments below...
---
drivers/net/ethernet/renesas/ravb_main.c | 58 +++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index fdf30bfa403b..7c6438cd7de7 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
[...]
@@ -1842,6 +1859,41 @@ static int ravb_do_ioctl(struct net_device *ndev, struct
ifreq *req, int cmd)
return phy_mii_ioctl(phydev, req, cmd);
}
+static void ravb_set_rx_csum(struct net_device *ndev, bool enable)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->lock, flags);
+
+ /* Disable TX and RX */
+ ravb_rcv_snd_disable(ndev);
+
+ /* Modify RX Checksum setting */
+ if (enable)
+ ravb_modify(ndev, ECMR, 0, ECMR_RCSC);
Please use ECMR_RCSC as the 3rd argument too to conform the common driver
style.
+ else
+ ravb_modify(ndev, ECMR, ECMR_RCSC, 0);
This *if* can easily be folded into a single ravb_modify() call...
[...]
@@ -2004,6 +2057,9 @@ static int ravb_probe(struct platform_device *pdev)
if (!ndev)
return -ENOMEM;
+ ndev->features |= NETIF_F_RXCSUM;
+ ndev->hw_features |= ndev->features;
Hum, both fields are 0 before this? Then why not use '=' instead of '|='?
Even if not, why not just use the same value as both the rvalues?
[...]
MBR, Sergei
[PATCH v2] net: smsc911x: Quieten netif during suspend
If the network interface is kept running during suspend, the net core
may call net_device_ops.ndo_start_xmit() while the Ethernet device is
still suspended, which may lead to a system crash.
E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is
driven by a PM controlled clock. If the Ethernet registers are accessed
while the clock is not running, the system will crash with an imprecise
external abort.
As this is a race condition with a small time window, it is not so easy
to trigger at will. Using pm_test may increase your chances:
# echo 0 > /sys/module/printk/parameters/console_suspend
# echo platform > /sys/power/pm_test
# echo mem > /sys/power/state
To fix this, make sure the network interface is quietened during
suspend.
Signed-off-by: Geert Uytterhoeven
---
This is v2 of the series "[PATCH 0/2] net: Fix crashes due to activity
during suspend", which degenerated into a single patch after commit
ebc8254aeae34226 ("Revert "net: phy: Correctly process PHY_HALTED in
phy_stop_machine()"") made "[PATCH 1/2] net: phy: Freeze PHY polling before
suspending devices" no longer needed.
v2:
- Spelling s/quit/quiet/g.
No stacktrace is provided, as the imprecise external abort is usually
reported from an innocent looking and unrelated function like
__loop_delay(), cpu_idle_poll(), or arch_timer_read_counter_long().
---
drivers/net/ethernet/smsc/smsc911x.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 0b6a39b003a4e188..012fb66eed8dd618 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2595,6 +2595,11 @@ static int smsc911x_suspend(struct device *dev)
struct net_device *ndev = dev_get_drvdata(dev);
struct smsc911x_data *pdata = netdev_priv(ndev);
+ if (netif_running(ndev)) {
+ netif_stop_queue(ndev);
+ netif_device_detach(ndev);
+ }
+
/* enable wake on LAN, energy detection and the external PME
* signal. */
smsc911x_reg_write(pdata, PMT_CTRL,
@@ -2628,7 +2633,15 @@ static int smsc911x_resume(struct device *dev)
while (!(smsc911x_reg_read(pdata, PMT_CTRL) & PMT_CTRL_READY_) && --to)
udelay(1000);
- return (to == 0) ? -EIO : 0;
+ if (to == 0)
+ return -EIO;
+
+ if (netif_running(ndev)) {
+ netif_device_attach(ndev);
+ netif_start_queue(ndev);
+ }
+
+ return 0;
}
static const struct dev_pm_ops smsc911x_pm_ops = {
--
2.7.4
Re: [PATCH 0/2] net: Fix crashes due to activity during suspend
Hi Florian,
On Thu, Sep 7, 2017 at 3:09 PM, Florian Fainelli wrote:
> On 08/23/2017 10:13 AM, Florian Fainelli wrote:
>> On 08/23/2017 04:45 AM, Geert Uytterhoeven wrote:
>>> On Tue, Aug 22, 2017 at 8:49 PM, Florian Fainelli
>>> wrote:
On 08/22/2017 11:37 AM, Geert Uytterhoeven wrote:
> If an Ethernet device is used while the device is suspended, the system
> may
> crash.
>
> E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is
> driven by a PM controlled clock. If the Ethernet registers are accessed
> while the clock is not running, the system will crash with an imprecise
> external abort.
>
> This patch series fixes two of such crashes:
> 1. The first patch prevents the PHY polling state machine from accessing
> PHY registers while a device is suspended,
> 2. The second patch prevents the net core from trying to transmit
> packets
> when an smsc911x device is suspended.
>
> Both crashes can be reproduced on sh73a0/kzm9g and r8a73a4/ape6evm during
> s2ram (rarely), or by using pm_test (more likely to trigger):
>
> # echo 0 > /sys/module/printk/parameters/console_suspend
> # echo platform > /sys/power/pm_test
> # echo mem > /sys/power/state
>
> With this series applied, my test systems survive a loop of 100 test
> suspends.
It seems to me like part, if not the entire problem is that smsc91xx's
suspend and resume functions are way too simplistic and absolutely do
not manage the PHY during suspend/resume, the PHY state machine is not
even stopped, so of course, this will cause bus errors if you access
those registers.
You are addressing this as part of patch 2, but this seems to me like
this is still a bit incomplete and you'd need at least phy_stop() and/or
phy_suspend() (does a power down of the PHY) and phy_start() and/or
phy_resume() calls to complete the PHY state machine shutdown during
suspend.
Have you tried that?
>>>
>>> Unfortunately that doesn't help.
>>> In state PHY_HALTED, the PHY state machine still calls the .adjust_link()
>>> callback while the device is suspended.
>>
>> Humm that is correct yes.
>>
>>> Do you have a clue? This is too far beyond my phy-foo...
>>
>> I was initially contemplating a revert of
>> 7ad813f208533cebfcc32d3d7474dc1677d1b09a ("net: phy: Correctly process
>> PHY_HALTED in phy_stop_machine()") but this is not the root of the
>> problem. The problem really is that phy_stop() does not wait for the PHY
>> state machine to be stopped so you cannot rely on that and past the
>> function return be offered any guarantees that adjust_link is not called.
>>
>> We seem to be getting away with that in most drivers because when we see
>> phydev->link = 0, we either do nothing or actually turn of the HW block.
>>
>> How about we export phy_stop_machine() to drivers which would provide a
>> synchronization point that would ensure that no HW accesses are done
>> past this point?
>>
>> I am absolutely not clear on the implications of using a freezable
>> workqueue with respect to the PHY state machine and how devices are
>> going to wind-up being powered down or not...
>
> Geert, as you may have notice a revert of the change was sent so 4.13
> should be fine, but ultimately I would like to put the non-reverted code
> back in after we add a few safeguards:
With the revert, I no longer need "[PATCH 1/2] net: phy: Freeze PHY polling
before suspending devices".
I just did more than 50 successful suspend/resume cycles to verify that.
I still need "[PATCH 2/2] net: smsc911x: Quiten netif during suspend", so
I'll submit a v2 for that.
> - and you reported the bus errors on smsc911x when we call adjust_link
> during suspend, and due to a lack of hard synchronization so phy_stop()
> here does not give you enough guarantees to let you turn off power to
> the smsc911x block
>
> If that seems accurate then we can work on something that should be
> working again (famous last words).
Sounds accurate to me.
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 8/8] ARM: drs: iwg22m: Add SPI NOR support
From: Fabrizio Castro
Add support for the SPI NOR device used to boot up the system
to the System on Module DT.
Signed-off-by: Fabrizio Castro
Signed-off-by: Chris Paterson
---
This patch is based on renesas-devel-20170913-v4.13.
This patch is dependant on:
- "of: add vendor prefix for Silicon Storage Technology Inc."
- "doc: dt: mtd: Add sst25vf016b to the list of supported chip names"
arch/arm/boot/dts/r8a7745-iwg22m.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
index f7f9cef..ed9a8cf 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
+++ b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
@@ -39,6 +39,11 @@
function = "mmc";
};
+ qspi_pins: qspi {
+ groups = "qspi_ctrl", "qspi_data2";
+ function = "qspi";
+ };
+
sdhi1_pins: sd1 {
groups = "sdhi1_data4", "sdhi1_ctrl";
function = "sdhi1";
@@ -61,6 +66,27 @@
status = "okay";
};
+&qspi {
+ pinctrl-0 = <&qspi_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ /* WARNING - This device contains the bootloader. Handle with care. */
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "sst,sst25vf016b", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ m25p,fast-read;
+ spi-cpol;
+ spi-cpha;
+ };
+};
+
&sdhi1 {
pinctrl-0 = <&sdhi1_pins>;
pinctrl-names = "default";
--
1.9.1
[PATCH 2/8] ARM: dts: r8a7745: Add SDHI controllers
From: Fabrizio Castro
Add the SDHI controllers to the r8a7745 device tree.
Signed-off-by: Fabrizio Castro
Signed-off-by: Chris Paterson
---
This patch is based on renesas-devel-20170913-v4.13.
This patch is dependant on:
- "dt-bindings: mmc: sh_mmcif: Document r8a7745 DT bindings"
arch/arm/boot/dts/r8a7745.dtsi | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 8ed2ac5..37c0fac 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -751,6 +751,48 @@
max-frequency = <9750>;
status = "disabled";
};
+
+ sdhi0: sd@ee10 {
+ compatible = "renesas,sdhi-r8a7745";
+ reg = <0 0xee10 0 0x328>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 314>;
+ dmas = <&dmac0 0xcd>, <&dmac0 0xce>,
+ <&dmac1 0xcd>, <&dmac1 0xce>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <19500>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 314>;
+ status = "disabled";
+ };
+
+ sdhi1: sd@ee14 {
+ compatible = "renesas,sdhi-r8a7745";
+ reg = <0 0xee14 0 0x100>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 312>;
+ dmas = <&dmac0 0xc1>, <&dmac0 0xc2>,
+ <&dmac1 0xc1>, <&dmac1 0xc2>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <9750>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 312>;
+ status = "disabled";
+ };
+
+ sdhi2: sd@ee16 {
+ compatible = "renesas,sdhi-r8a7745";
+ reg = <0 0xee16 0 0x100>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 311>;
+ dmas = <&dmac0 0xd3>, <&dmac0 0xd4>,
+ <&dmac1 0xd3>, <&dmac1 0xd4>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <9750>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 311>;
+ status = "disabled";
+ };
};
/* External root clock */
--
1.9.1
[PATCH 3/8] ARM: dts: iwg22m: Enable SDHI1 controller
From: Fabrizio Castro
Enable the SDHI1 controller on iWave RZ/G1E SoM.
Signed-off-by: Fabrizio Castro
Signed-off-by: Chris Paterson
---
This patch is based on renesas-devel-20170913-v4.13.
arch/arm/boot/dts/r8a7745-iwg22m.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
index e306e7c..f7f9cef 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
+++ b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
@@ -9,6 +9,7 @@
*/
#include "r8a7745.dtsi"
+#include
/ {
compatible = "iwave,g22m", "renesas,r8a7745";
@@ -38,6 +39,12 @@
function = "mmc";
};
+ sdhi1_pins: sd1 {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <3300>;
+ };
+
i2c3_pins: i2c3 {
groups = "i2c3_b";
function = "i2c3";
@@ -54,6 +61,16 @@
status = "okay";
};
+&sdhi1 {
+ pinctrl-0 = <&sdhi1_pins>;
+ pinctrl-names = "default";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_3p3v>;
+ cd-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
&i2c3 {
pinctrl-0 = <&i2c3_pins>;
pinctrl-names = "default";
--
1.9.1
[PATCH 1/8] ARM: dts: r8a7745: Add APMU node and second CPU core
From: Fabrizio Castro
Add DT node for the Advanced Power Management Unit (APMU), add the
second CPU core, and use "renesas,apmu" as "enable-method".
Signed-off-by: Fabrizio Castro
Signed-off-by: Chris Paterson
---
This patch is based on renesas-devel-20170913-v4.13.
arch/arm/boot/dts/r8a7745.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 6e82991..8ed2ac5 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -30,6 +30,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "renesas,apmu";
cpu0: cpu@0 {
device_type = "cpu";
@@ -41,6 +42,15 @@
next-level-cache = <&L2_CA7>;
};
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <1>;
+ clock-frequency = <10>;
+ power-domains = <&sysc R8A7745_PD_CA7_CPU1>;
+ next-level-cache = <&L2_CA7>;
+ };
+
L2_CA7: cache-controller-0 {
compatible = "cache";
cache-unified;
@@ -57,6 +67,12 @@
#size-cells = <2>;
ranges;
+ apmu@e6151000 {
+ compatible = "renesas,r8a7745-apmu", "renesas,apmu";
+ reg = <0 0xe6151000 0 0x188>;
+ cpus = <&cpu0 &cpu1>;
+ };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
1.9.1
[PATCH 4/8] ARM: dts: iwg22d: Enable SDHI0 controller
From: Fabrizio Castro
Enable the SDHI0 controller on iWave RZ/G1E carrier board.
Signed-off-by: Fabrizio Castro
Signed-off-by: Chris Paterson
---
This patch is based on renesas-devel-20170913-v4.13.
arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 37 +
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
index aac84c6..c34dbe7 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
@@ -24,6 +24,19 @@
bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = "serial0:115200n8";
};
+
+ vccq_sdhi0: regulator-vccq-sdhi0 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI0 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
&pfc {
@@ -36,6 +49,18 @@
groups = "avb_mdio", "avb_gmii";
function = "avb";
};
+
+ 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>;
+ };
};
&scif4 {
@@ -63,3 +88,15 @@
micrel,led-mode = <1>;
};
};
+
+&sdhi0 {
+ pinctrl-0 = <&sdhi0_pins>;
+ pinctrl-1 = <&sdhi0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <&vccq_sdhi0>;
+ cd-gpios = <&gpio6 6 GPIO_ACTIVE_LOW>;
+ sd-uhs-sdr104;
+ status = "okay";
+};
--
1.9.1
[PATCH 6/8] ARM: dts: iwg20m: Add SPI NOR support
From: Fabrizio Castro
Add support for the SPI NOR device used to boot up the system
to the System on Module DT.
Signed-off-by: Fabrizio Castro
Signed-off-by: Chris Paterson
---
This patch is based on renesas-devel-20170913-v4.13.
This patch is dependant on:
- "of: add vendor prefix for Silicon Storage Technology Inc."
- "doc: dt: mtd: Add sst25vf016b to the list of supported chip names"
arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
index 4119737..75a8ca5 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
@@ -44,6 +44,11 @@
function = "mmc";
};
+ qspi_pins: qspi {
+ groups = "qspi_ctrl", "qspi_data2";
+ function = "qspi";
+ };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
@@ -61,6 +66,27 @@
status = "okay";
};
+&qspi {
+ pinctrl-0 = <&qspi_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ /* WARNING - This device contains the bootloader. Handle with care. */
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "sst,sst25vf016b", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ m25p,fast-read;
+ spi-cpol;
+ spi-cpha;
+ };
+};
+
&sdhi0 {
pinctrl-0 = <&sdhi0_pins>;
pinctrl-names = "default";
--
1.9.1
[PATCH 0/8] ARM: renesas: Latest r8a774[35] dts updates
This series contains multiple additions to the r8a774[35] device trees. I've bundled them into a series to help avoid merge issues due to multiple changes to the same files. Hopefully this doesn't add too much confusion! Kind regards, Chris Fabrizio Castro (8): ARM: dts: r8a7745: Add APMU node and second CPU core ARM: dts: r8a7745: Add SDHI controllers ARM: dts: iwg22m: Enable SDHI1 controller ARM: dts: iwg22d: Enable SDHI0 controller ARM: dts: r8a7743: Add QSPI support ARM: dts: iwg20m: Add SPI NOR support ARM: dts: r8a7745: Add QSPI support ARM: drs: iwg22m: Add SPI NOR support arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 26 ++ arch/arm/boot/dts/r8a7743.dtsi | 17 +++ arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 37 ++ arch/arm/boot/dts/r8a7745-iwg22m.dtsi | 43 + arch/arm/boot/dts/r8a7745.dtsi | 75 + 5 files changed, 198 insertions(+) -- 1.9.1
[PATCH 5/8] ARM: dts: r8a7743: Add QSPI support
From: Fabrizio Castro
Add the DT node for the QSPI interface to the SoC dtsi.
Signed-off-by: Fabrizio Castro
Signed-off-by: Chris Paterson
---
This patch is based on renesas-devel-20170913-v4.13.
This patch is dependant on:
- "dt-bindings: qspi: Add r8a7743/5 to the compatible list"
arch/arm/boot/dts/r8a7743.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 266c5ec..454f980 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -28,6 +28,7 @@
i2c6 = &iic0;
i2c7 = &iic1;
i2c8 = &iic3;
+ spi0 = &qspi;
};
cpus {
@@ -835,6 +836,22 @@
status = "disabled";
};
+ qspi: spi@e6b1 {
+ compatible = "renesas,qspi-r8a7743", "renesas,qspi";
+ reg = <0 0xe6b1 0 0x2c>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 917>;
+ dmas = <&dmac0 0x17>, <&dmac0 0x18>,
+ <&dmac1 0x17>, <&dmac1 0x18>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = <&cpg 917>;
+ status = "disabled";
+ };
+
sdhi0: sd@ee10 {
compatible = "renesas,sdhi-r8a7743";
reg = <0 0xee10 0 0x328>;
--
1.9.1
[PATCH 7/8] ARM: dts: r8a7745: Add QSPI support
From: Fabrizio Castro
Add the DT node for the QSPI interface to the SoC dtsi.
Signed-off-by: Fabrizio Castro
Signed-off-by: Chris Paterson
---
This patch is based on renesas-devel-20170913-v4.13.
This patch is dependant on:
- "dt-bindings: qspi: Add r8a7743/5 to the compatible list"
arch/arm/boot/dts/r8a7745.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 37c0fac..b819ec5 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -25,6 +25,7 @@
i2c3 = &i2c3;
i2c4 = &i2c4;
i2c5 = &i2c5;
+ spi0 = &qspi;
};
cpus {
@@ -752,6 +753,22 @@
status = "disabled";
};
+ qspi: spi@e6b1 {
+ compatible = "renesas,qspi-r8a7745", "renesas,qspi";
+ reg = <0 0xe6b1 0 0x2c>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 917>;
+ dmas = <&dmac0 0x17>, <&dmac0 0x18>,
+ <&dmac1 0x17>, <&dmac1 0x18>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = <&cpg 917>;
+ status = "disabled";
+ };
+
sdhi0: sd@ee10 {
compatible = "renesas,sdhi-r8a7745";
reg = <0 0xee10 0 0x328>;
--
1.9.1
Re: [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
On 09/13/2017 07:02 PM, Sergei Shtylyov wrote: Add a new compatible string for the R8A77995 (R-Car D3) RAVB. Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 1672353..ae2213f 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -17,6 +17,7 @@ Required properties: - "renesas,etheravb-r8a7795" for the R8A7795 SoC. - "renesas,etheravb-r8a7796" for the R8A7796 SoC. + - "renesas,etheravb-r8a77995" for the R8A77995 SoC. That would conflict with the R8A77970 bindings patch posted by me yesterday. Please respin atop of it. Here's the link for your convenience: https://marc.info/?l=linux-renesas-soc&m=150524655515476 [...] MBR, Sergei
Re: [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
Hello! On 09/13/2017 03:17 PM, Yoshihiro Shimoda wrote: Add a new compatible string for the R8A77995 (R-Car D3) RAVB. Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 1672353..ae2213f 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -17,6 +17,7 @@ Required properties: - "renesas,etheravb-r8a7795" for the R8A7795 SoC. - "renesas,etheravb-r8a7796" for the R8A7796 SoC. + - "renesas,etheravb-r8a77995" for the R8A77995 SoC. That would conflict with the R8A77970 bindings patch posted by me yesterday. Please respin atop of it. - "renesas,etheravb-rcar-gen3" as a fallback for the above R-Car Gen3 devices. One more fragment is needed here, about the mandatory 'interrupt-names" prop. My patch makes this change unnecessary, however... MBR, Sergei
Re: [PATCH LOCAL/RFC] arm64: defconfig: Add renesas_defconfig
Hi Simon,
On Wed, Sep 6, 2017 at 10:44 AM, Simon Horman wrote:
> On Tue, Sep 05, 2017 at 07:15:24PM +0200, Geert Uytterhoeven wrote:
>> Add a defconfig for Renesas R-Car Gen3 boards.
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> Not intended for upstream merge.
>>
>> Loosely based on arm64 defconfig, with support for non-Renesas SoCs and
>> boards removed, and missing support added.
>
> Thanks,
>
> this seems reasonable to me and I'm happy to maintain this driver,
> out of mainline, in a branch in the renesas tree - f.e. topic/defconfig.
>
> I am curious to know which tree you ran savedefconfig against.
> I tried renesas-devel-20170905-v4.13 and renesas-drivers-2017-09-05-v4.13
> but both seemed to generate a diff against the file created in your patch.
I used my current development tree, which is based on
renesas-drivers-2017-09-05-v4.13.
But I see no diff when running savedefconfig against the latter?
> I tested this defconfig against renesas-devel-20170905-v4.13 on
> a salvator-x/m3 ES1.0. It boots to user-space but I observed the following:
>
> [ 13.000428] sh-sci e6e88000.serial: dma_request_slave_channel failed
> [ 13.015167] sh-sci e6e88000.serial: dma_request_slave_channel failed
The scif2 node in r8a7796.dtsi doesn't have "dmas" properties.
These were removed from the datasheet, and scif2 has always been a bit
weird on R-Car Gen3...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/2] arm64: dts: renesas: r8a77995: draak: enable EthernetAVB
Hi Shimoda-san,
On Wed, Sep 13, 2017 at 2:18 PM, Yoshihiro Shimoda
wrote:
> This patch enables EthernetAVB for R-Car D3 draak board.
>
> Signed-off-by: Yoshihiro Shimoda
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -37,6 +39,14 @@
> };
>
> &pfc {
> + avb0_pins: avb {
> + mux {
> + groups = "avb0_link", "avb0_phy_int", "avb0_mdc",
> +"avb0_mii";
> + function = "avb0";
This part depends on (an updated version of) "[PATCH 5/8] pinctrl: sh-pfc:
r8a77995: Add EthernetAVB pins, groups and functions", so it may change?
And we will probably have to add driver-strengths later, to avoid a
dependency on bootloader setup?
Apart from that:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
On Wed, Sep 13, 2017 at 2:17 PM, Yoshihiro Shimoda
wrote:
> Add a new compatible string for the R8A77995 (R-Car D3) RAVB.
>
> Signed-off-by: Yoshihiro Shimoda
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] arm64: dts: renesas: r8a77995: Add EthernetAVB device node
On Wed, Sep 13, 2017 at 2:18 PM, Yoshihiro Shimoda
wrote:
> This patch adds EthernetAVB device node for r8a77995.
>
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 08/11] arm64: dts: renesas: r8a77970: add EtherAVB support
On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov
wrote:
> Define the generic R8A77970 part of the EtherAVB device node.
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> + power-domains = <&sysc R8A77970_PD_ALWAYS_ON>;
For now, you want to use "<&sysc 32>".
Apart from that:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 07/11] arm64: dts: renesas: r8a77970: add [H]SCIF support
Hi Sergei,
On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov
wrote:
> Describe [H]SCIF ports in the R8A77970 device tree.
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> @@ -170,5 +177,139 @@
> #dma-cells = <1>;
> dma-channels = <8>;
> };
> +
> + hscif0: serial@e654 {
> + compatible = "renesas,hscif-r8a77970",
> +"renesas,rcar-gen3-hscif",
> +"renesas,hscif";
> + reg = <0 0xe654 0 96>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 520>,
> +<&cpg CPG_CORE 9>,
> +<&scif_clk>;
> + clock-names = "fck", "brg_int", "scif_clk";
> + dmas = <&dmac1 0x31>, <&dmac1 0x30>;
> + dma-names = "tx", "rx";
The DMA channel numbers in Table 17.5 in the datasheet are a bit messed up
(it doesn't take into account that each V3M DMAC has only 8 channels,
while they have
16 on H3 and M3-W), but it looks like HSCIF[0-3] and SCIF[0134] can use both
dmac1 and dmac2.
So please add these (preferably after verifying the above is true).
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 06/11] arm64: dts: renesas: r8a77970: add SYS-DMAC support
On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov
wrote:
> Describe SYS-DMAC1/2 in the R8A77970 device tree.
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] thermal: rcar_gen3_thermal: fix initialization sequence for H3 ES2.0
Hi Geert,
Thanks for your feedback!
On 2017-09-13 15:37:31 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Wed, Sep 13, 2017 at 12:55 PM, Niklas Söderlund
> wrote:
> > The initialization sequence for H3 (r8a7795) ES1.x and ES2.0 is
> > different. H3 ES2.0 and later uses the same sequence as M3 (r8a7796)
> > ES1.0. Fix this by swapping place of the two initialization functions
> > and calling the r8a7796 init function from the r8a7795 init function if
> > the ES version is not "ES1.*".
> >
> > Signed-off-by: Niklas Söderlund
>
> Thanks for your patch!
>
> > --- a/drivers/thermal/rcar_gen3_thermal.c
> > +++ b/drivers/thermal/rcar_gen3_thermal.c
>
> > -static void r8a7796_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
> > +static void r8a7795_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
> > {
> > - u32 reg_val;
> > + /* H3 ES2.0 and later uses same initialization sequence as M3 ES1.0
> > */
>
> ... use the same ...
Thanks.
>
> > + if (!soc_device_match(r8a7795es1)) {
> > + r8a7796_thermal_init(tsc);
> > + return;
> > + }
>
> In general, I prefer soc_device_match() tests for pre-production SoCs to
> use positive tests, not negative tests. That makes it easier to drop the
> tests and the related code when support for these pre-production SoCs is
> dropped later.
Good point, I will update and send a v2.
>
> I.e.
>
> static void rcar_gen3_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
> {
> if (soc_device_match(r8a7795es1))
> return r8a7795es1_thermal_init(tsc);
>
> [... common init code ...]
> }
>
> Notes:
> - The above naming ("rcar_gen3_thermal_init") assumes other R-Car Gen3
> SoCs need the same initialization sequence.
> - Yes, you can call and return from a void function like that ;-)
>
> However, that still leaves the test in the .thermal_init() callback, so it
> will be evaluated multiple times, during probe and during each and every
> resume.
>
> You can avoid that by using a separate rcar_gen3_thermal_data structure for
> H3 ES1.x, and changing the probe function like:
>
> priv->data = of_device_get_match_data(dev);
> + if (soc_device_match(r8a7795es1))
> + priv->data = &r8a7795es_data;
This seems like the best option for v2 so will go with that.
>
> 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: [PATCH] thermal: rcar_gen3_thermal: fix initialization sequence for H3 ES2.0
Hi Niklas,
On Wed, Sep 13, 2017 at 12:55 PM, Niklas Söderlund
wrote:
> The initialization sequence for H3 (r8a7795) ES1.x and ES2.0 is
> different. H3 ES2.0 and later uses the same sequence as M3 (r8a7796)
> ES1.0. Fix this by swapping place of the two initialization functions
> and calling the r8a7796 init function from the r8a7795 init function if
> the ES version is not "ES1.*".
>
> Signed-off-by: Niklas Söderlund
Thanks for your patch!
> --- a/drivers/thermal/rcar_gen3_thermal.c
> +++ b/drivers/thermal/rcar_gen3_thermal.c
> -static void r8a7796_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
> +static void r8a7795_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
> {
> - u32 reg_val;
> + /* H3 ES2.0 and later uses same initialization sequence as M3 ES1.0 */
... use the same ...
> + if (!soc_device_match(r8a7795es1)) {
> + r8a7796_thermal_init(tsc);
> + return;
> + }
In general, I prefer soc_device_match() tests for pre-production SoCs to
use positive tests, not negative tests. That makes it easier to drop the
tests and the related code when support for these pre-production SoCs is
dropped later.
I.e.
static void rcar_gen3_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
{
if (soc_device_match(r8a7795es1))
return r8a7795es1_thermal_init(tsc);
[... common init code ...]
}
Notes:
- The above naming ("rcar_gen3_thermal_init") assumes other R-Car Gen3
SoCs need the same initialization sequence.
- Yes, you can call and return from a void function like that ;-)
However, that still leaves the test in the .thermal_init() callback, so it
will be evaluated multiple times, during probe and during each and every
resume.
You can avoid that by using a separate rcar_gen3_thermal_data structure for
H3 ES1.x, and changing the probe function like:
priv->data = of_device_get_match_data(dev);
+ if (soc_device_match(r8a7795es1))
+ priv->data = &r8a7795es_data;
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 05/11] arm64: dts: renesas: initial R8A77970 SoC device tree
On 09/13/2017 11:59 AM, Geert Uytterhoeven wrote:
The initial R8A77970 SoC device tree including Cortex-A53 CPU, GIC, timer,
CPG, RST, and SYSC.
Based on the original (and large) patch by Daisuke Matsushita
.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 126
++
1 file changed, 126 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
===
--- /dev/null
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -0,0 +1,126 @@
+/*
+ * Device Tree Source for the r8a77970 SoC
+ *
+ * Copyright (C) 2016-2017 Renesas Electronics Corp.
+ * Copyright (C) 2017 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+#include
arm-gic.h includes irq.h.
I prefer to explicitly #include what's needed, so I'd leave this alone if
you don't mind...
+#include
+#include
You can avoid the dependency on the above header, which will go upstream
through a different branch, by hardcoding the power area indices for the
initial submission, like you already did for the CPG core clocks.
OK.
+
+/ {
+ compatible = "renesas,r8a77970";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ psci {
+ compatible = "arm,psci-1.0";
PSCI 1.0 is backwards compatible with PSI 0.2:
compatible = "arm,psci-1.0", "arm,psci-0.2";
OK.
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
MBR, Sergei
[PATCH 2/2] arm64: dts: renesas: r8a77995: draak: enable EthernetAVB
This patch enables EthernetAVB for R-Car D3 draak board.
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 19c5462..9c5a790 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "r8a77995.dtsi"
+#include
/ {
model = "Renesas Draak board based on r8a77995";
@@ -18,6 +19,7 @@
aliases {
serial0 = &scif2;
+ ethernet0 = &avb;
};
chosen {
@@ -37,6 +39,14 @@
};
&pfc {
+ avb0_pins: avb {
+ mux {
+ groups = "avb0_link", "avb0_phy_int", "avb0_mdc",
+"avb0_mii";
+ function = "avb0";
+ };
+ };
+
scif2_pins: scif2 {
groups = "scif2_data";
function = "scif2";
@@ -44,6 +54,21 @@
};
+&avb {
+ pinctrl-0 = <&avb0_pins>;
+ pinctrl-names = "default";
+ renesas,no-ether-link;
+ phy-handle = <&phy0>;
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ rxc-skew-ps = <1500>;
+ reg = <0>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <19 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
&scif2 {
pinctrl-0 = <&scif2_pins>;
pinctrl-names = "default";
--
1.9.1
[PATCH 1/2] arm64: dts: renesas: r8a77995: Add EthernetAVB device node
This patch adds EthernetAVB device node for r8a77995.
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 45 +++
1 file changed, 45 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index d7756256..72d04d7 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -251,6 +251,51 @@
resets = <&cpg 906>;
};
+ avb: ethernet@e680 {
+ compatible = "renesas,etheravb-r8a77995",
+"renesas,etheravb-rcar-gen3";
+ reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ interrupt-names = "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14", "ch15",
+ "ch16", "ch17", "ch18", "ch19",
+ "ch20", "ch21", "ch22", "ch23",
+ "ch24";
+ clocks = <&cpg CPG_MOD 812>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 812>;
+ phy-mode = "rgmii-txid";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
scif2: serial@e6e88000 {
compatible = "renesas,scif-r8a77995",
"renesas,rcar-gen3-scif", "renesas,scif";
--
1.9.1
[PATCH 0/2] arm64: dts: renesas: r8a77995 and draak: add support EthernetAVB
This patch is based on the renesas-drivers.git / renesas-drivers-2017-09-05-v4.13 tag. Yoshihiro Shimoda (2): arm64: dts: renesas: r8a77995: Add EthernetAVB device node arm64: dts: renesas: r8a77995: draak: enable EthernetAVB arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 25 ++ arch/arm64/boot/dts/renesas/r8a77995.dtsi | 45 ++ 2 files changed, 70 insertions(+) -- 1.9.1
[PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
Add a new compatible string for the R8A77995 (R-Car D3) RAVB. Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 1672353..ae2213f 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -17,6 +17,7 @@ Required properties: - "renesas,etheravb-r8a7795" for the R8A7795 SoC. - "renesas,etheravb-r8a7796" for the R8A7796 SoC. + - "renesas,etheravb-r8a77995" for the R8A77995 SoC. - "renesas,etheravb-rcar-gen3" as a fallback for the above R-Car Gen3 devices. -- 1.9.1
RE: [PATCH] arm64: dts: renesas: r8a77995: add GPIO device nodes
Hi Geert-san,
> From: Geert Uytterhoeven
> Sent: Wednesday, September 13, 2017 8:48 PM
>
> Hi Shimoda-san,
>
> On Wed, Sep 13, 2017 at 11:35 AM, Yoshihiro Shimoda
> wrote:
> >> From: Geert Uytterhoeven
> >> Sent: Wednesday, September 13, 2017 6:22 PM
> >> On Wed, Sep 13, 2017 at 8:52 AM, Yoshihiro Shimoda
> >> wrote:
> >> > --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> >> > +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> >> > @@ -139,6 +139,118 @@
> >> > #power-domain-cells = <1>;
> >> > };
> >> >
> >> > + gpio0: gpio@e605 {
> >> > + compatible = "renesas,gpio-r8a77995",
> >> > +"renesas,rcar-gen3-gpio",
> >> > +"renesas,gpio-rcar";
> >> > + reg = <0 0xe605 0 0x50>;
> >> > + interrupts = ;
> >> > + #gpio-cells = <2>;
> >> > + gpio-controller;
> >> > + gpio-ranges = <&pfc 0 0 9>;
> >> > + #interrupt-cells = <2>;
> >> > + interrupt-controller;
> >> > + clocks = <&cpg CPG_MOD 912>;
> >> > + power-domains = <&cpg>;
> >>
> >> All nodes lack the power domain index (32, to be replaced by
> >> R8A77995_PD_ALWAYS_ON later):
> >>
> >> power-domains = <&sysc 32>;
> >
> > The r8a77995.dtsi file already uses R8A77995_PD_ALWAYS_ON in scif2 node.
>
> In my renesas-drivers it does.
> In Simon's renesas/devel it doesn't, as the R8A77995_PD_* definitions
> go upstream through a different branch than the DTS changes.
I understood it.
> > So, should I fix this patch like the following?
> >
> > power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
>
> For now you should use 32.
> However, as soon as Simon merges v4.14-rc1 into renesas/devel, you
> can start on using R8A77995_PD_ALWAYS_ON.
> As that is expected to happen this Monday, he can just postpone applying
> your updated patch until then, so I don't think there's a need to resend a
> version with hardcoded numbers.
I got it. So, I will not resend such version.
> For R-Car V3M it's different, as the definitions for that SoC won't appear
> in upstream for another full cycle, i.e. in v4.15-rc1 the earliest.
Thank you for the information. I got it.
Best regards,
Yoshihiro Shimoda
> 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: r8a77995: add GPIO device nodes
Hi Shimoda-san,
On Wed, Sep 13, 2017 at 11:35 AM, Yoshihiro Shimoda
wrote:
>> From: Geert Uytterhoeven
>> Sent: Wednesday, September 13, 2017 6:22 PM
>> On Wed, Sep 13, 2017 at 8:52 AM, Yoshihiro Shimoda
>> wrote:
>> > --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> > +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
>> > @@ -139,6 +139,118 @@
>> > #power-domain-cells = <1>;
>> > };
>> >
>> > + gpio0: gpio@e605 {
>> > + compatible = "renesas,gpio-r8a77995",
>> > +"renesas,rcar-gen3-gpio",
>> > +"renesas,gpio-rcar";
>> > + reg = <0 0xe605 0 0x50>;
>> > + interrupts = ;
>> > + #gpio-cells = <2>;
>> > + gpio-controller;
>> > + gpio-ranges = <&pfc 0 0 9>;
>> > + #interrupt-cells = <2>;
>> > + interrupt-controller;
>> > + clocks = <&cpg CPG_MOD 912>;
>> > + power-domains = <&cpg>;
>>
>> All nodes lack the power domain index (32, to be replaced by
>> R8A77995_PD_ALWAYS_ON later):
>>
>> power-domains = <&sysc 32>;
>
> The r8a77995.dtsi file already uses R8A77995_PD_ALWAYS_ON in scif2 node.
In my renesas-drivers it does.
In Simon's renesas/devel it doesn't, as the R8A77995_PD_* definitions
go upstream through a different branch than the DTS changes.
> So, should I fix this patch like the following?
>
> power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
For now you should use 32.
However, as soon as Simon merges v4.14-rc1 into renesas/devel, you
can start on using R8A77995_PD_ALWAYS_ON.
As that is expected to happen this Monday, he can just postpone applying
your updated patch until then, so I don't think there's a need to resend a
version with hardcoded numbers.
For R-Car V3M it's different, as the definitions for that SoC won't appear
in upstream for another full cycle, i.e. in v4.15-rc1 the earliest.
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 v3 6/9] v4l: vsp1: Refactor display list configure operations
The entities provide a single .configure operation which configures the
object into the target display list, based on the vsp1_entity_params
selection.
This restricts us to a single function prototype for both static
configuration (the pre-stream INIT stage) and the dynamic runtime stages
for both each frame - and each partition therein.
Split the configure function into two parts, '.prepare()' and
'.configure()', merging both the VSP1_ENTITY_PARAMS_RUNTIME and
VSP1_ENTITY_PARAMS_PARTITION stages into a single call through the
.configure(). The configuration for individual partitions is handled by
passing the partition number to the configure call, and processing any
runtime stage actions on the first partition only.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_bru.c| 12 +-
drivers/media/platform/vsp1/vsp1_clu.c| 42 +--
drivers/media/platform/vsp1/vsp1_drm.c| 11 +-
drivers/media/platform/vsp1/vsp1_entity.c | 15 +-
drivers/media/platform/vsp1/vsp1_entity.h | 27 +--
drivers/media/platform/vsp1/vsp1_hgo.c| 12 +-
drivers/media/platform/vsp1/vsp1_hgt.c| 12 +-
drivers/media/platform/vsp1/vsp1_hsit.c | 12 +-
drivers/media/platform/vsp1/vsp1_lif.c| 12 +-
drivers/media/platform/vsp1/vsp1_lut.c| 24 +-
drivers/media/platform/vsp1/vsp1_rpf.c| 162 ++---
drivers/media/platform/vsp1/vsp1_sru.c| 12 +-
drivers/media/platform/vsp1/vsp1_uds.c| 55 ++--
drivers/media/platform/vsp1/vsp1_video.c | 24 +--
drivers/media/platform/vsp1/vsp1_wpf.c| 297 ---
15 files changed, 358 insertions(+), 371 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_bru.c
b/drivers/media/platform/vsp1/vsp1_bru.c
index e8fd2ae3b3eb..b9ff96f76b3e 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -285,19 +285,15 @@ static const struct v4l2_subdev_ops bru_ops = {
* VSP1 Entity Operations
*/
-static void bru_configure(struct vsp1_entity *entity,
- struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+static void bru_prepare(struct vsp1_entity *entity,
+ struct vsp1_pipeline *pipe,
+ struct vsp1_dl_list *dl)
{
struct vsp1_bru *bru = to_bru(&entity->subdev);
struct v4l2_mbus_framefmt *format;
unsigned int flags;
unsigned int i;
- if (params != VSP1_ENTITY_PARAMS_INIT)
- return;
-
format = vsp1_entity_get_pad_format(&bru->entity, bru->entity.config,
bru->entity.source_pad);
@@ -404,7 +400,7 @@ static void bru_configure(struct vsp1_entity *entity,
}
static const struct vsp1_entity_operations bru_entity_ops = {
- .configure = bru_configure,
+ .prepare = bru_prepare,
};
/*
-
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
b/drivers/media/platform/vsp1/vsp1_clu.c
index b2a39a6ef7e4..2e4af93a053f 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -213,37 +213,36 @@ static const struct v4l2_subdev_ops clu_ops = {
/*
-
* VSP1 Entity Operations
*/
+static void clu_prepare(struct vsp1_entity *entity,
+ struct vsp1_pipeline *pipe,
+ struct vsp1_dl_list *dl)
+{
+ struct vsp1_clu *clu = to_clu(&entity->subdev);
+
+ /*
+* The format can't be changed during streaming. Cache it internally
+* for future runtime configuration calls.
+*/
+ struct v4l2_mbus_framefmt *format;
+
+ format = vsp1_entity_get_pad_format(&clu->entity,
+ clu->entity.config,
+ CLU_PAD_SINK);
+ clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
+}
static void clu_configure(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+ unsigned int partition)
{
struct vsp1_clu *clu = to_clu(&entity->subdev);
struct vsp1_dl_body *dlb;
unsigned long flags;
u32 ctrl = VI6_CLU_CTRL_AAI | VI6_CLU_CTRL_MVS | VI6_CLU_CTRL_EN;
- switch (params) {
- case VSP1_ENTITY_PARAMS_INIT: {
- /*
-* The format can't be changed during streaming, only verify it
-* at setup time and store the information internally for future
-* runtime configuration calls.
-*/
- struct v4l2_mbus_framefmt *format;
-
- format = vsp1_entity_get_pad_format(&clu->entity,
-
[PATCH v3 2/9] v4l: vsp1: Protect bodies against overflow
The body write function relies on the code never asking it to write more
than the entries available in the list.
Currently with each list body containing 256 entries, this is fine, but
we can reduce this number greatly saving memory. In preparation of this
add a level of protection to catch any buffer overflows.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v3:
- adapt for new 'body' terminology
- simplify WARN_ON macro usage
---
drivers/media/platform/vsp1/vsp1_dl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 643f7ea3af24..a45d35aa676e 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -50,6 +50,7 @@ struct vsp1_dl_entry {
* @dma: DMA address of the entries
* @size: size of the DMA memory in bytes
* @num_entries: number of stored entries
+ * @max_entries: number of entries available
*/
struct vsp1_dl_body {
struct list_head list;
@@ -60,6 +61,7 @@ struct vsp1_dl_body {
size_t size;
unsigned int num_entries;
+ unsigned int max_entries;
};
/**
@@ -138,6 +140,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
dlb->vsp1 = vsp1;
dlb->size = size;
+ dlb->max_entries = num_entries;
dlb->entries = dma_alloc_wc(vsp1->bus_master, dlb->size, &dlb->dma,
GFP_KERNEL);
@@ -219,6 +222,10 @@ void vsp1_dl_body_free(struct vsp1_dl_body *dlb)
*/
void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 reg, u32 data)
{
+ if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
+ "DLB size exceeded (max %u)", dlb->max_entries))
+ return;
+
dlb->entries[dlb->num_entries].addr = reg;
dlb->entries[dlb->num_entries].data = data;
dlb->num_entries++;
--
git-series 0.9.1
[PATCH v3 9/9] v4l: vsp1: Reduce display list body size
The display list originally allocated a body of 256 entries to store all of the register lists required for each frame. This has now been separated into fragments for constant stream setup, and runtime updates. Empirical testing shows that the body0 now uses a maximum of 41 registers for each frame, for both DRM and Video API pipelines thus a rounded 64 entries provides a suitable allocation. Signed-off-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_dl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index bca9bd45ac7f..5bb1e9103f84 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -21,7 +21,7 @@ #include "vsp1.h" #include "vsp1_dl.h" -#define VSP1_DL_NUM_ENTRIES256 +#define VSP1_DL_NUM_ENTRIES64 #define VSP1_DLH_INT_ENABLE(1 << 1) #define VSP1_DLH_AUTO_START(1 << 0) -- git-series 0.9.1
[PATCH v3 7/9] v4l: vsp1: Adapt entities to configure into a body
Currently the entities store their configurations into a display list.
Adapt this such that the code can be configured into a body directly,
allowing greater flexibility and control of the content.
All users of vsp1_dl_list_write() are removed in this process, thus it
too is removed.
A helper, vsp1_dl_list_get_body() is provided to access the internal body0
from the display list.
Signed-off-by: Kieran Bingham
---
I don't like the fact this adds vsp1_dl_list_get_body() on top of
vsp1_dl_body_get(); which are a bit too similar.
Perhaps we should remove body0, or at least call vsp1_dl_list_get_body()
vsp1_dl_list_get_body0()...
---
drivers/media/platform/vsp1/vsp1_bru.c| 22 ++--
drivers/media/platform/vsp1/vsp1_clu.c| 22 ++--
drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
drivers/media/platform/vsp1/vsp1_dl.h | 4 +-
drivers/media/platform/vsp1/vsp1_drm.c| 14 +---
drivers/media/platform/vsp1/vsp1_entity.c | 16 -
drivers/media/platform/vsp1/vsp1_entity.h | 12 ---
drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
drivers/media/platform/vsp1/vsp1_hsit.c | 10 +++---
drivers/media/platform/vsp1/vsp1_lif.c| 13 +++
drivers/media/platform/vsp1/vsp1_lut.c| 21 ++--
drivers/media/platform/vsp1/vsp1_pipe.c | 4 +-
drivers/media/platform/vsp1/vsp1_pipe.h | 3 +-
drivers/media/platform/vsp1/vsp1_rpf.c| 43 +++-
drivers/media/platform/vsp1/vsp1_sru.c| 14
drivers/media/platform/vsp1/vsp1_uds.c| 24 +++--
drivers/media/platform/vsp1/vsp1_uds.h| 2 +-
drivers/media/platform/vsp1/vsp1_video.c | 11 --
drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
20 files changed, 169 insertions(+), 154 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_bru.c
b/drivers/media/platform/vsp1/vsp1_bru.c
index b9ff96f76b3e..60d449d7b135 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -30,10 +30,10 @@
* Device Access
*/
-static inline void vsp1_bru_write(struct vsp1_bru *bru, struct vsp1_dl_list
*dl,
- u32 reg, u32 data)
+static inline void vsp1_bru_write(struct vsp1_bru *bru,
+ struct vsp1_dl_body *dlb, u32 reg, u32 data)
{
- vsp1_dl_list_write(dl, bru->base + reg, data);
+ vsp1_dl_body_write(dlb, bru->base + reg, data);
}
/*
-
@@ -287,7 +287,7 @@ static const struct v4l2_subdev_ops bru_ops = {
static void bru_prepare(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl)
+ struct vsp1_dl_body *dlb)
{
struct vsp1_bru *bru = to_bru(&entity->subdev);
struct v4l2_mbus_framefmt *format;
@@ -309,7 +309,7 @@ static void bru_prepare(struct vsp1_entity *entity,
* format at the pipeline output is premultiplied.
*/
flags = pipe->output ? pipe->output->format.flags : 0;
- vsp1_bru_write(bru, dl, VI6_BRU_INCTRL,
+ vsp1_bru_write(bru, dlb, VI6_BRU_INCTRL,
flags & V4L2_PIX_FMT_FLAG_PREMUL_ALPHA ?
0 : VI6_BRU_INCTRL_NRM);
@@ -317,12 +317,12 @@ static void bru_prepare(struct vsp1_entity *entity,
* Set the background position to cover the whole output image and
* configure its color.
*/
- vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_SIZE,
+ vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_SIZE,
(format->width << VI6_BRU_VIRRPF_SIZE_HSIZE_SHIFT) |
(format->height << VI6_BRU_VIRRPF_SIZE_VSIZE_SHIFT));
- vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_LOC, 0);
+ vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_LOC, 0);
- vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_COL, bru->bgcolor |
+ vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_COL, bru->bgcolor |
(0xff << VI6_BRU_VIRRPF_COL_A_SHIFT));
/*
@@ -332,7 +332,7 @@ static void bru_prepare(struct vsp1_entity *entity,
* unit.
*/
if (entity->type == VSP1_ENTITY_BRU)
- vsp1_bru_write(bru, dl, VI6_BRU_ROP,
+ vsp1_bru_write(bru, dlb, VI6_BRU_ROP,
VI6_BRU_ROP_DSTSEL_BRUIN(1) |
VI6_BRU_ROP_CROP(VI6_ROP_NOP) |
VI6_BRU_ROP_AROP(VI6_ROP_NOP));
@@ -374,7 +374,7 @@ static void bru_prepare(struct vsp1_entity *entity,
if (!(entity->type == VSP1_ENTITY_BRU && i == 1))
ctrl |= VI6_BRU_CTRL_SRCSEL_BRUIN(i);
- vsp1_bru_write(bru, dl, VI6_BRU_CTRL(i), ctrl);
+ vsp1_bru_write(bru, dlb, VI6_BRU_CTRL(i), ctrl);
/*
* Harcode the bl
[PATCH v3 4/9] v4l: vsp1: Convert display lists to use new body pool
Adapt the dl->body0 object to use an object from the body pool. This
greatly reduces the pressure on the TLB for IPMMU use cases, as all of
the lists use a single allocation for the main body.
The CLU and LUT objects pre-allocate a pool containing three bodies,
allowing a userspace update before the hardware has committed a previous
set of tables.
Bodies are no longer 'freed' in interrupt context, but instead released
back to their respective pools. This allows us to remove the garbage
collector in the DLM.
Signed-off-by: Kieran Bingham
---
v3:
- 's/fragment/body', 's/fragments/bodies/'
- CLU/LUT now allocate 3 bodies
- vsp1_dl_list_fragments_free -> vsp1_dl_list_bodies_put
v2:
- Use dl->body0->max_entries to determine header offset, instead of the
global constant VSP1_DL_NUM_ENTRIES which is incorrect.
- squash updates for LUT, CLU, and fragment cleanup into single patch.
(Not fully bisectable when separated)
---
drivers/media/platform/vsp1/vsp1_clu.c | 27 ++-
drivers/media/platform/vsp1/vsp1_clu.h | 1 +-
drivers/media/platform/vsp1/vsp1_dl.c | 223 ++
drivers/media/platform/vsp1/vsp1_dl.h | 3 +-
drivers/media/platform/vsp1/vsp1_lut.c | 27 ++-
drivers/media/platform/vsp1/vsp1_lut.h | 1 +-
6 files changed, 101 insertions(+), 181 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
b/drivers/media/platform/vsp1/vsp1_clu.c
index 9621afa3658c..2018144470c5 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -23,6 +23,8 @@
#define CLU_MIN_SIZE 4U
#define CLU_MAX_SIZE 8190U
+#define CLU_SIZE (17 * 17 * 17)
+
/*
-
* Device Access
*/
@@ -47,19 +49,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
- dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+ dlb = vsp1_dl_body_get(clu->pool);
if (!dlb)
return -ENOMEM;
vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
- for (i = 0; i < 17 * 17 * 17; ++i)
+ for (i = 0; i < CLU_SIZE; ++i)
vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
spin_lock_irq(&clu->lock);
swap(clu->clu, dlb);
spin_unlock_irq(&clu->lock);
- vsp1_dl_body_free(dlb);
+ vsp1_dl_body_put(dlb);
return 0;
}
@@ -261,8 +263,16 @@ static void clu_configure(struct vsp1_entity *entity,
}
}
+static void clu_destroy(struct vsp1_entity *entity)
+{
+ struct vsp1_clu *clu = to_clu(&entity->subdev);
+
+ vsp1_dl_body_pool_destroy(clu->pool);
+}
+
static const struct vsp1_entity_operations clu_entity_ops = {
.configure = clu_configure,
+ .destroy = clu_destroy,
};
/*
-
@@ -288,6 +298,17 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device *vsp1)
if (ret < 0)
return ERR_PTR(ret);
+ /*
+* Pre-allocate a body pool, with 3 bodies allowing a userspace update
+* before the hardware has committed a previous set of tables, handling
+* both the queued and pending dl entries. One extra entry is added to
+* the CLU_SIZE to allow for the VI6_CLU_ADDR header.
+*/
+ clu->pool = vsp1_dl_body_pool_create(clu->entity.vsp1, 3, CLU_SIZE + 1,
+0);
+ if (!clu->pool)
+ return ERR_PTR(-ENOMEM);
+
/* Initialize the control handler. */
v4l2_ctrl_handler_init(&clu->ctrls, 2);
v4l2_ctrl_new_custom(&clu->ctrls, &clu_table_control, NULL);
diff --git a/drivers/media/platform/vsp1/vsp1_clu.h
b/drivers/media/platform/vsp1/vsp1_clu.h
index 036e0a2f1a42..fa3fe856725b 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.h
+++ b/drivers/media/platform/vsp1/vsp1_clu.h
@@ -36,6 +36,7 @@ struct vsp1_clu {
spinlock_t lock;
unsigned int mode;
struct vsp1_dl_body *clu;
+ struct vsp1_dl_body_pool *pool;
};
static inline struct vsp1_clu *to_clu(struct v4l2_subdev *subdev)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index e6f3e68367ff..671aef30d090 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -110,7 +110,7 @@ struct vsp1_dl_list {
struct vsp1_dl_header *header;
dma_addr_t dma;
- struct vsp1_dl_body body0;
+ struct vsp1_dl_body *body0;
struct list_head bodies;
bool has_chain;
@@ -134,8 +134,6 @@ enum vsp1_dl_mode {
* @queued: list queued to the hardware (written to the DL registers)
* @pending: list waiting to be queued to the hardware
* @pool: body pool for the display list bodies
- * @gc_work:
[PATCH v3 5/9] v4l: vsp1: Use reference counting for bodies
Extend the display list body with a reference count, allowing bodies to
be kept as long as a reference is maintained. This provides the ability
to keep a cached copy of bodies which will not change, so that they can
be re-applied to multiple display lists.
Signed-off-by: Kieran Bingham
---
This could be squashed into the body update code, but it's not a
straightforward squash as the refcounts will affect both:
v4l: vsp1: Provide a body pool
and
v4l: vsp1: Convert display lists to use new body pool
therefore, I have kept this separate to prevent breaking bisectability
of the vsp-tests.
v3:
- 's/fragment/body/'
---
drivers/media/platform/vsp1/vsp1_clu.c | 7 ++-
drivers/media/platform/vsp1/vsp1_dl.c | 15 ++-
drivers/media/platform/vsp1/vsp1_lut.c | 7 ++-
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
b/drivers/media/platform/vsp1/vsp1_clu.c
index 2018144470c5..b2a39a6ef7e4 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -257,8 +257,13 @@ static void clu_configure(struct vsp1_entity *entity,
clu->clu = NULL;
spin_unlock_irqrestore(&clu->lock, flags);
- if (dlb)
+ if (dlb) {
vsp1_dl_list_add_body(dl, dlb);
+
+ /* release our local reference */
+ vsp1_dl_body_put(dlb);
+ }
+
break;
}
}
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 671aef30d090..0ee12d3338dd 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -58,6 +59,8 @@ struct vsp1_dl_body {
struct list_head list;
struct list_head free;
+ refcount_t refcnt;
+
struct vsp1_dl_body_pool *pool;
struct vsp1_device *vsp1;
@@ -252,6 +255,7 @@ struct vsp1_dl_body *vsp1_dl_body_get(struct
vsp1_dl_body_pool *pool)
if (!list_empty(&pool->free)) {
dlb = list_first_entry(&pool->free, struct vsp1_dl_body, free);
list_del(&dlb->free);
+ refcount_set(&dlb->refcnt, 1);
}
spin_unlock_irqrestore(&pool->lock, flags);
@@ -272,6 +276,9 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
if (!dlb)
return;
+ if (!refcount_dec_and_test(&dlb->refcnt))
+ return;
+
dlb->num_entries = 0;
spin_lock_irqsave(&dlb->pool->lock, flags);
@@ -458,7 +465,11 @@ void vsp1_dl_list_write(struct vsp1_dl_list *dl, u32 reg,
u32 data)
* in the order in which bodies are added.
*
* Adding a body to a display list passes ownership of the body to the list.
The
- * caller must not touch the body after this call.
+ * caller must not modify the body after this call, but can retain a reference
+ * to it for future use if necessary, to add to subsequent lists.
+ *
+ * The reference count of the body is incremented by this attachment, and thus
+ * the caller should release it's reference if does not want to cache the body.
*
* Additional bodies are only usable for display lists in header mode.
* Attempting to add a body to a header-less display list will return an error.
@@ -470,6 +481,8 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl,
if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
return -EINVAL;
+ refcount_inc(&dlb->refcnt);
+
list_add_tail(&dlb->list, &dl->bodies);
return 0;
}
diff --git a/drivers/media/platform/vsp1/vsp1_lut.c
b/drivers/media/platform/vsp1/vsp1_lut.c
index 262cb72139d6..77cf7137a0f2 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.c
+++ b/drivers/media/platform/vsp1/vsp1_lut.c
@@ -213,8 +213,13 @@ static void lut_configure(struct vsp1_entity *entity,
lut->lut = NULL;
spin_unlock_irqrestore(&lut->lock, flags);
- if (dlb)
+ if (dlb) {
vsp1_dl_list_add_body(dl, dlb);
+
+ /* release our local reference */
+ vsp1_dl_body_put(dlb);
+ }
+
break;
}
}
--
git-series 0.9.1
[PATCH v3 0/9] vsp1: TLB optimisation and DL caching
Each display list currently allocates an area of DMA memory to store register settings for the VSP1 to process. Each of these allocations adds pressure to the IPMMU TLB entries. We can reduce the pressure by pre-allocating larger areas and dividing the area across multiple bodies represented as a pool. With this reconfiguration of bodies, we can adapt the configuration code to separate out constant hardware configuration and cache it for re-use. This posting is only really a status update following the previous review after quite a bit of work has been done. However this series is not yet complete, and I do not expect a full review - or integration of this series in its current form. In particular: Patch 1 : Reword uses of 'fragment' as 'body' - Is new and can be reviewed if desired. Otherwise, most other issues have been addressed, and the series is rebased to utilise the term 'bodies' instead of 'fragments'. A few 'larger' topics came up in review, and will be considered in a follow up series. (v4+) Patch 3 : Provide a body pool - Allocates more memory than is required for 'extra_size' Patch 5 : Use reference counting for bodies - Minor comment to be fixed up. (I should have done this already) Patch 7 : Adapt entities to configure into a body - To be reworked, quite substantially. Patch 8 : Move video configuration to a cached dlb - Previous review comments still to be addressed The patches provided in this series can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git tags/vsp1/tlb-optimise/v3 Kieran Bingham (9): v4l: vsp1: Reword uses of 'fragment' as 'body' v4l: vsp1: Protect bodies against overflow v4l: vsp1: Provide a body pool v4l: vsp1: Convert display lists to use new body pool v4l: vsp1: Use reference counting for bodies v4l: vsp1: Refactor display list configure operations v4l: vsp1: Adapt entities to configure into a body v4l: vsp1: Move video configuration to a cached dlb v4l: vsp1: Reduce display list body size drivers/media/platform/vsp1/vsp1_bru.c| 32 +-- drivers/media/platform/vsp1/vsp1_clu.c| 94 +++--- drivers/media/platform/vsp1/vsp1_clu.h| 1 +- drivers/media/platform/vsp1/vsp1_dl.c | 387 +-- drivers/media/platform/vsp1/vsp1_dl.h | 21 +- drivers/media/platform/vsp1/vsp1_drm.c| 21 +- drivers/media/platform/vsp1/vsp1_entity.c | 23 +- drivers/media/platform/vsp1/vsp1_entity.h | 31 +-- drivers/media/platform/vsp1/vsp1_hgo.c| 26 +-- drivers/media/platform/vsp1/vsp1_hgt.c| 28 +-- drivers/media/platform/vsp1/vsp1_hsit.c | 20 +- drivers/media/platform/vsp1/vsp1_lif.c| 23 +- drivers/media/platform/vsp1/vsp1_lut.c| 71 ++-- drivers/media/platform/vsp1/vsp1_lut.h| 1 +- drivers/media/platform/vsp1/vsp1_pipe.c | 8 +- drivers/media/platform/vsp1/vsp1_pipe.h | 7 +- drivers/media/platform/vsp1/vsp1_rpf.c| 179 +-- drivers/media/platform/vsp1/vsp1_sru.c| 24 +- drivers/media/platform/vsp1/vsp1_uds.c| 73 ++-- drivers/media/platform/vsp1/vsp1_uds.h| 2 +- drivers/media/platform/vsp1/vsp1_video.c | 82 ++--- drivers/media/platform/vsp1/vsp1_video.h | 2 +- drivers/media/platform/vsp1/vsp1_wpf.c| 325 +-- 23 files changed, 811 insertions(+), 670 deletions(-) base-commit: f44bd631453bf7dcbe57f79b924db3a6dd038bff -- git-series 0.9.1
[PATCH v3 8/9] v4l: vsp1: Move video configuration to a cached dlb
We are now able to configure a pipeline directly into a local display
list body. Take advantage of this fact, and create a cacheable body to
store the configuration of the pipeline in the video object.
vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
Convert this function to use the cached video->config body and obtain a
local display list reference.
Attach the video->config body to the display list when needed before
committing to hardware.
The pipe object is marked as un-configured when entering a suspend. This
ensures that upon resume, where the hardware is reset - our cached
configuration will be re-attached to the next committed DL.
Signed-off-by: Kieran Bingham
---
v3:
- 's/fragment/body/', 's/fragments/bodies/'
- video dlb cache allocation increased from 2 to 3 dlbs
Our video DL usage now looks like the below output:
dl->body0 contains our disposable runtime configuration. Max 41.
dl_child->body0 is our partition specific configuration. Max 12.
dl->bodies shows our constant configuration and LUTs.
These two are LUT/CLU:
* dl->bodies[x]->num_entries 256 / max 256
* dl->bodies[x]->num_entries 4914 / max 4914
Which shows that our 'constant' configuration cache is currently
utilised to a maximum of 64 entries.
trace-cmd report | \
grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;
dl->body0->num_entries 13 / max 128
dl->body0->num_entries 14 / max 128
dl->body0->num_entries 16 / max 128
dl->body0->num_entries 20 / max 128
dl->body0->num_entries 27 / max 128
dl->body0->num_entries 34 / max 128
dl->body0->num_entries 41 / max 128
dl_child->body0->num_entries 10 / max 128
dl_child->body0->num_entries 12 / max 128
dl->bodies[x]->num_entries 15 / max 128
dl->bodies[x]->num_entries 16 / max 128
dl->bodies[x]->num_entries 17 / max 128
dl->bodies[x]->num_entries 18 / max 128
dl->bodies[x]->num_entries 20 / max 128
dl->bodies[x]->num_entries 21 / max 128
dl->bodies[x]->num_entries 256 / max 256
dl->bodies[x]->num_entries 31 / max 128
dl->bodies[x]->num_entries 32 / max 128
dl->bodies[x]->num_entries 39 / max 128
dl->bodies[x]->num_entries 40 / max 128
dl->bodies[x]->num_entries 47 / max 128
dl->bodies[x]->num_entries 48 / max 128
dl->bodies[x]->num_entries 4914 / max 4914
dl->bodies[x]->num_entries 55 / max 128
dl->bodies[x]->num_entries 56 / max 128
dl->bodies[x]->num_entries 63 / max 128
dl->bodies[x]->num_entries 64 / max 128
---
drivers/media/platform/vsp1/vsp1_pipe.c | 4 +-
drivers/media/platform/vsp1/vsp1_pipe.h | 4 +-
drivers/media/platform/vsp1/vsp1_video.c | 67 -
drivers/media/platform/vsp1/vsp1_video.h | 2 +-
4 files changed, 51 insertions(+), 26 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 5012643583b6..7d1f7ba43060 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe)
vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index),
VI6_CMD_STRCMD);
pipe->state = VSP1_PIPELINE_RUNNING;
+ pipe->configured = true;
}
pipe->buffers_ready = 0;
@@ -430,6 +431,9 @@ void vsp1_pipelines_suspend(struct vsp1_device *vsp1)
spin_lock_irqsave(&pipe->irqlock, flags);
if (pipe->state == VSP1_PIPELINE_RUNNING)
pipe->state = VSP1_PIPELINE_STOPPING;
+
+ /* After a suspend, the hardware will be reset */
+ pipe->configured = false;
spin_unlock_irqrestore(&pipe->irqlock, flags);
}
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 90d29492b9b9..e7ad6211b4d0 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -90,6 +90,7 @@ struct vsp1_partition {
* @irqlock: protects the pipeline state
* @state: current state
* @wq: wait queue to wait for state change completion
+ * @configured: flag determining if the hardware has run since reset
* @frame_end: frame end interrupt handler
* @lock: protects the pipeline use count and stream count
* @kref: pipeline reference count
@@ -117,6 +118,7 @@ struct vsp1_pipeline {
spinlock_t irqlock;
enum vsp1_pipeline_state state;
wait_queue_head_t wq;
+ bool configured;
void (*frame_end)(struct vsp1_pipeline *pipe, bool completed);
@@ -143,8 +145,6 @@ struct vsp1_pipeline {
*/
struct list_head entities;
- struct vsp1_dl_list *dl;
-
unsigned int partitions;
struct vsp1_partition *partition;
struct vsp1_partition *part_table;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index 9366b41c1b43..54fef64c3457 100644
--- a/drivers/media/pl
[PATCH v3 1/9] v4l: vsp1: Reword uses of 'fragment' as 'body'
Throughout the codebase, the term 'fragment' is used to represent a
display list body. This term duplicates the 'body' which is already in
use.
The datasheet references these objects as a body, therefore replace all
mentions of a fragment with a body, along with the corresponding
pluralised terms.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_clu.c | 10 +-
drivers/media/platform/vsp1/vsp1_dl.c | 107 --
drivers/media/platform/vsp1/vsp1_dl.h | 14 +--
drivers/media/platform/vsp1/vsp1_lut.c | 8 +-
4 files changed, 69 insertions(+), 70 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
b/drivers/media/platform/vsp1/vsp1_clu.c
index f2fb26e5ab4e..9621afa3658c 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -47,19 +47,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
- dlb = vsp1_dl_fragment_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+ dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
if (!dlb)
return -ENOMEM;
- vsp1_dl_fragment_write(dlb, VI6_CLU_ADDR, 0);
+ vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
for (i = 0; i < 17 * 17 * 17; ++i)
- vsp1_dl_fragment_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
+ vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
spin_lock_irq(&clu->lock);
swap(clu->clu, dlb);
spin_unlock_irq(&clu->lock);
- vsp1_dl_fragment_free(dlb);
+ vsp1_dl_body_free(dlb);
return 0;
}
@@ -256,7 +256,7 @@ static void clu_configure(struct vsp1_entity *entity,
spin_unlock_irqrestore(&clu->lock, flags);
if (dlb)
- vsp1_dl_list_add_fragment(dl, dlb);
+ vsp1_dl_list_add_body(dl, dlb);
break;
}
}
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 8b5cbb6b7a70..643f7ea3af24 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -69,7 +69,7 @@ struct vsp1_dl_body {
* @header: display list header, NULL for headerless lists
* @dma: DMA address for the header
* @body0: first display list body
- * @fragments: list of extra display list bodies
+ * @bodies: list of extra display list bodies
* @chain: entry in the display list partition chain
*/
struct vsp1_dl_list {
@@ -80,7 +80,7 @@ struct vsp1_dl_list {
dma_addr_t dma;
struct vsp1_dl_body body0;
- struct list_head fragments;
+ struct list_head bodies;
bool has_chain;
struct list_head chain;
@@ -97,13 +97,13 @@ enum vsp1_dl_mode {
* @mode: display list operation mode (header or headerless)
* @singleshot: execute the display list in single-shot mode
* @vsp1: the VSP1 device
- * @lock: protects the free, active, queued, pending and gc_fragments lists
+ * @lock: protects the free, active, queued, pending and gc_bodies lists
* @free: array of all free display lists
* @active: list currently being processed (loaded) by hardware
* @queued: list queued to the hardware (written to the DL registers)
* @pending: list waiting to be queued to the hardware
- * @gc_work: fragments garbage collector work struct
- * @gc_fragments: array of display list fragments waiting to be freed
+ * @gc_work: bodies garbage collector work struct
+ * @gc_bodies: array of display list bodies waiting to be freed
*/
struct vsp1_dl_manager {
unsigned int index;
@@ -118,7 +118,7 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *pending;
struct work_struct gc_work;
- struct list_head gc_fragments;
+ struct list_head gc_bodies;
};
/*
-
@@ -156,17 +156,16 @@ static void vsp1_dl_body_cleanup(struct vsp1_dl_body *dlb)
}
/**
- * vsp1_dl_fragment_alloc - Allocate a display list fragment
+ * vsp1_dl_body_alloc - Allocate a display list body
* @vsp1: The VSP1 device
- * @num_entries: The maximum number of entries that the fragment can contain
+ * @num_entries: The maximum number of entries that the body can contain
*
- * Allocate a display list fragment with enough memory to contain the requested
+ * Allocate a display list body with enough memory to contain the requested
* number of entries.
*
- * Return a pointer to a fragment on success or NULL if memory can't be
- * allocated.
+ * Return a pointer to a body on success or NULL if memory can't be allocated.
*/
-struct vsp1_dl_body *vsp1_dl_fragment_alloc(struct vsp1_device *vsp1,
+struct vsp1_dl_body *vsp1_dl_body_alloc(struct vsp1_device *vsp1,
unsigned int num_entries)
{
struct vsp1_dl_body *dlb;
@@ -186,20 +185,20 @@ struct vsp1_dl_body *vsp1_d
[PATCH v3 3/9] v4l: vsp1: Provide a body pool
Each display list allocates a body to store register values in a dma
accessible buffer from a dma_alloc_wc() allocation. Each of these
results in an entry in the TLB, and a large number of display list
allocations adds pressure to this resource.
Reduce TLB pressure on the IPMMUs by allocating multiple display list
bodies in a single allocation, and providing these to the display list
through a 'body pool'. A pool can be allocated by the display list
manager or entities which require their own body allocations.
Signed-off-by: Kieran Bingham
---
v3:
- s/fragment/body/, s/fragments/bodies/
- qty -> num_bodies
- indentation fix
- s/vsp1_dl_body_pool_{alloc,free}/vsp1_dl_body_pool_{create,destroy}/'
- Add kerneldoc to non-static functions
v2:
- assign dlb->dma correctly
---
drivers/media/platform/vsp1/vsp1_dl.c | 157 +++-
drivers/media/platform/vsp1/vsp1_dl.h | 8 +-
2 files changed, 165 insertions(+)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index a45d35aa676e..e6f3e68367ff 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -45,6 +45,8 @@ struct vsp1_dl_entry {
/**
* struct vsp1_dl_body - Display list body
* @list: entry in the display list list of bodies
+ * @free: entry in the pool free body list
+ * @pool: pool to which this body belongs
* @vsp1: the VSP1 device
* @entries: array of entries
* @dma: DMA address of the entries
@@ -54,6 +56,9 @@ struct vsp1_dl_entry {
*/
struct vsp1_dl_body {
struct list_head list;
+ struct list_head free;
+
+ struct vsp1_dl_body_pool *pool;
struct vsp1_device *vsp1;
struct vsp1_dl_entry *entries;
@@ -65,6 +70,30 @@ struct vsp1_dl_body {
};
/**
+ * struct vsp1_dl_body_pool - display list body pool
+ * @dma: DMA address of the entries
+ * @size: size of the full DMA memory pool in bytes
+ * @mem: CPU memory pointer for the pool
+ * @bodies: Array of DLB structures for the pool
+ * @free: List of free DLB entries
+ * @lock: Protects the pool and free list
+ * @vsp1: the VSP1 device
+ */
+struct vsp1_dl_body_pool {
+ /* DMA allocation */
+ dma_addr_t dma;
+ size_t size;
+ void *mem;
+
+ /* Body management */
+ struct vsp1_dl_body *bodies;
+ struct list_head free;
+ spinlock_t lock;
+
+ struct vsp1_device *vsp1;
+};
+
+/**
* struct vsp1_dl_list - Display list
* @list: entry in the display list manager lists
* @dlm: the display list manager
@@ -104,6 +133,7 @@ enum vsp1_dl_mode {
* @active: list currently being processed (loaded) by hardware
* @queued: list queued to the hardware (written to the DL registers)
* @pending: list waiting to be queued to the hardware
+ * @pool: body pool for the display list bodies
* @gc_work: bodies garbage collector work struct
* @gc_bodies: array of display list bodies waiting to be freed
*/
@@ -119,6 +149,8 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *queued;
struct vsp1_dl_list *pending;
+ struct vsp1_dl_body_pool *pool;
+
struct work_struct gc_work;
struct list_head gc_bodies;
};
@@ -127,6 +159,131 @@ struct vsp1_dl_manager {
* Display List Body Management
*/
+/**
+ * vsp1_dl_body_pool_create - Create a pool of bodies from a single allocation
+ * @vsp1: The VSP1 device
+ * @num_bodies: The quantity of bodies to allocate
+ * @num_entries: The maximum number of entries that the body can contain
+ * @extra_size: Extra allocation provided for the bodies
+ *
+ * Allocate a pool of display list bodies each with enough memory to contain
the
+ * requested number of entries.
+ *
+ * Return a pointer to a pool on success or NULL if memory can't be allocated.
+ */
+struct vsp1_dl_body_pool *
+vsp1_dl_body_pool_create(struct vsp1_device *vsp1, unsigned int num_bodies,
+unsigned int num_entries, size_t extra_size)
+{
+ struct vsp1_dl_body_pool *pool;
+ size_t dlb_size;
+ unsigned int i;
+
+ pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+ if (!pool)
+ return NULL;
+
+ pool->vsp1 = vsp1;
+
+ dlb_size = num_entries * sizeof(struct vsp1_dl_entry) + extra_size;
+ pool->size = dlb_size * num_bodies;
+
+ pool->bodies = kcalloc(num_bodies, sizeof(*pool->bodies), GFP_KERNEL);
+ if (!pool->bodies) {
+ kfree(pool);
+ return NULL;
+ }
+
+ pool->mem = dma_alloc_wc(vsp1->bus_master, pool->size, &pool->dma,
+GFP_KERNEL);
+ if (!pool->mem) {
+ kfree(pool->bodies);
+ kfree(pool);
+ return NULL;
+ }
+
+ spin_lock_init(&pool->lock);
+ INIT_LIST_HEAD(&pool->free);
+
+ for (i = 0; i < num_bodies; ++i) {
+ struct vsp1_dl_body *dlb = &pool->bodies[i];
+
+ dlb->pool = pool;
+ dlb->max_entries = nu
[RFC 0/3] thermal: rcar_gen3_thermal: read calibration from hardware
Hi, This series extend the Renesas R-Car Gen3 thermal driver to try and read its calibration constants from hardware instead of using pseudo values hard-coded in the driver. Unfortunately one registers involved in are not yet documented in datasheets and I don't have access to any board where the calibration data is fused. For the not documented register the BSP code was used as a reference. I do believe the code is ready for upstream consumption but pending new datasheet and/or access to hardware where calibration is fused to test it marked it as RFC. Once I have addressed one or both of these concerns I will resend without the RFC prefix. The code is tested on H3 and M3-W where the calibration registers are not fused so only the fallback logic to pseudo values are truly tested. Niklas Söderlund (3): thermal: rcar_gen3_thermal: read calibration from hardware arm64: dts: r8a7795: update register size for thermal arm64: dts: r8a7796: update register size for thermal arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +- drivers/thermal/rcar_gen3_thermal.c | 70 +++- 3 files changed, 70 insertions(+), 4 deletions(-) -- 2.14.1
[RFC 3/3] arm64: dts: r8a7796: update register size for thermal
To be able to read fused calibration values from hardware the size of
the register resource of TSC1 needs to be incremented to cover one more
register which holds the information if the calibration values have been
fused or not.
Signed-off-by: Niklas Söderlund
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 0b805dc30925e9be..b1428c10e703b37c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -2098,7 +2098,7 @@
tsc: thermal@e6198000 {
compatible = "renesas,r8a7796-thermal";
- reg = <0 0xe6198000 0 0x68>,
+ reg = <0 0xe6198000 0 0x6c>,
<0 0xe61a 0 0x5c>,
<0 0xe61a8000 0 0x5c>;
interrupts = ,
--
2.14.1
[RFC 1/3] thermal: rcar_gen3_thermal: read calibration from hardware
In production hardware the calibration values used to convert register
values to temperatures can be read from hardware. While pre-production
hardware still depends on pseudo values hard-coded in the driver.
Add support for reading out calibration values from hardware if it's
fused. The presence of fused calibration is indicated in the THSCP
register, unfortunately this register where not present in early
datasheets. The resource size used in early DT descriptions do not cover
this register. This change takes this into account and fallback to the
pseudo values if the resource size in DT is to small.
Signed-off-by: Niklas Söderlund
---
drivers/thermal/rcar_gen3_thermal.c | 70 +++--
1 file changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/rcar_gen3_thermal.c
b/drivers/thermal/rcar_gen3_thermal.c
index 528a65b05b304ca3..29d041d79c6856d6 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -43,6 +43,10 @@
#define REG_GEN3_THCODE1 0x50
#define REG_GEN3_THCODE2 0x54
#define REG_GEN3_THCODE3 0x58
+#define REG_GEN3_PTAT1 0x5c
+#define REG_GEN3_PTAT2 0x60
+#define REG_GEN3_PTAT3 0x64
+#define REG_GEN3_THSCP 0x68
/* IRQ{STR,MSK,EN} bits */
#define IRQ_TEMP1 BIT(0)
@@ -64,6 +68,9 @@
#define THCTR_PONM BIT(6)
#define THCTR_THSSTBIT(0)
+/* THSCP bits */
+#define THSCP_COR_PARA_VLD (BIT(15) | BIT(14))
+
#define CTEMP_MASK 0xFFF
#define MCELSIUS(temp) ((temp) * 1000)
@@ -81,6 +88,7 @@ struct equation_coefs {
struct rcar_gen3_thermal_tsc {
void __iomem *base;
+ resource_size_t size;
struct thermal_zone_device *zone;
struct equation_coefs coef;
int low;
@@ -284,6 +292,55 @@ static const struct soc_device_attribute r8a7795es1[] = {
{ /* sentinel */ }
};
+static bool rcar_gen3_thermal_update_fuses(struct rcar_gen3_thermal_priv *priv)
+{
+ int i, ptat[3], thcode[3];
+ u32 thscp;
+
+ if (!priv->num_tscs)
+ return false;
+
+ /*
+* If resource size of TSC1 is less then 0x6c0 old DT is used, not
+* possible to read all fusees, fallback to pseudo values.
+*/
+ if (priv->tscs[0]->size < 0x6c)
+ return false;
+
+ /* If fuses are not set, fallback to pseudo values. */
+ thscp = rcar_gen3_thermal_read(priv->tscs[0], REG_GEN3_THSCP);
+ if ((thscp & THSCP_COR_PARA_VLD) != THSCP_COR_PARA_VLD)
+ return false;
+
+ /*
+* Update the pseudo calibration points with fused values.
+* PTAT is shared between all TSC:s but only fused for the first
+* TSC while THCODEs are fused for each TSC.
+*/
+
+ ptat[0] = rcar_gen3_thermal_read(priv->tscs[0], REG_GEN3_PTAT1) &
+ GEN3_FUSE_MASK;
+ ptat[1] = rcar_gen3_thermal_read(priv->tscs[0], REG_GEN3_PTAT2) &
+ GEN3_FUSE_MASK;
+ ptat[2] = rcar_gen3_thermal_read(priv->tscs[0], REG_GEN3_PTAT3) &
+ GEN3_FUSE_MASK;
+
+ for (i = 0; i < priv->num_tscs; i++) {
+ struct rcar_gen3_thermal_tsc *tsc = priv->tscs[i];
+
+ thcode[0] = rcar_gen3_thermal_read(tsc, REG_GEN3_THCODE1) &
+ GEN3_FUSE_MASK;
+ thcode[1] = rcar_gen3_thermal_read(tsc, REG_GEN3_THCODE2) &
+ GEN3_FUSE_MASK;
+ thcode[2] = rcar_gen3_thermal_read(tsc, REG_GEN3_THCODE3) &
+ GEN3_FUSE_MASK;
+
+ rcar_gen3_thermal_calc_coefs(&tsc->coef, ptat, thcode);
+ }
+
+ return true;
+}
+
static void r8a7796_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
{
u32 reg_val;
@@ -432,11 +489,22 @@ static int rcar_gen3_thermal_probe(struct platform_device
*pdev)
ret = PTR_ERR(tsc->base);
goto error_unregister;
}
+ tsc->size = resource_size(res);
priv->tscs[i] = tsc;
priv->data->thermal_init(tsc);
+
rcar_gen3_thermal_calc_coefs(&tsc->coef, ptat, thcode[i]);
+ }
+
+ priv->num_tscs = i;
+
+ if (rcar_gen3_thermal_update_fuses(priv))
+ dev_info(dev, "Using fused calibration values\n");
+
+ for (i = 0; i < priv->num_tscs; i++) {
+ struct rcar_gen3_thermal_tsc *tsc = priv->tscs[i];
zone = devm_thermal_zone_of_sensor_register(dev, i, tsc,
&rcar_gen3_tz_of_ops);
@@ -454,8 +522,6 @@ static int rcar_gen3_thermal_probe(struct platform_device
*pdev)
dev_info(dev, "TSC%d: Loaded %d trip points\n", i, ret);
}
- priv->num_tscs = i;
-
if (!priv->num_tscs) {
ret = -ENODEV;
goto error_unregister;
--
2.14.1
[RFC 2/3] arm64: dts: r8a7795: update register size for thermal
To be able to read fused calibration values from hardware the size of
the register resource of TSC1 needs to be incremented to cover one more
register which holds the information if the calibration values have been
fused or not.
Signed-off-by: Niklas Söderlund
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 1818fd20660d0315..be3c7ff6999af57e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2805,7 +2805,7 @@
tsc: thermal@e6198000 {
compatible = "renesas,r8a7795-thermal";
- reg = <0 0xe6198000 0 0x68>,
+ reg = <0 0xe6198000 0 0x6c>,
<0 0xe61a 0 0x5c>,
<0 0xe61a8000 0 0x5c>;
interrupts = ,
--
2.14.1
[PATCH 2/2] arm64: dts: r8a7796: add thermal cooling management
Add nodes and properties for thermal cooling management support.
Signed-off-by: Niklas Söderlund
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 38
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 2905a3b953aab145..0b805dc30925e9be 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -53,6 +53,7 @@
<&cluster0_opp_tb3>, <&cluster0_opp_tb4>,
<&cluster0_opp_tb5>, <&cluster0_opp_tb6>,
<&cluster0_opp_tb7>;
+ #cooling-cells = <2>;
};
a57_1: cpu@1 {
@@ -67,6 +68,7 @@
<&cluster0_opp_tb3>, <&cluster0_opp_tb4>,
<&cluster0_opp_tb5>, <&cluster0_opp_tb6>,
<&cluster0_opp_tb7>;
+ #cooling-cells = <2>;
};
a53_0: cpu@100 {
@@ -2116,12 +2118,24 @@
thermal-sensors = <&tsc 0>;
trips {
+ sensor1_passive: sensor1-passive {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
sensor1_crit: sensor1-crit {
temperature = <12>;
hysteresis = <2000>;
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&sensor1_passive>;
+ cooling-device = <&a57_0 5 5>;
+ };
+ };
};
sensor_thermal2: sensor-thermal2 {
@@ -2130,12 +2144,24 @@
thermal-sensors = <&tsc 1>;
trips {
+ sensor2_passive: sensor2-passive {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
sensor2_crit: sensor2-crit {
temperature = <12>;
hysteresis = <2000>;
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&sensor2_passive>;
+ cooling-device = <&a57_0 5 5>;
+ };
+ };
};
sensor_thermal3: sensor-thermal3 {
@@ -2144,12 +2170,24 @@
thermal-sensors = <&tsc 2>;
trips {
+ sensor3_passive: sensor3-passive {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
sensor3_crit: sensor3-crit {
temperature = <12>;
hysteresis = <2000>;
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&sensor3_passive>;
+ cooling-device = <&a57_0 5 5>;
+ };
+ };
};
};
--
2.14.1
[PATCH 0/2] arm64: dts: r8a7795: r8a7796: add thermal cooling management
Hi, This series adds support for for using CPUFreq as a cooling device for the A57 CUP:s on Renesas H3 and M3-W SoC:s. It depends on Simon Horman's topic/rcar-gen3-cpufreq branch [1] and is tested on-top the latest renesas-drivers on H3 and M3-W. For test results and test procedure please see: http://elinux.org/R-Car/Tests:rcar_gen3_thermal Few notes on the specific values used in this series and why they might need to be changed. - The trip point temperature of 95000 used is the most conservative one from the BSP and maybe should be set at 11 which is the most aggressive one in the BSP. - The cooling states described in all cooling-maps nodes might be subject to change depending on the out-come of the ongoing review process of Simon's work. It should use the highest possible cooling state so if the number of states change due review of his work this should be reflected in this series. 1. https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git Niklas Söderlund (2): arm64: dts: r8a7795: add thermal cooling management arm64: dts: r8a7796: add thermal cooling management arch/arm64/boot/dts/renesas/r8a7795.dtsi | 40 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 38 ++ 2 files changed, 78 insertions(+) -- 2.14.1
[PATCH 1/2] arm64: dts: r8a7795: add thermal cooling management
Add nodes and properties for thermal cooling management support.
Signed-off-by: Niklas Söderlund
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 40
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 0ccac86bccc6b6f0..1818fd20660d0315 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -53,6 +53,7 @@
<&cluster0_opp_tb3>, <&cluster0_opp_tb4>,
<&cluster0_opp_tb5>, <&cluster0_opp_tb6>,
<&cluster0_opp_tb7>;
+ #cooling-cells = <2>;
};
a57_1: cpu@1 {
@@ -67,6 +68,7 @@
<&cluster0_opp_tb3>, <&cluster0_opp_tb4>,
<&cluster0_opp_tb5>, <&cluster0_opp_tb6>,
<&cluster0_opp_tb7>;
+ #cooling-cells = <2>;
};
a57_2: cpu@2 {
@@ -81,6 +83,7 @@
<&cluster0_opp_tb3>, <&cluster0_opp_tb4>,
<&cluster0_opp_tb5>, <&cluster0_opp_tb6>,
<&cluster0_opp_tb7>;
+ #cooling-cells = <2>;
};
a57_3: cpu@3 {
@@ -95,6 +98,7 @@
<&cluster0_opp_tb3>, <&cluster0_opp_tb4>,
<&cluster0_opp_tb5>, <&cluster0_opp_tb6>,
<&cluster0_opp_tb7>;
+ #cooling-cells = <2>;
};
a53_0: cpu@100 {
@@ -2821,12 +2825,24 @@
thermal-sensors = <&tsc 0>;
trips {
+ sensor1_passive: sensor1-passive {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
sensor1_crit: sensor1-crit {
temperature = <12>;
hysteresis = <2000>;
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&sensor1_passive>;
+ cooling-device = <&a57_0 4 4>;
+ };
+ };
};
sensor_thermal2: sensor-thermal2 {
@@ -2835,12 +2851,24 @@
thermal-sensors = <&tsc 1>;
trips {
+ sensor2_passive: sensor2-passive {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
sensor2_crit: sensor2-crit {
temperature = <12>;
hysteresis = <2000>;
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&sensor2_passive>;
+ cooling-device = <&a57_0 4 4>;
+ };
+ };
};
sensor_thermal3: sensor-thermal3 {
@@ -2849,12 +2877,24 @@
thermal-sensors = <&tsc 2>;
trips {
+ sensor3_passive: sensor3-passive {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
sensor3_crit: sensor3-crit {
temperature = <12>;
hysteresis = <2000>;
type = "critical";
};
};
+
+
[PATCH] thermal: rcar_gen3_thermal: fix initialization sequence for H3 ES2.0
The initialization sequence for H3 (r8a7795) ES1.x and ES2.0 is
different. H3 ES2.0 and later uses the same sequence as M3 (r8a7796)
ES1.0. Fix this by swapping place of the two initialization functions
and calling the r8a7796 init function from the r8a7795 init function if
the ES version is not "ES1.*".
Signed-off-by: Niklas Söderlund
---
drivers/thermal/rcar_gen3_thermal.c | 54 ++---
1 file changed, 33 insertions(+), 21 deletions(-)
diff --git a/drivers/thermal/rcar_gen3_thermal.c
b/drivers/thermal/rcar_gen3_thermal.c
index 203aca44a2bb4bdf..528a65b05b304ca3 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include "thermal_core.h"
@@ -278,48 +279,59 @@ static irqreturn_t rcar_gen3_thermal_irq_thread(int irq,
void *data)
return IRQ_HANDLED;
}
-static void r8a7795_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
+static const struct soc_device_attribute r8a7795es1[] = {
+ { .soc_id = "r8a7795", .revision = "ES1.*" },
+ { /* sentinel */ }
+};
+
+static void r8a7796_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
{
- rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR, CTSR_THBGR);
- rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR, 0x0);
+ u32 reg_val;
- usleep_range(1000, 2000);
+ reg_val = rcar_gen3_thermal_read(tsc, REG_GEN3_THCTR);
+ reg_val &= ~THCTR_PONM;
+ rcar_gen3_thermal_write(tsc, REG_GEN3_THCTR, reg_val);
- rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR, CTSR_PONM);
+ usleep_range(1000, 2000);
rcar_gen3_thermal_write(tsc, REG_GEN3_IRQCTL, 0x3F);
rcar_gen3_thermal_write(tsc, REG_GEN3_IRQMSK, 0);
rcar_gen3_thermal_write(tsc, REG_GEN3_IRQEN, IRQ_TEMPD1 | IRQ_TEMP2);
- rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR,
- CTSR_PONM | CTSR_AOUT | CTSR_THBGR | CTSR_VMEN);
-
- usleep_range(100, 200);
-
- rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR,
- CTSR_PONM | CTSR_AOUT | CTSR_THBGR | CTSR_VMEN |
- CTSR_VMST | CTSR_THSST);
+ reg_val = rcar_gen3_thermal_read(tsc, REG_GEN3_THCTR);
+ reg_val |= THCTR_THSST;
+ rcar_gen3_thermal_write(tsc, REG_GEN3_THCTR, reg_val);
usleep_range(1000, 2000);
}
-static void r8a7796_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
+static void r8a7795_thermal_init(struct rcar_gen3_thermal_tsc *tsc)
{
- u32 reg_val;
+ /* H3 ES2.0 and later uses same initialization sequence as M3 ES1.0 */
+ if (!soc_device_match(r8a7795es1)) {
+ r8a7796_thermal_init(tsc);
+ return;
+ }
- reg_val = rcar_gen3_thermal_read(tsc, REG_GEN3_THCTR);
- reg_val &= ~THCTR_PONM;
- rcar_gen3_thermal_write(tsc, REG_GEN3_THCTR, reg_val);
+ rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR, CTSR_THBGR);
+ rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR, 0x0);
usleep_range(1000, 2000);
+ rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR, CTSR_PONM);
+
rcar_gen3_thermal_write(tsc, REG_GEN3_IRQCTL, 0x3F);
rcar_gen3_thermal_write(tsc, REG_GEN3_IRQMSK, 0);
rcar_gen3_thermal_write(tsc, REG_GEN3_IRQEN, IRQ_TEMPD1 | IRQ_TEMP2);
- reg_val = rcar_gen3_thermal_read(tsc, REG_GEN3_THCTR);
- reg_val |= THCTR_THSST;
- rcar_gen3_thermal_write(tsc, REG_GEN3_THCTR, reg_val);
+ rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR,
+ CTSR_PONM | CTSR_AOUT | CTSR_THBGR | CTSR_VMEN);
+
+ usleep_range(100, 200);
+
+ rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR,
+ CTSR_PONM | CTSR_AOUT | CTSR_THBGR | CTSR_VMEN |
+ CTSR_VMST | CTSR_THSST);
usleep_range(1000, 2000);
}
--
2.14.1
[PATCH v2] arm64: dts: renesas: r8a77995: add GPIO device nodes
This patch adds GPIO device nodes for r8a77995.
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Yoshihiro Shimoda
---
Changes from v1:
- Change power-domains property in each node.
- Add Reviewed-by (Thanks Geert-san!).
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 112 ++
1 file changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 84b6bd5..d7756256 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -139,6 +139,118 @@
#power-domain-cells = <1>;
};
+ gpio0: gpio@e605 {
+ compatible = "renesas,gpio-r8a77995",
+"renesas,rcar-gen3-gpio",
+"renesas,gpio-rcar";
+ reg = <0 0xe605 0 0x50>;
+ interrupts = ;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 0 9>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 912>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 912>;
+ };
+
+ gpio1: gpio@e6051000 {
+ compatible = "renesas,gpio-r8a77995",
+"renesas,rcar-gen3-gpio",
+"renesas,gpio-rcar";
+ reg = <0 0xe6051000 0 0x50>;
+ interrupts = ;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 32 32>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 911>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 911>;
+ };
+
+ gpio2: gpio@e6052000 {
+ compatible = "renesas,gpio-r8a77995",
+"renesas,rcar-gen3-gpio",
+"renesas,gpio-rcar";
+ reg = <0 0xe6052000 0 0x50>;
+ interrupts = ;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 64 32>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 910>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 910>;
+ };
+
+ gpio3: gpio@e6053000 {
+ compatible = "renesas,gpio-r8a77995",
+"renesas,rcar-gen3-gpio",
+"renesas,gpio-rcar";
+ reg = <0 0xe6053000 0 0x50>;
+ interrupts = ;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 96 10>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 909>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 909>;
+ };
+
+ gpio4: gpio@e6054000 {
+ compatible = "renesas,gpio-r8a77995",
+"renesas,rcar-gen3-gpio",
+"renesas,gpio-rcar";
+ reg = <0 0xe6054000 0 0x50>;
+ interrupts = ;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 128 32>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 908>;
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 908>;
+ };
+
+ gpio5: gpio@e6055000 {
+ compatible = "renesas,gpio-r8a77995",
+"renesas,rcar-gen3-gpio",
+"renesas,gpio-rcar";
+ reg = <0 0xe6055000 0 0x50>;
+ interrupts = ;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 160 21>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ clocks = <&cpg CPG_MOD 907>;
+ power-domains = <&sysc R8A77995
RE: [PATCH] arm64: dts: renesas: r8a77995: add GPIO device nodes
Hi Geert-san,
> From: Geert Uytterhoeven
> Sent: Wednesday, September 13, 2017 6:22 PM
>
> Hi Shimoda-san,
>
> On Wed, Sep 13, 2017 at 8:52 AM, Yoshihiro Shimoda
> wrote:
> > This patch adds GPIO device nodes for r8a77995.
> >
> > Signed-off-by: Yoshihiro Shimoda
>
> Thanks for your patch!
>
> > --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > @@ -139,6 +139,118 @@
> > #power-domain-cells = <1>;
> > };
> >
> > + gpio0: gpio@e605 {
> > + compatible = "renesas,gpio-r8a77995",
> > +"renesas,rcar-gen3-gpio",
> > +"renesas,gpio-rcar";
> > + reg = <0 0xe605 0 0x50>;
> > + interrupts = ;
> > + #gpio-cells = <2>;
> > + gpio-controller;
> > + gpio-ranges = <&pfc 0 0 9>;
> > + #interrupt-cells = <2>;
> > + interrupt-controller;
> > + clocks = <&cpg CPG_MOD 912>;
> > + power-domains = <&cpg>;
>
> All nodes lack the power domain index (32, to be replaced by
> R8A77995_PD_ALWAYS_ON later):
>
> power-domains = <&sysc 32>;
The r8a77995.dtsi file already uses R8A77995_PD_ALWAYS_ON in scif2 node.
So, should I fix this patch like the following?
power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> > + resets = <&cpg 912>;
> > + };
>
> With that fixed:
> Reviewed-by: Geert Uytterhoeven
Thank you for the review!
Best regards,
Yoshihiro Shimoda
> 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: r8a77995: add GPIO device nodes
Hi Shimoda-san,
On Wed, Sep 13, 2017 at 8:52 AM, Yoshihiro Shimoda
wrote:
> This patch adds GPIO device nodes for r8a77995.
>
> Signed-off-by: Yoshihiro Shimoda
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -139,6 +139,118 @@
> #power-domain-cells = <1>;
> };
>
> + gpio0: gpio@e605 {
> + compatible = "renesas,gpio-r8a77995",
> +"renesas,rcar-gen3-gpio",
> +"renesas,gpio-rcar";
> + reg = <0 0xe605 0 0x50>;
> + interrupts = ;
> + #gpio-cells = <2>;
> + gpio-controller;
> + gpio-ranges = <&pfc 0 0 9>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + clocks = <&cpg CPG_MOD 912>;
> + power-domains = <&cpg>;
All nodes lack the power domain index (32, to be replaced by
R8A77995_PD_ALWAYS_ON later):
power-domains = <&sysc 32>;
> + resets = <&cpg 912>;
> + };
With that fixed:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] gpio: rcar: Add r8a77995 (R-Car D3) support
On Wed, Sep 13, 2017 at 8:48 AM, Yoshihiro Shimoda
wrote:
> This patch adds binding for r8a77995 (R-Car D3). This SoC can use
> "renesas,rcar-gen3-gpio" fallback compatibility. So, this patch
> doesn't modify the gpio-rcar driver.
>
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 05/11] arm64: dts: renesas: initial R8A77970 SoC device tree
Hi Sergei,
On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov
wrote:
> The initial R8A77970 SoC device tree including Cortex-A53 CPU, GIC, timer,
> CPG, RST, and SYSC.
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
>
> ---
> arch/arm64/boot/dts/renesas/r8a77970.dtsi | 126
> ++
> 1 file changed, 126 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> ===
> --- /dev/null
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> @@ -0,0 +1,126 @@
> +/*
> + * Device Tree Source for the r8a77970 SoC
> + *
> + * Copyright (C) 2016-2017 Renesas Electronics Corp.
> + * Copyright (C) 2017 Cogent Embedded, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include
> +#include
arm-gic.h includes irq.h.
> +#include
> +#include
You can avoid the dependency on the above header, which will go upstream
through a different branch, by hardcoding the power area indices for the
initial submission, like you already did for the CPG core clocks.
> +
> +/ {
> + compatible = "renesas,r8a77970";
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + psci {
> + compatible = "arm,psci-1.0";
PSCI 1.0 is backwards compatible with PSI 0.2:
compatible = "arm,psci-1.0", "arm,psci-0.2";
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [git:media_tree/master] media: adv7180: add missing adv7180cp, adv7180st i2c device IDs
On Thu, Jul 20, 2017 at 12:54 PM, Mauro Carvalho Chehab
wrote:
> This is an automatic generated email to let you know that the following patch
> were queued:
>
> Subject: media: adv7180: add missing adv7180cp, adv7180st i2c device IDs
> Author: Ulrich Hecht
> Date:Mon Jul 3 04:43:33 2017 -0400
>
> Fixes a crash on Renesas R8A7793 Gose board that uses these "compatible"
> entries.
>
> Signed-off-by: Ulrich Hecht
> Tested-by: Geert Uytterhoeven
> Signed-off-by: Hans Verkuil
> Signed-off-by: Mauro Carvalho Chehab
Fixes: ce1ec5c07e0671cc ("[media] media: adv7180: add adv7180cp,
adv7180st compatible strings")
This fix is now upstream, as commit 281ddc3cdc10413b ("media: adv7180: add
missing adv7180cp, adv7180st i2c device IDs").
Greg: Can you please backport it to v3.14.x?
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 04/11] soc: renesas: rcar-sysc: add R8A77970 support
Hi Sergei,
On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov
wrote:
> Add support for R-Car V3M (R8A77970) SoC power areas to the R-Car SYSC
> driver.
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
> --- /dev/null
> +++ renesas/drivers/soc/renesas/r8a77970-sysc.c
> @@ -0,0 +1,39 @@
> +#include
I think this include is no longer needed since commit c7acec713d14c6ce
("kernel.h: handle pointers to arrays better in container_of()").
> +static const struct rcar_sysc_area r8a77970_areas[] __initconst = {
> + { "a3ir", 0x180, 0, R8A77970_PD_A3IR, R8A77970_PD_ALWAYS_ON
> },
> + { "a2ir0", 0x400, 0, R8A77970_PD_A2IR0,R8A77970_PD_ALWAYS_ON
> },
> + { "a2ir1", 0x400, 1, R8A77970_PD_A2IR1,R8A77970_PD_A2IR0 },
> + { "a2ir2", 0x400, 2, R8A77970_PD_A2IR2,R8A77970_PD_A2IR0 },
> + { "a2ir3", 0x400, 3, R8A77970_PD_A2IR3,R8A77970_PD_A2IR0 },
> + { "a2sc0", 0x400, 4, R8A77970_PD_A2SC0,R8A77970_PD_ALWAYS_ON
> },
> + { "a2sc1", 0x400, 5, R8A77970_PD_A2SC1,R8A77970_PD_A2SC0 },
According to Figure 9.2(b) "Power domain structure (R-Car V3M)" and Table 9.4
"Power domains", all of A2IR[0-3] and A2SC[01] are direct children of A3IR.
BTW, the bit indices "4" resp. "5" for A2SC[01] don't match Section 9.2.5
"Power Control Registers for A2IR" (which uses "0" resp. "1"), but I assume
that's just a typo in the datasheet, as those would conflict with A2IR[01], and
the would conflict with the documentation for other R-Car Gen3 SoCs.
With the above fixed:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 03/11] dt-bindings: power: add R8A77970 SYSC power domain definitions
On Wed, Sep 13, 2017 at 10:11:31AM +0200, Geert Uytterhoeven wrote: > On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov > wrote: > > Add macros usable by the device tree sources to reference R8A77970 SYSC > > power domains by index. > > > > Based on the original (and large) patch by Daisuke Matsushita > > . > > > > Signed-off-by: Vladimir Barinov > > Signed-off-by: Sergei Shtylyov > > Reviewed-by: Geert Uytterhoeven Thanks, applied.
Re: [PATCH 01/11] soc: renesas: identify R-Car V3M
On Wed, Sep 13, 2017 at 09:59:42AM +0200, Geert Uytterhoeven wrote: > On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov > wrote: > > Add support for identifying the R-Car V3M (R8A77970) SoC. > > > > Signed-off-by: Sergei Shtylyov > > (identical to what I wrote for topic/r8a77970-integration, which is no > surprise ;-) > > Reviewed-by: Geert Uytterhoeven Thanks, applied.
Re: [PATCH 03/11] dt-bindings: power: add R8A77970 SYSC power domain definitions
On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov
wrote:
> Add macros usable by the device tree sources to reference R8A77970 SYSC
> power domains by index.
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 01/11] soc: renesas: identify R-Car V3M
On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov
wrote:
> Add support for identifying the R-Car V3M (R8A77970) SoC.
>
> Signed-off-by: Sergei Shtylyov
(identical to what I wrote for topic/r8a77970-integration, which is no
surprise ;-)
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 02/11] soc: renesas: rcar-rst: add R8A77970 support
On Wed, Sep 13, 2017 at 09:52:23AM +0200, Geert Uytterhoeven wrote: > On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov > wrote: > > Add support for R-Car V3M (R8A77970) to the R-Car RST driver -- this driver > > is needed for the clock driver to work. > > > > Signed-off-by: Sergei Shtylyov > > Reviewed-by: Geert Uytterhoeven Thanks, applied.
Re: [PATCH] ravb: document R8A77970 bindings
On Tue, Sep 12, 2017 at 10:02 PM, Sergei Shtylyov
wrote:
> R-Car V3M (R8A77970) SoC also has the R-Car gen3 compatible EtherAVB
> device, so document the SoC specific bindings.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [PATCH] arm64: dts: renesas: r8a77995: add GPIO device nodes
Hi Simon-san,
> From: Simon Horman
> Sent: Wednesday, September 13, 2017 4:50 PM
>
> On Wed, Sep 13, 2017 at 03:52:08PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds GPIO device nodes for r8a77995.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > This patch should be applied after the following patch is applied:
> > "gpio: rcar: Add r8a77995 (R-Car D3) support".
>
> I think it can be applied in parallel with that patch as the driver
> will match on "renesas,rcar-gen3-gpio". Right?
That's right.
My little concern was checkpatch.pl output warning if we didn't applied
the gpio patch :)
Best regards,
Yoshihiro Shimoda
> > arch/arm64/boot/dts/renesas/r8a77995.dtsi | 112
> > ++
> > 1 file changed, 112 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > index 84b6bd5..a1c9271 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > @@ -139,6 +139,118 @@
> > #power-domain-cells = <1>;
> > };
> >
> > + gpio0: gpio@e605 {
> > + compatible = "renesas,gpio-r8a77995",
> > +"renesas,rcar-gen3-gpio",
> > +"renesas,gpio-rcar";
> > + reg = <0 0xe605 0 0x50>;
> > + interrupts = ;
> > + #gpio-cells = <2>;
> > + gpio-controller;
> > + gpio-ranges = <&pfc 0 0 9>;
> > + #interrupt-cells = <2>;
> > + interrupt-controller;
> > + clocks = <&cpg CPG_MOD 912>;
> > + power-domains = <&cpg>;
> > + resets = <&cpg 912>;
> > + };
>
> ...
Re: [PATCH 02/11] soc: renesas: rcar-rst: add R8A77970 support
On Tue, Sep 12, 2017 at 10:37 PM, Sergei Shtylyov
wrote:
> Add support for R-Car V3M (R8A77970) to the R-Car RST driver -- this driver
> is needed for the clock driver to work.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm64: dts: renesas: r8a77995: add GPIO device nodes
On Wed, Sep 13, 2017 at 03:52:08PM +0900, Yoshihiro Shimoda wrote:
> This patch adds GPIO device nodes for r8a77995.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> This patch should be applied after the following patch is applied:
> "gpio: rcar: Add r8a77995 (R-Car D3) support".
I think it can be applied in parallel with that patch as the driver
will match on "renesas,rcar-gen3-gpio". Right?
> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 112
> ++
> 1 file changed, 112 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> index 84b6bd5..a1c9271 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -139,6 +139,118 @@
> #power-domain-cells = <1>;
> };
>
> + gpio0: gpio@e605 {
> + compatible = "renesas,gpio-r8a77995",
> + "renesas,rcar-gen3-gpio",
> + "renesas,gpio-rcar";
> + reg = <0 0xe605 0 0x50>;
> + interrupts = ;
> + #gpio-cells = <2>;
> + gpio-controller;
> + gpio-ranges = <&pfc 0 0 9>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + clocks = <&cpg CPG_MOD 912>;
> + power-domains = <&cpg>;
> + resets = <&cpg 912>;
> + };
...
Re: sh: sh7758 User land programs crash with SIGBUS.
CC linux-sh On Wed, Sep 13, 2017 at 12:00 AM, wrote: > Hi, > > I am trying to port from 3.4.11 kernel to 3.10.107 based on my sh7757/58 > processor hardware and running into some odd behavior with user land > applications. I pretty much got the kernel up and running but some of the > applications in user land won't launch and are crashing with the below > messages in dmesg. > > <5>Fixing up unaligned userspace access in "aim" pid=28533 pc=0x3b142492 > ins=0x6252 > <5>Sending SIGBUS to "aim" pid=28533 due to unaligned access (PC 3b142492 PR > 296167e4) ins=0x6252 > <5>Sending SIGBUS to "pm" pid=28741 due to unaligned access (PC 58b2e409 PR > 297b0118) ins=0x8dc1 > <5>Sending SIGBUS to "pm" pid=28741 due to unaligned access (PC 3b142492 PR > 296ce7e4) ins=0x6252 > > Some of the older posts in the mailing lists pointed out to I/D cache issues, > I tried disabling the cache altogether in a hope to root cause the issue, but > still got the same responses. For some reason I believe the loader is loading > these programs into odd addresses. I am clueless as to where to look for the > possible issue. Is there any obvious settings that I am missing from the > board/cpu setup ? > > Any expert help and guidance is really appreciated. > > Thanks, > Prashanth
Re: [PATCH] gpio: rcar: Add r8a77995 (R-Car D3) support
On Wed, Sep 13, 2017 at 03:48:49PM +0900, Yoshihiro Shimoda wrote: > This patch adds binding for r8a77995 (R-Car D3). This SoC can use > "renesas,rcar-gen3-gpio" fallback compatibility. So, this patch > doesn't modify the gpio-rcar driver. > > Signed-off-by: Yoshihiro Shimoda Acked-by: Simon Horman
Re: [PATCH 02/11] soc: renesas: rcar-rst: add R8A77970 support
On Tue, Sep 12, 2017 at 11:37:18PM +0300, Sergei Shtylyov wrote: > Add support for R-Car V3M (R8A77970) to the R-Car RST driver -- this driver > is needed for the clock driver to work. > > Signed-off-by: Sergei Shtylyov Reviewed-by: Simon Horman
Re: [PATCH] ravb: document R8A77970 bindings
On Tue, Sep 12, 2017 at 11:02:08PM +0300, Sergei Shtylyov wrote: > R-Car V3M (R8A77970) SoC also has the R-Car gen3 compatible EtherAVB > device, so document the SoC specific bindings. > > Signed-off-by: Sergei Shtylyov Acked-by: Simon Horman > --- > The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if it's > applied to 'net.git' instead. :-) Personally I would prefer net-next, but I don't feel strongly about this. If you want it considered for net then I think it is likely that you will need to repost it with the appropriate patch prefix. > > Documentation/devicetree/bindings/net/renesas,ravb.txt |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt > === > --- net-next.orig/Documentation/devicetree/bindings/net/renesas,ravb.txt > +++ net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt > @@ -17,6 +17,7 @@ Required properties: > >- "renesas,etheravb-r8a7795" for the R8A7795 SoC. >- "renesas,etheravb-r8a7796" for the R8A7796 SoC. > + - "renesas,etheravb-r8a77970" for the R8A77970 SoC. >- "renesas,etheravb-rcar-gen3" as a fallback for the above > R-Car Gen3 devices. > > @@ -40,7 +41,7 @@ Optional properties: > - interrupt-parent: the phandle for the interrupt controller that services > interrupts for this device. > - interrupt-names: A list of interrupt names. > -For the R8A779[56] SoCs this property is mandatory; > +For the R-Car Gen 3 SoCs this property is mandatory; > it should include one entry per channel, named "ch%u", > where %u is the channel number ranging from 0 to 24. > For other SoCs this property is optional; if present >
Re: [PATCH 0/5] ARM: dts: rcar-gen2: Add reset control properties
On Mon, Sep 11, 2017 at 03:09:54PM +0200, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This patch series describes the reset topology on all R-Car Gen2 Socs, like > was done before for R-Car Gen3 and RZ/G1. > > Resets usually match the corresponding module clocks. Exceptions are: > - The audio module has resets for the Serial Sound Interfaces only, > - The display module has only a single reset for all DU channels, but > adding reset properties for the display is postponed upon request from > Laurent. > > Note that this patch series contains hardware description only. > Actual reset policy is to be defined and implemented separately. > Also, this is an optional feature, to be enabled explicitly using > CONFIG_RESET_CONTROLLER=y. When enabled, an on-SoC device can be reset > easily using device_reset(), or by using the reset_control_*() API when > more fine-grained control is desired. > > Possible use cases are (not exhaustive): > - Reset a device before use, to make sure it's in a predefined state, and > doesn't depend on earlier configuration by e.g. the boot loader, > - Reset a device after detecting an anomaly, > - Reset a device to verify suspend/resume is handled correctly by the > driver in case the device would be part of a power domain on a > different/future SoC. > > This has been tested on r8a7790/lager, r8a7791/koelsch, r8a7792/blanche, > and r8a7794/alt (r8a7793/gose was offline). > > Thanks for applying! > > Geert Uytterhoeven (5): > ARM: dts: r8a7790: Add reset control properties > ARM: dts: r8a7791: Add reset control properties > ARM: dts: r8a7792: Add reset control properties > ARM: dts: r8a7793: Add reset control properties > ARM: dts: r8a7794: Add reset control properties Thanks, applied.
Re: [PATCH v2] MAINTAINERS: Add Renesas SoC DT bindings doc to Renesas ARM sections
On Mon, Sep 11, 2017 at 01:01:43PM +0200, Geert Uytterhoeven wrote: > Suggested-by: Sergei Shtylyov > Signed-off-by: Geert Uytterhoeven Thanks, applied.
Re: [PATCH v2 0/2] Renesas R8A77970 CPG/MSSR clock support
On Mon, Sep 11, 2017 at 04:38:43PM +0200, Geert Uytterhoeven wrote: > Hi Sergei, > > On Fri, Sep 8, 2017 at 11:34 PM, Sergei Shtylyov > wrote: > >Here's the set of 2 patches against the 'clk-next' branch of CLK group's > > 'linux.git' repo. > > Thank you, looks good! > > > As the DT patches in the R8A77970/Eagle board support series > > depend on the patch #1 of this series, it might make sense to merge this > > patch > > to the 'renesas.git' repo as well... > > > > [1/2] dt-bindings: clock: add R8A77970 CPG core clock definitions > > The modern way to avoid this dependency is to use hardcoded numbers in > the initial submission of the DTS, cfr. > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/commit/?h=arm64-dt-for-v4.15&id=d917e0b24811eadeba419ba7318b967ee15933b3 > > After the definitions have hit upstream, you can replace the hardcoded > numbers by symbols, cfr. > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?h=topic/r8a77995-integration&id=d3f6987db28a4657bf3304eeeb8e2cd8dd510ad0 > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?h=topic/r8a77995-integration&id=81426223583d5575767c77684be28c40034785bd > > So I don't think Simon will merge the core clock definitions patch, unless > you plan to submit a full DTS describing the whole SoC in the initial > submissiong. Thanks, I would prefer if the DT patches followed the scheme described by Geert such that they do not depend on any part of this series. I expect that will allow the smoothest path for acceptance of those patches.
