Re: [PATCH] net: ethernet: ravb: Fix release of refclk
On Mon, Apr 19, 2021 at 5:45 PM David Miller wrote:
>
> From: Adam Ford
> Date: Sat, 17 Apr 2021 08:23:29 -0500
>
> > The call to clk_disable_unprepare() can happen before priv is
> > initialized. This means moving clk_disable_unprepare out of
> > out_release into a new label.
> >
> > Fixes: 8ef7adc6beb2("net: ethernet: ravb: Enable optional refclk")
> > Signed-off-by: Adam Ford
> Thjis does not apply cleanly, please rebbase and resubmit.
Which branch should I use as the rebase? I used net-next because
that's where the bug is, but I know it changes frequently.
>
> Please fix the formatting of your Fixes tag while you are at it, thank you.
no problem. Sorry about that
adam
Re: [PATCH V3 5/5] arm64: dts: renesas: beacon kits: Setup AVB refclk
On Thu, Mar 4, 2021 at 2:04 AM Geert Uytterhoeven wrote:
>
> On Wed, Feb 24, 2021 at 12:52 PM Adam Ford wrote:
> > The AVB refererence clock assumes an external clock that runs
>
> reference
>
> > automatically. Because the Versaclock is wired to provide the
> > AVB refclock, the device tree needs to reference it in order for the
> > driver to start the clock.
> >
> > Signed-off-by: Adam Ford
>
> Reviewed-by: Geert Uytterhoeven
> i.e. will queue in renesas-devel (with the typo fixed) once the DT
> bindings have been accepted.
Geert,
Since the refclk update and corresponding dt-bindings are in net-next,
are you OK applying the rest of the DT changes so they can get into
5.13?
adam
>
> 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] net: ethernet: ravb: Fix release of refclk
The call to clk_disable_unprepare() can happen before priv is
initialized. This means moving clk_disable_unprepare out of
out_release into a new label.
Fixes: 8ef7adc6beb2("net: ethernet: ravb: Enable optional refclk")
Signed-off-by: Adam Ford
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index 8c84c40ab9a0..64a545c98ff2 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2173,7 +2173,7 @@ static int ravb_probe(struct platform_device *pdev)
/* Set GTI value */
error = ravb_set_gti(ndev);
if (error)
- goto out_release;
+ goto out_unprepare_refclk;
/* Request GTI loading */
ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
@@ -2192,7 +2192,7 @@ static int ravb_probe(struct platform_device *pdev)
"Cannot allocate desc base address table (size %d
bytes)\n",
priv->desc_bat_size);
error = -ENOMEM;
- goto out_release;
+ goto out_unprepare_refclk;
}
for (q = RAVB_BE; q < DBAT_ENTRY_NUM; q++)
priv->desc_bat[q].die_dt = DT_EOS;
@@ -2252,8 +2252,9 @@ static int ravb_probe(struct platform_device *pdev)
/* Stop PTP Clock driver */
if (chip_id != RCAR_GEN2)
ravb_ptp_stop(ndev);
-out_release:
+out_unprepare_refclk:
clk_disable_unprepare(priv->refclk);
+out_release:
free_netdev(ndev);
pm_runtime_put(>dev);
--
2.25.1
Re: [PATCH V4 2/2] net: ethernet: ravb: Enable optional refclk
On Tue, Apr 13, 2021 at 2:33 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> On Mon, Apr 12, 2021 at 3:27 PM Adam Ford wrote:
> > For devices that use a programmable clock for the AVB reference clock,
> > the driver may need to enable them. Add code to find the optional clock
> > and enable it when available.
> >
> > Signed-off-by: Adam Ford
> > Reviewed-by: Andrew Lunn
> >
> > ---
> > V4: Eliminate the NULL check when disabling refclk, and add a line
> > to disable the refclk if there is a failure after it's been
> > initialized.
>
> Thanks for the update!
>
> > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > @@ -2148,6 +2148,13 @@ static int ravb_probe(struct platform_device *pdev)
> > goto out_release;
> > }
> >
> > + priv->refclk = devm_clk_get_optional(>dev, "refclk");
> > + if (IS_ERR(priv->refclk)) {
> > + error = PTR_ERR(priv->refclk);
> > + goto out_release;
>
> Note that this will call clk_disable_unprepare() in case of failure, which is
> fine, as that function is a no-op in case of a failed clock.
Geert,
A bot reported that if I jump to out_release may try to free a clock
if some instances where priv isn't defined.
Currently, the priv->clk isn't freed either. I have heard some
back-and-forth discussions in other threads on whether or not devm
functions auto free or not.
I'm fine with sending a V5 to make the free for the refclock happen
only when the priv has successfully initialized. Should I also add
one for freeing priv->clk and change all the other goto out_release
commands to point to this new section?
I am thinking it would like something like:
free_refclk:
clk_disable_unprepare(priv->refclk);
free_clk;
clk_disable_unprepare(priv->clk);
out_release:
free_netdev(ndev);
adam
>
> > + }
> > + clk_prepare_enable(priv->refclk);
> > +
> > ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
> > ndev->min_mtu = ETH_MIN_MTU;
> >
> > @@ -2244,6 +2251,7 @@ static int ravb_probe(struct platform_device *pdev)
> > if (chip_id != RCAR_GEN2)
> > ravb_ptp_stop(ndev);
> > out_release:
> > + clk_disable_unprepare(priv->refclk);
> > free_netdev(ndev);
> >
> > pm_runtime_put(>dev);
>
> 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
[PATCH V4 2/2] net: ethernet: ravb: Enable optional refclk
For devices that use a programmable clock for the AVB reference clock,
the driver may need to enable them. Add code to find the optional clock
and enable it when available.
Signed-off-by: Adam Ford
Reviewed-by: Andrew Lunn
---
V4: Eliminate the NULL check when disabling refclk, and add a line
to disable the refclk if there is a failure after it's been
initialized.
V3: Change 'avb' to 'AVB'
Remove unnessary else statement and pointer maniupluation when
enabling the refclock.
Add disable_unprepare call in remove funtion.
V2: The previous patch to fetch the fclk was dropped. In its place
is code to enable the refclk
diff --git a/drivers/net/ethernet/renesas/ravb.h
b/drivers/net/ethernet/renesas/ravb.h
index cb47e68c1a3e..86a1eb0634e8 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -993,6 +993,7 @@ struct ravb_private {
struct platform_device *pdev;
void __iomem *addr;
struct clk *clk;
+ struct clk *refclk;
struct mdiobb_ctrl mdiobb;
u32 num_rx_ring[NUM_RX_QUEUE];
u32 num_tx_ring[NUM_TX_QUEUE];
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index eb0c03bdb12d..1409ae986aa2 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2148,6 +2148,13 @@ static int ravb_probe(struct platform_device *pdev)
goto out_release;
}
+ priv->refclk = devm_clk_get_optional(>dev, "refclk");
+ if (IS_ERR(priv->refclk)) {
+ error = PTR_ERR(priv->refclk);
+ goto out_release;
+ }
+ clk_prepare_enable(priv->refclk);
+
ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
ndev->min_mtu = ETH_MIN_MTU;
@@ -2244,6 +2251,7 @@ static int ravb_probe(struct platform_device *pdev)
if (chip_id != RCAR_GEN2)
ravb_ptp_stop(ndev);
out_release:
+ clk_disable_unprepare(priv->refclk);
free_netdev(ndev);
pm_runtime_put(>dev);
@@ -2260,6 +2268,8 @@ static int ravb_remove(struct platform_device *pdev)
if (priv->chip_id != RCAR_GEN2)
ravb_ptp_stop(ndev);
+ clk_disable_unprepare(priv->refclk);
+
dma_free_coherent(ndev->dev.parent, priv->desc_bat_size, priv->desc_bat,
priv->desc_bat_dma);
/* Set reset mode */
--
2.17.1
[PATCH V4 1/2] dt-bindings: net: renesas,etheravb: Add additional clocks
The AVB driver assumes there is an external crystal, but it could be clocked by other means. In order to enable a programmable clock, it needs to be added to the clocks list and enabled in the driver. Since there currently only one clock, there is no clock-names list either. Update bindings to add the additional optional clock, and explicitly name both of them. Signed-off-by: Adam Ford Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring Reviewed-by: Sergei Shtylyov --- V4: No Change V3: No Change V2: No Change diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index 91ba96d43c6c..fe72a5598add 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -50,7 +50,16 @@ properties: interrupt-names: true clocks: -maxItems: 1 +minItems: 1 +maxItems: 2 +items: + - description: AVB functional clock + - description: Optional TXC reference clock + + clock-names: +items: + - const: fck + - const: refclk iommus: maxItems: 1 -- 2.17.1
Re: [PATCH v1 0/7] imx-gpcv2 improvements
On Wed, Apr 7, 2021 at 8:27 PM Peng Fan (OSS) wrote: > > Hi Lucas, > > On 2021/4/8 6:13, Lucas Stach wrote: > > Hi Adrien, > > > > I feel like I already mentioned to you some time ago that there is > > already a much more complete patch series to add this functionality on > > the list [1]. > > > > If you want this functionality to go upstream, please help test and > > extend this patch series. > > > > Regards, > > Lucas > > > > [1] > > https://lore.kernel.org/linux-arm-kernel/20201105174434.1817539-1-l.st...@pengutronix.de/ > > Would you share what's the issue that block this going forward? Peng, I know of a few. One of them is mentioned in [1] above. From what I can tell, the dt-bindings have halted being able to enable the GPU and USB power domains. See [2] for some of that dialog. The second part that I am aware is the blk-ctl being dependent on the power domain and the power domain being dependent on the blk-ctl [3] There was some discussion of using syscon to let the power-domain finish coming up and then referencing the the power-domain from the blk-ctl, but there was some disagreement [4] on that approach I think Abel tried to create an IRC, but by the time I was able to join the IRC, there was no activity. [2] - https://lore.kernel.org/linux-arm-kernel/cahcn7xldked0g3fa9gap-xvkz-bymvcyn-8oebgnjbjycco...@mail.gmail.com/ [3] - https://lkml.org/lkml/2020/11/9/17 [4] - https://www.spinics.net/lists/arm-kernel/msg849032.html > > Thanks, > Peng. > > > > > Am Mittwoch, dem 07.04.2021 um 23:21 +0200 schrieb Adrien Grassein: > >> Hi, > >> > >> This patch set aims is to add the support of the i.MX8 MM power domains > >> on the mainline kernel. > >> > >> To achieve this, I do several patches > >>- Check errors when reading or writing registers (concerns i.MX8M base > >> implementation); > >>- Fix power up/down sequence. Handshake was not checked and it was > >> not called at the appropriate time (concerns i.MX8M base > >> implementaions); > >>- Allow domains without power sequence control like the HSIOMIX of the > >> i.MX8MM. > >>- Add some i.MX8MM domains (HSIO and OTGS); > >>- Introduce quirks. For example, i.MX8MM OTG domains should not be > >> powered off (seen n the source code of th i.MX ATF). Quirks are > >> easily upgrable for other cases. > >>- Finally I defined power domains into the imx8mm.dtb file. > >> > >> I know that this kind of patch is rejected by NXP ut the other way > >> (callin ATF directly) was also rejected. > >> > >> I also know that NXP is concerned abou adding hundred lines of codes for > >> each new SOC but it' the way it works on Linux. And the "added code" > >> mainly consist of adding structures, defines and generic methods for > >> regmap. > >> > >> If it's a real problem, maybe we can introduc a new "gpcv3" driver for > >> i.MX8MM, i.MX8MN and i.MX8MP. > >> > >> Thanks, > >> > >> Adrien Grassein (7): > >>soc: imx: gpcv2: check for errors when r/w registers > >>soc: imx: gpcv2: Fix power up/down sequence > >>soc: imx: gpcv2: allow domains without power sequence control > >>dt-bindings: power: fsl,imx-gpcv2: add definitions for i.MX8MM > >>soc: imx: gpcv2: add HSIOMIX and USB domains for i.MX8MM > >>soc: imx: gpcv2: add quirks to domains > >>arm64: dts: imx8mm: add power-domains > >> > >> .../bindings/power/fsl,imx-gpcv2.yaml | 7 +- > >> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 35 ++ > >> drivers/soc/imx/gpcv2.c | 336 ++ > >> include/dt-bindings/power/imx8mm-power.h | 21 ++ > >> 4 files changed, 333 insertions(+), 66 deletions(-) > >> create mode 100644 include/dt-bindings/power/imx8mm-power.h > >> > > > >
Re: [PATCH v1 0/7] imx-gpcv2 improvements
On Wed, Apr 7, 2021 at 5:13 PM Lucas Stach wrote: > > Hi Adrien, > > I feel like I already mentioned to you some time ago that there is > already a much more complete patch series to add this functionality on > the list [1]. > > If you want this functionality to go upstream, please help test and > extend this patch series. > > Regards, > Lucas > > [1] > https://lore.kernel.org/linux-arm-kernel/20201105174434.1817539-1-l.st...@pengutronix.de/ I took Lucas' code and attempted to build upon it to add Nano support. At some point, someone from NXP thought it would get really hard to read if we started filling that file with every supported SoC. To help with that, I created a patch to split the gpcv2 code into a gcpv2 core functions with the individual SoC's having separate files to help keep things a little cleaner, and easier to read: gpcv2-imx7, gpcv2-imx8mq, gpcv2-imx8mm, and gpcv2-imx8mn, etc. I was holding off on doing anything with it, because the dt-bindings appeared to be stalled, and the attempt by Lucas to get the basic functionality was stalled. As of right now, it seems like without any changes, I can not get my Mini or Nano to wake from sleep unless I use a U-Boot and ATF based on NXP's custom branches. When using the custom branches, I made some additional patches to the gpcv2 to add a flag which would prevent disabling USB OTG on Mini and Nano which appeared to help waking from sleep, and it matched some of what NXP's custom ATF was doing. I know there has been some concern about using syscon address the resets and enables, but I took some work Marek did, and added to it by adding some flags to the structure which could take the syscon and write different values to the blk-ctl register depending on whether or not it was a Mini or Nano (and probably Plus). Using some of these, I was able to get the dispmix to come out of reset and enable the LCDIF on both Mini and Nano, but for some reason, any attempts to enable the mipi domain were causing failures in other domains, so I strilpped them out again. I've withheld posting any of these for the same reasons I withheld my other patches. As soon as Lucas' patch [1] above or something similar gets accepted, can rebase and submit a few of the patches I have. adam > > Am Mittwoch, dem 07.04.2021 um 23:21 +0200 schrieb Adrien Grassein: > > Hi, > > > > This patch set aims is to add the support of the i.MX8 MM power domains > > on the mainline kernel. > > > > To achieve this, I do several patches > > - Check errors when reading or writing registers (concerns i.MX8M base > > implementation); > > - Fix power up/down sequence. Handshake was not checked and it was > > not called at the appropriate time (concerns i.MX8M base > > implementaions); > > - Allow domains without power sequence control like the HSIOMIX of the > > i.MX8MM. > > - Add some i.MX8MM domains (HSIO and OTGS); > > - Introduce quirks. For example, i.MX8MM OTG domains should not be > > powered off (seen n the source code of th i.MX ATF). Quirks are > > easily upgrable for other cases. > > - Finally I defined power domains into the imx8mm.dtb file. > > > > I know that this kind of patch is rejected by NXP ut the other way > > (callin ATF directly) was also rejected. > > > > I also know that NXP is concerned abou adding hundred lines of codes for > > each new SOC but it' the way it works on Linux. And the "added code" > > mainly consist of adding structures, defines and generic methods for > > regmap. > > > > If it's a real problem, maybe we can introduc a new "gpcv3" driver for > > i.MX8MM, i.MX8MN and i.MX8MP. > > > > Thanks, > > > > Adrien Grassein (7): > > soc: imx: gpcv2: check for errors when r/w registers > > soc: imx: gpcv2: Fix power up/down sequence > > soc: imx: gpcv2: allow domains without power sequence control > > dt-bindings: power: fsl,imx-gpcv2: add definitions for i.MX8MM > > soc: imx: gpcv2: add HSIOMIX and USB domains for i.MX8MM > > soc: imx: gpcv2: add quirks to domains > > arm64: dts: imx8mm: add power-domains > > > > .../bindings/power/fsl,imx-gpcv2.yaml | 7 +- > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 35 ++ > > drivers/soc/imx/gpcv2.c | 336 ++ > > include/dt-bindings/power/imx8mm-power.h | 21 ++ > > 4 files changed, 333 insertions(+), 66 deletions(-) > > create mode 100644 include/dt-bindings/power/imx8mm-power.h > > > >
[PATCH 1/2] arm64: dts: imx8mn: Add spba1 bus
The i.MX8MN has an SPBA bus which covers much of the audio, but
there is a second SPBA bus which covers many of the serial interfaces
like SPI and UARTs currently missing from the device tree. The reference
manual calls the bus handling the audio peripherals SPBA2, and the bus
handling the serial peripherals is called SPBA1.
Rename the existing spba bus to spba2 and add spba1.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 4dac4da38f4c..e961acd237a8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -255,7 +255,7 @@ aips1: bus@3000 {
#size-cells = <1>;
ranges;
- spba: spba-bus@3000 {
+ spba2: spba-bus@3000 {
compatible = "fsl,spba-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
@@ -681,80 +681,88 @@ aips3: bus@3080 {
#size-cells = <1>;
ranges;
- ecspi1: spi@3082 {
- compatible = "fsl,imx8mn-ecspi",
"fsl,imx51-ecspi";
+ spba1: spba-bus@3080 {
+ compatible = "fsl,spba-bus", "simple-bus";
#address-cells = <1>;
- #size-cells = <0>;
- reg = <0x3082 0x1>;
- interrupts = ;
- clocks = < IMX8MN_CLK_ECSPI1_ROOT>,
-< IMX8MN_CLK_ECSPI1_ROOT>;
- clock-names = "ipg", "per";
- dmas = < 0 7 1>, < 1 7 2>;
- dma-names = "rx", "tx";
- status = "disabled";
- };
+ #size-cells = <1>;
+ reg = <0x3080 0x10>;
+ ranges;
- ecspi2: spi@3083 {
- compatible = "fsl,imx8mn-ecspi",
"fsl,imx51-ecspi";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x3083 0x1>;
- interrupts = ;
- clocks = < IMX8MN_CLK_ECSPI2_ROOT>,
-< IMX8MN_CLK_ECSPI2_ROOT>;
- clock-names = "ipg", "per";
- dmas = < 2 7 1>, < 3 7 2>;
- dma-names = "rx", "tx";
- status = "disabled";
- };
+ ecspi1: spi@3082 {
+ compatible = "fsl,imx8mn-ecspi",
"fsl,imx51-ecspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3082 0x1>;
+ interrupts = ;
+ clocks = < IMX8MN_CLK_ECSPI1_ROOT>,
+< IMX8MN_CLK_ECSPI1_ROOT>;
+ clock-names = "ipg", "per";
+ dmas = < 0 7 1>, < 1 7 2>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
- ecspi3: spi@3084 {
- compatible = "fsl,imx8mn-ecspi",
"fsl,imx51-ecspi";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x3084 0x1>;
- interrupts = ;
- clocks = < IMX8MN_CLK_ECSPI3_ROOT>,
-< IMX8MN_CLK_ECSPI3_ROOT>;
- clock-names = "ipg", "per";
- dmas = < 4 7 1>, < 5 7 2>;
- dma-names = "rx", "tx";
-
[PATCH 2/2] arm64: dts: imx8mm: Add spba1 and spba2 buses
The i.MX8MM reference manual shows there are two spba busses.
SPBA1 handles much of the serial interfaces, and SPBA2 covers much
of the audio.
Add both of them.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index a27e02bee6b4..64aa38fd2b6e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -271,117 +271,125 @@ aips1: bus@3000 {
#size-cells = <1>;
ranges = <0x3000 0x3000 0x40>;
- sai1: sai@3001 {
- #sound-dai-cells = <0>;
- compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
- reg = <0x3001 0x1>;
- interrupts = ;
- clocks = < IMX8MM_CLK_SAI1_IPG>,
-< IMX8MM_CLK_SAI1_ROOT>,
-< IMX8MM_CLK_DUMMY>, <
IMX8MM_CLK_DUMMY>;
- clock-names = "bus", "mclk1", "mclk2", "mclk3";
- dmas = < 0 2 0>, < 1 2 0>;
- dma-names = "rx", "tx";
- status = "disabled";
- };
+ spba2: spba-bus@3000 {
+ compatible = "fsl,spba-bus", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x3000 0x10>;
+ ranges;
+
+ sai1: sai@3001 {
+ #sound-dai-cells = <0>;
+ compatible = "fsl,imx8mm-sai",
"fsl,imx8mq-sai";
+ reg = <0x3001 0x1>;
+ interrupts = ;
+ clocks = < IMX8MM_CLK_SAI1_IPG>,
+< IMX8MM_CLK_SAI1_ROOT>,
+< IMX8MM_CLK_DUMMY>, <
IMX8MM_CLK_DUMMY>;
+ clock-names = "bus", "mclk1", "mclk2",
"mclk3";
+ dmas = < 0 2 0>, < 1 2 0>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
- sai2: sai@3002 {
- #sound-dai-cells = <0>;
- compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
- reg = <0x3002 0x1>;
- interrupts = ;
- clocks = < IMX8MM_CLK_SAI2_IPG>,
- < IMX8MM_CLK_SAI2_ROOT>,
- < IMX8MM_CLK_DUMMY>, <
IMX8MM_CLK_DUMMY>;
- clock-names = "bus", "mclk1", "mclk2", "mclk3";
- dmas = < 2 2 0>, < 3 2 0>;
- dma-names = "rx", "tx";
- status = "disabled";
- };
+ sai2: sai@3002 {
+ #sound-dai-cells = <0>;
+ compatible = "fsl,imx8mm-sai",
"fsl,imx8mq-sai";
+ reg = <0x3002 0x1>;
+ interrupts = ;
+ clocks = < IMX8MM_CLK_SAI2_IPG>,
+ < IMX8MM_CLK_SAI2_ROOT>,
+ < IMX8MM_CLK_DUMMY>, <
IMX8MM_CLK_DUMMY>;
+ clock-names = "bus", "mclk1", "mclk2",
"mclk3";
+ dmas = < 2 2 0>, < 3 2 0>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
- sai3: sai@3003 {
- #sound-dai-cells = <0>;
- compatib
Re: [PATCH v1 0/2] Add imx8m power domain driver
On Fri, Apr 2, 2021 at 1:16 PM Adrien Grassein wrote: > > Le ven. 2 avr. 2021 à 19:58, Abel Vesa a écrit : > > > > On 21-04-02 19:48:41, Adrien Grassein wrote: > > > Hi, > > > > > > Le ven. 2 avr. 2021 à 19:42, Abel Vesa a écrit : > > > > > > > > On 21-04-02 18:45:04, Adrien Grassein wrote: > > > > > Hi, > > > > > > > > > > this patch et aims to add the support of the i.MX 8 Power Domain > > > > > driver. > > > > > Some devices (like usbotg2) can't work without this patch as their > > > > > attached power domain are down. > > > > > > > > > > The original drivr was taken from le imx kernel and aapted to fit with > > > > > the actual mainline (minor fixes). > > > > > > > > > > Thanks, > > > > > > > > > > > > > Big NACK for the whole series. > > > > > > > > This approach has already been rejected upstream. > > > > > > So what is the correct approach? > > > At this point otg2 node of imx8mm is not working at all (and blocks the > > > whole > > > boot of the kernel) > > > > > > > Have a look at this thread: > > > > https://lkml.org/lkml/2020/4/27/706 > > > Understood, so I will try to update the gpc driver (at least for otg). Thanks for doing that. I know Lucas tried a few times to get something going. I'm willing to adapt whatever work you do on the Mini toward the Nano if you don't have time. adam > > > > > > > > > Plus, you changed the original author, this work was originally done by > > > > Jacky Bai. > > > > > > I have not changed this, the original author is not mentioned on the > > > original patch. > > > > Here is the original commit: > > > > https://github.com/Freescale/linux-fslc/commit/7ebcf5ccf423afe4ccd9c53ef204018b0b653ce0 > > > > > > > > > > > > > > > > Adrien Grassein (2): > > > > > dt-bindings: power: Add documentation for imx8m power domain driver > > > > > soc: imx: add Power Domain driver for i.MX8M(M|N|P) > > > > > > > > > > .../bindings/power/fsl,imx-power-domain.yaml | 89 +++ > > > > > MAINTAINERS | 10 + > > > > > drivers/soc/imx/Kconfig | 7 + > > > > > drivers/soc/imx/Makefile | 1 + > > > > > drivers/soc/imx/imx8m_pm_domains.c| 233 > > > > > ++ > > > > > include/dt-bindings/power/imx8mm-power.h | 21 ++ > > > > > include/dt-bindings/power/imx8mn-power.h | 15 ++ > > > > > include/dt-bindings/power/imx8mp-power.h | 28 +++ > > > > > include/soc/imx/imx_sip.h | 12 + > > > > > 9 files changed, 416 insertions(+) > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml > > > > > create mode 100644 drivers/soc/imx/imx8m_pm_domains.c > > > > > create mode 100644 include/dt-bindings/power/imx8mm-power.h > > > > > create mode 100644 include/dt-bindings/power/imx8mn-power.h > > > > > create mode 100644 include/dt-bindings/power/imx8mp-power.h > > > > > create mode 100644 include/soc/imx/imx_sip.h > > > > > > > > > > -- > > > > > 2.25.1 > > > > > > > > > > > Thanks, > > Thanks, > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH V5] dt-bindings: soc: imx: Add binding doc for spba bus
On Mon, Nov 30, 2020 at 4:02 PM Rob Herring wrote: > > On Wed, 18 Nov 2020 17:04:14 -0600, Adam Ford wrote: > > Add binding doc for fsl,spba-bus. > > > > Signed-off-by: Adam Ford > > --- > > make dt_binding_check -j8 |grep spba > > DTEXDocumentation/devicetree/bindings/bus/fsl,spba-bus.example.dts > > DTC Documentation/devicetree/bindings/bus/fsl,spba-bus.example.dt.yaml > > CHECK Documentation/devicetree/bindings/bus/fsl,spba-bus.example.dt.yaml > > > > V5: Rebase on 5.10-rc2 to be able to check yaml > > Add Reg entry > > > > V4: Remove an accidental makefile change > > Move type:object under additional properties > > > > V3: Rebase sample from aips-bus example > > Split off from series adding i.MX8M Nano functions to reduce noise > > > > V2: Attempted to update yaml from feedback > > > > Applied, thanks! Rob, I am not seeing this anywhere. Can you tell me where this was applied? It's not appearing in Linux-next adam
Re: [PATCH 2/4] arm64: dts: imx8mn: add spba bus node
On Tue, Dec 29, 2020 at 8:34 PM Peng Fan wrote:
>
> > Subject: Re: [PATCH 2/4] arm64: dts: imx8mn: add spba bus node
> >
> > On Tue, Dec 29, 2020 at 06:26:41AM -0600, Adam Ford wrote:
> > > On Tue, Dec 29, 2020 at 6:15 AM wrote:
> > > >
> > > > From: Peng Fan
> > > >
> > > > According to RM, there is a spba bus inside aips3 and aips1, add it.
> > > >
> > > > Signed-off-by: Peng Fan
> > > > ---
> > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 362
> > > > +++---
> > > > 1 file changed, 189 insertions(+), 173 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > > b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > > index c824f2615fe8..91f85b8cee9a 100644
> > > > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > > @@ -269,117 +269,125 @@ aips1: bus@3000 {
> > > > #size-cells = <1>;
> > > > ranges = <0x3000 0x3000
> > 0x40>;
> > > >
> > > > - sai1: sai@3001 {
> > > > - #sound-dai-cells = <0>;
> > > > - compatible = "fsl,imx8mm-sai",
> > "fsl,imx8mq-sai";
> > > > - reg = <0x3001 0x1>;
> > > > - interrupts = > IRQ_TYPE_LEVEL_HIGH>;
> > > > - clocks = <
> > IMX8MM_CLK_SAI1_IPG>,
> > > > -<
> > IMX8MM_CLK_SAI1_ROOT>,
> > > > -<
> > IMX8MM_CLK_DUMMY>, < IMX8MM_CLK_DUMMY>;
> > > > - clock-names = "bus", "mclk1",
> > "mclk2", "mclk3";
> > > > - dmas = < 0 2 0>, <
> > 1 2 0>;
> > > > - dma-names = "rx", "tx";
> > > > - status = "disabled";
> > > > - };
> > > > + bus@3000 {
> > >
> > > There is already a bus@3000 (aips1), and I think the system
> > > doesn't like it when there are multiple busses with the same name.
> > >
> > > There was some discussion on fixing the 8mn [1], but it doesn't look
> > > like it went anywhere.
> > >
> > > I am guessing the Mini will need something similar to the nano.
> > >
> > > [1] -
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > >
> > hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fpatch%2F1607324004-1
> > 29
> > >
> > 60-1-git-send-email-shengjiu.wang%40nxp.com%2Fdata=04%7C01%7
> > Cpeng
> > > .fan%40nxp.com%7C970d320f3ef7413296ed08d8ac1486f9%7C686ea1d3bc
> > 2b4c6fa9
> > >
> > 2cd99c5c301635%7C0%7C0%7C637448551481206715%7CUnknown%7CTW
> > FpbGZsb3d8ey
> > >
> > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > %7C200
> > >
> > 0sdata=xKgYHCDyitbUyTPKVuwQV%2FCoJvepCbdBJ1MD9vP%2B6MY
> > %3Dres
> > > erved=0
> >
> > Several replies from S.j. Wang are missing from LKML (and maybe
> > patchwork?) but we reached a conclusion:
>
> Thanks for the pointing, I'll give a look. If S.J take it, I'll leave it to
> S.J.
Peng or S.J,
I don't see this was ever finished. On the Nano, there is an spba-bus
under the aips1 bus, but I am not seeing anything on aips3 yet. It
appears to have been abandoned. The NXP kernel doesn't show either
spba-bus on the imx8m Mini either, but the documentation for the Mini
makes it look like it should work. Do you want me to submit a patch
for any of this?
adam
>
> Thanks,
> Peng.
>
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> > rnel.org%2Flinux-arm-kernel%2F20201208090601.GA8347%40kozik-lap%2F&
> > amp;data=04%7C01%7Cpeng.fan%40nxp.com%7C970d320f3ef7413296ed08
> > d8ac1486f9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63744
> > 8551481206715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=nk
> > t0J5RtzA%2B29nK4aPnd434FNQV8MUZ%2F8Aq64o6hl6I%3Dreserved
> > =0
> >
> > Either you do some remapping of address space or just rename the "bus"
> > nodes (e.g. generic bus-1 or a specific spba-bus).
> >
> > Best regards,
> > Krzysztof
Re: [PATCH V3 4/5] net: ethernet: ravb: Enable optional refclk
On Thu, Mar 4, 2021 at 2:08 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> On Wed, Feb 24, 2021 at 12:52 PM Adam Ford wrote:
> > For devices that use a programmable clock for the AVB reference clock,
> > the driver may need to enable them. Add code to find the optional clock
> > and enable it when available.
> >
> > Signed-off-by: Adam Ford
>
> Thanks for your patch!
>
> > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > @@ -2148,6 +2148,13 @@ static int ravb_probe(struct platform_device *pdev)
> > goto out_release;
> > }
> >
> > + priv->refclk = devm_clk_get_optional(>dev, "refclk");
> > + if (IS_ERR(priv->refclk)) {
> > + error = PTR_ERR(priv->refclk);
> > + goto out_release;
> > + }
> > + clk_prepare_enable(priv->refclk);
> > +
>
> Shouldn't the reference clock be disabled in case of any failure below?
>
I'll generate a V4.
Should I just regenerate this patch since it seems like the rest are
OK, or should I regenerate the whole series?
adam
> > ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
> > ndev->min_mtu = ETH_MIN_MTU;
> >
> > @@ -2260,6 +2267,9 @@ static int ravb_remove(struct platform_device *pdev)
> > if (priv->chip_id != RCAR_GEN2)
> > ravb_ptp_stop(ndev);
> >
> > + if (priv->refclk)
> > + clk_disable_unprepare(priv->refclk);
> > +
> > dma_free_coherent(ndev->dev.parent, priv->desc_bat_size,
> > priv->desc_bat,
> > priv->desc_bat_dma);
> > /* Set reset mode */
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH V4] clk: imx: Fix reparenting of UARTs not associated with stdout
On Mon, Mar 22, 2021 at 4:42 PM Abel Vesa wrote:
>
> On 21-03-13 06:28:17, Adam Ford wrote:
> > Most if not all i.MX SoC's call a function which enables all UARTS.
> > This is a problem for users who need to re-parent the clock source,
> > because any attempt to change the parent results in an busy error
> > due to the fact that the clocks have been enabled already.
> >
> > clk: failed to reparent uart1 to sys_pll1_80m: -16
> >
> > Instead of pre-initializing all UARTS, scan the device tree to see
> > which UART clocks are associated to stdout, and only enable those
> > UART clocks if it's needed early. This will move initialization of
> > the remaining clocks until after the parenting of the clocks.
> >
> > When the clocks are shutdown, this mechanism will also disable any
> > clocks that were pre-initialized.
> >
> > Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate
> > protection")
> > Suggested-by: Aisheng Dong
> > Signed-off-by: Adam Ford
> > Reviewed-by: Abel Vesa
> > Tested-by: Ahmad Fatoum
> >
> > ---
> > V4: Check if of_stdout is available before using it.
> > Re-align #ifdef to remove repeated code.
> > V3: Return a method more closely related to upstream kernel but
> > instead of passing an array of UART's, each SoC passes the max
> > number of UART clocks is has. The imx clock driver will create
> > an array to enable on startup, and disable later.
> > V2: Attempt to port driver from vendor kernel.
> > ---
> > drivers/clk/imx/clk-imx25.c | 12 +-
> > drivers/clk/imx/clk-imx27.c | 13 +--
> > drivers/clk/imx/clk-imx35.c | 10 +
> > drivers/clk/imx/clk-imx5.c| 30 +++--
> > drivers/clk/imx/clk-imx6q.c | 16 +-
> > drivers/clk/imx/clk-imx6sl.c | 16 +-
> > drivers/clk/imx/clk-imx6sll.c | 24 +---
> > drivers/clk/imx/clk-imx6sx.c | 16 +-
> > drivers/clk/imx/clk-imx7d.c | 22 +--
> > drivers/clk/imx/clk-imx7ulp.c | 31 ++
> > drivers/clk/imx/clk-imx8mm.c | 18 ++-
> > drivers/clk/imx/clk-imx8mn.c | 18 ++-
> > drivers/clk/imx/clk-imx8mp.c | 17 +--
> > drivers/clk/imx/clk-imx8mq.c | 18 ++-
> > drivers/clk/imx/clk.c | 41 +++
> > drivers/clk/imx/clk.h | 4 ++--
> > 16 files changed, 54 insertions(+), 252 deletions(-)
> >
> > diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
> > index a66cabfbf94f..66192fe0a898 100644
> > --- a/drivers/clk/imx/clk-imx25.c
> > +++ b/drivers/clk/imx/clk-imx25.c
> > @@ -73,16 +73,6 @@ enum mx25_clks {
> >
> > static struct clk *clk[clk_max];
> >
> > -static struct clk ** const uart_clks[] __initconst = {
> > - [uart_ipg_per],
> > - [uart1_ipg],
> > - [uart2_ipg],
> > - [uart3_ipg],
> > - [uart4_ipg],
> > - [uart5_ipg],
> > - NULL
> > -};
> > -
> > static int __init __mx25_clocks_init(void __iomem *ccm_base)
> > {
> > BUG_ON(!ccm_base);
> > @@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem
> > *ccm_base)
> >*/
> > clk_set_parent(clk[cko_sel], clk[ipg]);
> >
> > - imx_register_uart_clocks(uart_clks);
> > + imx_register_uart_clocks(6);
> >
> > return 0;
> > }
> > diff --git a/drivers/clk/imx/clk-imx27.c b/drivers/clk/imx/clk-imx27.c
> > index 5585ded8b8c6..56a5fc402b10 100644
> > --- a/drivers/clk/imx/clk-imx27.c
> > +++ b/drivers/clk/imx/clk-imx27.c
> > @@ -49,17 +49,6 @@ static const char *ssi_sel_clks[] = { "spll_gate",
> > "mpll", };
> > static struct clk *clk[IMX27_CLK_MAX];
> > static struct clk_onecell_data clk_data;
> >
> > -static struct clk ** const uart_clks[] __initconst = {
> > - [IMX27_CLK_PER1_GATE],
> > - [IMX27_CLK_UART1_IPG_GATE],
> > - [IMX27_CLK_UART2_IPG_GATE],
> > - [IMX27_CLK_UART3_IPG_GATE],
> > - [IMX27_CLK_UART4_IPG_GATE],
> > - [IMX27_CLK_UART5_IPG_GATE],
> > - [IMX27_CLK_UART6_IPG_GATE],
> > - NULL
> > -};
> > -
> > static void __init _mx27_clocks_init(unsigned long fref)
> > {
> > BUG_ON(!ccm);
> > @@ -176,7 +165,7 @@ static void __init _mx27_clocks_init(unsigned long fref)
> >
> > clk_prepare_enable(clk[IMX27_CLK_EMI_AHB_GA
Re: [PATCH v5 00/14] Add BLK_CTL support for i.MX8MP
On Wed, Mar 3, 2021 at 4:54 AM Marek Vasut wrote:
>
> On 3/3/21 11:47 AM, Abel Vesa wrote:
> > On 20-11-03 13:18:12, Abel Vesa wrote:
> >> The BLK_CTL according to HW design is basically the wrapper of the entire
> >> function specific group of IPs and holds GPRs that usually cannot be placed
> >> into one specific IP from that group. Some of these GPRs are used to
> >> control
> >> some clocks, other some resets, others some very specific function that
> >> does
> >> not fit into clocks or resets. Since the clocks are registered using the
> >> i.MX
> >> clock subsystem API, the driver is placed into the clock subsystem, but it
> >> also registers the resets. For the other functionalities that other GPRs
> >> might
> >> have, the syscon is used.
> >>
> >
> > This approach seems to be introducing a possible ABBA deadlock due to
> > the core clock and genpd locking. Here is a backtrace I got from Pete
> > Zhang (he reported the issue on the internal mailing list):
> >
> > [ 11.667711][ T108] -> #1 (>mlock){+.+.}-{3:3}:
> > [ 11.675041][ T108]__lock_acquire+0xae4/0xef8
> > [ 11.680093][ T108]lock_acquire+0xfc/0x2f8
> > [ 11.684888][ T108]__mutex_lock+0x90/0x870
> > [ 11.689685][ T108]mutex_lock_nested+0x44/0x50
> > [ 11.694826][ T108]genpd_lock_mtx+0x18/0x24
> > [ 11.699706][ T108]genpd_runtime_resume+0x90/0x214 (hold
> > genpd->mlock)
> > [ 11.705194][ T108]__rpm_callback+0x80/0x2c0
> > [ 11.710160][ T108]rpm_resume+0x468/0x650
> > [ 11.714866][ T108]__pm_runtime_resume+0x60/0x88
> > [ 11.720180][ T108]clk_pm_runtime_get+0x28/0x9c
> > [ 11.725410][ T108]clk_disable_unused_subtree+0x8c/0x144
> > [ 11.731420][ T108]clk_disable_unused_subtree+0x124/0x144
> > [ 11.737518][ T108]clk_disable_unused+0xa4/0x11c (hold
> > prepare_lock)
> > [ 11.742833][ T108]do_one_initcall+0x98/0x178
> > [ 11.747888][ T108]do_initcall_level+0x9c/0xb8
> > [ 11.753028][ T108]do_initcalls+0x54/0x94
> > [ 11.757736][ T108]do_basic_setup+0x24/0x30
> > [ 11.762614][ T108]kernel_init_freeable+0x70/0xa4
> > [ 11.768014][ T108]kernel_init+0x14/0x18c
> > [ 11.772722][ T108]ret_from_fork+0x10/0x18
> >
> > [ 11.777512][ T108] -> #0 (prepare_lock){+.+.}-{3:3}:
> > [ 11.784749][ T108]check_noncircular+0x134/0x13c
> > [ 11.790064][ T108]validate_chain+0x590/0x2a04
> > [ 11.795204][ T108]__lock_acquire+0xae4/0xef8
> > [ 11.800258][ T108]lock_acquire+0xfc/0x2f8
> > [ 11.805050][ T108]__mutex_lock+0x90/0x870
> > [ 11.809841][ T108]mutex_lock_nested+0x44/0x50
> > [ 11.814983][ T108]clk_unprepare+0x5c/0x100 ((hold prepare_lock))
> > [ 11.819864][ T108]imx8m_pd_power_off+0xac/0x110
> > [ 11.825179][ T108]genpd_power_off+0x1b4/0x2dc
> > [ 11.830318][ T108]genpd_power_off_work_fn+0x38/0x58 (hold
> > genpd->mlock)
> > [ 11.835981][ T108]process_one_work+0x270/0x444
> > [ 11.841208][ T108]worker_thread+0x280/0x4e4
> > [ 11.846176][ T108]kthread+0x13c/0x14
> > [ 11.850621][ T108]ret_from_fork+0x10/0x18
> >
> > Now, this has been reproduced only on the NXP internal tree, but I think
> > it is pretty obvious this could happen in upstream too, with this
> > patchset applied.
> >
> > First, my thought was to change the prepare_lock/enable_lock in clock
> > core, from a global approach to a per clock basis. But that doesn't
> > actually fix the issue.
> >
> > The usecase seen above is due to clk_disable_unused, but the same could
> > happen when a clock consumer calls prepare/unprepare on a clock.
> >
> > I guess the conclusion is that the current state of the clock core and
> > genpd implementation does not support a usecase where a clock controller
> > has a PD which in turn uses another clock (from another clock controller).
> >
> > Jacky, Pete, did I miss anything here ?
>
> Just for completeness, I have a feeling I already managed to trigger
> this and discussed this with Lucas before, so this concern is certainly
> valid.
I know it may not be ideal, someone tied a soft-reset and soft-enable
to the driver of the Hantro VPU on the IMXMQ [1], and I wonder if
something similar could be done for the drivers who are consumers of
the clocks.
For example:
lcdif could request the power domain.
The power domain soft-resets and enables bus clock (vis syscon)
After successful enabling of power-domain, the LCDIF requests the soft
reset and respective clock bits (also via syscon) similar to how [1]
and [2] do it for the Hantro VPU.
The syscon node could be a common node similar to what was done in
[2], and multiple consumers could control when each soft-reset and
clock-enable get activated. I know it's probably more of an abuse of
the syscon system, but having the individual drivers
Re: [PATCH V4] clk: imx: Fix reparenting of UARTs not associated with stdout
On Sun, Mar 14, 2021 at 4:40 AM Ahmad Fatoum wrote:
>
> On 13.03.21 16:16, Ahmad Fatoum wrote:
> >> +/* i.MX boards use device trees now. For build tests without CONFIG_OF,
> >> do nothing */
> >> +#ifdef CONFIG_OF
> >> if (imx_keep_uart_clocks) {
> >> int i;
> >>
> >> -imx_uart_clocks = clks;
> >> -for (i = 0; imx_uart_clocks[i]; i++)
> >> -clk_prepare_enable(*imx_uart_clocks[i]);
> >> +imx_uart_clocks = kcalloc(clk_count, sizeof(struct clk *),
> >> GFP_KERNEL);
> >> +
> >> +if (!of_stdout)
> >> +return;
> >
> > Memory leak. Just do if (imx_keep_uart_clocks && of_stdout)
>
> Please dismiss. I overlooked that you free it in a later initcall.
Abel,
Are you OK with this? I also have a V5 posted [1] which does what
Ahmad suggested.
Either of these will fix reparenting issues, but I need this for
Bluetooth to operate correctly, because both beacon imx8mn and imx8mn
kits switch the UART parent to an 80MHz clock in order to run at
4Mbps.
thank you,
adam
>
> >> static int __init imx_clk_disable_uart(void)
> >> {
> >> -if (imx_keep_uart_clocks && imx_uart_clocks) {
> >> +if (imx_keep_uart_clocks && imx_enabled_uart_clocks) {
> >> int i;
> >>
> >> -for (i = 0; imx_uart_clocks[i]; i++)
> >> -clk_disable_unprepare(*imx_uart_clocks[i]);
> >> +for (i = 0; i < imx_enabled_uart_clocks; i++) {
> >> +clk_disable_unprepare(imx_uart_clocks[i]);
> >> +clk_put(imx_uart_clocks[i]);
> >> +};
> >> +kfree(imx_uart_clocks);
> >> }
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH V3 5/5] arm64: dts: renesas: beacon kits: Setup AVB refclk
On Thu, Mar 4, 2021 at 2:04 AM Geert Uytterhoeven wrote:
>
> On Wed, Feb 24, 2021 at 12:52 PM Adam Ford wrote:
> > The AVB refererence clock assumes an external clock that runs
>
> reference
>
> > automatically. Because the Versaclock is wired to provide the
> > AVB refclock, the device tree needs to reference it in order for the
> > driver to start the clock.
> >
> > Signed-off-by: Adam Ford
>
> Reviewed-by: Geert Uytterhoeven
> i.e. will queue in renesas-devel (with the typo fixed) once the DT
> bindings have been accepted.
>
Who do I need to ping to get the DT bindings accepted? They have an
acked-by from Rob.
adam
> 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 V5] clk: imx: Fix reparenting of UARTs not associated with stdout
Most if not all i.MX SoC's call a function which enables all UARTS.
This is a problem for users who need to re-parent the clock source,
because any attempt to change the parent results in an busy error
due to the fact that the clocks have been enabled already.
clk: failed to reparent uart1 to sys_pll1_80m: -16
Instead of pre-initializing all UARTS, scan the device tree to see
which UART clocks are associated to stdout, and only enable those
UART clocks if it's needed early. This will move initialization of
the remaining clocks until after the parenting of the clocks.
When the clocks are shutdown, this mechanism will also disable any
clocks that were pre-initialized.
Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate protection")
Suggested-by: Aisheng Dong
Signed-off-by: Adam Ford
Reviewed-by: Abel Vesa
Tested-by: Ahmad Fatoum
---
V5: Combine of_stdout with check for imx_keep_uart_clocks to
reduce code lines and prevent memory leak.
V4: Check if of_stdout is available before using it.
Re-align #ifdef to remove repeated code.
V3: Return a method more closely related to upstream kernel but
instead of passing an array of UART's, each SoC passes the max
number of UART clocks is has. The imx clock driver will create
an array to enable on startup, and disable later.
V2: Attempt to port driver from vendor kernel.
---
drivers/clk/imx/clk-imx25.c | 12 +--
drivers/clk/imx/clk-imx27.c | 13 +---
drivers/clk/imx/clk-imx35.c | 10 +
drivers/clk/imx/clk-imx5.c| 30 +++---
drivers/clk/imx/clk-imx6q.c | 16 +-
drivers/clk/imx/clk-imx6sl.c | 16 +-
drivers/clk/imx/clk-imx6sll.c | 24 +
drivers/clk/imx/clk-imx6sx.c | 16 +-
drivers/clk/imx/clk-imx7d.c | 22 +--
drivers/clk/imx/clk-imx7ulp.c | 31 ++-
drivers/clk/imx/clk-imx8mm.c | 18 ++--
drivers/clk/imx/clk-imx8mn.c | 18 ++--
drivers/clk/imx/clk-imx8mp.c | 17 +--
drivers/clk/imx/clk-imx8mq.c | 18 ++--
drivers/clk/imx/clk.c | 40 ++-
drivers/clk/imx/clk.h | 4 ++--
16 files changed, 52 insertions(+), 253 deletions(-)
diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
index a66cabfbf94f..66192fe0a898 100644
--- a/drivers/clk/imx/clk-imx25.c
+++ b/drivers/clk/imx/clk-imx25.c
@@ -73,16 +73,6 @@ enum mx25_clks {
static struct clk *clk[clk_max];
-static struct clk ** const uart_clks[] __initconst = {
- [uart_ipg_per],
- [uart1_ipg],
- [uart2_ipg],
- [uart3_ipg],
- [uart4_ipg],
- [uart5_ipg],
- NULL
-};
-
static int __init __mx25_clocks_init(void __iomem *ccm_base)
{
BUG_ON(!ccm_base);
@@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem *ccm_base)
*/
clk_set_parent(clk[cko_sel], clk[ipg]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks(6);
return 0;
}
diff --git a/drivers/clk/imx/clk-imx27.c b/drivers/clk/imx/clk-imx27.c
index 5585ded8b8c6..56a5fc402b10 100644
--- a/drivers/clk/imx/clk-imx27.c
+++ b/drivers/clk/imx/clk-imx27.c
@@ -49,17 +49,6 @@ static const char *ssi_sel_clks[] = { "spll_gate", "mpll", };
static struct clk *clk[IMX27_CLK_MAX];
static struct clk_onecell_data clk_data;
-static struct clk ** const uart_clks[] __initconst = {
- [IMX27_CLK_PER1_GATE],
- [IMX27_CLK_UART1_IPG_GATE],
- [IMX27_CLK_UART2_IPG_GATE],
- [IMX27_CLK_UART3_IPG_GATE],
- [IMX27_CLK_UART4_IPG_GATE],
- [IMX27_CLK_UART5_IPG_GATE],
- [IMX27_CLK_UART6_IPG_GATE],
- NULL
-};
-
static void __init _mx27_clocks_init(unsigned long fref)
{
BUG_ON(!ccm);
@@ -176,7 +165,7 @@ static void __init _mx27_clocks_init(unsigned long fref)
clk_prepare_enable(clk[IMX27_CLK_EMI_AHB_GATE]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks(7);
imx_print_silicon_rev("i.MX27", mx27_revision());
}
diff --git a/drivers/clk/imx/clk-imx35.c b/drivers/clk/imx/clk-imx35.c
index c1df03665c09..0fe5ac210156 100644
--- a/drivers/clk/imx/clk-imx35.c
+++ b/drivers/clk/imx/clk-imx35.c
@@ -82,14 +82,6 @@ enum mx35_clks {
static struct clk *clk[clk_max];
-static struct clk ** const uart_clks[] __initconst = {
- [ipg],
- [uart1_gate],
- [uart2_gate],
- [uart3_gate],
- NULL
-};
-
static void __init _mx35_clocks_init(void)
{
void __iomem *base;
@@ -243,7 +235,7 @@ static void __init _mx35_clocks_init(void)
*/
clk_prepare_enable(clk[scc_gate]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks(4);
imx_print_silicon_rev("i.MX35", mx35_revision());
}
diff --git a/drivers/clk/imx/clk-imx5.c b/drivers/clk/imx/
[PATCH V4] clk: imx: Fix reparenting of UARTs not associated with stdout
Most if not all i.MX SoC's call a function which enables all UARTS.
This is a problem for users who need to re-parent the clock source,
because any attempt to change the parent results in an busy error
due to the fact that the clocks have been enabled already.
clk: failed to reparent uart1 to sys_pll1_80m: -16
Instead of pre-initializing all UARTS, scan the device tree to see
which UART clocks are associated to stdout, and only enable those
UART clocks if it's needed early. This will move initialization of
the remaining clocks until after the parenting of the clocks.
When the clocks are shutdown, this mechanism will also disable any
clocks that were pre-initialized.
Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate protection")
Suggested-by: Aisheng Dong
Signed-off-by: Adam Ford
Reviewed-by: Abel Vesa
Tested-by: Ahmad Fatoum
---
V4: Check if of_stdout is available before using it.
Re-align #ifdef to remove repeated code.
V3: Return a method more closely related to upstream kernel but
instead of passing an array of UART's, each SoC passes the max
number of UART clocks is has. The imx clock driver will create
an array to enable on startup, and disable later.
V2: Attempt to port driver from vendor kernel.
---
drivers/clk/imx/clk-imx25.c | 12 +-
drivers/clk/imx/clk-imx27.c | 13 +--
drivers/clk/imx/clk-imx35.c | 10 +
drivers/clk/imx/clk-imx5.c| 30 +++--
drivers/clk/imx/clk-imx6q.c | 16 +-
drivers/clk/imx/clk-imx6sl.c | 16 +-
drivers/clk/imx/clk-imx6sll.c | 24 +---
drivers/clk/imx/clk-imx6sx.c | 16 +-
drivers/clk/imx/clk-imx7d.c | 22 +--
drivers/clk/imx/clk-imx7ulp.c | 31 ++
drivers/clk/imx/clk-imx8mm.c | 18 ++-
drivers/clk/imx/clk-imx8mn.c | 18 ++-
drivers/clk/imx/clk-imx8mp.c | 17 +--
drivers/clk/imx/clk-imx8mq.c | 18 ++-
drivers/clk/imx/clk.c | 41 +++
drivers/clk/imx/clk.h | 4 ++--
16 files changed, 54 insertions(+), 252 deletions(-)
diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
index a66cabfbf94f..66192fe0a898 100644
--- a/drivers/clk/imx/clk-imx25.c
+++ b/drivers/clk/imx/clk-imx25.c
@@ -73,16 +73,6 @@ enum mx25_clks {
static struct clk *clk[clk_max];
-static struct clk ** const uart_clks[] __initconst = {
- [uart_ipg_per],
- [uart1_ipg],
- [uart2_ipg],
- [uart3_ipg],
- [uart4_ipg],
- [uart5_ipg],
- NULL
-};
-
static int __init __mx25_clocks_init(void __iomem *ccm_base)
{
BUG_ON(!ccm_base);
@@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem *ccm_base)
*/
clk_set_parent(clk[cko_sel], clk[ipg]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks(6);
return 0;
}
diff --git a/drivers/clk/imx/clk-imx27.c b/drivers/clk/imx/clk-imx27.c
index 5585ded8b8c6..56a5fc402b10 100644
--- a/drivers/clk/imx/clk-imx27.c
+++ b/drivers/clk/imx/clk-imx27.c
@@ -49,17 +49,6 @@ static const char *ssi_sel_clks[] = { "spll_gate", "mpll", };
static struct clk *clk[IMX27_CLK_MAX];
static struct clk_onecell_data clk_data;
-static struct clk ** const uart_clks[] __initconst = {
- [IMX27_CLK_PER1_GATE],
- [IMX27_CLK_UART1_IPG_GATE],
- [IMX27_CLK_UART2_IPG_GATE],
- [IMX27_CLK_UART3_IPG_GATE],
- [IMX27_CLK_UART4_IPG_GATE],
- [IMX27_CLK_UART5_IPG_GATE],
- [IMX27_CLK_UART6_IPG_GATE],
- NULL
-};
-
static void __init _mx27_clocks_init(unsigned long fref)
{
BUG_ON(!ccm);
@@ -176,7 +165,7 @@ static void __init _mx27_clocks_init(unsigned long fref)
clk_prepare_enable(clk[IMX27_CLK_EMI_AHB_GATE]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks(7);
imx_print_silicon_rev("i.MX27", mx27_revision());
}
diff --git a/drivers/clk/imx/clk-imx35.c b/drivers/clk/imx/clk-imx35.c
index c1df03665c09..0fe5ac210156 100644
--- a/drivers/clk/imx/clk-imx35.c
+++ b/drivers/clk/imx/clk-imx35.c
@@ -82,14 +82,6 @@ enum mx35_clks {
static struct clk *clk[clk_max];
-static struct clk ** const uart_clks[] __initconst = {
- [ipg],
- [uart1_gate],
- [uart2_gate],
- [uart3_gate],
- NULL
-};
-
static void __init _mx35_clocks_init(void)
{
void __iomem *base;
@@ -243,7 +235,7 @@ static void __init _mx35_clocks_init(void)
*/
clk_prepare_enable(clk[scc_gate]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks(4);
imx_print_silicon_rev("i.MX35", mx35_revision());
}
diff --git a/drivers/clk/imx/clk-imx5.c b/drivers/clk/imx/clk-imx5.c
index 01e079b81026..e4493846454d 100644
--- a/drivers/clk/imx/clk-imx5.c
+++ b/drivers/clk/imx/clk-imx5.c
@@
Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout
On Wed, Mar 10, 2021 at 4:25 PM Abel Vesa wrote: > > On 21-03-03 10:31:19, Abel Vesa wrote: > > On 21-03-02 13:03:04, Adam Ford wrote: > > > On Mon, Feb 15, 2021 at 7:06 AM Abel Vesa wrote: > > > > > > > > On 21-02-13 08:44:28, Adam Ford wrote: > > > > > On Wed, Feb 3, 2021 at 3:22 PM Adam Ford wrote: > > > > > > > > > > > > On Thu, Jan 21, 2021 at 4:24 AM Abel Vesa wrote: > > > > > > > > > > > > > > On 21-01-21 10:56:17, Sascha Hauer wrote: > > > > > > > > On Wed, Jan 20, 2021 at 06:14:21PM +0200, Abel Vesa wrote: > > > > > > > > > On 21-01-20 16:50:01, Sascha Hauer wrote: > > > > > > > > > > On Wed, Jan 20, 2021 at 05:28:13PM +0200, Abel Vesa wrote: > > > > > > > > > > > On 21-01-20 16:13:05, Sascha Hauer wrote: > > > > > > > > > > > > Hi Abel, > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On 21-01-18 08:00:43, Adam Ford wrote: > > > > > > > > > > > > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > TBH, I'm against the idea of having to call > > > > > > > > > > > > > > > consumer API from a clock provider driver. > > > > > > > > > > > > > > > I'm still investigating a way of moving the uart > > > > > > > > > > > > > > > clock control calls in drivers/serial/imx, > > > > > > > > > > > > > > > where they belong. > > > > > > > > > > > > > > > > > > > > > > > > > > > > That makes sense. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just a thought. The uart clock used for console > > > > > > > > > > > > > remains on from u-boot, > > > > > > > > > > > > > so maybe it's enough to just add the > > > > > > > > > > > > > CLK_IGNORE_UNUSED flag to all the > > > > > > > > > > > > > uart root clocks and remove the prepare/enable calls > > > > > > > > > > > > > for uart clocks > > > > > > > > > > > > > for good. I don't really have a way to test it right > > > > > > > > > > > > > now, but maybe > > > > > > > > > > > > > you could give it a try. > > > > > > > > > > > > > > > > > > > > > > > > That would mean that UART clocks will never be > > > > > > > > > > > > disabled, regardless of > > > > > > > > > > > > whether they are used for console or not. That doesn't > > > > > > > > > > > > sound very > > > > > > > > > > > > appealing. > > > > > > > > > > > > > > > > > > > > > > AFAIK, the only uart clock that is enabled by u-boot is > > > > > > > > > > > the one used for > > > > > > > > > > > the console. Later on, when the serial driver probes, it > > > > > > > > > > > will enable it itself. > > > > > > > > > > > > > > > > > > > > > > Unless I'm missing something, this is exactly what we > > > > > > > > > > > need. > > > > > > > > > > > > > > > > > > > > It might enable it, but with CLK_IGNORE_UNUSED t
Re: [PATCH v3 0/5] Reset driver for IMX8MQ VPU hardware block
On Wed, Mar 3, 2021 at 5:24 PM Philipp Zabel wrote: > > On Wed, 2021-03-03 at 16:20 +0100, Benjamin Gaignard wrote: > > Le 03/03/2021 à 15:17, Philipp Zabel a écrit : > > > Hi Benjamin, > > > > > > On Mon, 2021-03-01 at 16:17 +0100, Benjamin Gaignard wrote: > > > > The two VPUs inside IMX8MQ share the same control block which can be see > > > > as a reset hardware block. > > > This isn't a reset controller though. The control block also contains > > > clock gates of some sort and a filter register for the featureset fuses. > > > Those shouldn't be manipulated via the reset API. This driver is very similar to several other patches for clk_blk control [1] which contain both resets and clock-enables on the i.MX8MP, i.MX8MM and i.MX8MN. In those cases, there are some specific power domain controls that are needed, but I wonder if the approach to creating resets and clock enables could be used in a similar way if the IMX8MQ doesn't have the same quirks. In the case of the i.MX8M Mini, I think it has the same VPU. [1] - https://patchwork.kernel.org/project/linux-clk/patch/1599560691-3763-12-git-send-email-abel.v...@nxp.com/ adam > > > > They are all part of the control block and of the reset process for this > > hardware that why I put them here. I guess it is border line :-) > > I'm pushing back to keep the reset control framework focused on > controlling reset lines. Every side effect (such as the asymmetric clock > ungating) in a random driver makes it harder to reason about behaviour > at the API level, and to review patches for hardware I am not familiar > with. > > > > > In order to be able to add the second VPU (for HECV decoding) it will be > > > > more handy if the both VPU drivers instance don't have to share the > > > > control block registers. This lead to implement it as an independ reset > > > > driver and to change the VPU driver to use it. > > > Why not switch to a syscon regmap for the control block? That should > > > also allow to keep backwards compatibility with the old binding with > > > minimal effort. > > > > I will give a try in this direction. > > Thank you. > > > > > Please note that this series break the compatibility between the DTB and > > > > kernel. This break is limited to IMX8MQ SoC and is done when the driver > > > > is still in staging directory. > > > I know in this case we are pretty sure there are no users of this > > > binding except for a staging driver, but it would still be nice to keep > > > support for the deprecated binding, to avoid the requirement of updating > > > kernel and DT in lock-step. > > > > If I want to use a syscon (or a reset) the driver must not ioremap the > > "ctrl" > > registers. It means that "ctrl" has to be removed from the driver requested > > reg-names (imx8mq_reg_names[]). Doing that break the kernel/DT > > compatibility. > > Somehow syscon and "ctrl" are exclusive. > > The way the driver is set up currently, yes. You could add a bit of > platform specific probe code, though, that would set up the regmap > either by calling > syscon_regmap_lookup_by_phandle(); > for the new binding, or, if the phandle is not available, fall back to > platform_get_resource_byname(..., "ctrl"); > devm_ioremap_resource(); > devm_regmap_init_mmio(); > for the old binding. > The actual codec .reset and variant .runtime_resume ops could be > identical then. > > regards > Philipp > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout
On Mon, Feb 15, 2021 at 7:06 AM Abel Vesa wrote: > > On 21-02-13 08:44:28, Adam Ford wrote: > > On Wed, Feb 3, 2021 at 3:22 PM Adam Ford wrote: > > > > > > On Thu, Jan 21, 2021 at 4:24 AM Abel Vesa wrote: > > > > > > > > On 21-01-21 10:56:17, Sascha Hauer wrote: > > > > > On Wed, Jan 20, 2021 at 06:14:21PM +0200, Abel Vesa wrote: > > > > > > On 21-01-20 16:50:01, Sascha Hauer wrote: > > > > > > > On Wed, Jan 20, 2021 at 05:28:13PM +0200, Abel Vesa wrote: > > > > > > > > On 21-01-20 16:13:05, Sascha Hauer wrote: > > > > > > > > > Hi Abel, > > > > > > > > > > > > > > > > > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa wrote: > > > > > > > > > > On 21-01-18 08:00:43, Adam Ford wrote: > > > > > > > > > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > TBH, I'm against the idea of having to call consumer > > > > > > > > > > > > API from a clock provider driver. > > > > > > > > > > > > I'm still investigating a way of moving the uart clock > > > > > > > > > > > > control calls in drivers/serial/imx, > > > > > > > > > > > > where they belong. > > > > > > > > > > > > > > > > > > > > > > That makes sense. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just a thought. The uart clock used for console remains on > > > > > > > > > > from u-boot, > > > > > > > > > > so maybe it's enough to just add the CLK_IGNORE_UNUSED flag > > > > > > > > > > to all the > > > > > > > > > > uart root clocks and remove the prepare/enable calls for > > > > > > > > > > uart clocks > > > > > > > > > > for good. I don't really have a way to test it right now, > > > > > > > > > > but maybe > > > > > > > > > > you could give it a try. > > > > > > > > > > > > > > > > > > That would mean that UART clocks will never be disabled, > > > > > > > > > regardless of > > > > > > > > > whether they are used for console or not. That doesn't sound > > > > > > > > > very > > > > > > > > > appealing. > > > > > > > > > > > > > > > > AFAIK, the only uart clock that is enabled by u-boot is the one > > > > > > > > used for > > > > > > > > the console. Later on, when the serial driver probes, it will > > > > > > > > enable it itself. > > > > > > > > > > > > > > > > Unless I'm missing something, this is exactly what we need. > > > > > > > > > > > > > > It might enable it, but with CLK_IGNORE_UNUSED the clock won't be > > > > > > > disabled again when a port is closed after usage > > > > > > > > > > > > OK, tell me what I'm getting wrong in the following scenario: > > > > > > > > > > > > U-boot leaves the console uart clock enabled. All the other ones > > > > > > are disabled. > > > > > > > > > > > > Kernel i.MX clk driver registers the uart clocks with flag > > > > > > CLK_IGNORE_UNUSED. > > > > > > > > > > I was wrong at that point. I originally thought the kernel will never > > > > > disable these clocks, but in fact it only leaves them enabled during > > > > > the > > > > > clk_disable_unused call. > > > > > > > > > > However, when CLK_IGNORE_UNUSED becomes relevant it's too late > > > > > already. > > > > > I just chatted with Lucas and he told me what the original problem was > > > > &g
[PATCH V3 5/5] arm64: dts: renesas: beacon kits: Setup AVB refclk
The AVB refererence clock assumes an external clock that runs
automatically. Because the Versaclock is wired to provide the
AVB refclock, the device tree needs to reference it in order for the
driver to start the clock.
Signed-off-by: Adam Ford
---
V3: New to series
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index 8d3a4d6ee885..75355c354c38 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -53,6 +53,8 @@ {
phy-handle = <>;
rx-internal-delay-ps = <1800>;
tx-internal-delay-ps = <2000>;
+ clocks = < CPG_MOD 812>, < 4>;
+ clock-names = "fck", "refclk";
status = "okay";
phy0: ethernet-phy@0 {
--
2.25.1
[PATCH V3 4/5] net: ethernet: ravb: Enable optional refclk
For devices that use a programmable clock for the AVB reference clock,
the driver may need to enable them. Add code to find the optional clock
and enable it when available.
Signed-off-by: Adam Ford
---
V3: Change 'avb' to 'AVB'
Remove unnessary else statement and pointer maniupluation when
enabling the refclock.
Add disable_unprepare call in remove funtion.
V2: The previous patch to fetch the fclk was dropped. In its place
is code to enable the refclk
diff --git a/drivers/net/ethernet/renesas/ravb.h
b/drivers/net/ethernet/renesas/ravb.h
index 7453b17a37a2..ff363797bd2b 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -994,6 +994,7 @@ struct ravb_private {
struct platform_device *pdev;
void __iomem *addr;
struct clk *clk;
+ struct clk *refclk;
struct mdiobb_ctrl mdiobb;
u32 num_rx_ring[NUM_RX_QUEUE];
u32 num_tx_ring[NUM_TX_QUEUE];
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index bd30505fbc57..614448e6eb24 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2148,6 +2148,13 @@ static int ravb_probe(struct platform_device *pdev)
goto out_release;
}
+ priv->refclk = devm_clk_get_optional(>dev, "refclk");
+ if (IS_ERR(priv->refclk)) {
+ error = PTR_ERR(priv->refclk);
+ goto out_release;
+ }
+ clk_prepare_enable(priv->refclk);
+
ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
ndev->min_mtu = ETH_MIN_MTU;
@@ -2260,6 +2267,9 @@ static int ravb_remove(struct platform_device *pdev)
if (priv->chip_id != RCAR_GEN2)
ravb_ptp_stop(ndev);
+ if (priv->refclk)
+ clk_disable_unprepare(priv->refclk);
+
dma_free_coherent(ndev->dev.parent, priv->desc_bat_size, priv->desc_bat,
priv->desc_bat_dma);
/* Set reset mode */
--
2.25.1
[PATCH V3 2/5] ARM: dts: renesas: Add fck to etheravb-rcar-gen2 clock-names list
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
---
V3: No Change
V2: No Change
diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index 6a78c813057b..6b922f664fcd 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -750,6 +750,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7742_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index f444e418f408..084bf3e039cf 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -702,6 +702,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7743_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index 0442aad4f9db..d01eba99ceb0 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -702,6 +702,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7744_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0f14ac22921d..d0d45a369047 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -645,6 +645,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7745_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 691b1a131c87..ae90a001d663 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -537,6 +537,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A77470_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b0569b4ea5c8..af9cd3324f4c 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -768,6 +768,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7790_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 87f0d6dc3e5a..2354af7fa83f 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -728,6 +728,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7791_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index f5b299bfcb23..60c184ab1b49 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dt
[PATCH V3 1/5] dt-bindings: net: renesas,etheravb: Add additional clocks
The AVB driver assumes there is an external crystal, but it could be clocked by other means. In order to enable a programmable clock, it needs to be added to the clocks list and enabled in the driver. Since there currently only one clock, there is no clock-names list either. Update bindings to add the additional optional clock, and explicitly name both of them. Signed-off-by: Adam Ford Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring --- V3: No Change V2: No Change diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index de9dd574a2f9..7b32363ad8b4 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -49,7 +49,16 @@ properties: interrupt-names: true clocks: -maxItems: 1 +minItems: 1 +maxItems: 2 +items: + - description: AVB functional clock + - description: Optional TXC reference clock + + clock-names: +items: + - const: fck + - const: refclk iommus: maxItems: 1 -- 2.25.1
[PATCH V3 3/5] arm64: dts: renesas: Add fck to etheravb-rcar-gen3 clock-names list
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
---
V3: No Change
V2: No Change
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d64fb8b1b86c..ec4feb7df775 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1127,6 +1127,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774A1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 5b05474dc272..1ff62b2be1f3 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -1001,6 +1001,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774B1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index 20fa3caa050e..a4d9c6b31574 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -957,6 +957,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774C0_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
index 8eb006cbd9af..fec5839163ec 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
@@ -1230,6 +1230,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774E1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
index 5c39152e4570..1e622ab8a044 100644
--- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
@@ -1312,6 +1312,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
index 25d947a81b29..a3d1c33cbc1d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
@@ -1188,6 +1188,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7796_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
index e8c31ebec097..55a3ba3c844f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
@@ -1144,6 +1144,7 @@ avb: ethernet@e680 {
[PATCH] arm64: dts: imx8mn-beacon: Enable SDR104 on WiFi SDIO interface
Enable 100Mhz and 200MHz pinmux and corrsesponding voltage supplies
to enable SDR104 on usdhc1 connecting the WiFi chip.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
index de2cd0e3201c..c35eeaff958f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
@@ -262,8 +262,12 @@ bluetooth {
{
#address-cells = <1>;
#size-cells = <0>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc1>;
+ pinctrl-1 = <_usdhc1_100mhz>;
+ pinctrl-2 = <_usdhc1_200mhz>;
+ vmmc-supply = <_reg>;
+ vqmmc-supply = <_reg>;
bus-width = <4>;
non-removable;
cap-power-off-card;
--
2.25.1
Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout
On Wed, Feb 3, 2021 at 3:22 PM Adam Ford wrote: > > On Thu, Jan 21, 2021 at 4:24 AM Abel Vesa wrote: > > > > On 21-01-21 10:56:17, Sascha Hauer wrote: > > > On Wed, Jan 20, 2021 at 06:14:21PM +0200, Abel Vesa wrote: > > > > On 21-01-20 16:50:01, Sascha Hauer wrote: > > > > > On Wed, Jan 20, 2021 at 05:28:13PM +0200, Abel Vesa wrote: > > > > > > On 21-01-20 16:13:05, Sascha Hauer wrote: > > > > > > > Hi Abel, > > > > > > > > > > > > > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa wrote: > > > > > > > > On 21-01-18 08:00:43, Adam Ford wrote: > > > > > > > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa > > > > > > > > > wrote: > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > TBH, I'm against the idea of having to call consumer API > > > > > > > > > > from a clock provider driver. > > > > > > > > > > I'm still investigating a way of moving the uart clock > > > > > > > > > > control calls in drivers/serial/imx, > > > > > > > > > > where they belong. > > > > > > > > > > > > > > > > > > That makes sense. > > > > > > > > > > > > > > > > > > > > > > > > > Just a thought. The uart clock used for console remains on from > > > > > > > > u-boot, > > > > > > > > so maybe it's enough to just add the CLK_IGNORE_UNUSED flag to > > > > > > > > all the > > > > > > > > uart root clocks and remove the prepare/enable calls for uart > > > > > > > > clocks > > > > > > > > for good. I don't really have a way to test it right now, but > > > > > > > > maybe > > > > > > > > you could give it a try. > > > > > > > > > > > > > > That would mean that UART clocks will never be disabled, > > > > > > > regardless of > > > > > > > whether they are used for console or not. That doesn't sound very > > > > > > > appealing. > > > > > > > > > > > > AFAIK, the only uart clock that is enabled by u-boot is the one > > > > > > used for > > > > > > the console. Later on, when the serial driver probes, it will > > > > > > enable it itself. > > > > > > > > > > > > Unless I'm missing something, this is exactly what we need. > > > > > > > > > > It might enable it, but with CLK_IGNORE_UNUSED the clock won't be > > > > > disabled again when a port is closed after usage > > > > > > > > OK, tell me what I'm getting wrong in the following scenario: > > > > > > > > U-boot leaves the console uart clock enabled. All the other ones are > > > > disabled. > > > > > > > > Kernel i.MX clk driver registers the uart clocks with flag > > > > CLK_IGNORE_UNUSED. > > > > > > I was wrong at that point. I originally thought the kernel will never > > > disable these clocks, but in fact it only leaves them enabled during the > > > clk_disable_unused call. > > > > > > However, when CLK_IGNORE_UNUSED becomes relevant it's too late already. > > > I just chatted with Lucas and he told me what the original problem was > > > that his patch solved. > > > > > > The problem comes when an unrelated device and the earlycon UART have > > > the same parent clocks. The parent clock is enabled, but it's reference > > > count is zero. Now when the unrelated device probes and toggles its > > > clocks then the shared parent clock will be disabled due to the > > > reference count being zero. Next time earlycon prints a character the > > > system hangs because the UART gates are still enabled, but their parent > > > clocks no longer are. > > > > > > > Hmm, that is indeed a problem. That's why I think there should be some > > kind of NOCACHE flag for almost all the types of clocks. For example, > > in this case, it makes sense for the core to check the bit in the register > > and then disable the pare
Re: [PATCH V3 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property
On Wed, Feb 10, 2021 at 2:18 PM Rob Herring wrote: > > On Sun, Feb 07, 2021 at 12:51:38PM -0600, Adam Ford wrote: > > There are two registers which can set the load capacitance for > > XTAL1 and XTAL2. These are optional registers when using an > > external crystal. Since XTAL1 and XTAL2 will set to the same value, > > update the binding to support a single property called > > xtal-load-femtofarads. > > > > Signed-off-by: Adam Ford > > --- > > V3: No Change > > V2: No Change > > > > A couple people suggested that I not use the $ref, but without it, > > the bindings check failed with errors. > > > > diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > index 2ac1131fd922..c268debe5b8d 100644 > > --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > @@ -59,6 +59,12 @@ properties: > > minItems: 1 > > maxItems: 2 > > > > + idt,xtal-load-femtofarads: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > Don't need a type with standard unit suffix. If I remove that line, the binding check fails. adam > > > +minimum: 9000 > > +maximum: 22760 > > +description: Optional load capacitor for XTAL1 and XTAL2 > > + > > patternProperties: > >"^OUT[1-4]$": > > type: object > > -- > > 2.25.1 > >
[PATCH V3 2/2] clk: vc5: Add support for optional load capacitance
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal. Parse the device tree and set the
corresponding registers accordingly.
Signed-off-by: Adam Ford
---
V3: Fix whitespace. Use regmap_update_bits instead of performing
a manual read-modify-write.
V2: Make the math subtract 9000 since we have a DIV_ROUND_CLOSEST
This also allows us to remove the check for 9430 since values
between 9000 and 9430 will round up and down.
Make write VC5_XTAL_X1_LOAD_CAP and VC5_XTAL_X2_LOAD_CAP
a read-modify-write to not worry about the contents of
bits[1:0].
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 43db67337bc0..344cd6c61188 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -759,6 +759,63 @@ static int vc5_update_power(struct device_node *np_output,
return 0;
}
+static int vc5_map_cap_value(u32 femtofarads)
+{
+ int mapped_value;
+
+ /*
+* The datasheet explicitly states 9000 - 25000 with 0.5pF
+* steps, but the Programmer's guide shows the steps are 0.430pF.
+* After getting feedback from Renesas, the .5pF steps were the
+* goal, but 430nF was the actual values.
+* Because of this, the actual range goes to 22760 instead of 25000
+*/
+ if (femtofarads < 9000 || femtofarads > 22760)
+ return -EINVAL;
+
+ /*
+* The Programmer's guide shows XTAL[5:0] but in reality,
+* XTAL[0] and XTAL[1] are both LSB which makes the math
+* strange. With clarfication from Renesas, setting the
+* values should be simpler by ignoring XTAL[0]
+*/
+ mapped_value = DIV_ROUND_CLOSEST(femtofarads - 9000, 430);
+
+ /*
+* Since the calculation ignores XTAL[0], there is one
+* special case where mapped_value = 32. In reality, this means
+* the real mapped value should be 11b. In other cases,
+* the mapped_value needs to be shifted 1 to the left.
+*/
+ if (mapped_value > 31)
+ mapped_value = 0x3f;
+ else
+ mapped_value <<= 1;
+
+ return mapped_value;
+}
+static int vc5_update_cap_load(struct device_node *node, struct
vc5_driver_data *vc5)
+{
+ u32 value;
+ int mapped_value;
+
+ if (!of_property_read_u32(node, "idt,xtal-load-femtofarads", )) {
+ mapped_value = vc5_map_cap_value(value);
+ if (mapped_value < 0)
+ return mapped_value;
+
+ /*
+* The mapped_value is really the high 6 bits of
+* VC5_XTAL_X1_LOAD_CAP and VC5_XTAL_X2_LOAD_CAP, so
+* shift the value 2 places.
+*/
+ regmap_update_bits(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, ~0x03,
mapped_value << 2);
+ regmap_update_bits(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, ~0x03,
mapped_value << 2);
+ }
+
+ return 0;
+}
+
static int vc5_update_slew(struct device_node *np_output,
struct vc5_out_data *clk_out)
{
@@ -884,6 +941,13 @@ static int vc5_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return -EINVAL;
}
+ /* Configure Optional Loading Capacitance for external XTAL */
+ if (!(vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)) {
+ ret = vc5_update_cap_load(client->dev.of_node, vc5);
+ if (ret)
+ goto err_clk_register;
+ }
+
init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node);
init.ops = _mux_ops;
init.flags = 0;
--
2.25.1
[PATCH V3 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property
There are two registers which can set the load capacitance for XTAL1 and XTAL2. These are optional registers when using an external crystal. Since XTAL1 and XTAL2 will set to the same value, update the binding to support a single property called xtal-load-femtofarads. Signed-off-by: Adam Ford --- V3: No Change V2: No Change A couple people suggested that I not use the $ref, but without it, the bindings check failed with errors. diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index 2ac1131fd922..c268debe5b8d 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -59,6 +59,12 @@ properties: minItems: 1 maxItems: 2 + idt,xtal-load-femtofarads: +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 9000 +maximum: 22760 +description: Optional load capacitor for XTAL1 and XTAL2 + patternProperties: "^OUT[1-4]$": type: object -- 2.25.1
Re: [PATCH 3/4] thermal: ti-soc-thermal: Simplify polling with iopoll
On Fri, Feb 5, 2021 at 7:45 AM Tony Lindgren wrote:
>
> We can use iopoll for checking the EOCZ (end of conversion) bit. And with
> this we now also want to handle the timeout errors properly.
>
> For omap3, we need about 1.2ms for the single mode sampling to wait for
> EOCZ down, so let's use 1.5ms timeout there. Waiting for sampling to start
> is faster and we can use 1ms timeout.
>
> Cc: Adam Ford
> Cc: Carl Philipp Klemm
> Cc: Eduardo Valentin
> Cc: H. Nikolaus Schaller
> Cc: Merlijn Wajer
> Cc: Pavel Machek
> Cc: Peter Ujfalusi
> Cc: Sebastian Reichel
> Signed-off-by: Tony Lindgren
For the series,
Tested-by: Adam Ford #logicpd-torpedo-37xx-devkit
> ---
> drivers/thermal/ti-soc-thermal/ti-bandgap.c | 30 ++---
> 1 file changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -15,7 +15,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -27,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -604,7 +604,9 @@ static int
> ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
> {
> struct temp_sensor_registers *tsr = bgp->conf->sensors[id].registers;
> - u32 counter;
> + void __iomem *temp_sensor_ctrl = bgp->base + tsr->temp_sensor_ctrl;
> + int error;
> + u32 val;
>
> /* Select continuous or single conversion mode */
> if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) {
> @@ -619,26 +621,22 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp,
> int id)
> RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
>
> /* Wait for EOCZ going up */
> - counter = 1000;
> - while (--counter) {
> - if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
> - tsr->bgap_eocz_mask)
> - break;
> - udelay(1);
> - }
> + error = readl_poll_timeout_atomic(temp_sensor_ctrl, val,
> + val & tsr->bgap_eocz_mask,
> + 1, 1000);
> + if (error)
> + dev_warn(bgp->dev, "eocz timed out waiting high\n");
>
> /* Clear Start of Conversion if available */
> RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
> }
>
> /* Wait for EOCZ going down, always needed even if no bgap_soc_mask */
> - counter = 1000;
> - while (--counter) {
> - if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
> - tsr->bgap_eocz_mask))
> - break;
> - udelay(1);
> - }
> + error = readl_poll_timeout_atomic(temp_sensor_ctrl, val,
> + !(val & tsr->bgap_eocz_mask),
> + 1, 1500);
> + if (error)
> + dev_warn(bgp->dev, "eocz timed out waiting low\n");
>
> return 0;
> }
> --
> 2.30.0
Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout
On Thu, Jan 21, 2021 at 4:24 AM Abel Vesa wrote: > > On 21-01-21 10:56:17, Sascha Hauer wrote: > > On Wed, Jan 20, 2021 at 06:14:21PM +0200, Abel Vesa wrote: > > > On 21-01-20 16:50:01, Sascha Hauer wrote: > > > > On Wed, Jan 20, 2021 at 05:28:13PM +0200, Abel Vesa wrote: > > > > > On 21-01-20 16:13:05, Sascha Hauer wrote: > > > > > > Hi Abel, > > > > > > > > > > > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa wrote: > > > > > > > On 21-01-18 08:00:43, Adam Ford wrote: > > > > > > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa > > > > > > > > wrote: > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > TBH, I'm against the idea of having to call consumer API from > > > > > > > > > a clock provider driver. > > > > > > > > > I'm still investigating a way of moving the uart clock > > > > > > > > > control calls in drivers/serial/imx, > > > > > > > > > where they belong. > > > > > > > > > > > > > > > > That makes sense. > > > > > > > > > > > > > > > > > > > > > > Just a thought. The uart clock used for console remains on from > > > > > > > u-boot, > > > > > > > so maybe it's enough to just add the CLK_IGNORE_UNUSED flag to > > > > > > > all the > > > > > > > uart root clocks and remove the prepare/enable calls for uart > > > > > > > clocks > > > > > > > for good. I don't really have a way to test it right now, but > > > > > > > maybe > > > > > > > you could give it a try. > > > > > > > > > > > > That would mean that UART clocks will never be disabled, regardless > > > > > > of > > > > > > whether they are used for console or not. That doesn't sound very > > > > > > appealing. > > > > > > > > > > AFAIK, the only uart clock that is enabled by u-boot is the one used > > > > > for > > > > > the console. Later on, when the serial driver probes, it will enable > > > > > it itself. > > > > > > > > > > Unless I'm missing something, this is exactly what we need. > > > > > > > > It might enable it, but with CLK_IGNORE_UNUSED the clock won't be > > > > disabled again when a port is closed after usage > > > > > > OK, tell me what I'm getting wrong in the following scenario: > > > > > > U-boot leaves the console uart clock enabled. All the other ones are > > > disabled. > > > > > > Kernel i.MX clk driver registers the uart clocks with flag > > > CLK_IGNORE_UNUSED. > > > > I was wrong at that point. I originally thought the kernel will never > > disable these clocks, but in fact it only leaves them enabled during the > > clk_disable_unused call. > > > > However, when CLK_IGNORE_UNUSED becomes relevant it's too late already. > > I just chatted with Lucas and he told me what the original problem was > > that his patch solved. > > > > The problem comes when an unrelated device and the earlycon UART have > > the same parent clocks. The parent clock is enabled, but it's reference > > count is zero. Now when the unrelated device probes and toggles its > > clocks then the shared parent clock will be disabled due to the > > reference count being zero. Next time earlycon prints a character the > > system hangs because the UART gates are still enabled, but their parent > > clocks no longer are. > > > > Hmm, that is indeed a problem. That's why I think there should be some > kind of NOCACHE flag for almost all the types of clocks. For example, > in this case, it makes sense for the core to check the bit in the register > and then disable the parent based on that instead of relying on the refcount. > Anyway, that's something that needs to be added in the CCF. > > > Overall I think Lucas' patches are still valid and relevant and with > > Adams patches we even no longer have to enable all UART clocks, but > > only the ones which are actually needed. > > Yeah, for now, I think we can go with Adam's patches. But longterm, I would > like to remove the special case of the uart clocks we have right now in all > the i.MX clock drivers. > Is the patch I submitted good enough for someone's acked-by or reviewed-by, or are there changes I need to implement? adam > > > > Sascha > > > > > > -- > > Pengutronix e.K. | | > > Steuerwalder Str. 21 | > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pengutronix.de%2Fdata=04%7C01%7Cabel.vesa%40nxp.com%7Ceed68987c68f4aeaa63408d8bdf2d051%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637468197861821302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=X1J8KgxFquNin80zKVz0Ao22vv1MuTMWf91BUTczh9Y%3Dreserved=0 > > | > > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH V2 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property
On Wed, Jan 20, 2021 at 10:35 AM Luca Ceresoli wrote: > > Hi Adam, > > On 19/01/21 22:21, Adam Ford wrote: > > There are two registers which can set the load capacitance for > > XTAL1 and XTAL2. These are optional registers when using an > > external crystal. Since XTAL1 and XTAL2 will set to the same value, > > update the binding to support a single property called > > xtal-load-femtofarads. > > > > Signed-off-by: Adam Ford > > --- > > V2: No Change > > > > diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > index 2ac1131fd922..c268debe5b8d 100644 > > --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > @@ -59,6 +59,12 @@ properties: > > minItems: 1 > > maxItems: 2 > > > > + idt,xtal-load-femtofarads: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > "Vendor specific properties having a standard unit suffix don't need a > type." -- Documentation/devicetree/bindings/example-schema.yaml > I tried to remove the "$ref: /schemas/types.yaml#/definitions/uint32" but when I ran the test to make the yaml files, it threw an error, so I put it back. adam > Overall looks good. > > -- > Luca
[PATCH 1/2] arm64: dts: imx8mn: Add fspi node
The i.MX8M Nano has the same Flexspi controller used in the i.MX8M
Mini. Add the node and disable it by default.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 3fac73779fdd..16ea50089567 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -889,6 +889,19 @@ usdhc3: mmc@30b6 {
status = "disabled";
};
+ flexspi: spi@30bb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nxp,imx8mm-fspi";
+ reg = <0x30bb 0x1>, <0x800
0x1000>;
+ reg-names = "fspi_base", "fspi_mmap";
+ interrupts = ;
+ clocks = < IMX8MN_CLK_QSPI_ROOT>,
+< IMX8MN_CLK_QSPI_ROOT>;
+ clock-names = "fspi", "fspi_en";
+ status = "disabled";
+ };
+
sdma1: dma-controller@30bd {
compatible = "fsl,imx8mn-sdma",
"fsl,imx8mq-sdma";
reg = <0x30bd 0x1>;
--
2.25.1
[PATCH 2/2] arm64: dts: imx8mn-beacon-som: Enable QSPI on SOM
There is a QSPI chip connected to the FlexSPI bus. Enable it.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
index 2120e6485393..9f575184d899 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
@@ -7,6 +7,7 @@ / {
aliases {
rtc0 =
rtc1 = _rtc;
+ spi0 =
};
usdhc1_pwrseq: usdhc1_pwrseq {
@@ -89,6 +90,22 @@ ethphy0: ethernet-phy@0 {
};
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_flexspi>;
+ status = "okay";
+
+ flash@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <8000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ };
+};
+
{
clock-frequency = <40>;
pinctrl-names = "default";
@@ -318,6 +335,18 @@ MX8MN_IOMUXC_I2C3_SDA_I2C3_SDA 0x41c3
>;
};
+ pinctrl_flexspi: flexspigrp {
+ fsl,pins = <
+ MX8MN_IOMUXC_NAND_ALE_QSPI_A_SCLK 0x1c2
+ MX8MN_IOMUXC_NAND_CE0_B_QSPI_A_SS0_B0x82
+ MX8MN_IOMUXC_NAND_DATA00_QSPI_A_DATA0 0x82
+ MX8MN_IOMUXC_NAND_DATA01_QSPI_A_DATA1 0x82
+ MX8MN_IOMUXC_NAND_DATA02_QSPI_A_DATA2 0x82
+ MX8MN_IOMUXC_NAND_DATA03_QSPI_A_DATA3 0x82
+ >;
+ };
+
+
pinctrl_pmic: pmicirqgrp {
fsl,pins = <
MX8MN_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x141
--
2.25.1
[PATCH V2 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property
There are two registers which can set the load capacitance for XTAL1 and XTAL2. These are optional registers when using an external crystal. Since XTAL1 and XTAL2 will set to the same value, update the binding to support a single property called xtal-load-femtofarads. Signed-off-by: Adam Ford --- V2: No Change diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index 2ac1131fd922..c268debe5b8d 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -59,6 +59,12 @@ properties: minItems: 1 maxItems: 2 + idt,xtal-load-femtofarads: +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 9000 +maximum: 22760 +description: Optional load capacitor for XTAL1 and XTAL2 + patternProperties: "^OUT[1-4]$": type: object -- 2.25.1
[PATCH V2 2/2] clk: vc5: Add support for optional load capacitance
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal. Parse the device tree and set the
corresponding registers accordingly.
Signed-off-by: Adam Ford
---
V2: Make the math subtract 9000 since we have a DIV_ROUND_CLOSEST
This also allows us to remove the check for 9430 since values
between 9000 and 9430 will round up and down.
Make write VC5_XTAL_X1_LOAD_CAP and VC5_XTAL_X2_LOAD_CAP
a read-modify-write to not worry about the contents of
bits[1:0].
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 43db67337bc0..c6b04c077224 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -759,6 +759,74 @@ static int vc5_update_power(struct device_node *np_output,
return 0;
}
+static int vc5_map_cap_value(u32 femtofarads)
+{
+ int mapped_value;
+
+ /*
+* The datasheet explicitly states 9000 - 25000 with 0.5pF
+* steps, but the Programmer's guide shows the steps are 0.430pF.
+* After getting feedback from Renesas, the .5pF steps were the
+* goal, but 430nF was the actual values.
+* Because of this, the actual range goes to 22760 instead of 25000
+*/
+ if (femtofarads < 9000 || femtofarads > 22760)
+ return -EINVAL;
+
+ /*
+* The Programmer's guide shows XTAL[5:0] but in reality,
+* XTAL[0] and XTAL[1] are both LSB which makes the math
+* strange. With clarfication from Renesas, setting the
+* values should be simpler by ignoring XTAL[0]
+*/
+
+ mapped_value = DIV_ROUND_CLOSEST(femtofarads - 9000, 430);
+
+ /*
+* Since the calculation ignores XTAL[0], there is one
+* special case where mapped_value = 32. In reality, this means
+* the real mapped value should be 11b. In other clases,
+* the mapped_value needs to be shifted 1 to the left.
+*/
+
+ if (mapped_value > 31)
+ mapped_value = 0x3f;
+ else
+ mapped_value <<= 1;
+
+ return mapped_value;
+}
+static int vc5_update_cap_load(struct device_node *node, struct
vc5_driver_data *vc5)
+{
+ u32 value;
+ int mapped_value, cache;
+
+ if (!of_property_read_u32(node, "idt,xtal-load-femtofarads", )) {
+ mapped_value = vc5_map_cap_value(value);
+ if (mapped_value < 0)
+ return mapped_value;
+
+ /*
+* The mapped_value is really the high 6 bits of
+* VC5_XTAL_X1_LOAD_CAP and VC5_XTAL_X2_LOAD_CAP, so
+* shift the value 2 places. Read each register, wipe out
+* the top 6 bits and, write the combined data back.
+*/
+
+ mapped_value = (mapped_value << 2);
+
+ cache = regmap_read(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, );
+ cache &= 0x03;
+ regmap_write(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, mapped_value |
cache);
+
+ cache = regmap_read(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, );
+ cache &= 0x03;
+ regmap_write(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, mapped_value |
cache);
+ }
+
+ return 0;
+}
+
static int vc5_update_slew(struct device_node *np_output,
struct vc5_out_data *clk_out)
{
@@ -884,6 +952,13 @@ static int vc5_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return -EINVAL;
}
+ /* Configure Optional Loading Capacitance for external XTAL */
+ if (!(vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)) {
+ ret = vc5_update_cap_load(client->dev.of_node, vc5);
+ if (ret)
+ goto err_clk_register;
+ }
+
init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node);
init.ops = _mux_ops;
init.flags = 0;
--
2.25.1
Re: [PATCH 2/2] clk: vc5: Add support for optional load capacitance
On Sat, Jan 16, 2021 at 3:55 PM Adam Ford wrote:
>
> There are two registers which can set the load capacitance for
> XTAL1 and XTAL2. These are optional registers when using an
> external crystal. Parse the device tree and set the
> corresponding registers accordingly.
>
> Signed-off-by: Adam Ford
>
> diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
> index 43db67337bc0..224118ca08fd 100644
> --- a/drivers/clk/clk-versaclock5.c
> +++ b/drivers/clk/clk-versaclock5.c
> @@ -759,6 +759,72 @@ static int vc5_update_power(struct device_node
> *np_output,
> return 0;
> }
>
> +static int vc5_map_cap_value(u32 femtofarads)
> +{
> + int mapped_value;
> +
> + /*
> +* The datasheet explicitly states 9000 - 25000 with 0.5pF
> +* steps, but the Programmer's guide shows the steps are 0.430pF.
> +* After getting feedback from Renesas, the .5pF steps were the
> +* goal, but 430nF was the actual values.
> +* Because of this, the actual range goes to 22760 instead of 25000
> +*/
> + if (femtofarads < 9000 || femtofarads > 22760)
> + return -EINVAL;
> +
> + /* The lowest target we can hit is 9430, so exit if it's less */
> + if (femtofarads < 9430)
> + return 0;
> +
> + /*
> +* The Programmer's guide shows XTAL[5:0] but in reality,
> +* XTAL[0] and XTAL[1] are both LSB which makes the math
> +* strange. With clarfication from Renesas, setting the
> +* values should be simpler by ignoring XTAL[0]
> +*/
> +
> + mapped_value = DIV_ROUND_CLOSEST(femtofarads - 9430, 430);
> +
> + /*
> +* Since the calculation ignores XTAL[0], there is one
> +* special case where mapped_value = 32. In reality, this means
> +* the real mapped value should be 11b. In other clases,
> +* the mapped_value needs to be shifted 1 to the left.
> +*/
> +
> + if (mapped_value > 31)
> + mapped_value = 0x3f;
> + else
> + mapped_value <<= 1;
> +
> + return mapped_value;
> +}
> +static int vc5_update_cap_load(struct device_node *node, struct
> vc5_driver_data *vc5)
> +{
> + u32 value;
> + int mapped_value;
> +
> + if (!of_property_read_u32(node, "idt,xtal-load-femtofarads", ))
> {
> + mapped_value = vc5_map_cap_value(value);
> + if (mapped_value < 0)
> + return mapped_value;
> +
> + /*
> +* According to Renesas, bits [1:0] of VC5_XTAL_X1_LOAD_CAP
> +* and VC5_XTAL_X2_LOAD_CAP should always be 01b.
> +* Since the mapped_value is really the high 6 bits of 8,
> +* shift the value 2 places and or in the 0x01;
> +*/
> +
> + mapped_value = (mapped_value << 2) | 0x01;
> + regmap_write(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, mapped_value);
> + regmap_write(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, mapped_value);
On second thought I'm going to change register write to a
read-modify-write since the low two bits are unclear and X1 and X2 low
bits are not exactly the same. Since the info is confusing, I can
cache VC5_XTAL_X1_LOAD_CAP, clear the upper 6 bits and then logic-or
the value. This way we don't have to guess about what the 0x01. It
also appears the 0x01 is only for one of the registers and not both.
> + }
> +
> + return 0;
> +}
> +
> static int vc5_update_slew(struct device_node *np_output,
>struct vc5_out_data *clk_out)
> {
> @@ -884,6 +950,13 @@ static int vc5_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> return -EINVAL;
> }
>
> + /* Configure Optional Loading Capacitance for external XTAL */
> + if (!(vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)) {
> + ret = vc5_update_cap_load(client->dev.of_node, vc5);
> + if (ret)
> + goto err_clk_register;
> + }
> +
> init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node);
> init.ops = _mux_ops;
> init.flags = 0;
> --
> 2.25.1
>
Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout
On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa wrote:
>
> On 21-01-15 12:29:08, Adam Ford wrote:
>
> ...
>
> > diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
> > index a66cabfbf94f..66192fe0a898 100644
> > --- a/drivers/clk/imx/clk-imx25.c
> > +++ b/drivers/clk/imx/clk-imx25.c
> > @@ -73,16 +73,6 @@ enum mx25_clks {
> >
> > static struct clk *clk[clk_max];
> >
> > -static struct clk ** const uart_clks[] __initconst = {
> > - [uart_ipg_per],
> > - [uart1_ipg],
> > - [uart2_ipg],
> > - [uart3_ipg],
> > - [uart4_ipg],
> > - [uart5_ipg],
> > - NULL
> > -};
> > -
>
> I'm assuming there is another patch that updates the dts files. Right ?
I have only been able to test this on an i.MX8M Mini. I need to set
the parent clock of the i.MX8M Mini to an 80 MHz clock in order to run
the UART at 4Mbps. With this patch, I can stop enabling the all the
UART clocks early and allow the clock parent configuration to occur.
>From what I can tell, the remaining clocks should get activated as
they are needed, because I was able to use Bluetooth connected to
UART1 running at 4MBps using a 80MHz clock source with this patch, and
the clk_summary shows the clock is running at the proper speed.
Without this patch, the UART fails to re-parent, so I'm stuck at lower
speeds and that means choppy Bluetooth audio.
The Kernel that NXP hosts on Code Aurora that they use for Yocto
attempts scan through stdout to only enable those clocks [1]. I
attempted to push it upstream, but it was rejected [2]. Sascha
suggested creating an array which could be filled when the clocks are
enabled and that array would be used to deactivate the clocks at
shutdown. That's what I attempted to do here.
I don't have older imx boards to know if their device trees are
configured in such a way without modifications to the device tree or
not, but since it appears to work for NXP in [2], I assumed it would
work here.
[1] -
https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/clk/imx/clk.c?h=imx_5.4.47_2.2.0=754ae82cc55b7445545fc2f092a70e0f490e9c1b
[2] -
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201229145130.2680442-1-aford...@gmail.com/
>
> TBH, I'm against the idea of having to call consumer API from a clock
> provider driver.
> I'm still investigating a way of moving the uart clock control calls in
> drivers/serial/imx,
> where they belong.
That makes sense.
>
> > static int __init __mx25_clocks_init(void __iomem *ccm_base)
> > {
> > BUG_ON(!ccm_base);
> > @@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem
> > *ccm_base)
> >*/
> > clk_set_parent(clk[cko_sel], clk[ipg]);
> >
> > - imx_register_uart_clocks(uart_clks);
> > + imx_register_uart_clocks(6);
>
> Suggestion: Maybe the number of clocks can be determined by the existing
> clocks in that dts node.
> Hardcoding is not a good ideea here.
The tables were hard-coded before, so the idea was to pass the maximum
number of clocks instead the entire table. The higher-level clock
code wouldn't necessarily know the maximum number of UART clocks since
the number of UARTs may change depending on the SoC. So that
hard-coded number was simply the number of entries that were
previously used in the array that was previously passed. When
creating a table of active clocks, it could use the number passed to
define an array, and fill the array with data grabbed from of_stdout.
If you want, I could leave the existing UART clocks alone, and create
a new function that uses the array of clocks passed to it to count the
number of available clocks. It would limit the scope of the change to
clk/imx/clk.c. I think that would be easier than trying to parse the
DT for a bunch of compatible flags looking for a bunch of UARTS and
their respective clocks.
If you'd rather do something in the serial imx driver, I can hold off.
adam
>
> ...
>
> >
> > diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
> > index 47882c51cb85..158fe302a8b7 100644
> > --- a/drivers/clk/imx/clk.c
> > +++ b/drivers/clk/imx/clk.c
> > @@ -147,8 +147,10 @@ void imx_cscmr1_fixup(u32 *val)
> > }
> >
> > #ifndef MODULE
> > -static int imx_keep_uart_clocks;
> > -static struct clk ** const *imx_uart_clocks;
> > +
> > +static bool imx_keep_uart_clocks;
> > +static int imx_enabled_uart_clocks;
> > +static struct clk **imx_uart_clocks;
> >
> > static int __init imx_keep_uart_clocks_param(char *str)
> > {
> > @@ -161,24 +163,43 @@ __setup_param("earlycon", imx_keep_uart_earlycon,
> > __setup_param("earlyprintk", imx_keep_uart_ea
[PATCH 2/2] clk: vc5: Add support for optional load capacitance
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal. Parse the device tree and set the
corresponding registers accordingly.
Signed-off-by: Adam Ford
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 43db67337bc0..224118ca08fd 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -759,6 +759,72 @@ static int vc5_update_power(struct device_node *np_output,
return 0;
}
+static int vc5_map_cap_value(u32 femtofarads)
+{
+ int mapped_value;
+
+ /*
+* The datasheet explicitly states 9000 - 25000 with 0.5pF
+* steps, but the Programmer's guide shows the steps are 0.430pF.
+* After getting feedback from Renesas, the .5pF steps were the
+* goal, but 430nF was the actual values.
+* Because of this, the actual range goes to 22760 instead of 25000
+*/
+ if (femtofarads < 9000 || femtofarads > 22760)
+ return -EINVAL;
+
+ /* The lowest target we can hit is 9430, so exit if it's less */
+ if (femtofarads < 9430)
+ return 0;
+
+ /*
+* The Programmer's guide shows XTAL[5:0] but in reality,
+* XTAL[0] and XTAL[1] are both LSB which makes the math
+* strange. With clarfication from Renesas, setting the
+* values should be simpler by ignoring XTAL[0]
+*/
+
+ mapped_value = DIV_ROUND_CLOSEST(femtofarads - 9430, 430);
+
+ /*
+* Since the calculation ignores XTAL[0], there is one
+* special case where mapped_value = 32. In reality, this means
+* the real mapped value should be 11b. In other clases,
+* the mapped_value needs to be shifted 1 to the left.
+*/
+
+ if (mapped_value > 31)
+ mapped_value = 0x3f;
+ else
+ mapped_value <<= 1;
+
+ return mapped_value;
+}
+static int vc5_update_cap_load(struct device_node *node, struct
vc5_driver_data *vc5)
+{
+ u32 value;
+ int mapped_value;
+
+ if (!of_property_read_u32(node, "idt,xtal-load-femtofarads", )) {
+ mapped_value = vc5_map_cap_value(value);
+ if (mapped_value < 0)
+ return mapped_value;
+
+ /*
+* According to Renesas, bits [1:0] of VC5_XTAL_X1_LOAD_CAP
+* and VC5_XTAL_X2_LOAD_CAP should always be 01b.
+* Since the mapped_value is really the high 6 bits of 8,
+* shift the value 2 places and or in the 0x01;
+*/
+
+ mapped_value = (mapped_value << 2) | 0x01;
+ regmap_write(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, mapped_value);
+ regmap_write(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, mapped_value);
+ }
+
+ return 0;
+}
+
static int vc5_update_slew(struct device_node *np_output,
struct vc5_out_data *clk_out)
{
@@ -884,6 +950,13 @@ static int vc5_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return -EINVAL;
}
+ /* Configure Optional Loading Capacitance for external XTAL */
+ if (!(vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)) {
+ ret = vc5_update_cap_load(client->dev.of_node, vc5);
+ if (ret)
+ goto err_clk_register;
+ }
+
init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node);
init.ops = _mux_ops;
init.flags = 0;
--
2.25.1
[PATCH 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property
There are two registers which can set the load capacitance for XTAL1 and XTAL2. These are optional registers when using an external crystal. Since XTAL1 and XTAL2 will set to the same value, update the binding to support a single property called xtal-load-femtofarads. Signed-off-by: Adam Ford diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index 2ac1131fd922..c268debe5b8d 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -59,6 +59,12 @@ properties: minItems: 1 maxItems: 2 + idt,xtal-load-femtofarads: +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 9000 +maximum: 22760 +description: Optional load capacitor for XTAL1 and XTAL2 + patternProperties: "^OUT[1-4]$": type: object -- 2.25.1
[PATCH V2 3/4] arm64: dts: renesas: Add fck to etheravb-rcar-gen3 clock-names list
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77951.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77960.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77961.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 1 +
12 files changed, 12 insertions(+)
V2: No change
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d64fb8b1b86c..ec4feb7df775 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1127,6 +1127,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774A1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 5b05474dc272..1ff62b2be1f3 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -1001,6 +1001,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774B1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index 20fa3caa050e..a4d9c6b31574 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -957,6 +957,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774C0_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
index 8eb006cbd9af..fec5839163ec 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
@@ -1230,6 +1230,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774E1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
index 5c39152e4570..1e622ab8a044 100644
--- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
@@ -1312,6 +1312,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
index 25d947a81b29..a3d1c33cbc1d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
@@ -1188,6 +1188,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
[PATCH V2 1/4] dt-bindings: net: renesas,etheravb: Add additional clocks
The AVB driver assumes there is an external crystal, but it could be clocked by other means. In order to enable a programmable clock, it needs to be added to the clocks list and enabled in the driver. Since there currently only one clock, there is no clock-names list either. Update bindings to add the additional optional clock, and explicitly name both of them. Signed-off-by: Adam Ford Reviewed-by: Geert Uytterhoeven Acked-by: Rob Herring --- .../devicetree/bindings/net/renesas,etheravb.yaml | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) V2: Change name from TXC Refclock to refclock The r-b and a-b notes were pulled from patchwork. diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index 244befb6402a..9f84d9c6f141 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -49,7 +49,16 @@ properties: interrupt-names: true clocks: -maxItems: 1 +minItems: 1 +maxItems: 2 +items: + - description: AVB functional clock + - description: Optional reference clock + + clock-names: +items: + - const: fck + - const: refclk iommus: maxItems: 1 -- 2.25.1
[PATCH V2 4/4] net: ethernet: ravb: Enable optional refclk
For devices that use a programmable clock for the avb reference clock,
the driver may need to enable them. Add code to find the optional clock
and enable it when available.
Signed-off-by: Adam Ford
---
drivers/net/ethernet/renesas/ravb.h | 1 +
drivers/net/ethernet/renesas/ravb_main.c | 8
2 files changed, 9 insertions(+)
V2: The previous patch to fetch the fclk was dropped. In its place
is code to enable the refclk
diff --git a/drivers/net/ethernet/renesas/ravb.h
b/drivers/net/ethernet/renesas/ravb.h
index 7453b17a37a2..ff363797bd2b 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -994,6 +994,7 @@ struct ravb_private {
struct platform_device *pdev;
void __iomem *addr;
struct clk *clk;
+ struct clk *refclk;
struct mdiobb_ctrl mdiobb;
u32 num_rx_ring[NUM_RX_QUEUE];
u32 num_tx_ring[NUM_TX_QUEUE];
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index bd30505fbc57..739e30f45daa 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2148,6 +2148,14 @@ static int ravb_probe(struct platform_device *pdev)
goto out_release;
}
+ priv->refclk = devm_clk_get_optional(>dev, "refclk");
+ if (IS_ERR(priv->refclk)) {
+ error = PTR_ERR(priv->refclk);
+ goto out_release;
+ } else {
+ (void)clk_prepare_enable(priv->refclk);
+ }
+
ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
ndev->min_mtu = ETH_MIN_MTU;
--
2.25.1
[PATCH V2 2/4] ARM: dts: renesas: Add fck to etheravb-rcar-gen2 clock-names list
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7742.dtsi | 1 +
arch/arm/boot/dts/r8a7743.dtsi | 1 +
arch/arm/boot/dts/r8a7744.dtsi | 1 +
arch/arm/boot/dts/r8a7745.dtsi | 1 +
arch/arm/boot/dts/r8a77470.dtsi | 1 +
arch/arm/boot/dts/r8a7790.dtsi | 1 +
arch/arm/boot/dts/r8a7791.dtsi | 1 +
arch/arm/boot/dts/r8a7792.dtsi | 1 +
arch/arm/boot/dts/r8a7794.dtsi | 1 +
9 files changed, 9 insertions(+)
V2: No change
diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index 6a78c813057b..6b922f664fcd 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -750,6 +750,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7742_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index f444e418f408..084bf3e039cf 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -702,6 +702,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7743_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index 0442aad4f9db..d01eba99ceb0 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -702,6 +702,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7744_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0f14ac22921d..d0d45a369047 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -645,6 +645,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7745_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 691b1a131c87..ae90a001d663 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -537,6 +537,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A77470_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b0569b4ea5c8..af9cd3324f4c 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -768,6 +768,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7790_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 87f0d6dc3e5a..2354af7fa83f 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -728,6 +728,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
[PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout
Most if not all i.MX SoC's call a function which enables all UARTS.
This is a problem for users who need to re-parent the clock source,
because any attempt to change the parent results in an busy error
due to the fact that the clocks have been enabled already.
clk: failed to reparent uart1 to sys_pll1_80m: -16
Instead of pre-initializing all UARTS, scan the device tree to see
which UART clocks are associated to stdout, and only enable those
UART clocks if it's needed early. This will move initialization of
the remaining clocks until after the parenting of the clocks.
When the clocks are shutdown, this mechanism will also disable any
clocks that were pre-initialized.
Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate protection")
Suggested-by: Aisheng Dong
Signed-off-by: Adam Ford
---
V3: Return a method more closely related to upstream kernel but
instead of passing an array of UART's, each SoC passes the max
number of UART clocks is has. The imx clock driver will create
an array to enable on startup, and disable later.
V2: Attempt to port driver from vendor kernel.
diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
index a66cabfbf94f..66192fe0a898 100644
--- a/drivers/clk/imx/clk-imx25.c
+++ b/drivers/clk/imx/clk-imx25.c
@@ -73,16 +73,6 @@ enum mx25_clks {
static struct clk *clk[clk_max];
-static struct clk ** const uart_clks[] __initconst = {
- [uart_ipg_per],
- [uart1_ipg],
- [uart2_ipg],
- [uart3_ipg],
- [uart4_ipg],
- [uart5_ipg],
- NULL
-};
-
static int __init __mx25_clocks_init(void __iomem *ccm_base)
{
BUG_ON(!ccm_base);
@@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem *ccm_base)
*/
clk_set_parent(clk[cko_sel], clk[ipg]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks(6);
return 0;
}
diff --git a/drivers/clk/imx/clk-imx27.c b/drivers/clk/imx/clk-imx27.c
index 5585ded8b8c6..56a5fc402b10 100644
--- a/drivers/clk/imx/clk-imx27.c
+++ b/drivers/clk/imx/clk-imx27.c
@@ -49,17 +49,6 @@ static const char *ssi_sel_clks[] = { "spll_gate", "mpll", };
static struct clk *clk[IMX27_CLK_MAX];
static struct clk_onecell_data clk_data;
-static struct clk ** const uart_clks[] __initconst = {
- [IMX27_CLK_PER1_GATE],
- [IMX27_CLK_UART1_IPG_GATE],
- [IMX27_CLK_UART2_IPG_GATE],
- [IMX27_CLK_UART3_IPG_GATE],
- [IMX27_CLK_UART4_IPG_GATE],
- [IMX27_CLK_UART5_IPG_GATE],
- [IMX27_CLK_UART6_IPG_GATE],
- NULL
-};
-
static void __init _mx27_clocks_init(unsigned long fref)
{
BUG_ON(!ccm);
@@ -176,7 +165,7 @@ static void __init _mx27_clocks_init(unsigned long fref)
clk_prepare_enable(clk[IMX27_CLK_EMI_AHB_GATE]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks(7);
imx_print_silicon_rev("i.MX27", mx27_revision());
}
diff --git a/drivers/clk/imx/clk-imx31.c b/drivers/clk/imx/clk-imx31.c
index 7b13fb57d842..c44e18c6f63f 100644
--- a/drivers/clk/imx/clk-imx31.c
+++ b/drivers/clk/imx/clk-imx31.c
@@ -51,16 +51,6 @@ enum mx31_clks {
static struct clk *clk[clk_max];
static struct clk_onecell_data clk_data;
-static struct clk ** const uart_clks[] __initconst = {
- [ipg],
- [uart1_gate],
- [uart2_gate],
- [uart3_gate],
- [uart4_gate],
- [uart5_gate],
- NULL
-};
-
static void __init _mx31_clocks_init(void __iomem *base, unsigned long fref)
{
clk[dummy] = imx_clk_fixed("dummy", 0);
diff --git a/drivers/clk/imx/clk-imx35.c b/drivers/clk/imx/clk-imx35.c
index c1df03665c09..0fe5ac210156 100644
--- a/drivers/clk/imx/clk-imx35.c
+++ b/drivers/clk/imx/clk-imx35.c
@@ -82,14 +82,6 @@ enum mx35_clks {
static struct clk *clk[clk_max];
-static struct clk ** const uart_clks[] __initconst = {
- [ipg],
- [uart1_gate],
- [uart2_gate],
- [uart3_gate],
- NULL
-};
-
static void __init _mx35_clocks_init(void)
{
void __iomem *base;
@@ -243,7 +235,7 @@ static void __init _mx35_clocks_init(void)
*/
clk_prepare_enable(clk[scc_gate]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks(4);
imx_print_silicon_rev("i.MX35", mx35_revision());
}
diff --git a/drivers/clk/imx/clk-imx5.c b/drivers/clk/imx/clk-imx5.c
index 01e079b81026..e4493846454d 100644
--- a/drivers/clk/imx/clk-imx5.c
+++ b/drivers/clk/imx/clk-imx5.c
@@ -128,30 +128,6 @@ static const char *ieee1588_sels[] = { "pll3_sw",
"pll4_sw", "dummy" /* usbphy2_
static struct clk *clk[IMX5_CLK_END];
static struct clk_onecell_data clk_data;
-static struct clk ** const uart_clks_mx51[] __initconst = {
- [IMX5_CLK_UART1_IPG_GATE],
- [IMX5_CLK_UART1_PER_GATE],
- [IMX5_CLK_UART2_IPG_GATE],
- [IMX5_CLK_UART2_PER_GATE],
- [IMX5_CLK
Re: [RFC 1/2] dt-bindings: clk: versaclock5: Add load capacitance properties
On Tue, Jan 12, 2021 at 9:16 PM Rob Herring wrote: > > On Wed, Jan 06, 2021 at 11:38:59AM -0600, Adam Ford wrote: > > There are two registers which can set the load capacitance for > > XTAL1 and XTAL2. These are optional registers when using an > > external crystal. Update the bindings to support them. > > > > Signed-off-by: Adam Ford > > --- > > .../devicetree/bindings/clock/idt,versaclock5.yaml | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > index 2ac1131fd922..e5e55ffb266e 100644 > > --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > @@ -59,6 +59,18 @@ properties: > > minItems: 1 > > maxItems: 2 > > > > + idt,xtal1-load-femtofarads: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > Already has a type, so you can drop the $ref. > > > +minimum: 9000 > > +maximum: 25000 Luca, Do you want the range to the 9000 - 25000 per the datasheet, or should I use the max value based on the programmer guide? Currently, my intent was to cap the value to 1b, so anyone who writes 23000, 24000, or 25000 will all be the same value based on the feedback I got from Renesas. adam > > +description: Optional loading capacitor for XTAL1 > > + > > + idt,xtal2-load-femtofarads: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +minimum: 9000 > > +maximum: 25000 > > +description: Optional loading capacitor for XTAL2 > > + > > patternProperties: > >"^OUT[1-4]$": > > type: object > > -- > > 2.25.1 > >
Re: [RFC 2/2] clk: vc5: Add support for optional load capacitance
On Tue, Jan 12, 2021 at 10:45 AM Luca Ceresoli wrote:
>
> Hi Adam,
>
> On 11/01/21 17:40, Adam Ford wrote:
> > On Sat, Jan 9, 2021 at 12:02 PM Luca Ceresoli wrote:
> >>
> >> Hi Adam,
> >>
> >> On 09/01/21 04:00, Adam Ford wrote:
> >>> On Fri, Jan 8, 2021 at 4:49 PM Luca Ceresoli
> >>> wrote:
> >>>>
> >>>> Hi Adam,
> >>>>
> >>>> On 06/01/21 18:39, Adam Ford wrote:
> >>>>> There are two registers which can set the load capacitance for
> >>>>> XTAL1 and XTAL2. These are optional registers when using an
> >>>>> external crystal. Parse the device tree and set the
> >>>>> corresponding registers accordingly.
> >>>>
> >>>> No need to repeat the first 2 sentences, they are already in patch 1.
> >>>
> >>> The reason I did that was because if someone does a git log on the
> >>> individual file, they'd see the comment. While it's redundant not, it
> >>> might not be as obvious in the future when looking back. Not
> >>> everyone reviews the history of the binding, but the source files' git
> >>> logs usually have some value. However, if you want me to drop it or
> >>> rephrase it, I can do that.
> >>
> >> Makes sense, I had never considered that before.
> >>
> >>>>> +static int vc5_map_cap_value(u32 femtofarads)
> >>>>> +{
> >>>>> + int mapped_value;
> >>>>> +
> >>>>> + /* The datasheet explicitly states 9000 - 25000 */
> >>>>> + if ((femtofarads < 9000) || (femtofarads > 25000))
> >>>>> + return -EINVAL;
> >>>>> +
> >>>>> + /* The lowest target we can hit is 9430, so exit if it's less */
> >>>>> + if (femtofarads < 9430)
> >>>>> + return 0;
> >>>>> +
> >>>>> + /*
> >>>>> + * According to VersaClock 6E Programming Guide, there are 6
> >>>>> + * bits which translate to 64 entries in XTAL registers 12 and
> >>>>> + * 13. Because bits 0 and 1 increase the capacitance the
> >>>>> + * same, some of the values can be repeated. Plugging this
> >>>>> + * into a spreadsheet and generating a trendline, the output
> >>>>> + * equation becomes x = (y-9098.29) / 216.44, where 'y' is
> >>>>> + * the desired capacitance in femtofarads, and x is the value
> >>>>> + * of XTAL[5:0].
> >>>>> + * To help with rounding, do fixed point math
> >>>>> + */
> >>>>> + femtofarads *= 100;
> >>>>> + mapped_value = (femtofarads - 909829) / 21644;
> >>>>
> >>>> Thanks for the extensive comment, but I am confused. Not by your code
> >>>> which is very clean and readable, but by the chip documentation
> >>>> (disclaimer: I haven't read it in full depth).
> >>>
> >>> I was confused too since the datasheet and programmers manual differ a
> >>> bit.
> >>>>
> >>>> The 5P49V6965 datasheet at page 17 clearly states capacitance can be
> >>>> increased in 0.5 pF steps. The "VersaClock 6E Family Register
> >>>> Descriptions and Programming Guide" at page 18 shows a table that allows
> >>>> 0.43 pF. Can you clarify how the thing works?
> >>>
> >>> I used the Versaclock 6E doc which is based on the following:
> >>>
> >>> BIT 5 - Add 6.92pF
> >>> BIT 4 - Add 3.46pF
> >>> BIT 3 - Add 1.73pF
> >>> BIT 2 - Add 0.86pF
> >>> Bit 1 - Add 0.43pF
> >>> Bit 0 - Add 0.43pF
> >>>
> >>> Because the Datasheet starts at 9pF, the math I used, assumes these
> >>> numbers are added to 9pF.
> >>> Because the datasheet shows the increments are in .5pF increments, the
> >>> 430nF seems close. The datasheet shows 9pF - 25pF and based on the
> >>> programmer table, we could get close to 25pF by enabling all bits and
> >>> adding 9pF, however the math doesn't quite hit 25pF.
> >>>
> >>> For what it's worth I needed around 11.5pF, and with this patch, the
> >>> hardware engineer said our ppm went from around 70 ppm to around 4ppm.
> >>
> >> Did he me
[PATCH] arm64: defconfig: Enable CLK_RCAR_USB2_CLOCK_SEL
The RZ/G2 Series has the optional CLK_RCAR_USB2_CLOCK_SEL. Enable it by default. It's disabled by default in the the device tree, so it should be safe to enable it here. Signed-off-by: Adam Ford diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 838301650a79..84fcfa7a1865 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -932,6 +932,7 @@ CONFIG_SM_GCC_8250=y CONFIG_SM_GPUCC_8150=y CONFIG_SM_GPUCC_8250=y CONFIG_QCOM_HFPLL=y +CONFIG_CLK_RCAR_USB2_CLOCK_SEL=y CONFIG_HWSPINLOCK=y CONFIG_HWSPINLOCK_QCOM=y CONFIG_ARM_MHU=y -- 2.25.1
Re: [RFC 2/2] clk: vc5: Add support for optional load capacitance
On Sat, Jan 9, 2021 at 12:02 PM Luca Ceresoli wrote:
>
> Hi Adam,
>
> On 09/01/21 04:00, Adam Ford wrote:
> > On Fri, Jan 8, 2021 at 4:49 PM Luca Ceresoli wrote:
> >>
> >> Hi Adam,
> >>
> >> On 06/01/21 18:39, Adam Ford wrote:
> >>> There are two registers which can set the load capacitance for
> >>> XTAL1 and XTAL2. These are optional registers when using an
> >>> external crystal. Parse the device tree and set the
> >>> corresponding registers accordingly.
> >>
> >> No need to repeat the first 2 sentences, they are already in patch 1.
> >
> > The reason I did that was because if someone does a git log on the
> > individual file, they'd see the comment. While it's redundant not, it
> > might not be as obvious in the future when looking back. Not
> > everyone reviews the history of the binding, but the source files' git
> > logs usually have some value. However, if you want me to drop it or
> > rephrase it, I can do that.
>
> Makes sense, I had never considered that before.
>
> >>> +static int vc5_map_cap_value(u32 femtofarads)
> >>> +{
> >>> + int mapped_value;
> >>> +
> >>> + /* The datasheet explicitly states 9000 - 25000 */
> >>> + if ((femtofarads < 9000) || (femtofarads > 25000))
> >>> + return -EINVAL;
> >>> +
> >>> + /* The lowest target we can hit is 9430, so exit if it's less */
> >>> + if (femtofarads < 9430)
> >>> + return 0;
> >>> +
> >>> + /*
> >>> + * According to VersaClock 6E Programming Guide, there are 6
> >>> + * bits which translate to 64 entries in XTAL registers 12 and
> >>> + * 13. Because bits 0 and 1 increase the capacitance the
> >>> + * same, some of the values can be repeated. Plugging this
> >>> + * into a spreadsheet and generating a trendline, the output
> >>> + * equation becomes x = (y-9098.29) / 216.44, where 'y' is
> >>> + * the desired capacitance in femtofarads, and x is the value
> >>> + * of XTAL[5:0].
> >>> + * To help with rounding, do fixed point math
> >>> + */
> >>> + femtofarads *= 100;
> >>> + mapped_value = (femtofarads - 909829) / 21644;
> >>
> >> Thanks for the extensive comment, but I am confused. Not by your code
> >> which is very clean and readable, but by the chip documentation
> >> (disclaimer: I haven't read it in full depth).
> >
> > I was confused too since the datasheet and programmers manual differ a bit.
> >>
> >> The 5P49V6965 datasheet at page 17 clearly states capacitance can be
> >> increased in 0.5 pF steps. The "VersaClock 6E Family Register
> >> Descriptions and Programming Guide" at page 18 shows a table that allows
> >> 0.43 pF. Can you clarify how the thing works?
> >
> > I used the Versaclock 6E doc which is based on the following:
> >
> > BIT 5 - Add 6.92pF
> > BIT 4 - Add 3.46pF
> > BIT 3 - Add 1.73pF
> > BIT 2 - Add 0.86pF
> > Bit 1 - Add 0.43pF
> > Bit 0 - Add 0.43pF
> >
> > Because the Datasheet starts at 9pF, the math I used, assumes these
> > numbers are added to 9pF.
> > Because the datasheet shows the increments are in .5pF increments, the
> > 430nF seems close. The datasheet shows 9pF - 25pF and based on the
> > programmer table, we could get close to 25pF by enabling all bits and
> > adding 9pF, however the math doesn't quite hit 25pF.
> >
> > For what it's worth I needed around 11.5pF, and with this patch, the
> > hardware engineer said our ppm went from around 70 ppm to around 4ppm.
>
> Did he measure what happens if you set the register according to the 0.5
> pF interpretation? Does it improve? I understand the difference is
> probably olwer than the noise, but who knows.
>
> >>> +
> >>> + /*
> >>> + * The datasheet states, the maximum capacitance is 25000,
> >>> + * but the programmer guide shows a max value is 22832,
> >>> + * so values higher values could overflow, so cap it.
> >>> + */
> >>
> >> The 22832 limit is if you assume 0.43 pF steps. Assuming 0.5 pF steps
> >> leads to 25000. Now I am more confused than before.
> >
> > I agree. It would be nice to get some clarification from Renesas.
>
> Definitely. Do you have access to some support from them?
Luca,
We
Re: [PATCH 1/2] clk: imx: enable the earlycon uart clocks by parsing from dt
On Mon, Jan 4, 2021 at 1:12 AM Sascha Hauer wrote:
>
> Hi Adam,
>
> On Tue, Dec 29, 2020 at 08:51:28AM -0600, Adam Ford wrote:
> > Remove the earlycon uart clocks that are hard cord in platforms
> > clock driver, instead of parsing the earlycon uart port from dt
>
> "instead parse the earlycon uart..."
>
> Otherwise it's confusing what you mean here.
>
> > and enable these clocks from clock property in dt node.
> >
> > Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate
> > protection")
> > Signed-off-by: Fugang Duan
> > Signed-off-by: Adam Ford
> > ---
> > Based on NXP's code base and adapted for 5.11-rc1.
> > https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/clk/imx/clk.c?h=imx_5.4.47_2.2.0=754ae82cc55b7445545fc2f092a70e0f490e9c1b
> >
> > The original signed-off was retained.
> > Added the fixes tag.
> > ---
> > drivers/clk/imx/clk.c | 43 +--
> > 1 file changed, 29 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
> > index 47882c51cb85..c32b46890945 100644
> > --- a/drivers/clk/imx/clk.c
> > +++ b/drivers/clk/imx/clk.c
> > @@ -148,7 +148,7 @@ void imx_cscmr1_fixup(u32 *val)
> >
> > #ifndef MODULE
> > static int imx_keep_uart_clocks;
> > -static struct clk ** const *imx_uart_clocks;
> > +static bool imx_uart_clks_on;
> >
> > static int __init imx_keep_uart_clocks_param(char *str)
> > {
> > @@ -161,25 +161,40 @@ __setup_param("earlycon", imx_keep_uart_earlycon,
> > __setup_param("earlyprintk", imx_keep_uart_earlyprintk,
> > imx_keep_uart_clocks_param, 0);
> >
> > -void imx_register_uart_clocks(struct clk ** const clks[])
> > +static void imx_earlycon_uart_clks_onoff(bool is_on)
>
> "is_on" sounds like it's the current state of the clock, but actually
> the variable is used for the desired state, so I suggest using plain
> "on" as name.
Sascha,
I think I'll try to keep the existing structure of imx/clk.c in place
so this function won't be needed. It was part of NXP's custom kernel,
but I have a different idea that I'll explain below.
>
> > {
> > - if (imx_keep_uart_clocks) {
> > - int i;
> > + struct clk *uart_clk;
> > + int i = 0;
> >
> > - imx_uart_clocks = clks;
> > - for (i = 0; imx_uart_clocks[i]; i++)
> > - clk_prepare_enable(*imx_uart_clocks[i]);
> > - }
> > + if (!imx_keep_uart_clocks || (!is_on && !imx_uart_clks_on))
> > + return;
> > +
> > + /* only support dt */
> > + if (!of_stdout)
> > + return;
> > +
> > + do {
> > + uart_clk = of_clk_get(of_stdout, i++);
>
> of_clk_get() allocates memory and gets you a reference to the clock. You
> have to release the clock with clk_put(). I think what you have to do
> here is to fill an array with clks when called from
> imx_register_uart_clocks() and when called from imx_clk_disable_uart()
> use that array to clk_disable_unprepare()/clk_put() the clocks.
I have another revision pending which modifies
imx_register_uart_clocks() to receive the number of available UART
clocks from the calling SoC. It will then allocate an array of clock
structures equal to that size. Instead of enabling all UART clocks,
it will then go through of_clk_get(of_stdout, ...) to fill the array
and keep track of the number of devices it's assigned to the array.
Most likely the array will be larger than the number of of_stdout
entries.
Because it keeps track of the number of enabled UART's, it will use
that to go through the array and only try to unprepare/disable and put
that many clocks. Once all the clocks have been disabled and put, the
entire clock array will be freed.
It will be more closely related to how the current imx/clk.c file is
now instead of using NXP's custom kernel, but it will also allow me to
remove the static arrays setting up the UART clocks for each SoC.
Does that sound OK to you?
I need to run some tests on my i.MX6Q board before I submit it, but
tests on my i.MX8MM are looking promising. I can re-parent the UART
that I need reparented, and it fails if I try to reparent when that
UART is assigned to stdout.
adam
>
> Sascha
>
> > + if (IS_ERR(uart_clk))
> > + break;
> > +
> > + if (is_on)
> > + clk_prepare_enable(uart_clk);
> > + else
> > + clk_disable_un
[PATCH] arm64: dts: imx8mn-beacon-som: Configure RTC aliases
On the i.MX8MN Beacon SOM, there is an RTC chip which is fed power
from the baseboard during power off. The SNVS RTC integrated into
the SoC is not fed power. Depending on the order the modules are
loaded, this can be a problem if the external RTC isn't rtc0.
Make the alias for rtc0 point to the external RTC all the time and
rtc1 point to the SVNS in order to correctly hold date/time over
a power-cycle.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
index 67e5e5b9ddea..2120e6485393 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
@@ -4,6 +4,11 @@
*/
/ {
+ aliases {
+ rtc0 =
+ rtc1 = _rtc;
+ };
+
usdhc1_pwrseq: usdhc1_pwrseq {
compatible = "mmc-pwrseq-simple";
pinctrl-names = "default";
@@ -212,7 +217,7 @@ eeprom@50 {
reg = <0x50>;
};
- rtc@51 {
+ rtc: rtc@51 {
compatible = "nxp,pcf85263";
reg = <0x51>;
};
--
2.25.1
[PATCH] arm64: dts: imx8mm-beacon: add more pinctrl states for usdhc1
The WiFi chip is capable of communication at SDR104 speeds.
Enable 100Mhz and 200MHz pinmux to support this.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
index d897913537ca..988f8ab679ad 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
@@ -256,8 +256,10 @@ bluetooth {
{
#address-cells = <1>;
#size-cells = <0>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc1>;
+ pinctrl-1 = <_usdhc1_100mhz>;
+ pinctrl-2 = <_usdhc1_200mhz>;
bus-width = <4>;
non-removable;
cap-power-off-card;
--
2.25.1
Re: [PATCH] ARM: dts: omap36xx: Remove turbo mode for 1GHz variants
On Sat, Jan 9, 2021 at 10:58 AM H. Nikolaus Schaller wrote:
>
> Hi Adam,
>
> > Am 09.01.2021 um 17:39 schrieb Adam Ford :
> >
> > Previously, the 1GHz variants were marked as a turbo,
> > because that variant has reduced thermal operating range.
> >
> > Now that the thermal throttling is in place, it should be
> > safe to remove the turbo-mode from the 1GHz variants, because
> > the CPU will automatically slow if the thermal limit is reached.
>
> Subject and description may be misunderstood in a way that 1GHz
> is now disabled.
>
> Rather the 1GHz OPP is now permanently enabled and does no longer
> need to be manuall enabled through something like
> /sys/devices/system/cpu/cpufreq/boost.
I just sent a V2, before I saw this. I can send a V3 with your
feedback. I just want to give Tony and/or others a chance to chime
in.
>
> >
> > Signed-off-by: Adam Ford
> >
> > diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> > b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> > index 3a5228562b0d..3451f9be104e 100644
> > --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> > +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> > @@ -70,6 +70,7 @@ nand@0,0 {
> > gpmc,device-width = <2>;
> > #address-cells = <1>;
> > #size-cells = <1>;
> > + status = "disabled";
>
> this does not seem to match the description?
I just sent an apology e-mail because I realized I grabbed the wrong file.
>
> > };
> > };
> >
> > --
> > 2.25.1
> >
>
> BR,
> Nikolaus
>
[PATCH V2] ARM: dts: omap36xx: Remove turbo mode for 1GHz variants
Previously, the 1GHz variants were marked as a turbo,
because that variant has reduced thermal operating range.
Now that the thermal throttling is in place, it should be
safe to remove the turbo-mode from the 1GHz variants, because
the CPU will automatically slow if the thermal limit is reached.
Signed-off-by: Adam Ford
---
V2: The orignal patch had the wrong file added. Add the omap36xx.dtsi
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 05fe5ed127b0..20844dbc002e 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -72,7 +72,6 @@ opp1g-10 {
<1375000 1375000 1375000>;
/* only on am/dm37x with speed-binned bit set */
opp-supported-hw = <0x 2>;
- turbo-mode;
};
};
--
2.25.1
Re: [PATCH] ARM: dts: omap36xx: Remove turbo mode for 1GHz variants
On Sat, Jan 9, 2021 at 10:39 AM Adam Ford wrote:
>
> Previously, the 1GHz variants were marked as a turbo,
> because that variant has reduced thermal operating range.
>
> Now that the thermal throttling is in place, it should be
> safe to remove the turbo-mode from the 1GHz variants, because
> the CPU will automatically slow if the thermal limit is reached.
>
> Signed-off-by: Adam Ford
>
Sorry for the noise. grabbed the wrong thing.
Please disregard.
> diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> index 3a5228562b0d..3451f9be104e 100644
> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> @@ -70,6 +70,7 @@ nand@0,0 {
> gpmc,device-width = <2>;
> #address-cells = <1>;
> #size-cells = <1>;
> + status = "disabled";
> };
> };
>
> --
> 2.25.1
>
[PATCH] ARM: dts: omap36xx: Remove turbo mode for 1GHz variants
Previously, the 1GHz variants were marked as a turbo,
because that variant has reduced thermal operating range.
Now that the thermal throttling is in place, it should be
safe to remove the turbo-mode from the 1GHz variants, because
the CPU will automatically slow if the thermal limit is reached.
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 3a5228562b0d..3451f9be104e 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -70,6 +70,7 @@ nand@0,0 {
gpmc,device-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
+ status = "disabled";
};
};
--
2.25.1
Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
On Fri, Jan 8, 2021 at 1:37 PM Andreas Kemnade wrote:
>
> Hi,
>
> On Fri, 8 Jan 2021 13:17:06 -0600
> Adam Ford wrote:
>
> > On Mon, Dec 7, 2020 at 8:01 AM Tony Lindgren wrote:
> > >
> > > * Doug Anderson [201204 16:43]:
> > > > Hi,
> > > >
> > > > On Fri, Dec 4, 2020 at 8:14 AM Andreas Kemnade
> > > > wrote:
> > > > >
> > > > > > > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for
> > > > > > > drivers that existed in v4.4")
> > > > > >
> > > > > > From the description it sounds like this problem has always existed
> > > > > > but the async probe just tickled it reliably. Seems like it'd make
> > > > > > sense to tag the "Fixes" as some earlier commit so you make sure
> > > > > > your
> > > > > > fix gets picked to kernels even if they don't have the async probe
> > > > > > patch?
> > > > > >
> > > > >
> > > > > Hmm, maybe
> > > > > Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and
> > > > > pm_runtime after probe defer")
> > > > >
> > > > > But on the other hand to stable branches only such patches are applied
> > > > > which solve pratical problems not only theoretical problems. But maybe
> > > > > it solves several random issues where nobody took care to debug them.
> > > > >
> > > > > That would be since v4.11.
> > > >
> > > > I guess maybe best is to include both. Then if someone is debugging
> > > > why their async probe is failing they will notice this commit, but
> > > > they also might decide to pick it earlier just to be safe...
> > >
> > > OK I'll add the above fixes tag too and apply this into fixes.
> > >
> >
> > It might be too late, but...
> >
> > Tested-by: Adam Ford #logicpd-torpedo-37xx-devkit
> >
> hmm, when will it arrive in mainline?
It looks like it's been merged onto Linus Torvalds' branch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95f05058b2bbe3b85c8617b961879e52f692caa5
>
> Regards,
> Andreas
Re: [RFC 2/2] clk: vc5: Add support for optional load capacitance
On Fri, Jan 8, 2021 at 4:49 PM Luca Ceresoli wrote:
>
> Hi Adam,
>
> On 06/01/21 18:39, Adam Ford wrote:
> > There are two registers which can set the load capacitance for
> > XTAL1 and XTAL2. These are optional registers when using an
> > external crystal. Parse the device tree and set the
> > corresponding registers accordingly.
>
> No need to repeat the first 2 sentences, they are already in patch 1.
The reason I did that was because if someone does a git log on the
individual file, they'd see the comment. While it's redundant not, it
might not be as obvious in the future when looking back. Not
everyone reviews the history of the binding, but the source files' git
logs usually have some value. However, if you want me to drop it or
rephrase it, I can do that.
>
> >
> > Signed-off-by: Adam Ford
> > ---
> > drivers/clk/clk-versaclock5.c | 64 +++
> > 1 file changed, 64 insertions(+)
> >
> > diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
> > index 43db67337bc0..445abc3731fb 100644
> > --- a/drivers/clk/clk-versaclock5.c
> > +++ b/drivers/clk/clk-versaclock5.c
> > @@ -759,6 +759,63 @@ static int vc5_update_power(struct device_node
> > *np_output,
> > return 0;
> > }
> >
> > +static int vc5_map_cap_value(u32 femtofarads)
> > +{
> > + int mapped_value;
> > +
> > + /* The datasheet explicitly states 9000 - 25000 */
> > + if ((femtofarads < 9000) || (femtofarads > 25000))
> > + return -EINVAL;
> > +
> > + /* The lowest target we can hit is 9430, so exit if it's less */
> > + if (femtofarads < 9430)
> > + return 0;
> > +
> > + /*
> > + * According to VersaClock 6E Programming Guide, there are 6
> > + * bits which translate to 64 entries in XTAL registers 12 and
> > + * 13. Because bits 0 and 1 increase the capacitance the
> > + * same, some of the values can be repeated. Plugging this
> > + * into a spreadsheet and generating a trendline, the output
> > + * equation becomes x = (y-9098.29) / 216.44, where 'y' is
> > + * the desired capacitance in femtofarads, and x is the value
> > + * of XTAL[5:0].
> > + * To help with rounding, do fixed point math
> > + */
> > + femtofarads *= 100;
> > + mapped_value = (femtofarads - 909829) / 21644;
>
> Thanks for the extensive comment, but I am confused. Not by your code
> which is very clean and readable, but by the chip documentation
> (disclaimer: I haven't read it in full depth).
I was confused too since the datasheet and programmers manual differ a bit.
>
> The 5P49V6965 datasheet at page 17 clearly states capacitance can be
> increased in 0.5 pF steps. The "VersaClock 6E Family Register
> Descriptions and Programming Guide" at page 18 shows a table that allows
> 0.43 pF. Can you clarify how the thing works?
I used the Versaclock 6E doc which is based on the following:
BIT 5 - Add 6.92pF
BIT 4 - Add 3.46pF
BIT 3 - Add 1.73pF
BIT 2 - Add 0.86pF
Bit 1 - Add 0.43pF
Bit 0 - Add 0.43pF
Because the Datasheet starts at 9pF, the math I used, assumes these
numbers are added to 9pF.
Because the datasheet shows the increments are in .5pF increments, the
430nF seems close. The datasheet shows 9pF - 25pF and based on the
programmer table, we could get close to 25pF by enabling all bits and
adding 9pF, however the math doesn't quite hit 25pF.
For what it's worth I needed around 11.5pF, and with this patch, the
hardware engineer said our ppm went from around 70 ppm to around 4ppm.
>
> > +
> > + /*
> > + * The datasheet states, the maximum capacitance is 25000,
> > + * but the programmer guide shows a max value is 22832,
> > + * so values higher values could overflow, so cap it.
> > + */
>
> The 22832 limit is if you assume 0.43 pF steps. Assuming 0.5 pF steps
> leads to 25000. Now I am more confused than before.
I agree. It would be nice to get some clarification from Renesas.
>
> > + mapped_value = max(mapped_value/100, 0x3f);
>
> Uhm, min()?
Oops! You're absolutely right.
>
> > +
> > + return mapped_value;
> > +}
> > +static int vc5_update_cap_load(struct device_node *node, struct
> > vc5_driver_data *vc5)
> > +{
> > + u32 value, mapped_value;
> > +
> > + if (!of_property_read_u32(node, "idt,xtal1-load-femtofarads",
> > )) {
> > + mapped_value = vc5_map_cap_value(value);
> > + if (mapped_value < 0)
> > + return
Re: [RFC 1/2] dt-bindings: clk: versaclock5: Add load capacitance properties
On Fri, Jan 8, 2021 at 4:49 PM Luca Ceresoli wrote: > > Hi Adam, > > On 06/01/21 18:38, Adam Ford wrote: > > There are two registers which can set the load capacitance for > > XTAL1 and XTAL2. These are optional registers when using an > > external crystal. Update the bindings to support them. > > > > Signed-off-by: Adam Ford > > --- > > .../devicetree/bindings/clock/idt,versaclock5.yaml | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > index 2ac1131fd922..e5e55ffb266e 100644 > > --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml > > @@ -59,6 +59,18 @@ properties: > > minItems: 1 > > maxItems: 2 > > > > + idt,xtal1-load-femtofarads: > > I wonder whether we should have a common, vendor independent property. That would be nice. > In mainline we have xtal-load-pf (ti,cdce925.txt bindings) which has no > vendor prefix. However I don't know how much common it is to need rtc-pcf85063.c uses quartz-load-femtofarads, so there is already some discrepancy. Since the unit of measure here is femtofarads, using pF in the name seems wrong. We need to read the data as a u32, so femtofarads works better than pF, which would require a decimal point. > different loads for x1 and x2. Any hardware engineer around? I talked to a hardware engineer where I work, and he said it makes sense to keep them the same. I only separated them because there are two registers, and I assumed there might be a reason to have X1 and X2 be different, but I'm ok with reading one value and writing it to two different registers. adam > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +minimum: 9000 > > +maximum: 25000 > > +description: Optional loading capacitor for XTAL1 > > Nit: I think the common wording is "load capacitor", not "loading > capacitor". > > -- > Luca
Re: [PATCH 1/3] thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430
On Fri, Jan 8, 2021 at 12:31 PM Adam Ford wrote: > > On Fri, Jan 8, 2021 at 7:45 AM Adam Ford wrote: > > > > On Fri, Jan 8, 2021 at 1:22 AM Tony Lindgren wrote: > > > > > > * H. Nikolaus Schaller [201230 13:29]: > > > > > Am 30.12.2020 um 13:55 schrieb Adam Ford : > > > > > On Wed, Dec 30, 2020 at 2:43 AM Tony Lindgren > > > > > wrote: > > > > >> > > > > >> At least for 4430, trying to use the single conversion mode > > > > >> eventually > > > > >> hangs the thermal sensor. This can be quite easily seen with errors: > > > > >> > > > > >> thermal thermal_zone0: failed to read out thermal zone (-5) > > > ... > > > > > > > > I don't have an OMAP4, but if you want, I can test a DM3730. > > > > > > > > Indeed I remember a similar discussion from the DM3730 [1]. temp values > > > > were > > > > always those from the last measurement. E.g. the first one was done > > > > during (cold) boot and the first request after 10 minutes did show a > > > > quite cold system... The next one did show a hot system independent > > > > of what had been between (suspend or high activity). > > > > > > > > It seems as if it was even reproducible with a very old kernel on a > > > > BeagleBoard. > > > > So it is quite fundamental. > > > > > > > > We tried to fix it but did not come to a solution [2]. So we opened an > > > > issue > > > > in our tracker [3] and decided to stay with continuous conversion > > > > although this > > > > raises idle mode processor load. > > > > > > Hmm so maybe eocz high always times out in single mode since it also > > > triggers at least on dra7? > > > > > > Yes it would be great if you guys can the $subject patch a try at > > > least on your omap36xx and omap5 boards and see if you see eocz > > > time out warnings in dmesg. I do see chatter. [ 15.531005] ti-soc-thermal 48002524.bandgap: eocz timed out waiting low [ 16.571075] ti-soc-thermal 48002524.bandgap: eocz timed out waiting low [ 17.610961] ti-soc-thermal 48002524.bandgap: eocz timed out waiting low and it repeats quite often. I would say this patch series would cause a regression on the DM3730. adam > > > > I should be able to try it on the dm3730 logicpd-torpedo kit this weekend. > > I am going to be a bit delayed testing this. I cannot boot omap2plus > using Linux version 5.11.0-rc2. > > [2.666748] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc > [2.673309] nand: Micron MT29F4G16ABBDA3W > [2.677368] nand: 512 MiB, SLC, erase size: 128 KiB, page size: > 2048, OOB size: 64 > [2.685119] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW > [2.693237] Invalid ECC layout > [2.696350] omap2-nand 3000.nand: unable to use BCH library > [2.702575] omap2-nand: probe of 3000.nand failed with error -22 > [2.716094] 8<--- cut here --- > [2.719207] Unable to handle kernel NULL pointer dereference at > virtual address 0018 > [2.727600] pgd = (ptrval) > ... > [3.050933] ---[ end trace 59640c7399a80a07 ]--- > [3.055603] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x000b > [3.063323] ---[ end Kernel panic - not syncing: Attempted to kill > init! exitcode=0x000b ]--- > > Once I get past this, I'll try to test the thermal stuff. > > adam > > > > > adam > > > > > > Regards, > > > > > > Tony
Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
On Mon, Dec 7, 2020 at 8:01 AM Tony Lindgren wrote:
>
> * Doug Anderson [201204 16:43]:
> > Hi,
> >
> > On Fri, Dec 4, 2020 at 8:14 AM Andreas Kemnade wrote:
> > >
> > > > > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers
> > > > > that existed in v4.4")
> > > >
> > > > From the description it sounds like this problem has always existed
> > > > but the async probe just tickled it reliably. Seems like it'd make
> > > > sense to tag the "Fixes" as some earlier commit so you make sure your
> > > > fix gets picked to kernels even if they don't have the async probe
> > > > patch?
> > > >
> > >
> > > Hmm, maybe
> > > Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and
> > > pm_runtime after probe defer")
> > >
> > > But on the other hand to stable branches only such patches are applied
> > > which solve pratical problems not only theoretical problems. But maybe
> > > it solves several random issues where nobody took care to debug them.
> > >
> > > That would be since v4.11.
> >
> > I guess maybe best is to include both. Then if someone is debugging
> > why their async probe is failing they will notice this commit, but
> > they also might decide to pick it earlier just to be safe...
>
> OK I'll add the above fixes tag too and apply this into fixes.
>
It might be too late, but...
Tested-by: Adam Ford #logicpd-torpedo-37xx-devkit
> Thanks,
>
> Tony
Re: [PATCH 1/3] thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430
On Fri, Jan 8, 2021 at 7:45 AM Adam Ford wrote: > > On Fri, Jan 8, 2021 at 1:22 AM Tony Lindgren wrote: > > > > * H. Nikolaus Schaller [201230 13:29]: > > > > Am 30.12.2020 um 13:55 schrieb Adam Ford : > > > > On Wed, Dec 30, 2020 at 2:43 AM Tony Lindgren wrote: > > > >> > > > >> At least for 4430, trying to use the single conversion mode eventually > > > >> hangs the thermal sensor. This can be quite easily seen with errors: > > > >> > > > >> thermal thermal_zone0: failed to read out thermal zone (-5) > > ... > > > > > > I don't have an OMAP4, but if you want, I can test a DM3730. > > > > > > Indeed I remember a similar discussion from the DM3730 [1]. temp values > > > were > > > always those from the last measurement. E.g. the first one was done > > > during (cold) boot and the first request after 10 minutes did show a > > > quite cold system... The next one did show a hot system independent > > > of what had been between (suspend or high activity). > > > > > > It seems as if it was even reproducible with a very old kernel on a > > > BeagleBoard. > > > So it is quite fundamental. > > > > > > We tried to fix it but did not come to a solution [2]. So we opened an > > > issue > > > in our tracker [3] and decided to stay with continuous conversion > > > although this > > > raises idle mode processor load. > > > > Hmm so maybe eocz high always times out in single mode since it also > > triggers at least on dra7? > > > > Yes it would be great if you guys can the $subject patch a try at > > least on your omap36xx and omap5 boards and see if you see eocz > > time out warnings in dmesg. > > I should be able to try it on the dm3730 logicpd-torpedo kit this weekend. I am going to be a bit delayed testing this. I cannot boot omap2plus using Linux version 5.11.0-rc2. [2.666748] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc [2.673309] nand: Micron MT29F4G16ABBDA3W [2.677368] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [2.685119] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW [2.693237] Invalid ECC layout [2.696350] omap2-nand 3000.nand: unable to use BCH library [2.702575] omap2-nand: probe of 3000.nand failed with error -22 [2.716094] 8<--- cut here --- [2.719207] Unable to handle kernel NULL pointer dereference at virtual address 0018 [2.727600] pgd = (ptrval) ... [3.050933] ---[ end trace 59640c7399a80a07 ]--- [3.055603] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [3.063323] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b ]--- Once I get past this, I'll try to test the thermal stuff. adam > > adam > > > > Regards, > > > > Tony
Re: [PATCH 1/3] thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430
On Fri, Jan 8, 2021 at 1:22 AM Tony Lindgren wrote: > > * H. Nikolaus Schaller [201230 13:29]: > > > Am 30.12.2020 um 13:55 schrieb Adam Ford : > > > On Wed, Dec 30, 2020 at 2:43 AM Tony Lindgren wrote: > > >> > > >> At least for 4430, trying to use the single conversion mode eventually > > >> hangs the thermal sensor. This can be quite easily seen with errors: > > >> > > >> thermal thermal_zone0: failed to read out thermal zone (-5) > ... > > > > I don't have an OMAP4, but if you want, I can test a DM3730. > > > > Indeed I remember a similar discussion from the DM3730 [1]. temp values were > > always those from the last measurement. E.g. the first one was done > > during (cold) boot and the first request after 10 minutes did show a > > quite cold system... The next one did show a hot system independent > > of what had been between (suspend or high activity). > > > > It seems as if it was even reproducible with a very old kernel on a > > BeagleBoard. > > So it is quite fundamental. > > > > We tried to fix it but did not come to a solution [2]. So we opened an issue > > in our tracker [3] and decided to stay with continuous conversion although > > this > > raises idle mode processor load. > > Hmm so maybe eocz high always times out in single mode since it also > triggers at least on dra7? > > Yes it would be great if you guys can the $subject patch a try at > least on your omap36xx and omap5 boards and see if you see eocz > time out warnings in dmesg. I should be able to try it on the dm3730 logicpd-torpedo kit this weekend. adam > > Regards, > > Tony
[RFC 1/2] dt-bindings: clk: versaclock5: Add load capacitance properties
There are two registers which can set the load capacitance for XTAL1 and XTAL2. These are optional registers when using an external crystal. Update the bindings to support them. Signed-off-by: Adam Ford --- .../devicetree/bindings/clock/idt,versaclock5.yaml | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index 2ac1131fd922..e5e55ffb266e 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -59,6 +59,18 @@ properties: minItems: 1 maxItems: 2 + idt,xtal1-load-femtofarads: +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 9000 +maximum: 25000 +description: Optional loading capacitor for XTAL1 + + idt,xtal2-load-femtofarads: +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 9000 +maximum: 25000 +description: Optional loading capacitor for XTAL2 + patternProperties: "^OUT[1-4]$": type: object -- 2.25.1
[RFC 2/2] clk: vc5: Add support for optional load capacitance
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal. Parse the device tree and set the
corresponding registers accordingly.
Signed-off-by: Adam Ford
---
drivers/clk/clk-versaclock5.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 43db67337bc0..445abc3731fb 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -759,6 +759,63 @@ static int vc5_update_power(struct device_node *np_output,
return 0;
}
+static int vc5_map_cap_value(u32 femtofarads)
+{
+ int mapped_value;
+
+ /* The datasheet explicitly states 9000 - 25000 */
+ if ((femtofarads < 9000) || (femtofarads > 25000))
+ return -EINVAL;
+
+ /* The lowest target we can hit is 9430, so exit if it's less */
+ if (femtofarads < 9430)
+ return 0;
+
+ /*
+* According to VersaClock 6E Programming Guide, there are 6
+* bits which translate to 64 entries in XTAL registers 12 and
+* 13. Because bits 0 and 1 increase the capacitance the
+* same, some of the values can be repeated. Plugging this
+* into a spreadsheet and generating a trendline, the output
+* equation becomes x = (y-9098.29) / 216.44, where 'y' is
+* the desired capacitance in femtofarads, and x is the value
+* of XTAL[5:0].
+* To help with rounding, do fixed point math
+*/
+ femtofarads *= 100;
+ mapped_value = (femtofarads - 909829) / 21644;
+
+ /*
+* The datasheet states, the maximum capacitance is 25000,
+* but the programmer guide shows a max value is 22832,
+* so values higher values could overflow, so cap it.
+*/
+ mapped_value = max(mapped_value/100, 0x3f);
+
+ return mapped_value;
+}
+static int vc5_update_cap_load(struct device_node *node, struct
vc5_driver_data *vc5)
+{
+ u32 value, mapped_value;
+
+ if (!of_property_read_u32(node, "idt,xtal1-load-femtofarads", )) {
+ mapped_value = vc5_map_cap_value(value);
+ if (mapped_value < 0)
+ return mapped_value;
+
+ regmap_write(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, (mapped_value
<< 2));
+ }
+
+ if (!of_property_read_u32(node, "idt,xtal2-load-femtofarads", )) {
+ mapped_value = vc5_map_cap_value(value);
+ if (mapped_value < 0)
+ return mapped_value;
+ regmap_write(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, (mapped_value
<< 2));
+ }
+
+ return 0;
+}
+
static int vc5_update_slew(struct device_node *np_output,
struct vc5_out_data *clk_out)
{
@@ -884,6 +941,13 @@ static int vc5_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return -EINVAL;
}
+ /* Configure Optional Loading Capacitance for external XTAL */
+ if (!(vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)) {
+ ret = vc5_update_cap_load(client->dev.of_node, vc5);
+ if (ret)
+ goto err_clk_register;
+ }
+
init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node);
init.ops = _mux_ops;
init.flags = 0;
--
2.25.1
Re: [PATCH 4/4] net: ethernet: ravb: Name the AVB functional clock fck
On Mon, Jan 4, 2021 at 4:41 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> > The bindings have been updated to support two clocks, but the
> > original clock now requires the name fck to distinguish it
> > from the other.
> >
> > Signed-off-by: Adam Ford
>
> Thanks for your patch!
>
> > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > @@ -2142,7 +2142,7 @@ static int ravb_probe(struct platform_device *pdev)
> >
> > priv->chip_id = chip_id;
> >
> > - priv->clk = devm_clk_get(>dev, NULL);
> > + priv->clk = devm_clk_get(>dev, "fck");
>
> This change is not backwards compatible, as existing DTB files do not
> have the "fck" clock. So the driver has to keep on assuming the first
> clock is the functional clock, and this patch is thus not needed nor
> desired.
Should I post a V2 with this removed, or can this patch just be excluded?
adam
>
> > if (IS_ERR(priv->clk)) {
> > error = PTR_ERR(priv->clk);
> > goto out_release;
>
> 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: imx8mm-beacon: Fix WiFi Pinmuxing
On Mon, Jan 4, 2021 at 9:03 PM Shawn Guo wrote:
>
> On Wed, Dec 02, 2020 at 07:59:50AM -0600, Adam Ford wrote:
> > The WiFi chip is capable of communication at SDR104 speeds, and
> > the pinmux was configured to support this, but the sdhc1 controller
> > didn't properly reference the pinmux. Enable 100Mhz and 200MHz pinmux
> > as was originally intended.
> >
> > Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development
> > kit")
>
> This looks more like an improvement than bug fix.
Do you want me to resubmit without the fixes tag?
adam
>
> Shawn
>
> > Signed-off-by: Adam Ford
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
> > index 6de86a4f0ec4..90fd15e95798 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
> > @@ -217,8 +217,10 @@
> > {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > - pinctrl-names = "default";
> > + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > pinctrl-0 = <_usdhc1>;
> > + pinctrl-1 = <_usdhc1_100mhz>;
> > + pinctrl-2 = <_usdhc1_200mhz>;
> > bus-width = <4>;
> > non-removable;
> > cap-power-off-card;
> > --
> > 2.17.1
> >
[PATCH V2 4/4] arm64: dts: renesas: rzg2: Add RPC-IF Support
The RZ/G2 series contain the SPI Multi I/O Bus Controller (RPC-IF).
Add the nodes, but make them disabled by default.
Signed-off-by: Adam Ford
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 17 +
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 17 +
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 17 +
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 17 +
4 files changed, 68 insertions(+)
V2: No Change
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d37ec42a1caa..5246f4d91e84 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -2302,6 +2302,23 @@ sdhi3: mmc@ee16 {
status = "disabled";
};
+ rpc: spi@ee20 {
+ compatible = "renesas,r8a774a1-rpc-if",
+"renesas,rcar-gen3-rpc-if";
+ reg = <0 0xee20 0 0x200>,
+ <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+ reg-names = "regs", "dirmap", "wbuf";
+ interrupts = ;
+ clocks = < CPG_MOD 917>;
+ clock-names = "rpc";
+ power-domains = < R8A774A1_PD_ALWAYS_ON>;
+ resets = < 917>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 83523916d360..5862aa2ad2bf 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -2160,6 +2160,23 @@ sdhi3: mmc@ee16 {
status = "disabled";
};
+ rpc: spi@ee20 {
+ compatible = "renesas,r8a774b1-rpc-if",
+"renesas,rcar-gen3-rpc-if";
+ reg = <0 0xee20 0 0x200>,
+ <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+ reg-names = "regs", "dirmap", "wbuf";
+ interrupts = ;
+ clocks = < CPG_MOD 917>;
+ clock-names = "rpc";
+ power-domains = < R8A774B1_PD_ALWAYS_ON>;
+ resets = < 917>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
sata: sata@ee30 {
compatible = "renesas,sata-r8a774b1",
"renesas,rcar-gen3-sata";
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index e0e54342cd4c..20fa3caa050e 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -1654,6 +1654,23 @@ sdhi3: mmc@ee16 {
status = "disabled";
};
+ rpc: spi@ee20 {
+ compatible = "renesas,r8a774c0-rpc-if",
+"renesas,rcar-gen3-rpc-if";
+ reg = <0 0xee20 0 0x200>,
+ <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+ reg-names = "regs", "dirmap", "wbuf";
+ interrupts = ;
+ clocks = < CPG_MOD 917>;
+ clock-names = "rpc";
+ power-domains = < R8A774C0_PD_ALWAYS_ON>;
+ resets = < 917>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
index 1333b02d623a..9be94945af8c 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesa
[PATCH V2 2/4] memory: renesas rpc-if: Update Add RZ/G2 to Kconfig description
The Renesas RPC-IF is present on the RZ/G2 Series. Add that to the description. Suggested-by: Biju Das Signed-off-by: Adam Ford --- drivers/memory/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) V2: New to series diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 3ea6913df176..d55252f349d4 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -202,9 +202,9 @@ config RENESAS_RPCIF depends on ARCH_RENESAS || COMPILE_TEST select REGMAP_MMIO help - This supports Renesas R-Car Gen3 RPC-IF which provides either SPI - host or HyperFlash. You'll have to select individual components - under the corresponding menu. + This supports Renesas R-Car Gen3 of RZ/G2 RPC-IF which provides + either SPI host or HyperFlash. You'll have to select individual + components under the corresponding menu. config STM32_FMC2_EBI tristate "Support for FMC2 External Bus Interface on STM32MP SoCs" -- 2.25.1
[PATCH V2 3/4] spi: renesas rpc-if: Update Add RZ/G2 to Kconfig description
The SPI driver for the Renesas RPC-IF is present on the RZ/G2 Series. Add that to the description. Suggested-by: Biju Das Signed-off-by: Adam Ford --- drivers/spi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) V2: New to series diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index aadaea052f51..e0eb2093aca6 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -650,7 +650,7 @@ config SPI_RPCIF tristate "Renesas RPC-IF SPI driver" depends on RENESAS_RPCIF help - SPI driver for Renesas R-Car Gen3 RPC-IF. + SPI driver for Renesas R-Car Gen3 or RZ/G2 RPC-IF. config SPI_RSPI tristate "Renesas RSPI/QSPI controller" -- 2.25.1
[PATCH V2 1/4] dt-bindings: memory: Renesas RPC-IF: Add support for RZ/G2 Series
The RZ/G2 Series has the RPC-IF interface. Update bindings to support: r8a774a1, r8a774b1, r8a774c0, and r8a774e1 Signed-off-by: Adam Ford --- .../bindings/memory-controllers/renesas,rpc-if.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) V2: Updated renesas,rcar-gen3-rpc-if to include RZ/G2 diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 6d6ba608fd22..990489fdd2ac 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -26,10 +26,14 @@ properties: compatible: items: - enum: + - renesas,r8a774a1-rpc-if # RZ/G2M + - renesas,r8a774b1-rpc-if # RZ/G2N + - renesas,r8a774c0-rpc-if # RZ/G2E + - renesas,r8a774e1-rpc-if # RZ/G2H - renesas,r8a77970-rpc-if # R-Car V3M - renesas,r8a77980-rpc-if # R-Car V3H - renesas,r8a77995-rpc-if # R-Car D3 - - const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 device + - const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 or RZ/G2 device reg: items: -- 2.25.1
Re: [PATCH 1/2] dt-bindings: memory: Renesas RPC-IF: Add support for RZ/G2 Series
On Sat, Jan 2, 2021 at 2:13 AM Biju Das wrote: > > > > > -Original Message- > > From: Adam Ford > > Sent: 01 January 2021 21:34 > > To: Biju Das > > Cc: linux-renesas-...@vger.kernel.org; af...@beaconembedded.com; Krzysztof > > Kozlowski ; Rob Herring ; Geert > > Uytterhoeven ; Magnus Damm > > ; Sergei Shtylyov ; > > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org > > Subject: Re: [PATCH 1/2] dt-bindings: memory: Renesas RPC-IF: Add support > > for RZ/G2 Series > > > > On Fri, Jan 1, 2021 at 12:58 PM Biju Das > > wrote: > > > > > > Hi Adam, > > > > > > Thanks for the patch. > > > > > > > -Original Message- > > > > From: Adam Ford > > > > Sent: 01 January 2021 11:39 > > > > To: linux-renesas-...@vger.kernel.org > > > > Cc: af...@beaconembedded.com; Adam Ford ; > > > > Krzysztof Kozlowski ; Rob Herring > > > > ; Geert Uytterhoeven ; > > > > Magnus Damm ; Sergei Shtylyov > > > > ; linux-kernel@vger.kernel.org; > > > > devicet...@vger.kernel.org > > > > Subject: [PATCH 1/2] dt-bindings: memory: Renesas RPC-IF: Add > > > > support for > > > > RZ/G2 Series > > > > > > > > The RZ/G2 Series has the RPC-IF interface. > > > > Update bindings to support: r8a774a1, r8a774b1, r8a774c0, and > > > > r8a774e1 > > > > > > > > Signed-off-by: Adam Ford > > > > --- > > > > .../bindings/memory-controllers/renesas,rpc-if.yaml | 4 > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/memory- > > > > controllers/renesas,rpc-if.yaml > > > > b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-i > > > > f.yaml index 6d6ba608fd22..050c66af8c2c 100644 > > > > --- > > > > a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc- > > > > if.yaml > > > > +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,r > > > > +++ pc- > > > > if.yaml > > > > @@ -26,6 +26,10 @@ properties: > > > >compatible: > > > > items: > > > >- enum: > > > > + - renesas,r8a774a1-rpc-if # RZ/G2M > > > > + - renesas,r8a774b1-rpc-if # RZ/G2N > > > > + - renesas,r8a774c0-rpc-if # RZ/G2E > > > > + - renesas,r8a774e1-rpc-if # RZ/G2H > > > >- renesas,r8a77970-rpc-if # R-Car V3M > > > >- renesas,r8a77980-rpc-if # R-Car V3H > > > >- renesas,r8a77995-rpc-if # R-Car D3 > > > > > > May be we need to update the below description as well to cover RZ/G2 > > device?? > > > > > > - const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 device > > > > How do you want it to read? > > Since it is generic compatible string for both R-Car gen3 and RZ/G2 device, I > would update the description as > > - const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 or RZ/G2 device > > Also may be we need to update the description of config RENESAS_RPCIF in > drivers/memory/Kconfig to taken care of RZ/G2 devices in a separate patch. > Thanks for the suggestion. I'll work on V2 where I update the descriptions for both. adam > Cheers, > Biju
Re: [PATCH 1/2] dt-bindings: memory: Renesas RPC-IF: Add support for RZ/G2 Series
On Fri, Jan 1, 2021 at 12:58 PM Biju Das wrote: > > Hi Adam, > > Thanks for the patch. > > > -Original Message- > > From: Adam Ford > > Sent: 01 January 2021 11:39 > > To: linux-renesas-...@vger.kernel.org > > Cc: af...@beaconembedded.com; Adam Ford ; Krzysztof > > Kozlowski ; Rob Herring ; Geert > > Uytterhoeven ; Magnus Damm > > ; Sergei Shtylyov ; > > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org > > Subject: [PATCH 1/2] dt-bindings: memory: Renesas RPC-IF: Add support for > > RZ/G2 Series > > > > The RZ/G2 Series has the RPC-IF interface. > > Update bindings to support: r8a774a1, r8a774b1, r8a774c0, and r8a774e1 > > > > Signed-off-by: Adam Ford > > --- > > .../bindings/memory-controllers/renesas,rpc-if.yaml | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/memory- > > controllers/renesas,rpc-if.yaml > > b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml > > index 6d6ba608fd22..050c66af8c2c 100644 > > --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc- > > if.yaml > > +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc- > > if.yaml > > @@ -26,6 +26,10 @@ properties: > >compatible: > > items: > >- enum: > > + - renesas,r8a774a1-rpc-if # RZ/G2M > > + - renesas,r8a774b1-rpc-if # RZ/G2N > > + - renesas,r8a774c0-rpc-if # RZ/G2E > > + - renesas,r8a774e1-rpc-if # RZ/G2H > >- renesas,r8a77970-rpc-if # R-Car V3M > >- renesas,r8a77980-rpc-if # R-Car V3H > >- renesas,r8a77995-rpc-if # R-Car D3 > > May be we need to update the below description as well to cover RZ/G2 device?? > > - const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 device How do you want it to read? adam > > Cheers, > Biju > > > > -- > > 2.25.1 >
[PATCH 2/2] arm64: dts: renesas: rzg2: Add RPC-IF Support
The RZ/G2 series contain the SPI Multi I/O Bus Controller (RPC-IF).
Add the nodes, but make them disabled by default.
Signed-off-by: Adam Ford
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 17 +
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 17 +
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 17 +
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 17 +
4 files changed, 68 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d37ec42a1caa..5246f4d91e84 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -2302,6 +2302,23 @@ sdhi3: mmc@ee16 {
status = "disabled";
};
+ rpc: spi@ee20 {
+ compatible = "renesas,r8a774a1-rpc-if",
+"renesas,rcar-gen3-rpc-if";
+ reg = <0 0xee20 0 0x200>,
+ <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+ reg-names = "regs", "dirmap", "wbuf";
+ interrupts = ;
+ clocks = < CPG_MOD 917>;
+ clock-names = "rpc";
+ power-domains = < R8A774A1_PD_ALWAYS_ON>;
+ resets = < 917>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 83523916d360..5862aa2ad2bf 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -2160,6 +2160,23 @@ sdhi3: mmc@ee16 {
status = "disabled";
};
+ rpc: spi@ee20 {
+ compatible = "renesas,r8a774b1-rpc-if",
+"renesas,rcar-gen3-rpc-if";
+ reg = <0 0xee20 0 0x200>,
+ <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+ reg-names = "regs", "dirmap", "wbuf";
+ interrupts = ;
+ clocks = < CPG_MOD 917>;
+ clock-names = "rpc";
+ power-domains = < R8A774B1_PD_ALWAYS_ON>;
+ resets = < 917>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
sata: sata@ee30 {
compatible = "renesas,sata-r8a774b1",
"renesas,rcar-gen3-sata";
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index e0e54342cd4c..20fa3caa050e 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -1654,6 +1654,23 @@ sdhi3: mmc@ee16 {
status = "disabled";
};
+ rpc: spi@ee20 {
+ compatible = "renesas,r8a774c0-rpc-if",
+"renesas,rcar-gen3-rpc-if";
+ reg = <0 0xee20 0 0x200>,
+ <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+ reg-names = "regs", "dirmap", "wbuf";
+ interrupts = ;
+ clocks = < CPG_MOD 917>;
+ clock-names = "rpc";
+ power-domains = < R8A774C0_PD_ALWAYS_ON>;
+ resets = < 917>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
index 1333b02d623a..9be94945af8c 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
@@
[PATCH 1/2] dt-bindings: memory: Renesas RPC-IF: Add support for RZ/G2 Series
The RZ/G2 Series has the RPC-IF interface. Update bindings to support: r8a774a1, r8a774b1, r8a774c0, and r8a774e1 Signed-off-by: Adam Ford --- .../bindings/memory-controllers/renesas,rpc-if.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 6d6ba608fd22..050c66af8c2c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -26,6 +26,10 @@ properties: compatible: items: - enum: + - renesas,r8a774a1-rpc-if # RZ/G2M + - renesas,r8a774b1-rpc-if # RZ/G2N + - renesas,r8a774c0-rpc-if # RZ/G2E + - renesas,r8a774e1-rpc-if # RZ/G2H - renesas,r8a77970-rpc-if # R-Car V3M - renesas,r8a77980-rpc-if # R-Car V3H - renesas,r8a77995-rpc-if # R-Car D3 -- 2.25.1
Re: [PATCH 1/3] thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430
On Wed, Dec 30, 2020 at 2:43 AM Tony Lindgren wrote:
>
> At least for 4430, trying to use the single conversion mode eventually
> hangs the thermal sensor. This can be quite easily seen with errors:
>
> thermal thermal_zone0: failed to read out thermal zone (-5)
>
> Also, trying to read the temperature shows a stuck value with:
>
> $ while true; do cat /sys/class/thermal/thermal_zone0/temp; done
>
> Where the temperature is not rising at all with the busy loop.
>
> Additionally, the EOCZ (end of conversion) bit is not rising on 4430 in
> single conversion mode while it works fine in continuous conversion mode.
> It is also possible that the hung temperature sensor can affect the
> thermal shutdown alert too.
>
> Let's fix the issue by adding TI_BANDGAP_FEATURE_CONT_MODE_ONLY flag and
> use it for 4430.
>
> Note that we also need to add udelay to for the EOCZ (end of conversion)
> bit polling as otherwise we have it time out too early on 4430. We'll be
> changing the loop to use iopoll in the following clean-up patch.
>
> Cc: Adam Ford
I don't have an OMAP4, but if you want, I can test a DM3730.
adam
> Cc: Carl Philipp Klemm
> Cc: Eduardo Valentin
> Cc: Merlijn Wajer
> Cc: Pavel Machek
> Cc: Peter Ujfalusi
> Cc: Sebastian Reichel
> Signed-off-by: Tony Lindgren
> ---
> drivers/thermal/ti-soc-thermal/omap4-thermal-data.c | 3 ++-
> drivers/thermal/ti-soc-thermal/ti-bandgap.c | 9 +++--
> drivers/thermal/ti-soc-thermal/ti-bandgap.h | 2 ++
> 3 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
> b/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
> --- a/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
> +++ b/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
> @@ -58,7 +58,8 @@ omap4430_adc_to_temp[OMAP4430_ADC_END_VALUE -
> OMAP4430_ADC_START_VALUE + 1] = {
> const struct ti_bandgap_data omap4430_data = {
> .features = TI_BANDGAP_FEATURE_MODE_CONFIG |
> TI_BANDGAP_FEATURE_CLK_CTRL |
> - TI_BANDGAP_FEATURE_POWER_SWITCH,
> + TI_BANDGAP_FEATURE_POWER_SWITCH |
> + TI_BANDGAP_FEATURE_CONT_MODE_ONLY,
> .fclock_name = "bandgap_fclk",
> .div_ck_name = "bandgap_fclk",
> .conv_table = omap4430_adc_to_temp,
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -605,8 +606,10 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int
> id)
> u32 counter = 1000;
> struct temp_sensor_registers *tsr;
>
> - /* Select single conversion mode */
> - if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
> + /* Select continuous or single conversion mode */
> + if (TI_BANDGAP_HAS(bgp, CONT_MODE_ONLY))
> + RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 1);
> + else if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
> RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0);
>
> /* Start of Conversion = 1 */
> @@ -619,6 +622,7 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int
> id)
> if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
> tsr->bgap_eocz_mask)
> break;
> + udelay(1);
> }
>
> /* Start of Conversion = 0 */
> @@ -630,6 +634,7 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int
> id)
> if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
> tsr->bgap_eocz_mask))
> break;
> + udelay(1);
> }
>
> return 0;
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> @@ -280,6 +280,7 @@ struct ti_temp_sensor {
> * has Errata 814
> * TI_BANDGAP_FEATURE_UNRELIABLE - used when the sensor readings are too
> * inaccurate.
> + * TI_BANDGAP_FEATURE_CONT_MODE_ONLY - used when single mode hangs the sensor
> * TI_BANDGAP_HAS(b, f) - macro to check if a bandgap device is capable of a
> * specific feature (above) or not. Return non-zero, if yes.
> */
> @@ -295,6 +296,7 @@ struct ti_temp_sensor {
> #define TI_BANDGAP_FEATURE_HISTORY_BUFFER BIT(9)
> #define TI_BANDGAP_FEATURE_ERRATA_814 BIT(10)
> #define TI_BANDGAP_FEATURE_UNRELIABLE BIT(11)
> +#define TI_BANDGAP_FEATURE_CONT_MODE_ONLY BIT(12)
> #define TI_BANDGAP_HAS(b, f) \
> ((b)->conf->features & TI_BANDGAP_FEATURE_ ## f)
>
> --
> 2.29.2
[PATCH 2/2] clk: imx: Cleanup references to imx_register_uart_clocks
With the clk driver scanning the device tree the for stdout, it
doesn't require a list of clocks to be passed to it. Remove the
code that generates these clock lists.
Signed-off-by: Adam Ford
---
This was build tested for arm, and tested on i.MX8M Nano.
---
drivers/clk/imx/clk-imx25.c | 12 +---
drivers/clk/imx/clk-imx27.c | 13 +
drivers/clk/imx/clk-imx31.c | 10 --
drivers/clk/imx/clk-imx35.c | 10 +-
drivers/clk/imx/clk-imx5.c| 30 +++---
drivers/clk/imx/clk-imx6q.c | 16 +---
drivers/clk/imx/clk-imx6sl.c | 16 +---
drivers/clk/imx/clk-imx6sll.c | 24 +---
drivers/clk/imx/clk-imx6sx.c | 16 +---
drivers/clk/imx/clk-imx7d.c | 22 +-
drivers/clk/imx/clk-imx7ulp.c | 31 ++-
drivers/clk/imx/clk-imx8mm.c | 18 ++
drivers/clk/imx/clk-imx8mn.c | 18 ++
drivers/clk/imx/clk-imx8mp.c | 17 +
drivers/clk/imx/clk-imx8mq.c | 18 ++
drivers/clk/imx/clk.c | 2 +-
drivers/clk/imx/clk.h | 4 ++--
17 files changed, 23 insertions(+), 254 deletions(-)
diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
index a66cabfbf94f..cc013b343e62 100644
--- a/drivers/clk/imx/clk-imx25.c
+++ b/drivers/clk/imx/clk-imx25.c
@@ -73,16 +73,6 @@ enum mx25_clks {
static struct clk *clk[clk_max];
-static struct clk ** const uart_clks[] __initconst = {
- [uart_ipg_per],
- [uart1_ipg],
- [uart2_ipg],
- [uart3_ipg],
- [uart4_ipg],
- [uart5_ipg],
- NULL
-};
-
static int __init __mx25_clocks_init(void __iomem *ccm_base)
{
BUG_ON(!ccm_base);
@@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem *ccm_base)
*/
clk_set_parent(clk[cko_sel], clk[ipg]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks();
return 0;
}
diff --git a/drivers/clk/imx/clk-imx27.c b/drivers/clk/imx/clk-imx27.c
index 5585ded8b8c6..5d177125728d 100644
--- a/drivers/clk/imx/clk-imx27.c
+++ b/drivers/clk/imx/clk-imx27.c
@@ -49,17 +49,6 @@ static const char *ssi_sel_clks[] = { "spll_gate", "mpll", };
static struct clk *clk[IMX27_CLK_MAX];
static struct clk_onecell_data clk_data;
-static struct clk ** const uart_clks[] __initconst = {
- [IMX27_CLK_PER1_GATE],
- [IMX27_CLK_UART1_IPG_GATE],
- [IMX27_CLK_UART2_IPG_GATE],
- [IMX27_CLK_UART3_IPG_GATE],
- [IMX27_CLK_UART4_IPG_GATE],
- [IMX27_CLK_UART5_IPG_GATE],
- [IMX27_CLK_UART6_IPG_GATE],
- NULL
-};
-
static void __init _mx27_clocks_init(unsigned long fref)
{
BUG_ON(!ccm);
@@ -176,7 +165,7 @@ static void __init _mx27_clocks_init(unsigned long fref)
clk_prepare_enable(clk[IMX27_CLK_EMI_AHB_GATE]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks();
imx_print_silicon_rev("i.MX27", mx27_revision());
}
diff --git a/drivers/clk/imx/clk-imx31.c b/drivers/clk/imx/clk-imx31.c
index 7b13fb57d842..c44e18c6f63f 100644
--- a/drivers/clk/imx/clk-imx31.c
+++ b/drivers/clk/imx/clk-imx31.c
@@ -51,16 +51,6 @@ enum mx31_clks {
static struct clk *clk[clk_max];
static struct clk_onecell_data clk_data;
-static struct clk ** const uart_clks[] __initconst = {
- [ipg],
- [uart1_gate],
- [uart2_gate],
- [uart3_gate],
- [uart4_gate],
- [uart5_gate],
- NULL
-};
-
static void __init _mx31_clocks_init(void __iomem *base, unsigned long fref)
{
clk[dummy] = imx_clk_fixed("dummy", 0);
diff --git a/drivers/clk/imx/clk-imx35.c b/drivers/clk/imx/clk-imx35.c
index c1df03665c09..7dcbaea3fea3 100644
--- a/drivers/clk/imx/clk-imx35.c
+++ b/drivers/clk/imx/clk-imx35.c
@@ -82,14 +82,6 @@ enum mx35_clks {
static struct clk *clk[clk_max];
-static struct clk ** const uart_clks[] __initconst = {
- [ipg],
- [uart1_gate],
- [uart2_gate],
- [uart3_gate],
- NULL
-};
-
static void __init _mx35_clocks_init(void)
{
void __iomem *base;
@@ -243,7 +235,7 @@ static void __init _mx35_clocks_init(void)
*/
clk_prepare_enable(clk[scc_gate]);
- imx_register_uart_clocks(uart_clks);
+ imx_register_uart_clocks();
imx_print_silicon_rev("i.MX35", mx35_revision());
}
diff --git a/drivers/clk/imx/clk-imx5.c b/drivers/clk/imx/clk-imx5.c
index 01e079b81026..b82044911603 100644
--- a/drivers/clk/imx/clk-imx5.c
+++ b/drivers/clk/imx/clk-imx5.c
@@ -128,30 +128,6 @@ static const char *ieee1588_sels[] = { "pll3_sw",
"pll4_sw", "dummy" /* usbphy2_
static struct clk *clk[IMX5_CLK_END];
static struct clk_onecell_data clk_data;
-static struct clk ** const uart_clks_mx51[] __initconst = {
- [IMX5_CLK_UART1_IPG_GATE],
- [IMX5_CLK_UART
[PATCH 1/2] clk: imx: enable the earlycon uart clocks by parsing from dt
Remove the earlycon uart clocks that are hard cord in platforms
clock driver, instead of parsing the earlycon uart port from dt
and enable these clocks from clock property in dt node.
Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate protection")
Signed-off-by: Fugang Duan
Signed-off-by: Adam Ford
---
Based on NXP's code base and adapted for 5.11-rc1.
https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/clk/imx/clk.c?h=imx_5.4.47_2.2.0=754ae82cc55b7445545fc2f092a70e0f490e9c1b
The original signed-off was retained.
Added the fixes tag.
---
drivers/clk/imx/clk.c | 43 +--
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
index 47882c51cb85..c32b46890945 100644
--- a/drivers/clk/imx/clk.c
+++ b/drivers/clk/imx/clk.c
@@ -148,7 +148,7 @@ void imx_cscmr1_fixup(u32 *val)
#ifndef MODULE
static int imx_keep_uart_clocks;
-static struct clk ** const *imx_uart_clocks;
+static bool imx_uart_clks_on;
static int __init imx_keep_uart_clocks_param(char *str)
{
@@ -161,25 +161,40 @@ __setup_param("earlycon", imx_keep_uart_earlycon,
__setup_param("earlyprintk", imx_keep_uart_earlyprintk,
imx_keep_uart_clocks_param, 0);
-void imx_register_uart_clocks(struct clk ** const clks[])
+static void imx_earlycon_uart_clks_onoff(bool is_on)
{
- if (imx_keep_uart_clocks) {
- int i;
+ struct clk *uart_clk;
+ int i = 0;
- imx_uart_clocks = clks;
- for (i = 0; imx_uart_clocks[i]; i++)
- clk_prepare_enable(*imx_uart_clocks[i]);
- }
+ if (!imx_keep_uart_clocks || (!is_on && !imx_uart_clks_on))
+ return;
+
+ /* only support dt */
+ if (!of_stdout)
+ return;
+
+ do {
+ uart_clk = of_clk_get(of_stdout, i++);
+ if (IS_ERR(uart_clk))
+ break;
+
+ if (is_on)
+ clk_prepare_enable(uart_clk);
+ else
+ clk_disable_unprepare(uart_clk);
+ } while (true);
+
+ if (is_on)
+ imx_uart_clks_on = true;
+}
+void imx_register_uart_clocks(struct clk ** const clks[])
+{
+ imx_earlycon_uart_clks_onoff(true);
}
static int __init imx_clk_disable_uart(void)
{
- if (imx_keep_uart_clocks && imx_uart_clocks) {
- int i;
-
- for (i = 0; imx_uart_clocks[i]; i++)
- clk_disable_unprepare(*imx_uart_clocks[i]);
- }
+ imx_earlycon_uart_clks_onoff(false);
return 0;
}
--
2.25.1
Re: [PATCH 2/4] arm64: dts: imx8mn: add spba bus node
On Tue, Dec 29, 2020 at 6:15 AM wrote:
>
> From: Peng Fan
>
> According to RM, there is a spba bus inside aips3 and aips1, add it.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 362 +++---
> 1 file changed, 189 insertions(+), 173 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index c824f2615fe8..91f85b8cee9a 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -269,117 +269,125 @@ aips1: bus@3000 {
> #size-cells = <1>;
> ranges = <0x3000 0x3000 0x40>;
>
> - sai1: sai@3001 {
> - #sound-dai-cells = <0>;
> - compatible = "fsl,imx8mm-sai",
> "fsl,imx8mq-sai";
> - reg = <0x3001 0x1>;
> - interrupts = ;
> - clocks = < IMX8MM_CLK_SAI1_IPG>,
> -< IMX8MM_CLK_SAI1_ROOT>,
> -< IMX8MM_CLK_DUMMY>, <
> IMX8MM_CLK_DUMMY>;
> - clock-names = "bus", "mclk1", "mclk2",
> "mclk3";
> - dmas = < 0 2 0>, < 1 2 0>;
> - dma-names = "rx", "tx";
> - status = "disabled";
> - };
> + bus@3000 {
There is already a bus@3000 (aips1), and I think the system
doesn't like it when there are multiple busses with the same name.
There was some discussion on fixing the 8mn [1], but it doesn't look
like it went anywhere.
I am guessing the Mini will need something similar to the nano.
[1] -
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1607324004-12960-1-git-send-email-shengjiu.w...@nxp.com/
adam
> + compatible = "fsl,spba-bus", "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x3000 0x10>;
> + ranges;
> +
> + sai1: sai@3001 {
> + #sound-dai-cells = <0>;
> + compatible = "fsl,imx8mm-sai",
> "fsl,imx8mq-sai";
> + reg = <0x3001 0x1>;
> + interrupts = IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < IMX8MM_CLK_SAI1_IPG>,
> +< IMX8MM_CLK_SAI1_ROOT>,
> +< IMX8MM_CLK_DUMMY>,
> < IMX8MM_CLK_DUMMY>;
> + clock-names = "bus", "mclk1",
> "mclk2", "mclk3";
> + dmas = < 0 2 0>, < 1 2 0>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
>
> - sai2: sai@3002 {
> - #sound-dai-cells = <0>;
> - compatible = "fsl,imx8mm-sai",
> "fsl,imx8mq-sai";
> - reg = <0x3002 0x1>;
> - interrupts = ;
> - clocks = < IMX8MM_CLK_SAI2_IPG>,
> - < IMX8MM_CLK_SAI2_ROOT>,
> - < IMX8MM_CLK_DUMMY>, <
> IMX8MM_CLK_DUMMY>;
> - clock-names = "bus", "mclk1", "mclk2",
> "mclk3";
> - dmas = < 2 2 0>, < 3 2 0>;
> - dma-names = "rx", "tx";
> - status = "disabled";
> - };
> + sai2: sai@3002 {
> + #sound-dai-cells = <0>;
> + compatible = "fsl,imx8mm-sai",
> "fsl,imx8mq-sai";
> + reg = <0x3002 0x1>;
> + interrupts = IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < IMX8MM_CLK_SAI2_IPG>,
> + < IMX8MM_CLK_SAI2_ROOT>,
> + < IMX8MM_CLK_DUMMY>,
> < IMX8MM_CLK_DUMMY>;
> + clock-names = "bus", "mclk1",
> "mclk2", "mclk3";
> + dmas = < 2 2 0>, < 3 2 0>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
>
> -
[PATCH 2/2] arm64: dts: renesas: Add usb2_clksel to RZ/G2 M/N/H
Per the reference manal for the RZ/G Series, 2nd Generation,
the RZ/G2M, RZ/G2N, and RZ/G2H have a bit that can be set to
choose between a crystal oscillator and an external oscillator.
Because only boards that need this should enable it, it's marked
as disabled by default for backwards compatibility with existing
boards.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d37ec42a1caa..60e150320ce8 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -835,6 +835,21 @@ hsusb: usb@e659 {
status = "disabled";
};
+ usb2_clksel: clock-controller@e6590630 {
+ compatible = "renesas,r8a774a1-rcar-usb2-clock-sel",
+"renesas,rcar-gen3-usb2-clock-sel";
+ reg = <0 0xe6590630 0 0x02>;
+ clocks = < CPG_MOD 703>, < CPG_MOD 704>,
+<_extal_clk>, <_clk>;
+ clock-names = "ehci_ohci", "hs-usb-if",
+ "usb_extal", "usb_xtal";
+ #clock-cells = <0>;
+ power-domains = < R8A774A1_PD_ALWAYS_ON>;
+ resets = < 703>, < 704>;
+ reset-names = "ehci_ohci", "hs-usb-if";
+ status = "disabled";
+ };
+
usb_dmac0: dma-controller@e65a {
compatible = "renesas,r8a774a1-usb-dmac",
"renesas,usb-dmac";
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 83523916d360..20003a41a706 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -709,6 +709,21 @@ hsusb: usb@e659 {
status = "disabled";
};
+ usb2_clksel: clock-controller@e6590630 {
+ compatible = "renesas,r8a774b1-rcar-usb2-clock-sel",
+"renesas,rcar-gen3-usb2-clock-sel";
+ reg = <0 0xe6590630 0 0x02>;
+ clocks = < CPG_MOD 703>, < CPG_MOD 704>,
+<_extal_clk>, <_clk>;
+ clock-names = "ehci_ohci", "hs-usb-if",
+ "usb_extal", "usb_xtal";
+ #clock-cells = <0>;
+ power-domains = < R8A774B1_PD_ALWAYS_ON>;
+ resets = < 703>, < 704>;
+ reset-names = "ehci_ohci", "hs-usb-if";
+ status = "disabled";
+ };
+
usb_dmac0: dma-controller@e65a {
compatible = "renesas,r8a774b1-usb-dmac",
"renesas,usb-dmac";
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
index 1333b02d623a..2e6c12a46daf 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
@@ -890,6 +890,21 @@ hsusb: usb@e659 {
status = "disabled";
};
+ usb2_clksel: clock-controller@e6590630 {
+ compatible = "renesas,r8a774e1-rcar-usb2-clock-sel",
+"renesas,rcar-gen3-usb2-clock-sel";
+ reg = <0 0xe6590630 0 0x02>;
+ clocks = < CPG_MOD 703>, < CPG_MOD 704>,
+<_extal_clk>, <_clk>;
+ clock-names = "ehci_ohci", "hs-usb-if",
+ "usb_extal", "usb_xtal";
+ #clock-cells = <0>;
+ power-domains = < R8A774E1_PD_ALWAYS_ON>;
+ resets = < 703>, < 704>;
+ reset-names = "ehci_ohci", "hs-usb-if";
+ status = "disabled";
+ };
+
usb_dmac0: dma-controller@e65a {
compatible = "renesas,r8a774e1-usb-dmac",
"renesas,usb-dmac";
--
2.25.1
[PATCH 1/2] dt-bindings: clock: renesas: rcar-usb2-clock-sel: Add support for RZ/G2 M/N/H
The datasheet for the RZ/G2 Series show the bit for choosing between a crystal oscillator and an external oscillator is present. Add the bindings for r8a774a1 (RZ/G2M), r8a774b1 (RZ/G2N), and r8a774e1 (RZ/G2H) Signed-off-by: Adam Ford diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml index 5be1229b3d6e..6eaabb4d82ec 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml @@ -35,6 +35,9 @@ properties: compatible: items: - enum: + - renesas,r8a774a1-rcar-usb2-clock-sel # RZ/G2M + - renesas,r8a774b1-rcar-usb2-clock-sel # RZ/G2N + - renesas,r8a774e1-rcar-usb2-clock-sel # RZ/G2H - renesas,r8a7795-rcar-usb2-clock-sel # R-Car H3 - renesas,r8a7796-rcar-usb2-clock-sel # R-Car M3-W - renesas,r8a77961-rcar-usb2-clock-sel # R-Car M3-W+ -- 2.25.1
[PATCH 4/4] net: ethernet: ravb: Name the AVB functional clock fck
The bindings have been updated to support two clocks, but the
original clock now requires the name fck to distinguish it
from the other.
Signed-off-by: Adam Ford
---
drivers/net/ethernet/renesas/ravb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c
b/drivers/net/ethernet/renesas/ravb_main.c
index bd30505fbc57..99a6ef9c15c1 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2142,7 +2142,7 @@ static int ravb_probe(struct platform_device *pdev)
priv->chip_id = chip_id;
- priv->clk = devm_clk_get(>dev, NULL);
+ priv->clk = devm_clk_get(>dev, "fck");
if (IS_ERR(priv->clk)) {
error = PTR_ERR(priv->clk);
goto out_release;
--
2.25.1
[PATCH 2/4] ARM: dts: renesas: Add fck to etheravb-rcar-gen2 clock-names list
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
---
arch/arm/boot/dts/r8a7742.dtsi | 1 +
arch/arm/boot/dts/r8a7743.dtsi | 1 +
arch/arm/boot/dts/r8a7744.dtsi | 1 +
arch/arm/boot/dts/r8a7745.dtsi | 1 +
arch/arm/boot/dts/r8a77470.dtsi | 1 +
arch/arm/boot/dts/r8a7790.dtsi | 1 +
arch/arm/boot/dts/r8a7791.dtsi | 1 +
arch/arm/boot/dts/r8a7792.dtsi | 1 +
arch/arm/boot/dts/r8a7794.dtsi | 1 +
9 files changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index 6a78c813057b..6b922f664fcd 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -750,6 +750,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7742_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index f444e418f408..084bf3e039cf 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -702,6 +702,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7743_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index 0442aad4f9db..d01eba99ceb0 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -702,6 +702,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7744_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0f14ac22921d..d0d45a369047 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -645,6 +645,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7745_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 691b1a131c87..ae90a001d663 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -537,6 +537,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A77470_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b0569b4ea5c8..af9cd3324f4c 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -768,6 +768,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7790_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 87f0d6dc3e5a..2354af7fa83f 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -728,6 +728,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7791_PD
[PATCH 3/4] arm64: dts: renesas: Add fck to etheravb-rcar-gen3 clock-names list
The bindings have been updated to support two clocks, but the
original clock now requires the name fck. Add a clock-names
list in the device tree with fck in it.
Signed-off-by: Adam Ford
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77951.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77960.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77961.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 1 +
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 1 +
12 files changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d37ec42a1caa..6804de678453 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1112,6 +1112,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774A1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 83523916d360..179817de1bef 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -986,6 +986,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774B1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index e0e54342cd4c..e43e8b0a167b 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -957,6 +957,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774C0_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
index 1333b02d623a..c6b47ca9ed45 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
@@ -1215,6 +1215,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A774E1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
index 5c39152e4570..1e622ab8a044 100644
--- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
@@ -1312,6 +1312,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
clocks = < CPG_MOD 812>;
+ clock-names = "fck";
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
index 25d947a81b29..a3d1c33cbc1d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
@@ -1188,6 +1188,7 @@ avb: ethernet@e680 {
"ch20", "ch21", "ch22", "ch23",
"ch24";
c
[PATCH 1/4] dt-bindings: net: renesas,etheravb: Add additional clocks
The AVB driver assumes there is an external clock, but it could be driven by an external clock. In order to enable a programmable clock, it needs to be added to the clocks list and enabled in the driver. Since there currently only one clock, there is no clock-names list either. Update bindings to add the additional optional clock, and explicitly name both of them. Signed-off-by: Adam Ford --- .../devicetree/bindings/net/renesas,etheravb.yaml | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index 244befb6402a..c1a06510f056 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -49,7 +49,16 @@ properties: interrupt-names: true clocks: -maxItems: 1 +minItems: 1 +maxItems: 2 +items: + - description: AVB functional clock + - description: Optional TXC reference clock + + clock-names: +items: + - const: fck + - const: txc_refclk iommus: maxItems: 1 -- 2.25.1
Re: [RFC] ravb: Add support for optional txc_refclk
On Mon, Dec 14, 2020 at 4:05 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> On Sun, Dec 13, 2020 at 5:18 PM Adam Ford wrote:
> > The SoC expects the txv_refclk is provided, but if it is provided
> > by a programmable clock, there needs to be a way to get and enable
> > this clock to operate. It needs to be optional since it's only
> > necessary for those with programmable clocks.
> >
> > Signed-off-by: Adam Ford
>
> Thanks for your patch!
>
> > --- a/drivers/net/ethernet/renesas/ravb.h
> > +++ b/drivers/net/ethernet/renesas/ravb.h
> > @@ -994,6 +994,7 @@ struct ravb_private {
> > struct platform_device *pdev;
> > void __iomem *addr;
> > struct clk *clk;
> > + struct clk *ref_clk;
> > struct mdiobb_ctrl mdiobb;
> > u32 num_rx_ring[NUM_RX_QUEUE];
> > u32 num_tx_ring[NUM_TX_QUEUE];
> > diff --git a/drivers/net/ethernet/renesas/ravb_main.c
> > b/drivers/net/ethernet/renesas/ravb_main.c
> > index bd30505fbc57..4c3f95923ef2 100644
> > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > @@ -2148,6 +2148,18 @@ static int ravb_probe(struct platform_device *pdev)
> > goto out_release;
> > }
> >
> > + priv->ref_clk = devm_clk_get(>dev, "txc_refclk");
>
> Please also update the DT bindings[1], to document the optional
> presence of the clock.
I am not all that familiar with the YAML syntax, but right now, the
clock-names property isn't in the binding, and the driver doesn't use
a name when requesting the single clock it's expecting.
Since the txc_refclk is optional, can the clock-names property allow
for 0-2 names while the number of clocks be 1-2?
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 0
maxItems: 2
items:
enum:
- fck # AVB functional clock (optional if it is the only clock)
- txc_refclk # TXC reference clock
With the above proposal, the clock-names would only be necessary when
using the txc_refclk.
>
> > + if (IS_ERR(priv->ref_clk)) {
> > + if (PTR_ERR(priv->ref_clk) == -EPROBE_DEFER) {
> > + /* for Probe defer return error */
> > + error = PTR_ERR(priv->ref_clk);
> > + goto out_release;
> > + }
> > + /* Ignore other errors since it's optional */
> > + } else {
> > + (void)clk_prepare_enable(priv->ref_clk);
>
> This can fail.
> Does this clock need to be enabled all the time?
> At least it should be disabled in the probe failure path, and in
> ravb_remove().
I'll do that for the next rev.
thanks,
adam
>
> [1] Documentation/devicetree/bindings/net/renesas,etheravb.yaml
>
> 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/18] arm64: dts: renesas: beacon kit: Configure programmable clocks
On Mon, Dec 28, 2020 at 6:33 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> On Thu, Dec 24, 2020 at 2:53 PM Adam Ford wrote:
> > On Tue, Dec 22, 2020 at 2:03 AM Geert Uytterhoeven
> > wrote:
> > > On Tue, Dec 22, 2020 at 2:39 AM Adam Ford wrote:
> > > > On Fri, Dec 18, 2020 at 7:16 AM Geert Uytterhoeven
> > > > wrote:
> > > > > On Thu, Dec 17, 2020 at 12:52 PM Adam Ford wrote:
> > > > > > On Thu, Dec 17, 2020 at 2:16 AM Geert Uytterhoeven
> > > > > > wrote:
> > > > > > > On Wed, Dec 16, 2020 at 6:03 PM Adam Ford
> > > > > > > wrote:
> > > > > > > > On Wed, Dec 16, 2020 at 8:55 AM Geert Uytterhoeven
> > > > > > > > wrote:
> > > > > > > > > On Sun, Dec 13, 2020 at 7:38 PM Adam Ford
> > > > > > > > > wrote:
> > > > > > > > > > When the board was added, clock drivers were being updated
> > > > > > > > > > done at
> > > > > > > > > > the same time to allow the versaclock driver to properly
> > > > > > > > > > configure
> > > > > > > > > > the modes. Unforutnately, the updates were not applied to
> > > > > > > > > > the board
> > > > > > >
> > > > > > > > > > ---
> > > > > > > > > > a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > > > > > > > +++
> > > > > > > > > > b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > > > > > > > @@ -5,6 +5,7 @@
> > > > > > > > > >
> > > > > > > > > > #include
> > > > > > > > > > #include
> > > > > > > > > > +#include
> > > > > > > > > >
> > > > > > > > > > / {
> > > > > > > > > > backlight_lvds: backlight-lvds {
> > > > > > > > > > @@ -294,12 +295,12 @@ _out_rgb {
> > > > > > > > > > {
> > > > > > > > > > dr_mode = "otg";
> > > > > > > > > > status = "okay";
> > > > > > > > > > - clocks = < CPG_MOD 703>, < CPG_MOD 704>;
> > > > > > > > > > + clocks = < CPG_MOD 703>, < CPG_MOD 704>,
> > > > > > > > > > < 3>;
> > > > > > > > >
> > > > > > > > > Why this change? You said before you don't need this
> > > > > > > > > https://lore.kernel.org/linux-renesas-soc/cahcn7xjwbp16sa-ok-5synnqozat8ofjo2_rtg5vrnvsn2-...@mail.gmail.com/
> > > > > > > > >
> > > > > > > >
> > > > > > > > I had talked with the hardware guys about buy pre-programmed
> > > > > > > > versaclock chips which would have been pre-configured and
> > > > > > > > pre-enabled.
> > > > > > > > I thought it was going to happen, but it didn't, so we need the
> > > > > > > > versaclock driver to enable the reference clock for the USB
> > > > > > > > controllers, ethernet controller and audio clocks. Previously
> > > > > > > > we were
> > > > > > > > manually configuring it or it was coincidentally working.
> > > > > > > > Ideally,
> > > > > > > > we'd have the clock system intentionally enable/disable the
> > > > > > > > clocks
> > > > > > > > when drivers are loaded/unloaded for for power management
> > > > > > > > reasons.
> > > > > > >
> > > > > > > Can you tell me how exactly the Versaclock outputs are wired?
> > > > > >
> > > > > > The SoC is expecting a fixed external 50 MHz clock connected to
> > > > > > USB_EXTAL. Instead of a fixed clock, we're using the Versaclock.
> > > > > > We're also using the Versaclock to drive the AVB TXCRefClk,
> > > > > > du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on
> > > > > > RZ/G2N) instead of fixed clocks.
> > > >
[PATCH V2 9/9] arm64: dts: renesas: beacon: Increase sdhi speeds
The eMMC can run at hs400 and the WiFi chip can run at sdr104.
Set the respective flags to push the sdhi faster.
Signed-off-by: Adam Ford
---
V2: New to series
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index b34ffa1e77fa..56bdd80e36d0 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -271,8 +271,9 @@ {
};
{
- pinctrl-names = "default";
pinctrl-0 = <_pins>;
+ pinctrl-1 = <_pins>;
+ pinctrl-names = "default", "state_uhs";
bus-width = <4>;
vmmc-supply = <_3p3v>;
vqmmc-supply = <_1p8v>;
@@ -281,6 +282,8 @@ {
pm-ignore-notify;
keep-power-in-suspend;
mmc-pwrseq = <_pwrseq>;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
--
2.25.1
[PATCH V2 6/9] arm64: dts: renesas: beacon-rzg2m-kit: Rearange SoC unique functions
In preparation for adding new dev kits, move anything specific to the
RZ/G2M from the SOM-level and baseboard-levels and move them to the
kit-level. This allows the SOM and baseboard to be reused with
other SoC's.
Signed-off-by: Adam Ford
---
V2: Fix missing entries in dts file.
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index 3b3efaf749bb..a6aa0b815c46 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -241,21 +241,6 @@ {
status = "okay";
};
- {
- pinctrl-0 = <_pins>;
- pinctrl-names = "default";
- status = "okay";
-
- clocks = < CPG_MOD 724>,
- < CPG_MOD 723>,
- < CPG_MOD 722>,
- < 1>,
- <_clk>,
- < 2>;
- clock-names = "du.0", "du.1", "du.2",
- "dclkin.0", "dclkin.1", "dclkin.2";
-};
-
_out_rgb {
remote-endpoint = <_panel>;
};
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index a6f7193e4d97..b34ffa1e77fa 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -13,11 +13,6 @@ memory@4800 {
reg = <0x0 0x4800 0x0 0x7800>;
};
- memory@6 {
- device_type = "memory";
- reg = <0x6 0x 0x0 0x8000>;
- };
-
osc_32k: osc_32k {
compatible = "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
index 25eeac411f12..501cb05da228 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
@@ -26,6 +26,26 @@ aliases {
chosen {
stdout-path = "serial0:115200n8";
};
+
+ memory@6 {
+ device_type = "memory";
+ reg = <0x6 0x 0x0 0x8000>;
+ };
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ clocks = < CPG_MOD 724>,
+< CPG_MOD 723>,
+< CPG_MOD 722>,
+< 1>,
+<_clk>,
+< 2>;
+ clock-names = "du.0", "du.1", "du.2",
+ "dclkin.0", "dclkin.1", "dclkin.2";
};
/* Reference versaclock instead of audio_clk_a */
--
2.25.1
[PATCH V2 8/9] arm64: dts: renesas: Introduce r8a774e1-beacon-rzg2h-kit
eacon EmebeddedWorks is introducing a new kit based on the
RZ/G2H SoC from Renesas.
The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1
cellular radio.
The Baseboard has Ethernet, USB, HDMI, stereo audio in and out,
along with a variety of push buttons and LED's, and support for
a parallel RGB and an LVDS display. It uses the same baseboard
and SOM files as the RZ/G2M and RZ/G2N kits.
Signed-off-by: Adam Ford
---
V2: Add missing du node entries
diff --git a/arch/arm64/boot/dts/renesas/Makefile
b/arch/arm64/boot/dts/renesas/Makefile
index cf7e2f77e4ea..5c68de184501 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-ek874.dtb
dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-ek874-idk-2121wr.dtb
dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-ek874-mipi-2.1.dtb
+dtb-$(CONFIG_ARCH_R8A774E1) += r8a774e1-beacon-rzg2h-kit.dtb
dtb-$(CONFIG_ARCH_R8A774E1) += r8a774e1-hihope-rzg2h.dtb
dtb-$(CONFIG_ARCH_R8A774E1) += r8a774e1-hihope-rzg2h-ex.dtb
dtb-$(CONFIG_ARCH_R8A774E1) += r8a774e1-hihope-rzg2h-ex-idk-1110wr.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
b/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
new file mode 100644
index ..273f062f2909
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020, Compass Electronics Group, LLC
+ */
+
+/dts-v1/;
+
+#include "r8a774e1.dtsi"
+#include "beacon-renesom-som.dtsi"
+#include "beacon-renesom-baseboard.dtsi"
+
+/ {
+ model = "Beacon Embedded Works RZ/G2H Development Kit";
+ compatible ="beacon,beacon-rzg2h", "renesas,r8a774e1";
+
+ aliases {
+ serial0 =
+ serial1 =
+ serial2 =
+ serial3 =
+ serial4 =
+ serial5 =
+ serial6 =
+ ethernet0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@5 {
+ device_type = "memory";
+ reg = <0x5 0x 0x0 0x8000>;
+ };
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ clocks = < CPG_MOD 724>,
+ < CPG_MOD 723>,
+ < CPG_MOD 721>,
+ < 1>,
+ <_clk>,
+ < 2>;
+ clock-names = "du.0", "du.1", "du.3",
+ "dclkin.0", "dclkin.1", "dclkin.3";
+};
+
+/* Reference versaclock instead of audio_clk_a */
+_sound {
+ clocks = < CPG_MOD 1005>,
+< CPG_MOD 1006>, < CPG_MOD 1007>,
+< CPG_MOD 1008>, < CPG_MOD 1009>,
+< CPG_MOD 1010>, < CPG_MOD 1011>,
+< CPG_MOD 1012>, < CPG_MOD 1013>,
+< CPG_MOD 1014>, < CPG_MOD 1015>,
+< CPG_MOD 1022>, < CPG_MOD 1023>,
+< CPG_MOD 1024>, < CPG_MOD 1025>,
+< CPG_MOD 1026>, < CPG_MOD 1027>,
+< CPG_MOD 1028>, < CPG_MOD 1029>,
+< CPG_MOD 1030>, < CPG_MOD 1031>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
+< CPG_MOD 1019>, < CPG_MOD 1018>,
+<_bb 4>, <_clk_b>,
+<_clk_c>,
+< CPG_CORE R8A774E1_CLK_S0D4>;
+};
--
2.25.1
[PATCH V2 4/9] arm64: dts: renesas: beacon: Better describe keys
The keys on the baseboard are laid out in an diamond pattern, up, down,
left, right and center. Update the descriptions to make it easier to
read.
Signed-off-by: Adam Ford
---
V2: Make keycode match the key name.
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index dc5e05d7a792..a54ec36c69e4 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -40,38 +40,38 @@ hdmi0_con: endpoint {
keys {
compatible = "gpio-keys";
- key-1 {
+ key-1 { /* S19 */
gpios = < 6 GPIO_ACTIVE_LOW>;
- linux,code = ;
- label = "Switch-1";
+ linux,code = ;
+ label = "Up";
wakeup-source;
debounce-interval = <20>;
};
- key-2 {
+ key-2 { /*S20 */
gpios = < 13 GPIO_ACTIVE_LOW>;
- linux,code = ;
- label = "Switch-2";
+ linux,code = ;
+ label = "Left";
wakeup-source;
debounce-interval = <20>;
};
- key-3 {
+ key-3 { /* S21 */
gpios = < 17 GPIO_ACTIVE_LOW>;
- linux,code = ;
- label = "Switch-3";
+ linux,code = ;
+ label = "Down";
wakeup-source;
debounce-interval = <20>;
};
- key-4 {
+ key-4 { /* S22 */
gpios = < 20 GPIO_ACTIVE_LOW>;
- linux,code = ;
- label = "Switch-4";
+ linux,code = ;
+ label = "Right";
wakeup-source;
debounce-interval = <20>;
};
- key-5 {
+ key-5 { /* S23 */
gpios = < 22 GPIO_ACTIVE_LOW>;
- linux,code = ;
- label = "Switch-4";
+ linux,code = ;
+ label = "Center";
wakeup-source;
debounce-interval = <20>;
};
--
2.25.1
[PATCH V2 7/9] arm64: dts: renesas: Introduce r8a774b1-beacon-rzg2n-kit
Beacon EmebeddedWorks is introducing a new kit based on the
RZ/G2N SoC from Renesas.
The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1
cellular radio.
The Baseboard has Ethernet, USB, HDMI, stereo audio in and out,
along with a variety of push buttons and LED's, and support for
a parallel RGB and an LVDS display. It uses the same baseboard
and SOM as the RZ/G2M.
This SOM has only 2GB of DDR, and beacon-renesom-som.dtsi contains
the base memory node, so an additional memory node isn't necessary.
Signed-off-by: Adam Ford
---
V2: Add missing du node entries.
diff --git a/arch/arm64/boot/dts/renesas/Makefile
b/arch/arm64/boot/dts/renesas/Makefile
index dffefe030a76..cf7e2f77e4ea 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -7,6 +7,7 @@ dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-rev2.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-rev2-ex.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-rev2-ex-idk-1110wr.dtb
+dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-beacon-rzg2n-kit.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex-idk-1110wr.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
b/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
new file mode 100644
index ..71763f4402a7
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020, Compass Electronics Group, LLC
+ */
+
+/dts-v1/;
+
+#include "r8a774b1.dtsi"
+#include "beacon-renesom-som.dtsi"
+#include "beacon-renesom-baseboard.dtsi"
+
+/ {
+ model = "Beacon Embedded Works RZ/G2N Development Kit";
+ compatible ="beacon,beacon-rzg2n", "renesas,r8a774b1";
+
+ aliases {
+ serial0 =
+ serial1 =
+ serial2 =
+ serial3 =
+ serial4 =
+ serial5 =
+ serial6 =
+ ethernet0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ clocks = < CPG_MOD 724>,
+ < CPG_MOD 723>,
+ < CPG_MOD 721>,
+ < 1>,
+ <_clk>,
+ < 2>;
+ clock-names = "du.0", "du.1", "du.3",
+ "dclkin.0", "dclkin.1", "dclkin.3";
+};
+
+/* Reference versaclock instead of audio_clk_a */
+_sound {
+ clocks = < CPG_MOD 1005>,
+< CPG_MOD 1006>, < CPG_MOD 1007>,
+< CPG_MOD 1008>, < CPG_MOD 1009>,
+< CPG_MOD 1010>, < CPG_MOD 1011>,
+< CPG_MOD 1012>, < CPG_MOD 1013>,
+< CPG_MOD 1014>, < CPG_MOD 1015>,
+< CPG_MOD 1022>, < CPG_MOD 1023>,
+< CPG_MOD 1024>, < CPG_MOD 1025>,
+< CPG_MOD 1026>, < CPG_MOD 1027>,
+< CPG_MOD 1028>, < CPG_MOD 1029>,
+< CPG_MOD 1030>, < CPG_MOD 1031>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
+< CPG_MOD 1019>, < CPG_MOD 1018>,
+<_bb 4>, <_clk_b>,
+<_clk_c>,
+< CPG_CORE R8A774B1_CLK_S0D4>;
+};
--
2.25.1
[PATCH V2 5/9] arm64: dts: renesas: beacon: Cleanup USB References
The programmable versaclock is used for the usb_extal reference clock for
the EHCI driver instead of a fixed-clock. Because the versaclock needs to
be enabled, the clock reference needs to be added to the clocks list.
For the USB3 Phy, the perferred clock reference is usb3s_clk, so
remove the usb_extal reference.
Signed-off-by: Adam Ford
---
V2: Split this off into its own patch.
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index a54ec36c69e4..3b3efaf749bb 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -263,12 +263,22 @@ _out_rgb {
{
dr_mode = "otg";
status = "okay";
- clocks = < CPG_MOD 703>, < CPG_MOD 704>;
+ clocks = < CPG_MOD 703>, < CPG_MOD 704>, < 3>;
};
{
status = "okay";
- clocks = < CPG_MOD 703>, < CPG_MOD 704>;
+ clocks = < CPG_MOD 702>, < 3>;
+};
+
+ {
+
+ usb_hub_reset {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "usb-hub-reset";
+ };
};
{
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index ade2f58ad99b..a6f7193e4d97 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -75,15 +75,6 @@ _clk {
clock-frequency = <32768>;
};
- {
- usb_hub_reset {
- gpio-hog;
- gpios = <10 GPIO_ACTIVE_HIGH>;
- output-high;
- line-name = "usb-hub-reset";
- };
-};
-
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -315,16 +306,12 @@ {
vmmc-supply = <_3p3v>;
vqmmc-supply = <_1p8v>;
bus-width = <8>;
- mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
non-removable;
fixed-emmc-driver-type = <1>;
status = "okay";
};
-_extal_clk {
- clock-frequency = <5000>;
-};
-
_clk {
clock-frequency = <1>;
};
--
2.25.1
[PATCH V2 3/9] arm64: dts: renesas: beacon: Configure Audio CODEC clocks
With the newly added configurable clock options, the audio CODEC can
configure the mclk automatically. Add the reference to the versaclock.
Since the devices on I2C5 can communicate at 400KHz, let's also increase
that too
Signed-off-by: Adam Ford
---
V2: Remove the un-used clock-names reference.
Base on:
https://patchwork.kernel.org/project/alsa-devel/patch/20201217162740.1452000-1-aford...@gmail.com/
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index 4e86d308d07e..dc5e05d7a792 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -385,13 +385,14 @@ {
{
status = "okay";
- clock-frequency = <10>;
+ clock-frequency = <40>;
pinctrl-0 = <_pins>;
pinctrl-names = "default";
codec: wm8962@1a {
compatible = "wlf,wm8962";
reg = <0x1a>;
+ clocks = <_bb 3>;
DCVDD-supply = <_audio>;
DBVDD-supply = <_audio>;
AVDD-supply = <_audio>;
--
2.25.1
[PATCH V2 2/9] arm64: dts: renesas: beacon kit: Fix Audio Clock sources
The SoC was expecting two clock sources with different frequencies.
One to support 44.1KHz and one to support 48KHz. With the newly added
ability to configure the programmably clock, configure both clocks.
Assign the rcar-sound clocks to reference the versaclock instead of
the fixed clock.
Signed-off-by: Adam Ford
---
V2: Go from fixed-factor-clock to just redefining the rcar-sound node
to reference the versaclock instead of the audio_clk_a.
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index 46a3ba895330..4e86d308d07e 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -223,12 +223,6 @@ x304_clk: x304-clock {
};
};
-_clk_a {
- clock-frequency = <24576000>;
- assigned-clocks = <_bb 4>;
- assigned-clock-rates = <24576000>;
-};
-
_clk_b {
clock-frequency = <22579200>;
};
@@ -574,7 +568,7 @@ sound_pins: sound {
};
sound_clk_pins: sound_clk {
- groups = "audio_clk_a_a";
+ groups = "audio_clk_a_a", "audio_clk_b_a";
function = "audio_clk";
};
@@ -625,23 +619,6 @@ _sound {
status = "okay";
- clocks = < CPG_MOD 1005>,
-< CPG_MOD 1006>, < CPG_MOD 1007>,
-< CPG_MOD 1008>, < CPG_MOD 1009>,
-< CPG_MOD 1010>, < CPG_MOD 1011>,
-< CPG_MOD 1012>, < CPG_MOD 1013>,
-< CPG_MOD 1014>, < CPG_MOD 1015>,
-< CPG_MOD 1022>, < CPG_MOD 1023>,
-< CPG_MOD 1024>, < CPG_MOD 1025>,
-< CPG_MOD 1026>, < CPG_MOD 1027>,
-< CPG_MOD 1028>, < CPG_MOD 1029>,
-< CPG_MOD 1030>, < CPG_MOD 1031>,
-< CPG_MOD 1020>, < CPG_MOD 1021>,
-< CPG_MOD 1020>, < CPG_MOD 1021>,
-< CPG_MOD 1019>, < CPG_MOD 1018>,
-<_clk_a>, <_clk_b>, <_clk_c>,
-< CPG_CORE R8A774A1_CLK_S0D4>;
-
ports {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
index 2c5b057c30c6..25eeac411f12 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
@@ -27,3 +27,24 @@ chosen {
stdout-path = "serial0:115200n8";
};
};
+
+/* Reference versaclock instead of audio_clk_a */
+_sound {
+ clocks = < CPG_MOD 1005>,
+< CPG_MOD 1006>, < CPG_MOD 1007>,
+< CPG_MOD 1008>, < CPG_MOD 1009>,
+< CPG_MOD 1010>, < CPG_MOD 1011>,
+< CPG_MOD 1012>, < CPG_MOD 1013>,
+< CPG_MOD 1014>, < CPG_MOD 1015>,
+< CPG_MOD 1022>, < CPG_MOD 1023>,
+< CPG_MOD 1024>, < CPG_MOD 1025>,
+< CPG_MOD 1026>, < CPG_MOD 1027>,
+< CPG_MOD 1028>, < CPG_MOD 1029>,
+< CPG_MOD 1030>, < CPG_MOD 1031>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
+< CPG_MOD 1020>, < CPG_MOD 1021>,
+< CPG_MOD 1019>, < CPG_MOD 1018>,
+<_bb 4>, <_clk_b>,
+<_clk_c>,
+< CPG_CORE R8A774A1_CLK_S0D4>;
+};
--
2.25.1
[PATCH V2 1/9] arm64: dts: renesas: beacon kit: Configure programmable clocks
When the board was added, clock drivers were being updated done at
the same time to allow the versaclock driver to properly configure
the modes. Unfortunately, the updates were not applied to the board
files at the time they should have been, so do it now.
Signed-off-by: Adam Ford
---
V2: Limit the changes to the versaclocks chips.
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index cc0e7ce8e503..46a3ba895330 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -5,6 +5,7 @@
#include
#include
+#include
/ {
backlight_lvds: backlight-lvds {
@@ -347,12 +348,36 @@ versaclock6_bb: clock-controller@6a {
#clock-cells = <1>;
clocks = <_clk>;
clock-names = "xin";
- /* CSI0_MCLK, CSI1_MCLK, AUDIO_CLKIN, USB_HUB_MCLK_BB */
+
assigned-clocks = <_bb 1>,
<_bb 2>,
<_bb 3>,
<_bb 4>;
assigned-clock-rates = <2400>, <2400>, <2400>,
<24576000>;
+
+ OUT1 {
+ idt,mode = ;
+ idt,voltage-microvolt = <180>;
+ idt,slew-percent = <100>;
+ };
+
+ OUT2 {
+ idt,mode = ;
+ idt,voltage-microvolt = <180>;
+ idt,slew-percent = <100>;
+ };
+
+ OUT3 {
+ idt,mode = ;
+ idt,voltage-microvolt = <330>;
+ idt,slew-percent = <100>;
+ };
+
+ OUT4 {
+ idt,mode = ;
+ idt,voltage-microvolt = <330>;
+ idt,slew-percent = <100>;
+ };
};
};
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index e6885d50bb62..ade2f58ad99b 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -4,6 +4,7 @@
*/
#include
+#include
/ {
memory@4800 {
@@ -169,7 +170,32 @@ versaclock5: versaclock_som@6a {
< 2>,
< 3>,
< 4>;
+
assigned-clock-rates = <>, <>, <5000>,
<12500>;
+
+ OUT1 {
+ idt,mode = ;
+ idt,voltage-microvolt = <180>;
+ idt,slew-percent = <100>;
+ };
+
+ OUT2 {
+ idt,mode = ;
+ idt,voltage-microvolt = <180>;
+ idt,slew-percent = <100>;
+ };
+
+ OUT3 {
+ idt,mode = ;
+ idt,voltage-microvolt = <180>;
+ idt,slew-percent = <100>;
+ };
+
+ OUT4 {
+ idt,mode = ;
+ idt,voltage-microvolt = <330>;
+ idt,slew-percent = <100>;
+ };
};
};
--
2.25.1
