[PATCH] drm/i915/adl_s: ADL-S platform Update PCI ids for Mobile BGA
As per Bspec: 53655 Update PCI ids for Mobile BGA. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Anand Moon diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index ebd0dd1c35b3..3be25768321d 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -640,6 +640,8 @@ INTEL_VGA_DEVICE(0x4681, info), \ INTEL_VGA_DEVICE(0x4682, info), \ INTEL_VGA_DEVICE(0x4683, info), \ + INTEL_VGA_DEVICE(0x4688, info), \ + INTEL_VGA_DEVICE(0x4689, info), \ INTEL_VGA_DEVICE(0x4690, info), \ INTEL_VGA_DEVICE(0x4691, info), \ INTEL_VGA_DEVICE(0x4692, info), \ -- 2.30.0
Re: [PATCH v2] ARM: dts: exynos: Add a placeholder for a MAC address
Hi Marek,
On Mon, 2 Nov 2020 at 21:53, Marek Szyprowski wrote:
>
> Hi Anand,
>
> On 01.11.2020 15:07, Anand Moon wrote:
> > Hi Lukasz,
> >
> > On Thu, 1 Oct 2020 at 19:25, Łukasz Stelmach wrote:
> >> Add a placeholder for a MAC address. A bootloader may fill it
> >> to set the MAC address and override EEPROM settings.
> >>
> >> Signed-off-by: Łukasz Stelmach
> >> ---
> >> Changes in v2:
> >> - use local-mac-address and leave mac-address to be added by a bootloader
> >>
> >> arch/arm/boot/dts/exynos5422-odroidxu3.dts | 18 ++
> >> 1 file changed, 18 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> index db0bc17a667b..d0f6ac5fa79d 100644
> >> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> >> @@ -70,3 +70,21 @@ {
> >> _dwc3_1 {
> >> dr_mode = "peripheral";
> >> };
> >> +
> >> + {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + hub@1 {
> >> + compatible = "usb8087,0024";
> >> + reg = <1>;
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + ethernet: usbether@1 {
> >> + compatible = "usb0c45,6310";
> >> + reg = <1>;
> >> + local-mac-address = [00 00 00 00 00 00]; /* Filled
> >> in by a bootloader */
> >> + };
> >> + };
> >> +};
> >> --
> >> 2.26.2
> >>
> > Thanks for this patch, can you share some example on how to set the
> > mac address via u-boot bootargs
>
> A little bit hacky script to set permanent board unique MAC address:
>
> # setexp.b u0 *0x1014; setexp.b u1 *0x1015; setexp.b u2
> *0x1016; setexp.b u3 *0x1017; setenv ethaddr
> 0:0:${u0}:${u1}:${u2}:${u3}; setenv usbethaddr ${ethaddr};
>
OK this command worked for me.
> Then if there is proper ethernet0 alias set, u-boot will then
> automatically save the configured MAC address to the device tree. I've
> just check this on recent u-boot v2020.10 and Odroid U3 board.
>
> Lukasz will send updated patch soon (with proper alias entry).
>
> If you want to hack setting MAC address manually, this will work with
> the current patch:
>
> # setexp.b u0 *0x1014; setexp.b u1 *0x1015; setexp.b u2
> *0x1016; setexp.b u3 *0x1017; fdt addr ${fdtaddr}; fdt set
> /soc/usb@1211/hub@1/usbether@1 local-mac-address [ 0 0 ${u0} ${u1}
> ${u2} ${u3} ]
>
So do we need a similar patch for u-boot ?
I am getting following error on Odroid U3+ and U-Boot 2020.10
Odroid # setexp.b u0 *0x1014; setexp.b u1 *0x1015; setexp.b
u2 *0x1016; setexp.b u3 *0x1017; fdt addr ${fdtaddr}; fdt set
/soc/usb@1211/hub@1/usbether@1 local-mac-address [ 0 0 ${u0} ${u1}
${u2} ${u3} ]
No FDT memory address configured. Please configure
the FDT address via "fdt addr " command.
Aborting!
Also added these command to boot.scr but still observing the failure
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
969 bytes read in 5 ms (188.5 KiB/s)
## Executing script at 4200
7341440 bytes read in 265 ms (26.4 MiB/s)
53875 bytes read in 56 ms (939.5 KiB/s)
7964187 bytes read in 285 ms (26.6 MiB/s)
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
Kernel image @ 0x4100 [ 0x00 - 0x700580 ]
## Flattened Device Tree blob at 4080
Booting using the fdt blob at 0x4080
Loading Ramdisk to 4f867000, end 461b ... OK
Loading Device Tree to 4f856000, end 4f866272 ... OK
,
Best Regards
-Anand
> > also can you update this patch for exynos5422-odroidxu3-lite.dts and
> > exynos4412-odroidu3.dts.
>
> Also odroid-x2 and odroid-xu. Lukasz will take care of them.
>
> Best regards
>
> --
> Marek Szyprowski, PhD
> Samsung R Institute Poland
>
Re: [PATCH v2] ARM: dts: exynos: Add a placeholder for a MAC address
Hi Lukasz,
On Thu, 1 Oct 2020 at 19:25, Łukasz Stelmach wrote:
>
> Add a placeholder for a MAC address. A bootloader may fill it
> to set the MAC address and override EEPROM settings.
>
> Signed-off-by: Łukasz Stelmach
> ---
> Changes in v2:
> - use local-mac-address and leave mac-address to be added by a bootloader
>
> arch/arm/boot/dts/exynos5422-odroidxu3.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> index db0bc17a667b..d0f6ac5fa79d 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -70,3 +70,21 @@ {
> _dwc3_1 {
> dr_mode = "peripheral";
> };
> +
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hub@1 {
> + compatible = "usb8087,0024";
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet: usbether@1 {
> + compatible = "usb0c45,6310";
> + reg = <1>;
> + local-mac-address = [00 00 00 00 00 00]; /* Filled in
> by a bootloader */
> + };
> + };
> +};
> --
> 2.26.2
>
Thanks for this patch, can you share some example on how to set the
mac address via u-boot bootargs
also can you update this patch for exynos5422-odroidxu3-lite.dts and
exynos4412-odroidu3.dts.
Best Regards
-Anand
Re: [PATCH] clk: meson: g12a: mark fclk_div2 as critical
Hi Stefan,
On Fri, 28 Aug 2020 at 03:14, Stefan Agner wrote:
>
> On Amlogic Meson G12b platform, similar to fclk_div3, the fclk_div2
> seems to be necessary for the system to operate correctly as well.
>
> Typically, the clock also gets chosen by the eMMC peripheral. This
> probably masked the problem so far. However, when booting from a SD
> card the clock seems to get disabled which leads to a system freeze.
>
> Let's mark this clock as critical, fixing boot from SD card on G12b
> platforms.
>
> Signed-off-by: Stefan Agner
> ---
Thank you for this patch. I reported this a long time ago but could
not solve it.
Please add my
Tested-by: Anand Moon
> drivers/clk/meson/g12a.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
> index fad616cac01e..2214b974f748 100644
> --- a/drivers/clk/meson/g12a.c
> +++ b/drivers/clk/meson/g12a.c
> @@ -298,6 +298,7 @@ static struct clk_regmap g12a_fclk_div2 = {
> _fclk_div2_div.hw
> },
> .num_parents = 1,
> + .flags = CLK_IS_CRITICAL,
> },
> };
>
> --
> 2.28.0
>
>
> ___
> linux-amlogic mailing list
> linux-amlo...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
[PATCH v5] phy: samsung: Use readl_poll_timeout function
Instead of a busy waiting while loop using udelay
use readl_poll_timeout function to check the condition
is met or timeout occurs in crport_handshake function.
readl_poll_timeout is called in non atomic context so
it safe to sleep until the condition is met.
Signed-off-by: Anand Moon
---
Changes v5:
--Fix the indentation, checkpatch warning.
--Drop the Fix tags.
Changes v4:
Rebased on to of patch [0] https://patchwork.kernel.org/patch/11651673/
--Fix the commit message.
--Fix the error timeout condition for -ETIMEDOUT
Changes v3:
--Fix the commit message.
--Drop the variable, used the value directly.
Changes v2:
--used the default timeout values.
--Added missing Fixed tags.
---
drivers/phy/samsung/phy-exynos5-usbdrd.c | 39
1 file changed, 12 insertions(+), 27 deletions(-)
diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index 7f6279fb4f8f..c45ed9cabc5e 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -556,41 +557,25 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
u32 val, u32 cmd)
{
- u32 usec = 100;
unsigned int result;
+ int err;
writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (result & PHYREG1_CR_ACK)
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout1 (0x%08x)\n", val);
- return -ETIME;
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+result, (result & PHYREG1_CR_ACK), 1, 100);
+ if (err == -ETIMEDOUT) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout1 (0x%08x)\n",
val);
+ return err;
}
- usec = 100;
-
writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (!(result & PHYREG1_CR_ACK))
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout2 (0x%08x)\n", val);
- return -ETIME;
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+result, !(result & PHYREG1_CR_ACK), 1, 100);
+ if (err == -ETIMEDOUT) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout2 (0x%08x)\n",
val);
+ return err;
}
return 0;
--
2.27.0
Re: [PATCH v4] phy: samsung: Use readl_poll_timeout function
Hi Krzysztof,
On Mon, 20 Jul 2020 at 13:20, Krzysztof Kozlowski wrote:
>
> On Mon, Jul 13, 2020 at 07:42:43AM +, Anand Moon wrote:
> > Instead of a busy waiting while loop using udelay
> > use readl_poll_timeout function to check the condition
> > is met or timeout occurs in crport_handshake function.
> > readl_poll_timeout is called in non atomic context so
> > it safe to sleep until the condition is met.
> >
> > Fixes: d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
> > exynos5420/5800")
>
> There is no bug in original code so Fixes tag is not appropriate. Remove
> it please.
>
Thanks for your review. Ok I will do that.
> Best regards,
> Krzysztof
>
-Anand
> > Signed-off-by: Anand Moon
> > ---
> > Changes v4:
> > Rebased on to of patch [0] https://patchwork.kernel.org/patch/11651673/
> > --Fix the commit message.
> > --Fix the error timeout condition for -ETIMEDOUT
> > ---
> > Changes v3:
> > --Fix the commit message.
> > --Drop the variable, used the value directly.
> > Changes v2:
> > --used the default timeout values.
> > --Added missing Fixed tags.
> > ---
> > drivers/phy/samsung/phy-exynos5-usbdrd.c | 39
> > 1 file changed, 12 insertions(+), 27 deletions(-)
> >
Re: [PATCH v4] phy: samsung: Use readl_poll_timeout function
Hi Vinod,
On Thu, 16 Jul 2020 at 11:20, Vinod Koul wrote:
>
> On 13-07-20, 07:42, Anand Moon wrote:
> > Instead of a busy waiting while loop using udelay
> > use readl_poll_timeout function to check the condition
> > is met or timeout occurs in crport_handshake function.
> > readl_poll_timeout is called in non atomic context so
> > it safe to sleep until the condition is met.
> >
> > Fixes: d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
> > exynos5420/5800")
> > Signed-off-by: Anand Moon
> > ---
> > Changes v4:
> > Rebased on to of patch [0] https://patchwork.kernel.org/patch/11651673/
> > --Fix the commit message.
> > --Fix the error timeout condition for -ETIMEDOUT
> > ---
> > Changes v3:
> > --Fix the commit message.
> > --Drop the variable, used the value directly.
> > Changes v2:
> > --used the default timeout values.
> > --Added missing Fixed tags.
> > ---
> > drivers/phy/samsung/phy-exynos5-usbdrd.c | 39
> > 1 file changed, 12 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > index 7f6279fb4f8f..ad81aa65cdff 100644
> > --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -556,41 +557,25 @@ static int exynos5_usbdrd_phy_power_off(struct phy
> > *phy)
> > static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
> > u32 val, u32 cmd)
> > {
> > - u32 usec = 100;
> > unsigned int result;
> > + int err;
> >
> > writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
> >
> > - do {
> > - result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
> > - if (result & PHYREG1_CR_ACK)
> > - break;
> > -
> > - udelay(1);
> > - } while (usec-- > 0);
> > -
> > - if (!usec) {
> > - dev_err(phy_drd->dev,
> > - "CRPORT handshake timeout1 (0x%08x)\n", val);
> > - return -ETIME;
> > + err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
> > + result, (result & PHYREG1_CR_ACK), 1, 100);
>
> pls align this line to opening brace of preceding line:
>
> err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
> result, (result & PHYREG1_CR_ACK), 1, 100);
>
> This is recommended way of splitting lines, see
> Documentation/process/coding-style.rst and run checkpatch.pl with
> --strict option
Ok, I will do this, just waiting for some more feedback on these changes.
>
> thanks
> --
> ~Vinod
-Anand
[PATCH v4] phy: samsung: Use readl_poll_timeout function
Instead of a busy waiting while loop using udelay
use readl_poll_timeout function to check the condition
is met or timeout occurs in crport_handshake function.
readl_poll_timeout is called in non atomic context so
it safe to sleep until the condition is met.
Fixes: d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
exynos5420/5800")
Signed-off-by: Anand Moon
---
Changes v4:
Rebased on to of patch [0] https://patchwork.kernel.org/patch/11651673/
--Fix the commit message.
--Fix the error timeout condition for -ETIMEDOUT
---
Changes v3:
--Fix the commit message.
--Drop the variable, used the value directly.
Changes v2:
--used the default timeout values.
--Added missing Fixed tags.
---
drivers/phy/samsung/phy-exynos5-usbdrd.c | 39
1 file changed, 12 insertions(+), 27 deletions(-)
diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index 7f6279fb4f8f..ad81aa65cdff 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -556,41 +557,25 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
u32 val, u32 cmd)
{
- u32 usec = 100;
unsigned int result;
+ int err;
writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (result & PHYREG1_CR_ACK)
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout1 (0x%08x)\n", val);
- return -ETIME;
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+ result, (result & PHYREG1_CR_ACK), 1, 100);
+ if (err == -ETIMEDOUT) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout1 (0x%08x)\n",
val);
+ return err;
}
- usec = 100;
-
writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (!(result & PHYREG1_CR_ACK))
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout2 (0x%08x)\n", val);
- return -ETIME;
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+ result, !(result & PHYREG1_CR_ACK), 1, 100);
+ if (err == -ETIMEDOUT) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout2 (0x%08x)\n",
val);
+ return err;
}
return 0;
--
2.27.0
Re: [PATCH v3] phy: samsung: Use readl_poll_timeout function
Hi Krzysztof,
On Tue, 7 Jul 2020 at 17:06, Krzysztof Kozlowski wrote:
>
> On Tue, Jul 07, 2020 at 09:59:08AM +, Anand Moon wrote:
> > Instead of a busy waiting loop while loop using udelay
>
> You doubled "loop".
>
I will fix this in the next version.
> > use readl_poll_timeout function to check the condition
> > is met or timeout occurs in crport_handshake function.
>
> Still you did not mention that you convert the function to use sleeping
> primitive. You also did not mention whether it is actually allowed in
> this context and I am not sure if you investigated it.
>
OK, I am not sure how to resolve your query.
I learned some new things.
So here are some points.
-- Yes read_poll_timeout internally used might_sleep if sleep_us != 0
under some condition.
-- None of the code in phy-exynos5-usbdrd.c is called using kernel
synchronization
methods like spinlock / mutex.
-- I have checked this function is called non atomic context.
see below.
[6.006395] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.013042] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.019646] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.026174] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.032699] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.039246] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.045707] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.052276] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.058760] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.065189] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.071631] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.078033] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.084433] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.090812] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.097102] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.103413] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.109670] exynos5_usb3drd_phy 1250.phy: Not In atomic context
[6.115871] exynos5_usb3drd_phy 1250.phy: Not In atomic context
> Best regards,
> Krzysztof
>
> >
> > Fixes: d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
> > exynos5420/5800")
> > Signed-off-by: Anand Moon
> > ---
> > Changes v3:
> > --Fix the commit message.
> > --Drop the variable, used the value directly.
> > Changes v2:
> > --used the default timeout values.
> > --Added missing Fixed tags.
> > ---
> > drivers/phy/samsung/phy-exynos5-usbdrd.c | 35 +++-
> > 1 file changed, 10 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > index e510732afb8b..fa75fa88da33 100644
> > --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -556,40 +557,24 @@ static int exynos5_usbdrd_phy_power_off(struct phy
> > *phy)
> > static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
> > u32 val, u32 cmd)
> > {
> > - u32 usec = 100;
> > unsigned int result;
> > + int err;
> >
> > writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
> >
> > - do {
> > - result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
> > - if (result & PHYREG1_CR_ACK)
> > - break;
> > -
> > - udelay(1);
> > - } while (usec-- > 0);
> > -
> > - if (!usec) {
> > - dev_err(phy_drd->dev,
> > - "CRPORT handshake timeout1 (0x%08x)\n", val);
> > + err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
> > + result, (result & PHYREG1_CR_ACK), 1, 100);
> > + if (err) {
> > + dev_err(phy_drd->dev, "CRPORT handshake timeout1 (0x%08x)\n",
> > val);
> > return -ETIME;
Here return should be -ETIMEDOUT;
> > }
> >
> > - usec = 100;
> > -
> > writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
> >
> > - do {
> > - result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
> > - if (!(result & PHYREG1_CR_ACK))
> > - break;
[PATCH v3] phy: samsung: Use readl_poll_timeout function
Instead of a busy waiting loop while loop using udelay
use readl_poll_timeout function to check the condition
is met or timeout occurs in crport_handshake function.
Fixes: d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
exynos5420/5800")
Signed-off-by: Anand Moon
---
Changes v3:
--Fix the commit message.
--Drop the variable, used the value directly.
Changes v2:
--used the default timeout values.
--Added missing Fixed tags.
---
drivers/phy/samsung/phy-exynos5-usbdrd.c | 35 +++-
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index e510732afb8b..fa75fa88da33 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -556,40 +557,24 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
u32 val, u32 cmd)
{
- u32 usec = 100;
unsigned int result;
+ int err;
writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (result & PHYREG1_CR_ACK)
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout1 (0x%08x)\n", val);
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+ result, (result & PHYREG1_CR_ACK), 1, 100);
+ if (err) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout1 (0x%08x)\n",
val);
return -ETIME;
}
- usec = 100;
-
writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (!(result & PHYREG1_CR_ACK))
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout2 (0x%08x)\n", val);
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+ result, !(result & PHYREG1_CR_ACK), 1, 100);
+ if (err) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout2 (0x%08x)\n",
val);
return -ETIME;
}
--
2.27.0
Re: [PATCH v2] phy: samsung: Use readl_poll_timeout function
Hi Krzysztof,
Thanks for your review comments.
On Sun, 5 Jul 2020 at 23:32, Krzysztof Kozlowski wrote:
>
> On Sun, Jul 05, 2020 at 06:04:35AM +, Anand Moon wrote:
> > User readl_poll_timeout function instead of open
> > coded handling in crport_handshake function.
>
> Your change does not replace only the "open coded handling" with
> readl_poll_timeout(). Your change does more - switches busy waiting with
> udelay to a sleeping mode. I am not sure if it is correct but definitly
> it should be mentioned. Otherwise how can we be sure that you checked
> if this is allowed in this section? Did you test everything with
> DEBUG_ATOMIC_SLEEP?
Yes this DEBUG_ATOMIC_SLEEP is enabled in exynos_defconfig.
>
Ok how about the below commit message.
Instead of a busy waiting loop while loop using udelay use readl_poll_timeout
function to check the condition is met or timeout occurs in
crport_handshake function.
> >
> > Fixes: d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
> > exynos5420/5800")
> > Signed-off-by: Anand Moon
> > ---
> > Changes v2:
> > --used the default timeout values.
> > --Added missing Fixed tags.
> > ---
> > drivers/phy/samsung/phy-exynos5-usbdrd.c | 37 +---
> > 1 file changed, 13 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > index e510732afb8b..c97f5fb6a9a0 100644
> > --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -556,40 +557,28 @@ static int exynos5_usbdrd_phy_power_off(struct phy
> > *phy)
> > static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
> > u32 val, u32 cmd)
> > {
> > - u32 usec = 100;
> > + u32 timeout_us = 100, sleep_us = 1;
>
> No need for the variables actually and their type does not match. Just
> use the values directly.
Ok thanks
>
> > unsigned int result;
> > + int err;
> >
> > writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
> >
> > - do {
> > - result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
> > - if (result & PHYREG1_CR_ACK)
> > - break;
> > -
> > - udelay(1);
> > - } while (usec-- > 0);
> > -
> > - if (!usec) {
> > - dev_err(phy_drd->dev,
> > - "CRPORT handshake timeout1 (0x%08x)\n", val);
> > + err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
> > + result, (result & PHYREG1_CR_ACK), sleep_us,
> > timeout_us);
> > + if (err) {
> > + dev_err(phy_drd->dev, "CRPORT handshake timeout1 (0x%08x)\n",
> > val);
> > return -ETIME;
> > }
> >
> > - usec = 100;
> > + timeout_us = 100;
> > + sleep_us = 1;
>
> Why defining then again?
I had removed this in this but last minute I added this code again.
>
> Best regards,
> Krzysztof
>
Best Regards
-Anand
[PATCH v2] phy: samsung: Use readl_poll_timeout function
User readl_poll_timeout function instead of open
coded handling in crport_handshake function.
Fixes: d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
exynos5420/5800")
Signed-off-by: Anand Moon
---
Changes v2:
--used the default timeout values.
--Added missing Fixed tags.
---
drivers/phy/samsung/phy-exynos5-usbdrd.c | 37 +---
1 file changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index e510732afb8b..c97f5fb6a9a0 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -556,40 +557,28 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
u32 val, u32 cmd)
{
- u32 usec = 100;
+ u32 timeout_us = 100, sleep_us = 1;
unsigned int result;
+ int err;
writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (result & PHYREG1_CR_ACK)
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout1 (0x%08x)\n", val);
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+ result, (result & PHYREG1_CR_ACK), sleep_us,
timeout_us);
+ if (err) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout1 (0x%08x)\n",
val);
return -ETIME;
}
- usec = 100;
+ timeout_us = 100;
+ sleep_us = 1;
writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (!(result & PHYREG1_CR_ACK))
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout2 (0x%08x)\n", val);
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+ result, !(result & PHYREG1_CR_ACK), sleep_us,
timeout_us);
+ if (err) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout2 (0x%08x)\n",
val);
return -ETIME;
}
--
2.27.0
Re: [PATCH] phy: samsung: Use readl_poll_timeout function
hi Krzysztof,
On Fri, 3 Jul 2020 at 22:13, Krzysztof Kozlowski wrote:
>
> On Fri, Jul 03, 2020 at 01:20:12PM +, Anand Moon wrote:
> > User readl_poll_timeout function instead of open
> > coded handling in crport_handshake function.
> >
> > Signed-off-by: Anand Moon
> > ---
> > drivers/phy/samsung/phy-exynos5-usbdrd.c | 37 +---
> > 1 file changed, 13 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > index e510732afb8b..83274c5e3820 100644
> > --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -556,40 +557,28 @@ static int exynos5_usbdrd_phy_power_off(struct phy
> > *phy)
> > static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
> > u32 val, u32 cmd)
> > {
> > - u32 usec = 100;
> > + u32 timeout_us = 1000, sleep_us = 10;
> > unsigned int result;
>
> You silently (without mentioning in commit msg and explaining why)
> changed both the sleep time and total timeout.
>
Ok I will stick with the original default value.
timeout_us = 100, sleep_us = 1;
> Nope, please explain why you chosen such values and change them in
> separate patch..
I choose these values following Alim Akhtar's UFS PHY patches.
>
> > + int err;
> >
> > writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
> >
> > - do {
> > - result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
> > - if (result & PHYREG1_CR_ACK)
> > - break;
> > -
> > - udelay(1);
> > - } while (usec-- > 0);
> > -
> > - if (!usec) {
> > - dev_err(phy_drd->dev,
> > - "CRPORT handshake timeout1 (0x%08x)\n", val);
> > + err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
> > + result, (result & PHYREG1_CR_ACK), sleep_us,
> > timeout_us);
> > + if (err) {
> > + dev_err(phy_drd->dev, "CRPORT handshake timeout1 (0x%08x)\n",
> > val);
> > return -ETIME;
> > }
> >
> > - usec = 100;
> > + timeout_us = 1000;
> > + sleep_us = 10;
>
> The same.
>
> Best regards,
> Krzysztof
>
Best regards,
-Anand
[PATCH] phy: samsung: Use readl_poll_timeout function
User readl_poll_timeout function instead of open
coded handling in crport_handshake function.
Signed-off-by: Anand Moon
---
drivers/phy/samsung/phy-exynos5-usbdrd.c | 37 +---
1 file changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index e510732afb8b..83274c5e3820 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -556,40 +557,28 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
u32 val, u32 cmd)
{
- u32 usec = 100;
+ u32 timeout_us = 1000, sleep_us = 10;
unsigned int result;
+ int err;
writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (result & PHYREG1_CR_ACK)
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout1 (0x%08x)\n", val);
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+ result, (result & PHYREG1_CR_ACK), sleep_us,
timeout_us);
+ if (err) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout1 (0x%08x)\n",
val);
return -ETIME;
}
- usec = 100;
+ timeout_us = 1000;
+ sleep_us = 10;
writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (!(result & PHYREG1_CR_ACK))
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout2 (0x%08x)\n", val);
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+ result, !(result & PHYREG1_CR_ACK), sleep_us,
timeout_us);
+ if (err) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout2 (0x%08x)\n",
val);
return -ETIME;
}
--
2.27.0
[PATCH] Revert "usb: dwc3: exynos: Add support for Exynos5422 suspend clk"
This reverts commit 07f6842341abe978e6375078f84506ec3280ece5.
Since SCLK_SCLK_USBD300 suspend clock need to be configured
for phy module, I wrongly mapped this clock to DWC3 code.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Signed-off-by: Anand Moon
---
drivers/usb/dwc3/dwc3-exynos.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 48b68b6f0dc8..90bb022737da 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -162,12 +162,6 @@ static const struct dwc3_exynos_driverdata
exynos5250_drvdata = {
.suspend_clk_idx = -1,
};
-static const struct dwc3_exynos_driverdata exynos5420_drvdata = {
- .clk_names = { "usbdrd30", "usbdrd30_susp_clk"},
- .num_clks = 2,
- .suspend_clk_idx = 1,
-};
-
static const struct dwc3_exynos_driverdata exynos5433_drvdata = {
.clk_names = { "aclk", "susp_clk", "pipe_pclk", "phyclk" },
.num_clks = 4,
@@ -184,9 +178,6 @@ static const struct of_device_id exynos_dwc3_match[] = {
{
.compatible = "samsung,exynos5250-dwusb3",
.data = _drvdata,
- }, {
- .compatible = "samsung,exynos5420-dwusb3",
- .data = _drvdata,
}, {
.compatible = "samsung,exynos5433-dwusb3",
.data = _drvdata,
--
2.27.0
Re: [PATCH 1/3] ARM: dts: meson: add the SDHC MMC controller
Hi Martin,
On Sat, 20 Jun 2020 at 22:07, Martin Blumenstingl
wrote:
>
> Meson6, Meson8, Meson8b and Meson8m2 are using a similar SDHC controller
> IP which typically connects to an eMMC chip (because unlike the SDIO
> controller the SDHC controller has an 8-bit bus interface).
>
> On Meson8, Meson8b and Meson8m2 the clock inputs are all the same.
> However, Meson8m2 seems to have an improved version of the SHDC
> controller IP which doesn't require the driver to wait manually for a
> flush of a DMA transfer. Thus every SoC has it's own compatible string
> so if more difference are discovered they can be implemented.
>
> Signed-off-by: Martin Blumenstingl
Please add my
Reviewed-by: Anand Moon
-Anand
> ---
> arch/arm/boot/dts/meson.dtsi| 7 +++
> arch/arm/boot/dts/meson8.dtsi | 19 +++
> arch/arm/boot/dts/meson8b.dtsi | 20
> arch/arm/boot/dts/meson8m2.dtsi | 4
> 4 files changed, 50 insertions(+)
>
> diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
> index ae89deaa8c9c..464057989572 100644
> --- a/arch/arm/boot/dts/meson.dtsi
> +++ b/arch/arm/boot/dts/meson.dtsi
> @@ -140,6 +140,13 @@ spifc: spi@8c80 {
> status = "disabled";
> };
>
> + sdhc: mmc@8e00 {
> + compatible = "amlogic,meson-mx-sdhc";
> + reg = <0x8e00 0x42>;
> + interrupts = IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
> + };
> +
> gpio_intc: interrupt-controller@9880 {
> compatible = "amlogic,meson-gpio-intc";
> reg = <0x9880 0x10>;
> diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
> index 3d0ab2ac5332..04688e8abce2 100644
> --- a/arch/arm/boot/dts/meson8.dtsi
> +++ b/arch/arm/boot/dts/meson8.dtsi
> @@ -384,6 +384,15 @@ mux {
> };
> };
>
> + sdxc_b_pins: sdxc-b {
> + mux {
> + groups = "sdxc_d0_b", "sdxc_d13_b",
> +"sdxc_clk_b", "sdxc_cmd_b";
> + function = "sdxc_b";
> + bias-pull-up;
> + };
> + };
> +
> spi_nor_pins: nor {
> mux {
> groups = "nor_d", "nor_q", "nor_c", "nor_cs";
> @@ -558,6 +567,16 @@ {
> nvmem-cell-names = "temperature_calib";
> };
>
> + {
> + compatible = "amlogic,meson8-sdhc", "amlogic,meson-mx-sdhc";
> + clocks = <>,
> +< CLKID_FCLK_DIV4>,
> +< CLKID_FCLK_DIV3>,
> +< CLKID_FCLK_DIV5>,
> +< CLKID_SDHC>;
> + clock-names = "clkin0", "clkin1", "clkin2", "clkin3", "pclk";
> +};
> +
> {
> compatible = "amlogic,meson8-sdio", "amlogic,meson-mx-sdio";
> clocks = < CLKID_SDIO>, < CLKID_CLK81>;
> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> index 2069c57343e5..2401cdf5f751 100644
> --- a/arch/arm/boot/dts/meson8b.dtsi
> +++ b/arch/arm/boot/dts/meson8b.dtsi
> @@ -363,6 +363,16 @@ mux {
> };
> };
>
> + sdxc_c_pins: sdxc-c {
> + mux {
> + groups = "sdxc_d0_c", "sdxc_d13_c",
> +"sdxc_d47_c", "sdxc_clk_c",
> +"sdxc_cmd_c";
> + function = "sdxc_c";
> + bias-pull-up;
> + };
> + };
> +
> pwm_c1_pins: pwm-c1 {
> mux {
> groups = "pwm_c1";
> @@ -554,6 +564,16 @@ {
> nvmem-cell-names = "temperature_calib";
> };
>
> + {
> + compatible = "amlogic,meson8-sdhc", "amlogic,meson-mx-sdhc";
> + clocks = <>,
> +< CLKID_FCLK_DIV4>,
> +< CLKID_FCLK_DIV3>,
> +&
Re: [PATCH 3/3] ARM: dts: meson8b: odroidc1: enable the SDHC controller
Hi Martin,
On Sat, 20 Jun 2020 at 22:08, Martin Blumenstingl
wrote:
>
> Odroid-C1 has an eMMC connector where users can optionally install an
> eMMC module. The eMMC modules run off a 1.8V VQMMC supply which means
> that HS-200 mode can be used (this is the highest mode that the SDHC
> controller supports). Enable the SDHC controller so eMMC modules can be
> accessed.
>
> Signed-off-by: Martin Blumenstingl
Please add my
Reviewed-by: Anand Moon
-Anand
> ---
> arch/arm/boot/dts/meson8b-odroidc1.dts | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/meson8b-odroidc1.dts
> b/arch/arm/boot/dts/meson8b-odroidc1.dts
> index cb21ac9f517c..0c26467de4d0 100644
> --- a/arch/arm/boot/dts/meson8b-odroidc1.dts
> +++ b/arch/arm/boot/dts/meson8b-odroidc1.dts
> @@ -15,6 +15,7 @@ / {
> aliases {
> serial0 = _AO;
> mmc0 = _card_slot;
> + mmc1 =
> };
>
> chosen {
> @@ -26,6 +27,11 @@ memory {
> reg = <0x4000 0x4000>;
> };
>
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
> + };
> +
> leds {
> compatible = "gpio-leds";
> blue {
> @@ -310,6 +316,26 @@ {
> vref-supply = <_1v8>;
> };
>
> + {
> + status = "okay";
> +
> + pinctrl-0 = <_c_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <8>;
> + max-frequency = <1>;
> +
> + disable-wp;
> + cap-mmc-highspeed;
> + mmc-hs200-1_8v;
> + no-sdio;
> +
> + mmc-pwrseq = <_pwrseq>;
> +
> + vmmc-supply = <_3v3>;
> + vqmmc-supply = <_1v8>;
> +};
> +
> {
> status = "okay";
>
> --
> 2.27.0
>
>
> ___
> linux-amlogic mailing list
> linux-amlo...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Hi Neil,
On Mon, 21 Oct 2019 at 19:55, Neil Armstrong wrote:
>
> Hi Anand,
>
> On 21/10/2019 16:11, Anand Moon wrote:
> > Hi Martin,
> >
> > On Fri, 18 Oct 2019 at 23:40, Martin Blumenstingl
> > wrote:
> >>
> >> Hi Anand,
> >>
> >> On Fri, Oct 18, 2019 at 4:04 PM Anand Moon wrote:
> >> [...]
> >>>> Next step it to try narrow down the clock causing the issue.
> >>>> Remove clk_ignore_unused from the command line and add CLK_INGORE_UNUSED
> >>>> to the flag of some clocks your clock controller (g12a I think) until
> >>>>
> >>>> The peripheral clock gates already have this flag (something we should
> >>>> fix someday) so don't bother looking there.
> >>>>
> >>>> Most likely the source of the pwm is getting disabled between the
> >>>> late_init call and the probe of the PWM module. Since the pwm is already
> >>>> active (w/o a driver), gating the clock source shuts dowm the power to
> >>>> the cores.
> >>>>
> >>>> Looking a the possible inputs in pwm driver, I'd bet on fdiv4.
> >>>>
> >>>
> >>> I had give this above steps a try but with little success.
> >>> I am still looking into this much close.
> >> it's not clear to me if you have only tested with the PWM and/or
> >> FCLK_DIV4 clocks. can you please describe what you have tested so far?
> >>
> > Sorry for delayed response.
> >
> > I had just looked into clk related to SD_EMMC_A/B/C,
> > with adding CLK_IGNORE/CRITICAL.
> > Also looked into clk_summary for eMMC and microSD card,
> > to identify the root cause, but I failed to move ahead.
> >
> >> for reference - my way of debugging this in the past was:
> >> 1. add some printks to clk_disable_unused_subtree (right after the
> >> clk_core_is_enabled check) to see which clocks are being disabled
> >> 2. add CLK_IGNORE_UNUSED or CLK_IS_CRITICAL to the clocks which are
> >> being disabled based on the information from step #1
> >> 3. (at some point I had a working kernel with lots of clocks with
> >> CLK_IGNORE_UNUSED/CLK_IS_CRITICAL)
> >> 4. start dropping the CLK_IGNORE_UNUSED/CLK_IS_CRITICAL flags again
> >> until you have traced it down to the clocks that are the actual issue
> >> (so far I always had only one clock which caused issues, but it may be
> >> multiple)
> >> 5. investigate (and/or ask on the mailing list, Amlogic developers are
> >> reading the mails here as well) for the few clocks from step #4
> >>
> >
> > Thanks for you valuable suggestion. I have your patch to debug this
> > [0] https://patchwork.kernel.org/patch/9725921/mbox/
> >
> > So from the fist step I could identify that all the clk were getting closed
> > after some core cpu clk was failing. Here is the log.
> >
> > step1: [1] https://pastebin.com/p13F9HGG
> >
> > so I marked these clk as CLK_IGNORE_UNUSED and finally
> > I made it to boot using microSD card.
> >
> > After this just I converted these CLK to CLK_IS_CRITICAL
> > as mostly these are used the CPU clk for now.
> > Here is boot log successful for as of now.
> >
> > Finally: [2] https://pastebin.com/qB6pMyGQ
> >
> > I know clk maintainer are against marking flags as *CLK_IS_CRITICAL*
> > But this is just the step to move ahead.
>
> Thanks for the extensive debug.
>
> >
> > Attach is my local clk and dts patch.Just for testing.
> > [3] clk_critical.patch
>
>
> Could you test with only the following changes:
> diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
> index ea4c791f106d..f49f5463363e 100644
> --- a/drivers/clk/meson/g12a.c
> +++ b/drivers/clk/meson/g12a.c
> @@ -298,6 +298,7 @@ static struct clk_regmap g12a_fclk_div2 = {
> _fclk_div2_div.hw
> },
> .num_parents = 1,
> + .flags = CLK_IS_CRITICAL,
> },
> };
>
> @@ -672,7 +673,7 @@ static struct clk_regmap g12b_cpub_clk = {
> _sys_pll.hw
> },
> .num_parents = 2,
> - .flags = CLK_SET_RATE_PARENT,
> + .flags = CLK_SET_RATE_PARENT | CLK_IS_CRITICAL,
> },
> };
>
Yes these changes work at my end,
I want to narrow down my changes, this looks pretty good.
Best Regards
-Anand
Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Hi Martin, On Fri, 18 Oct 2019 at 23:40, Martin Blumenstingl wrote: > > Hi Anand, > > On Fri, Oct 18, 2019 at 4:04 PM Anand Moon wrote: > [...] > > > Next step it to try narrow down the clock causing the issue. > > > Remove clk_ignore_unused from the command line and add CLK_INGORE_UNUSED > > > to the flag of some clocks your clock controller (g12a I think) until > > > > > > The peripheral clock gates already have this flag (something we should > > > fix someday) so don't bother looking there. > > > > > > Most likely the source of the pwm is getting disabled between the > > > late_init call and the probe of the PWM module. Since the pwm is already > > > active (w/o a driver), gating the clock source shuts dowm the power to > > > the cores. > > > > > > Looking a the possible inputs in pwm driver, I'd bet on fdiv4. > > > > > > > I had give this above steps a try but with little success. > > I am still looking into this much close. > it's not clear to me if you have only tested with the PWM and/or > FCLK_DIV4 clocks. can you please describe what you have tested so far? > Sorry for delayed response. I had just looked into clk related to SD_EMMC_A/B/C, with adding CLK_IGNORE/CRITICAL. Also looked into clk_summary for eMMC and microSD card, to identify the root cause, but I failed to move ahead. > for reference - my way of debugging this in the past was: > 1. add some printks to clk_disable_unused_subtree (right after the > clk_core_is_enabled check) to see which clocks are being disabled > 2. add CLK_IGNORE_UNUSED or CLK_IS_CRITICAL to the clocks which are > being disabled based on the information from step #1 > 3. (at some point I had a working kernel with lots of clocks with > CLK_IGNORE_UNUSED/CLK_IS_CRITICAL) > 4. start dropping the CLK_IGNORE_UNUSED/CLK_IS_CRITICAL flags again > until you have traced it down to the clocks that are the actual issue > (so far I always had only one clock which caused issues, but it may be > multiple) > 5. investigate (and/or ask on the mailing list, Amlogic developers are > reading the mails here as well) for the few clocks from step #4 > Thanks for you valuable suggestion. I have your patch to debug this [0] https://patchwork.kernel.org/patch/9725921/mbox/ So from the fist step I could identify that all the clk were getting closed after some core cpu clk was failing. Here is the log. step1: [1] https://pastebin.com/p13F9HGG so I marked these clk as CLK_IGNORE_UNUSED and finally I made it to boot using microSD card. After this just I converted these CLK to CLK_IS_CRITICAL as mostly these are used the CPU clk for now. Here is boot log successful for as of now. Finally: [2] https://pastebin.com/qB6pMyGQ I know clk maintainer are against marking flags as *CLK_IS_CRITICAL* But this is just the step to move ahead. Attach is my local clk and dts patch.Just for testing. [3] clk_critical.patch Plz share your thought on this. > > Well I am not the expert in clk or bus configuration. > > but after looking into the datasheet of for clk configuration > > I found some bus are not configured correctly. > did you find any reason which indicates that the problem is related to a bus? > the issues I had were due to clocks not being assigned to their > consumers in .dts - that can be anything (from a bus to something > different). > Yes I feel each core bus should be independent as each clk PLL controls these bus. for example datasheet: *6-5 Clock Connections* What I feel currently missing with bus are clock gating (enable/disable of features). clock-controller reset-controller Here is the current overview of bus topology using latest u-boot (dm tree). [4] https://pastebin.com/MZ25bgiP Bet Regards -Anand clk_critical.patch Description: Binary data
Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Hi Neil, On Fri, 18 Oct 2019 at 19:43, Neil Armstrong wrote: > > On 18/10/2019 16:04, Anand Moon wrote: > > Hi Jerome / Neil / Martin, > > > > On Wed, 9 Oct 2019 at 17:34, Jerome Brunet wrote: > >> > >> > >> On Wed 09 Oct 2019 at 10:48, Anand Moon wrote: > >>> > >>> Kernel command line: console=ttyAML0,115200n8 > >>> root=PARTUUID=45d7d61e-01 rw rootwait > >>> earlyprintk=serial,ttyAML0,115200 initcall_debug printk.time=y > >>> > >>> [0] https://pastebin.com/eBgJrSKe > >>> > >>>> you can also try the command line parameter "clk_ignore_unused" (it's > >>>> just a gut feeling: maybe a "critical" clock is being disabled because > >>>> it's not wired up correctly). > >>>> > >>> > >>> It look like some clk issue after I added the *clk_ignore_unused* to > >>> kernel command line > >>> it booted further to login prompt and cpufreq DVFS seem to be loaded. > >>> So I could conclude this is clk issue.below is the boot log > >>> > >>> Kernel command line: console=ttyAML0,115200n8 > >>> root=PARTUUID=45d7d61e-01 rw rootwait > >>> earlyprintk=serial,ttyAML0,115200 initcall_debug printk.time=y > >>> clk_ignore_unused > >>> > >>> [1] https://pastebin.com/Nsk0wZQJ > >>> > >> > >> Next step it to try narrow down the clock causing the issue. > >> Remove clk_ignore_unused from the command line and add CLK_INGORE_UNUSED > >> to the flag of some clocks your clock controller (g12a I think) until > >> > >> The peripheral clock gates already have this flag (something we should > >> fix someday) so don't bother looking there. > >> > >> Most likely the source of the pwm is getting disabled between the > >> late_init call and the probe of the PWM module. Since the pwm is already > >> active (w/o a driver), gating the clock source shuts dowm the power to > >> the cores. > >> > >> Looking a the possible inputs in pwm driver, I'd bet on fdiv4. > >> > > > > I had give this above steps a try but with little success. > > I am still looking into this much close. > > > > Well I am not the expert in clk or bus configuration. > > but after looking into the datasheet of for clk configuration > > I found some bus are not configured correctly. > > > > As per Amlogic's kernel S922X (Hardkernel) > > below link share the bus controller. > > > > [0] > > https://github.com/hardkernel/linux/blob/odroidn2-4.9.y/arch/arm64/boot/dts/amlogic/mesong12b.dtsi#L295-L315 > > > > looking in to current dts changes it looks bit wrong to me. > > > > *As per 6.1 Memory Map* > > apb_efuse: bus@3 --> apb_efuse: bus@ff63 > > periphs: bus@34400--> periphs: bus@ff634400 > > dmc: bus@38000--> dmc: bus@ff638000 > > hiu: bus@3c000--> hiu: bus@ff63c > > If these was wrong, the drivers simply won't work, at all > > > > > Also the order of these is not correct. > > The order is correct, actually > > > > > Down the line in the datasheet some of the interrupt GIC bit are not > > mapped correctly for example. > > > > *As per 6.9.2 Interrupt Control Source* > > 223 SD_EMMC_C > > 222 SD_EMMC_B > > 221 SD_EMMC_A > > There is an offset between the doc and the actual GIC_SPI line, > they start the datasheet numbers from the GIC_PPI numbers (+32). > Ok. Thanks. > Neil > Thanks for answering my query. Best Regards -Anand
Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Hi Jerome / Neil / Martin, On Wed, 9 Oct 2019 at 17:34, Jerome Brunet wrote: > > > On Wed 09 Oct 2019 at 10:48, Anand Moon wrote: > > > > Kernel command line: console=ttyAML0,115200n8 > > root=PARTUUID=45d7d61e-01 rw rootwait > > earlyprintk=serial,ttyAML0,115200 initcall_debug printk.time=y > > > > [0] https://pastebin.com/eBgJrSKe > > > >> you can also try the command line parameter "clk_ignore_unused" (it's > >> just a gut feeling: maybe a "critical" clock is being disabled because > >> it's not wired up correctly). > >> > > > > It look like some clk issue after I added the *clk_ignore_unused* to > > kernel command line > > it booted further to login prompt and cpufreq DVFS seem to be loaded. > > So I could conclude this is clk issue.below is the boot log > > > > Kernel command line: console=ttyAML0,115200n8 > > root=PARTUUID=45d7d61e-01 rw rootwait > > earlyprintk=serial,ttyAML0,115200 initcall_debug printk.time=y > > clk_ignore_unused > > > > [1] https://pastebin.com/Nsk0wZQJ > > > > Next step it to try narrow down the clock causing the issue. > Remove clk_ignore_unused from the command line and add CLK_INGORE_UNUSED > to the flag of some clocks your clock controller (g12a I think) until > > The peripheral clock gates already have this flag (something we should > fix someday) so don't bother looking there. > > Most likely the source of the pwm is getting disabled between the > late_init call and the probe of the PWM module. Since the pwm is already > active (w/o a driver), gating the clock source shuts dowm the power to > the cores. > > Looking a the possible inputs in pwm driver, I'd bet on fdiv4. > I had give this above steps a try but with little success. I am still looking into this much close. Well I am not the expert in clk or bus configuration. but after looking into the datasheet of for clk configuration I found some bus are not configured correctly. As per Amlogic's kernel S922X (Hardkernel) below link share the bus controller. [0] https://github.com/hardkernel/linux/blob/odroidn2-4.9.y/arch/arm64/boot/dts/amlogic/mesong12b.dtsi#L295-L315 looking in to current dts changes it looks bit wrong to me. *As per 6.1 Memory Map* apb_efuse: bus@3 --> apb_efuse: bus@ff63 periphs: bus@34400--> periphs: bus@ff634400 dmc: bus@38000--> dmc: bus@ff638000 hiu: bus@3c000--> hiu: bus@ff63c Also the order of these is not correct. Down the line in the datasheet some of the interrupt GIC bit are not mapped correctly for example. *As per 6.9.2 Interrupt Control Source* 223 SD_EMMC_C 222 SD_EMMC_B 221 SD_EMMC_A and so on. Please share your thought if these changes are valid. Best Regards -Anand
Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Hi Martin, Thanks for your inputs. On Tue, 8 Oct 2019 at 23:11, Martin Blumenstingl wrote: > > Hi Anand, > > On Tue, Oct 8, 2019 at 4:39 PM Anand Moon wrote: > > > > Hi Kevin / Martin, > > > > On Tue, 8 Oct 2019 at 04:28, Kevin Hilman wrote: > > > > > > Martin Blumenstingl writes: > > > > > > > On Mon, Oct 7, 2019 at 3:17 PM Anand Moon wrote: > > > > [...] > > > >> diff --git a/arch/arm64/configs/defconfig > > > >> b/arch/arm64/configs/defconfig > > > >> index c9a867ac32d4..72f6a7dca0d6 100644 > > > >> --- a/arch/arm64/configs/defconfig > > > >> +++ b/arch/arm64/configs/defconfig > > > >> @@ -774,7 +774,7 @@ CONFIG_MPL3115=m > > > >> CONFIG_PWM=y > > > >> CONFIG_PWM_BCM2835=m > > > >> CONFIG_PWM_CROS_EC=m > > > >> -CONFIG_PWM_MESON=m > > > >> +CONFIG_PWM_MESON=y > > > > > > > > some time ago I submitted a similar patch for the 32-bit SoCs > > > > it turned that that pwm-meson can be built as module because the > > > > kernel will run without CPU DVFS as long as the clock and regulator > > > > drivers are returning -EPROBE_DEFER (-517) > > > > > > On 64-bit SoCs, the kernel boots with PWM as a module also, but DVFS > > > only works sometimes, and making it built-in fixes the problem. > > > Actually, it doesn't fix, it just hides the problem, which is likely a > > > race or timeout happening during deferred probing. > > > > > > > did you check whether there's some other problem like some unused > > > > clock which is being disabled at that moment? > > > > I've been hunting weird problems in the past where it turned out that > > > > changing kernel config bits changed the boot timing - that masked the > > > > original problem > > > > > > Right, I would definitely prefer to not make this built-in without a lot > > > more information to *why* this is needed. In figuring that out, we'll > > > probably find the race/timeout that's the root cause. > > > > > > Kevin > > > > > > > > > > Kevin, > > > > As per my understanding from the kernelci.org logs it seen that > > pwm-meson driver is requested more than once before it finally load the > > module. > > > > [0] > > https://storage.kernelci.org/next/master/next-20191008/arm64/defconfig/gcc-8/lab-baylibre/boot-meson-g12b-odroid-n2.txt > my understanding is that: > - the PWM regulator driver is built in (=y) > - the Meson PWM controller driver is built as module (=m) > - during boot the PWM regulator node is found and it has a matching > driver (built-in) > - the PWM regulator driver tries to find the PWM controller but cannot > find it yet (and reports "Failed to get PWM: -517") > - (this repeats a few times) > - then the filesystem / initramfs is loaded where the modules are located > - now the Meson PWM controller driver is loaded > - the PWM regulator driver tries to find the PWM controller -> now it found it > Thanks of this information. At my end on archlinux I also tried to update my initramfs to add support for *pwm-meson* to but it did not work for me. > > Hi Martin, > > > > I have tired your Martin's patch [1] and still the boot fails to move > > ahead with below logs. > > [1] https://lore.kernel.org/patchwork/patch/1034186/ > this patch only silences the "Failed to get PWM: -517" message > Mark didn't apply it back then because without that message it would > be harder to debug these issues > > > [1.543928] xhci-hcd xhci-hcd.0.auto: Host supports USB 3.0 SuperSpeed > > [1.550422] usb usb2: We don't know the algorithms for LPM for this > > host, disabling LPM. > > [1.558702] hub 2-0:1.0: USB hub found > > [1.562131] hub 2-0:1.0: 1 port detected > > [1.566206] dwc3-meson-g12a ffe09000.usb: switching to Device Mode > > [1.573252] meson-gx-mmc ffe05000.sd: Got CD GPIO > > [1.607405] hctosys: unable to open rtc device (rtc0) > > > > I have put some more prints in pwm-meson.c it fails to load the module > > as microsSD card is not completely initialized. > what makes you think that there's a problem with pwm-meson? > > can you please share a boot log with the command line parameter > "initcall_debug" [0]? > from Documentation/admin-guide/kernel-parameters.txt: > initcall_debug [KNL] Trace initcalls as they are executed. Useful > for working out where the kernel is dying during
Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Hi Kevin / Martin, On Tue, 8 Oct 2019 at 04:28, Kevin Hilman wrote: > > Martin Blumenstingl writes: > > > On Mon, Oct 7, 2019 at 3:17 PM Anand Moon wrote: > > [...] > >> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > >> index c9a867ac32d4..72f6a7dca0d6 100644 > >> --- a/arch/arm64/configs/defconfig > >> +++ b/arch/arm64/configs/defconfig > >> @@ -774,7 +774,7 @@ CONFIG_MPL3115=m > >> CONFIG_PWM=y > >> CONFIG_PWM_BCM2835=m > >> CONFIG_PWM_CROS_EC=m > >> -CONFIG_PWM_MESON=m > >> +CONFIG_PWM_MESON=y > > > > some time ago I submitted a similar patch for the 32-bit SoCs > > it turned that that pwm-meson can be built as module because the > > kernel will run without CPU DVFS as long as the clock and regulator > > drivers are returning -EPROBE_DEFER (-517) > > On 64-bit SoCs, the kernel boots with PWM as a module also, but DVFS > only works sometimes, and making it built-in fixes the problem. > Actually, it doesn't fix, it just hides the problem, which is likely a > race or timeout happening during deferred probing. > > > did you check whether there's some other problem like some unused > > clock which is being disabled at that moment? > > I've been hunting weird problems in the past where it turned out that > > changing kernel config bits changed the boot timing - that masked the > > original problem > > Right, I would definitely prefer to not make this built-in without a lot > more information to *why* this is needed. In figuring that out, we'll > probably find the race/timeout that's the root cause. > > Kevin > > Kevin, As per my understanding from the kernelci.org logs it seen that pwm-meson driver is requested more than once before it finally load the module. [0] https://storage.kernelci.org/next/master/next-20191008/arm64/defconfig/gcc-8/lab-baylibre/boot-meson-g12b-odroid-n2.txt Hi Martin, I have tired your Martin's patch [1] and still the boot fails to move ahead with below logs. [1] https://lore.kernel.org/patchwork/patch/1034186/ [1.543928] xhci-hcd xhci-hcd.0.auto: Host supports USB 3.0 SuperSpeed [1.550422] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [1.558702] hub 2-0:1.0: USB hub found [1.562131] hub 2-0:1.0: 1 port detected [1.566206] dwc3-meson-g12a ffe09000.usb: switching to Device Mode [1.573252] meson-gx-mmc ffe05000.sd: Got CD GPIO [1.607405] hctosys: unable to open rtc device (rtc0) I have put some more prints in pwm-meson.c it fails to load the module as microsSD card is not completely initialized. Here is what I have tried to enable sd_emmc_b node, but still it fails to initialize this driver.. - max-frequency = <5000>; + sd-uhs-sdr12; + sd-uhs-sdr25; + sd-uhs-sdr50; + sd-uhs-ddr50; + max-frequency = <1>; disable-wp; Below are the boot logs. [1.729877] meson-gx-mmc ffe05000.sd: Anand mmc proble start1 [1.734658] meson-gx-mmc ffe05000.sd: Got CD GPIO [1.739237] meson-gx-mmc ffe05000.sd: Anand mmc proble start2 [1.744900] meson-gx-mmc ffe05000.sd: Anand mmc proble start3 [1.750594] meson-gx-mmc ffe05000.sd: Anand mmc proble start4 [1.756292] meson-gx-mmc ffe05000.sd: Anand mmc proble start5 [1.761987] meson-gx-mmc ffe05000.sd: Anand mmc proble start6 [1.767668] meson-gx-mmc ffe05000.sd: Anand mmc proble start7 [1.773356] meson-gx-mmc ffe05000.sd: Anand mmc proble start8 [1.779050] meson-gx-mmc ffe05000.sd: Anand mmc proble start9 [1.784748] meson-gx-mmc ffe05000.sd: Anand mmc proble start10 [1.790523] meson-gx-mmc ffe05000.sd: Anand mmc proble start11 [1.796578] meson-gx-mmc ffe05000.sd: Anand mmc proble start12 [1.802150] meson-gx-mmc ffe05000.sd: Anand mmc proble start13 [1.807980] meson-gx-mmc ffe05000.sd: Anand mmc proble start14 [1.813642] meson-gx-mmc ffe05000.sd: Anand mmc proble start15 [1.819416] meson-gx-mmc ffe05000.sd: Anand mmc proble start17 [1.825491] meson-gx-mmc ffe05000.sd: Anand mmc proble start18 [1.830984] meson-gx-mmc ffe05000.sd: Anand mmc proble start19 [1.862000] meson-gx-mmc ffe05000.sd: Anand mmc Final proble good to go [1.863323] pwm-regulator regulator-vddcpu-a: Anand : dutycycle_unit 100: dutycycle_range 100:0 [1.871617] pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517 [1.878560] pwm-regulator regulator-vddcpu-b: Anand : dutycycle_unit 100: dutycycle_range 100:0 [1.886613] pwm-regulator regulator-vddcpu-b: Failed to get PWM: -517 [1.894094] pwm-regulator regulator-vddcpu-a: Anand : dutycycle_unit 100: dutycycle_range 100:0 [1.901771] pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517 [1.909089] pwm-regulator regulator-vddcpu-b: Anand : dutycycle_unit 100
Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Hi Martin. On Tue, 8 Oct 2019 at 01:40, Martin Blumenstingl wrote: > > On Mon, Oct 7, 2019 at 3:17 PM Anand Moon wrote: > [...] > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > > index c9a867ac32d4..72f6a7dca0d6 100644 > > --- a/arch/arm64/configs/defconfig > > +++ b/arch/arm64/configs/defconfig > > @@ -774,7 +774,7 @@ CONFIG_MPL3115=m > > CONFIG_PWM=y > > CONFIG_PWM_BCM2835=m > > CONFIG_PWM_CROS_EC=m > > -CONFIG_PWM_MESON=m > > +CONFIG_PWM_MESON=y > some time ago I submitted a similar patch for the 32-bit SoCs > it turned that that pwm-meson can be built as module because the > kernel will run without CPU DVFS as long as the clock and regulator > drivers are returning -EPROBE_DEFER (-517) > > did you check whether there's some other problem like some unused > clock which is being disabled at that moment? > I've been hunting weird problems in the past where it turned out that > changing kernel config bits changed the boot timing - that masked the > original problem OK. > > > Martin Sorry for linking this two separate issue PWM failed and microSD detect failed. Thanks for the input, I will check if you patch help, I will try to investigate more why it fails at my end. Best Regards -Anand
Re: [RFCv1 4/5] arm64: dts: meson: Add missing regulator linked to VCCV5 regulator to VDDIO_C/TF_IO
Hi Neil,
On Mon, 7 Oct 2019 at 19:51, Neil Armstrong wrote:
>
> On 07/10/2019 15:16, Anand Moon wrote:
> > As per schematics add missing VCCV5 power supply to VDDIO_C/TF_IO
> > regulator. Also add TF_3V3N_1V8_EN signal name to gpio pin.
> >
> > Fixes: c35f6dc5c377 (arm64: dts: meson: Add minimal support for Odroid-N2)
> > Cc: Martin Blumenstingl
> > Cc: Jerome Brunet
> > Cc: Neil Armstrong
> > Signed-off-by: Anand Moon
> > ---
> > arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > index 6bd23a1e7e1d..5daf176452f7 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > @@ -66,11 +66,14 @@
> > regulator-min-microvolt = <180>;
> > regulator-max-microvolt = <330>;
> >
> > + /* TF_3V3N_1V8_EN */
> > gpios = <_ao GPIOAO_9 GPIO_ACTIVE_HIGH>;
> > gpios-states = <0>;
> >
> > states = <330 0>,
> ><180 1>;
> > + /* U16 RT9179GB */
> > + vin-supply = <_5v>;
> > };
> >
> > flash_1v8: regulator-flash_1v8 {
> >
>
> Reviewed-by: Neil Armstrong
Thanks,
Best Regards
-Anand
Re: [RFCv1 3/5] arm64: dts: meson: Add missing regulator linked to VDDAO_3V3 regulator to FLASH_VDD
Hi Neil,
On Mon, 7 Oct 2019 at 19:51, Neil Armstrong wrote:
>
> On 07/10/2019 15:16, Anand Moon wrote:
> > As per schematics add missing VDDAO_3V3 power supply to FLASH_VDD
> > regulator. Also add TFLASH_VDD_EN signal name to gpio pin.
> >
> > Fixes: c35f6dc5c377 (arm64: dts: meson: Add minimal support for Odroid-N2)
> > Cc: Martin Blumenstingl
> > Cc: Jerome Brunet
> > Cc: Neil Armstrong
> > Signed-off-by: Anand Moon
> > ---
> > arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > index 66262a6ab3fe..6bd23a1e7e1d 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > @@ -51,9 +51,12 @@
> > regulator-min-microvolt = <330>;
> > regulator-max-microvolt = <330>;
> >
> > + /* TFLASH_VDD_EN */
> > gpio = <_ao GPIOAO_8 GPIO_ACTIVE_HIGH>;
> > enable-active-high;
> > regulator-always-on;
> > + /* U18 FC8731-09VF05NRR */
> > + vin-supply = <_3v3>;
> > };
> >
> > tf_io: gpio-regulator-tf_io {
> >
>
> Reviewed-by: Neil Armstrong
Thanks,
Best Regards
-Anand
Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Hi Neil, On Mon, 7 Oct 2019 at 19:55, Neil Armstrong wrote: > > On 07/10/2019 15:16, Anand Moon wrote: > > Using microSD card we cannot get the mainline kernel to boot > > What's the link with microSD card here ? Well I thought that the PWM failed stop's booting further on linux kernel. But looking into kernelcli.org it seem to be working fine, but not at my end. [0] https://storage.kernelci.org/media/master/v5.4-rc1-82-gc0e284ccfeda/arm64/defconfig/gcc-8/lab-baylibre/boot-meson-g12b-odroid-n2.txt > > > using mainline u-boot it fails with below logs. > > Build PWM_MESSON as build-in solve the issue. > > > > [1.569240] meson-gx-mmc ffe05000.sd: Got CD GPIO > > [1.599227] pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517 > > [1.600605] pwm-regulator regulator-vddcpu-b: Failed to get PWM: -517 > > [1.607166] pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517 > > [1.613273] pwm-regulator regulator-vddcpu-b: Failed to get PWM: -517 > > [1.619931] hctosys: unable to open rtc device (rtc0) > > > > Cc: Martin Blumenstingl > > Cc: Jerome Brunet > > Cc: Neil Armstrong > > Signed-off-by: Anand Moon > > --- > > Odroid N2 Schematics says "GPIOC_6 should not pulled low if GPIOC is not > > work as SDCARD" > > Sorry, what's the link with the PWM build-in, and your case ? > Sorry I linked two issues with this commit message. > This comment is linked to the comment in the datasheet: > "" > If GPIOC is not work as SDIO port, please do not pull CARD_DET(GPIOC_6) low > when system booting > up, to avoid romcode trying to boot from SD CARD. > "" > Seems pretty explicit for me. > Ok I will recheck this at my end. > > Is their any other approch to help resolve this issue. > > > > Boot log failed with cold boot: > > [0] https://pastebin.com/cEtWq2iX > > --- > > arch/arm64/configs/defconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > > index c9a867ac32d4..72f6a7dca0d6 100644 > > --- a/arch/arm64/configs/defconfig > > +++ b/arch/arm64/configs/defconfig > > @@ -774,7 +774,7 @@ CONFIG_MPL3115=m > > CONFIG_PWM=y > > CONFIG_PWM_BCM2835=m > > CONFIG_PWM_CROS_EC=m > > -CONFIG_PWM_MESON=m > > +CONFIG_PWM_MESON=y > > CONFIG_PWM_RCAR=m > > CONFIG_PWM_ROCKCHIP=y > > CONFIG_PWM_SAMSUNG=y > > > > For these changes without the microSD fail description in the commit log : > Acked-by: Neil Armstrong Thanks. I will rephrase this without linking the microSD card, with better commit message. Best Regards -Anand
Re: [RFCv1 2/5] arm64: dts: meson: Add missing pwm control gpio signal for pwm-regulator
Hi Neil,
On Mon, 7 Oct 2019 at 19:50, Neil Armstrong wrote:
>
> On 07/10/2019 15:16, Anand Moon wrote:
> > As per schematics add missing VDDCPUA_PWM and VDDCPUB_PWM
> > gpio signal use to enable/disable the pwm regulator for DVFS.
> >
> > Fixes: d14734a04a8a (arm64: dts: meson-g12b-odroid-n2: enable DVFS)
> > Cc: Martin Blumenstingl
> > Cc: Jerome Brunet
> > Cc: Neil Armstrong
> > Signed-off-by: Anand Moon
> > ---
> > arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > index a9a661258886..66262a6ab3fe 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > @@ -135,6 +135,8 @@
> >
> > regulator-boot-on;
> > regulator-always-on;
> > + /* VDDCPUA_PWM */
> > + enable-gpios = < GPIOE_1 GPIO_ACTIVE_HIGH>;
> > };
> >
> > vddcpu_b: regulator-vddcpu-b {
> > @@ -154,6 +156,8 @@
> >
> > regulator-boot-on;
> > regulator-always-on;
> > + /* VDDCPUB_PWM */
> > + enable-gpios = < GPIOE_2 GPIO_ACTIVE_HIGH>;
> > };
> >
> > hub_5v: regulator-hub_5v {
> >
>
> Same as 5V_EN, This GPIO is handled by the BL301 SCP firmware, I'm personally
> against
> adding this to the DT since it's out of control of Linux or any OS.
>
> This GPIO id controlles by the PSCI call to SCP to enable/disable
> the CPU clusters.
>
> Neil
Thanks for your input's.
Best Regards
-Anand
Re: [RFCv1 1/5] arm64: dts: meson: Add missing 5V_EN gpio signal for VCC5V regulator
Hi Neil,
On Mon, 7 Oct 2019 at 19:49, Neil Armstrong wrote:
>
> Hi Anand,
>
> On 07/10/2019 15:16, Anand Moon wrote:
> > As per schematics add missing 5V_EN gpio signal to enable
> > VCC5V regulator node.
> >
> > Fixes: c35f6dc5c377 (arm64: dts: meson: Add minimal support for Odroid-N2)
> > Cc: Martin Blumenstingl
> > Cc: Jerome Brunet
> > Cc: Neil Armstrong
> > Signed-off-by: Anand Moon
> > ---
> > arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > index 42f15405750c..a9a661258886 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > @@ -94,6 +94,9 @@
> > regulator-max-microvolt = <500>;
> > regulator-always-on;
> > vin-supply = <_12v>;
> > + /* U12 NB679GD 5V_EN */
> > + gpio = < GPIOH_8 GPIO_OPEN_DRAIN>;
> > + enable-active-high;
>
> This GPIO is handled by the BL301 SCP firmware, I'm personally against
> adding this to the DT since it's out of control of Linux or any OS.
>
> Neil
>
Thanks for your input.
> > };
> >
> > vcc_1v8: regulator-vcc_1v8 {
> >
>
Best Regards
-Anand
[RFCv1 1/5] arm64: dts: meson: Add missing 5V_EN gpio signal for VCC5V regulator
As per schematics add missing 5V_EN gpio signal to enable
VCC5V regulator node.
Fixes: c35f6dc5c377 (arm64: dts: meson: Add minimal support for Odroid-N2)
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
index 42f15405750c..a9a661258886 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
@@ -94,6 +94,9 @@
regulator-max-microvolt = <500>;
regulator-always-on;
vin-supply = <_12v>;
+ /* U12 NB679GD 5V_EN */
+ gpio = < GPIOH_8 GPIO_OPEN_DRAIN>;
+ enable-active-high;
};
vcc_1v8: regulator-vcc_1v8 {
--
2.23.0
[RFCv1 2/5] arm64: dts: meson: Add missing pwm control gpio signal for pwm-regulator
As per schematics add missing VDDCPUA_PWM and VDDCPUB_PWM
gpio signal use to enable/disable the pwm regulator for DVFS.
Fixes: d14734a04a8a (arm64: dts: meson-g12b-odroid-n2: enable DVFS)
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
index a9a661258886..66262a6ab3fe 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
@@ -135,6 +135,8 @@
regulator-boot-on;
regulator-always-on;
+ /* VDDCPUA_PWM */
+ enable-gpios = < GPIOE_1 GPIO_ACTIVE_HIGH>;
};
vddcpu_b: regulator-vddcpu-b {
@@ -154,6 +156,8 @@
regulator-boot-on;
regulator-always-on;
+ /* VDDCPUB_PWM */
+ enable-gpios = < GPIOE_2 GPIO_ACTIVE_HIGH>;
};
hub_5v: regulator-hub_5v {
--
2.23.0
[RFCv1 4/5] arm64: dts: meson: Add missing regulator linked to VCCV5 regulator to VDDIO_C/TF_IO
As per schematics add missing VCCV5 power supply to VDDIO_C/TF_IO
regulator. Also add TF_3V3N_1V8_EN signal name to gpio pin.
Fixes: c35f6dc5c377 (arm64: dts: meson: Add minimal support for Odroid-N2)
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
index 6bd23a1e7e1d..5daf176452f7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
@@ -66,11 +66,14 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
+ /* TF_3V3N_1V8_EN */
gpios = <_ao GPIOAO_9 GPIO_ACTIVE_HIGH>;
gpios-states = <0>;
states = <330 0>,
<180 1>;
+ /* U16 RT9179GB */
+ vin-supply = <_5v>;
};
flash_1v8: regulator-flash_1v8 {
--
2.23.0
[RFCv1 3/5] arm64: dts: meson: Add missing regulator linked to VDDAO_3V3 regulator to FLASH_VDD
As per schematics add missing VDDAO_3V3 power supply to FLASH_VDD
regulator. Also add TFLASH_VDD_EN signal name to gpio pin.
Fixes: c35f6dc5c377 (arm64: dts: meson: Add minimal support for Odroid-N2)
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
index 66262a6ab3fe..6bd23a1e7e1d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
@@ -51,9 +51,12 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
+ /* TFLASH_VDD_EN */
gpio = <_ao GPIOAO_8 GPIO_ACTIVE_HIGH>;
enable-active-high;
regulator-always-on;
+ /* U18 FC8731-09VF05NRR */
+ vin-supply = <_3v3>;
};
tf_io: gpio-regulator-tf_io {
--
2.23.0
[RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y
Using microSD card we cannot get the mainline kernel to boot using mainline u-boot it fails with below logs. Build PWM_MESSON as build-in solve the issue. [1.569240] meson-gx-mmc ffe05000.sd: Got CD GPIO [1.599227] pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517 [1.600605] pwm-regulator regulator-vddcpu-b: Failed to get PWM: -517 [1.607166] pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517 [1.613273] pwm-regulator regulator-vddcpu-b: Failed to get PWM: -517 [1.619931] hctosys: unable to open rtc device (rtc0) Cc: Martin Blumenstingl Cc: Jerome Brunet Cc: Neil Armstrong Signed-off-by: Anand Moon --- Odroid N2 Schematics says "GPIOC_6 should not pulled low if GPIOC is not work as SDCARD" Is their any other approch to help resolve this issue. Boot log failed with cold boot: [0] https://pastebin.com/cEtWq2iX --- arch/arm64/configs/defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index c9a867ac32d4..72f6a7dca0d6 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -774,7 +774,7 @@ CONFIG_MPL3115=m CONFIG_PWM=y CONFIG_PWM_BCM2835=m CONFIG_PWM_CROS_EC=m -CONFIG_PWM_MESON=m +CONFIG_PWM_MESON=y CONFIG_PWM_RCAR=m CONFIG_PWM_ROCKCHIP=y CONFIG_PWM_SAMSUNG=y -- 2.23.0
[RFCv1 0/5] Odroid N2 failes to boot using upstream kernel & u-boot
We am trying to build the upstream u-boot and upstream kernel, but it fails to pass the initialization of PWM_MESON driver. So these patches help boot the kernel on microSD card. Patchs based on Linux 5.4-rc2 Boot log failed are shown below. [0] https://pastebin.com/cEtWq2iX [1.569240] meson-gx-mmc ffe05000.sd: Got CD GPIO [1.599227] pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517 [1.600605] pwm-regulator regulator-vddcpu-b: Failed to get PWM: -517 [1.607166] pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517 [1.613273] pwm-regulator regulator-vddcpu-b: Failed to get PWM: -517 [1.619931] hctosys: unable to open rtc device (rtc0) My guess their is not much issue with eMMC module, if their is other approach to resolve this issue, I will give this a try. Best Regards -Anand Anand Moon (5): arm64: dts: meson: Add missing 5V_EN gpio signal for VCC5V regulator arm64: dts: meson: Add missing pwm control gpio signal for pwm-regulator arm64: dts: meson: Add missing regulator linked to VDDAO_3V3 regulator to FLASH_VDD arm64: dts: meson: Add missing regulator linked to VCCV5 regulator to VDDIO_C/TF_IO arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y .../arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 13 + arch/arm64/configs/defconfig| 2 +- 2 files changed, 14 insertions(+), 1 deletion(-) -- 2.23.0
Re: [PATCHv3 RESEND-next 0/3] Odroid c2 missing regulator linking
Hi Kevin, On Thu, 3 Oct 2019 at 23:14, Kevin Hilman wrote: > > Anand Moon writes: > > > Looks like this changes got lost so resend these changes again. > > Yeah, sorry about that. Your cover letter subjects were quite similar, > and several versions of this series and the previoius series arrived > close together, so some stuff fell through the cracks. Sorry about > that. I will keep this in my mind and do not repeat my silly mistakes. > > Queued for v5.5 now, > > Thanks, No worries, thanks for the update! > > Kevin Best Regards -Anand
[PATCHv3 RESEND-next 2/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator
As per schematics TFLASH_VDD, TF_IO, VCC3V3 fixed regulator output which
is supplied by VDDIO_AO3V3.
While here, move the comment name with the signal name in the
schematics above the gpio property to make it consistent with other
regulators.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Reviewed-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
changes from previous.
Patchv1
- Fix the typo.
- Add the comment as per Martin's suggestion.
- Added Martin's review tags
Patchv2
- Added missing Neil's Reviewed-by tags.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 5adecdf3b175..2fcd512373a3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -67,17 +67,19 @@
};
tflash_vdd: regulator-tflash_vdd {
- /*
-* signal name from schematics: TFLASH_VDD_EN
-*/
compatible = "regulator-fixed";
regulator-name = "TFLASH_VDD";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
+ /*
+* signal name from schematics: TFLASH_VDD_EN
+*/
gpio = < GPIOY_12 GPIO_ACTIVE_HIGH>;
enable-active-high;
+ /* U16 RT9179GB */
+ vin-supply = <_ao3v3>;
};
tf_io: gpio-regulator-tf_io {
@@ -95,6 +97,8 @@
states = <330 0>,
<180 1>;
+ /* U12/U13 RT9179GB */
+ vin-supply = <_ao3v3>;
};
vcc1v8: regulator-vcc1v8 {
@@ -102,6 +106,9 @@
regulator-name = "VCC1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-always-on;
+ /* U18 RT9179GB */
+ vin-supply = <_ao3v3>;
};
vcc3v3: regulator-vcc3v3 {
--
2.23.0
[PATCHv3 RESEND-next 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
As per schematics VDDIO_AO18, VDDIO_AO3V3/VDD3V3 DDR3_1V5/DDR_VDDC:
fixed regulator output which is supplied by P5V0.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Reviewed-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
Changes from previous.
patchv1.
- drop the rename and linking vcc3v3 regulator node.
- fix the typo spelling.
patchv2.
- change the vddc_ddr node name to ddr3_1v5 as per Martin's suggestion
- Added Matrin's and Neil's Reviewed-by.
---
.../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 30 +++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index e739f10f9442..5adecdf3b175 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -111,6 +111,36 @@
regulator-max-microvolt = <330>;
};
+ vddio_ao1v8: regulator-vddio-ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ /* U17 RT9179GB */
+ vin-supply = <>;
+ };
+
+ vddio_ao3v3: regulator-vddio-ao3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ /* U11 MP2161GJ-C499 */
+ vin-supply = <>;
+ };
+
+ ddr3_1v5: regulator-ddr3_1v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "DDR3_1V5";
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-always-on;
+ /* U15 MP2161GJ-C499 */
+ vin-supply = <>;
+ };
+
emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
--
2.23.0
[PATCHv3 RESEND-next 0/3] Odroid c2 missing regulator linking
Looks like this changes got lost so resend these changes again. Below small changes help re-configure or fix missing inter linking of regulator node. Re-based on *next-20191001* Changes from previous patch's series. Build using Cross Compiler. Added missing Reviewed-by Neil's and Martin. Added few suggestion from martin for rename of node. Changes for previous changes. Fix some typo. Updated few patches as per Martin's suggestion. Best Regards -Anand Anand Moon (3): arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 53 +-- 1 file changed, 50 insertions(+), 3 deletions(-) -- 2.23.0
[PATCHv3 RESEND-next 3/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply
As per schematics HDMI_P5V0 is supplied by P5V0 so add missing link.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Reviewed-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
Changes from previous
Patchv1
- As per Martin's suggestion added the HDMI_P5V0 fix regulator node.
Patchv2
- Added Matrin's and Neil's Reviewed-by.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 2fcd512373a3..6ded279c40c8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -66,6 +66,15 @@
regulator-always-on;
};
+ hdmi_p5v0: regulator-hdmi_p5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "HDMI_P5V0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ /* AP2331SA-7 */
+ vin-supply = <>;
+ };
+
tflash_vdd: regulator-tflash_vdd {
compatible = "regulator-fixed";
@@ -220,6 +229,7 @@
status = "okay";
pinctrl-0 = <_hpd_pins>, <_i2c_pins>;
pinctrl-names = "default";
+ hdmi-supply = <_p5v0>;
};
_tx_tmds_port {
--
2.23.0
Re: [PATCHv3-next 0/3] Odroid c2 missing regulator linking
Hi Kevin, On Fri, 6 Sep 2019 at 17:50, Anand Moon wrote: > > Below small changes help re-configure or fix missing inter linking > of regulator node. > > Re-based on linux-next-20190904 > Changes from previous patch's series. > Build using Cross Compiler. > > Added missing Reviewed-by Neil's and Martin. > Added few suggestion from martin for rename of node. > > Dependencies: > Changes based top on my previous usb fix series patch's. > > [0] https://patchwork.kernel.org/patch/3095/ > [1] https://patchwork.kernel.org/patch/3099/ > [3] https://patchwork.kernel.org/patch/3103/ > > Hope this series get picked up for 5.4-rc1, finger crossed. > > Changes for previous changes. > Fix some typo. > Updated few patches as per Martin's suggestion. > > I will try to commit less mistake in the future. > > Best Regards > -Anand > Gentle ping for this series. Best Regards -Anand > Anand Moon (3): > arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 > regulator > arm64: dts: meson: odroid-c2: Add missing regulator linked to > VDDIO_AO3V3 regulator > arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI > supply > > .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 53 +-- > 1 file changed, 50 insertions(+), 3 deletions(-) > > -- > 2.23.0 >
Re: [PATCHv4-next 0/3] Odroid c2 usb fixs rebase on linux-next
Hi Kevin, On Thu, 26 Sep 2019 at 03:34, Kevin Hilman wrote: > > Anand Moon writes: > > > Some time ago I had tired to enable usb bus 1 for Odroid C2/C1 > > but it's look like some more work is needed to u-boot and > > usb_phy driver to initialize this port. > > > > Below patches tries to address the issue regarding usb bus 2 (4 port) > > while disable the usb bus 1 on this board. > > > > Previous patch > > [0] https://lkml.org/lkml/2019/1/29/325 > > > > Re send below series based re based on linux-next-20190830. > > For review and testing. > > > > [1] https://patchwork.kernel.org/cover/3091/ > > > > Small changes from previous series. > > Fix the commit message for patch 1 > > Queued for v5.5. > > I fixed up the typo in patch 2/3 when applying as suggested by Martin. > > Kevin Thanks, Best Regards -Anand
[PATCHv3-next 3/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply
As per schematics HDMI_P5V0 is supplied by P5V0 so add missing link.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Reviewed-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
Changes from previous
Patchv1
- As per Martin's suggestion added the HDMI_P5V0 fix regulator node.
Patchv2
- Added Matrin's and Neil's Reviewed-by.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 5624ff034659..6ae9fafe4244 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -66,6 +66,15 @@
regulator-always-on;
};
+ hdmi_p5v0: regulator-hdmi_p5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "HDMI_P5V0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ /* AP2331SA-7 */
+ vin-supply = <>;
+ };
+
tflash_vdd: regulator-tflash_vdd {
compatible = "regulator-fixed";
@@ -220,6 +229,7 @@
status = "okay";
pinctrl-0 = <_hpd_pins>, <_i2c_pins>;
pinctrl-names = "default";
+ hdmi-supply = <_p5v0>;
};
_tx_tmds_port {
--
2.23.0
[PATCHv3-next 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
As per schematics VDDIO_AO18, VDDIO_AO3V3/VDD3V3 DDR3_1V5/DDR_VDDC:
fixed regulator output which is supplied by P5V0.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Reviewed-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
Changes from previous.
patchv1.
- drop the rename and linking vcc3v3 regulator node.
- fix the typo spelling.
patchv2.
- change the vddc_ddr node name to ddr3_1v5 as per Martin's suggestion
- Added Matrin's and Neil's Reviewed-by.
---
---
.../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 30 +++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 3e51f0835c8d..9ea336c33d00 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -111,6 +111,36 @@
regulator-max-microvolt = <330>;
};
+ vddio_ao1v8: regulator-vddio-ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ /* U17 RT9179GB */
+ vin-supply = <>;
+ };
+
+ vddio_ao3v3: regulator-vddio-ao3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ /* U11 MP2161GJ-C499 */
+ vin-supply = <>;
+ };
+
+ ddr3_1v5: regulator-ddr3_1v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "DDR3_1V5";
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-always-on;
+ /* U15 MP2161GJ-C499 */
+ vin-supply = <>;
+ };
+
emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
--
2.23.0
[PATCHv3-next 2/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator
As per schematics TFLASH_VDD, TF_IO, VCC3V3 fixed regulator output which
is supplied by VDDIO_AO3V3.
While here, move the comment name with the signal name in the
schematics above the gpio property to make it consistent with other
regulators.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Reviewed-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
changes from previous.
Patchv1
- Fix the typo.
- Add the comment as per Martin's suggestion.
- Added Martin's review tags
Patchv2
- Added missing Neil's Reviewed-by tags.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 9ea336c33d00..5624ff034659 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -67,17 +67,19 @@
};
tflash_vdd: regulator-tflash_vdd {
- /*
-* signal name from schematics: TFLASH_VDD_EN
-*/
compatible = "regulator-fixed";
regulator-name = "TFLASH_VDD";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
+ /*
+* signal name from schematics: TFLASH_VDD_EN
+*/
gpio = < GPIOY_12 GPIO_ACTIVE_HIGH>;
enable-active-high;
+ /* U16 RT9179GB */
+ vin-supply = <_ao3v3>;
};
tf_io: gpio-regulator-tf_io {
@@ -95,6 +97,8 @@
states = <330 0>,
<180 1>;
+ /* U12/U13 RT9179GB */
+ vin-supply = <_ao3v3>;
};
vcc1v8: regulator-vcc1v8 {
@@ -102,6 +106,9 @@
regulator-name = "VCC1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-always-on;
+ /* U18 RT9179GB */
+ vin-supply = <_ao3v3>;
};
vcc3v3: regulator-vcc3v3 {
--
2.23.0
[PATCHv3-next 0/3] Odroid c2 missing regulator linking
Below small changes help re-configure or fix missing inter linking of regulator node. Re-based on linux-next-20190904 Changes from previous patch's series. Build using Cross Compiler. Added missing Reviewed-by Neil's and Martin. Added few suggestion from martin for rename of node. Dependencies: Changes based top on my previous usb fix series patch's. [0] https://patchwork.kernel.org/patch/3095/ [1] https://patchwork.kernel.org/patch/3099/ [3] https://patchwork.kernel.org/patch/3103/ Hope this series get picked up for 5.4-rc1, finger crossed. Changes for previous changes. Fix some typo. Updated few patches as per Martin's suggestion. I will try to commit less mistake in the future. Best Regards -Anand Anand Moon (3): arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 53 +-- 1 file changed, 50 insertions(+), 3 deletions(-) -- 2.23.0
[PATCHv3-next 0/3] Odroid c2 missing regulator linking
Below small changes help re-configure or fix missing inter linking of regulator node. Re-based on linux-next-20190904 Changes from previous patch's series. Build using Cross Compiler. Added missing Reviewed-by Neil's and Martin. Added few suggestion from martin for rename of node. Dependencies: Changes based top on my previous usb fix series patch's. [0] https://patchwork.kernel.org/patch/3095/ [1] https://patchwork.kernel.org/patch/3099/ [3] https://patchwork.kernel.org/patch/3103/ Hope this series get picked up for 5.4-rc1, finger crossed. Changes for previous changes. Fix some typo. Updated few patches as per Martin's suggestion. I will try to commit less mistake in the future. Best Regards -Anand Anand Moon (3): arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 53 +-- 1 file changed, 50 insertions(+), 3 deletions(-) -- 2.23.0
[PATCHv2-next 2/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator
As per schematics TFLASH_VDD, TF_IO, VCC3V3 fixed regulator output which
is supplied by VDDIO_AO3V3.
While here, move the comment name with the signal name in the
schematics above the gpio property to make it consistent with other
regulators.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Reviewed-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
changes from previous.
- Fix the typo.
- Add the comment as per Martin's suggestion.
- Added Martin's review tags
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index b763b76820ba..ef2c3b74415b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -67,17 +67,19 @@
};
tflash_vdd: regulator-tflash_vdd {
- /*
-* signal name from schematics: TFLASH_VDD_EN
-*/
compatible = "regulator-fixed";
regulator-name = "TFLASH_VDD";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
+ /*
+* signal name from schematics: TFLASH_VDD_EN
+*/
gpio = < GPIOY_12 GPIO_ACTIVE_HIGH>;
enable-active-high;
+ /* U16 RT9179GB */
+ vin-supply = <_ao3v3>;
};
tf_io: gpio-regulator-tf_io {
@@ -95,6 +97,8 @@
states = <330 0>,
<180 1>;
+ /* U12/U13 RT9179GB */
+ vin-supply = <_ao3v3>;
};
vcc1v8: regulator-vcc1v8 {
@@ -102,6 +106,9 @@
regulator-name = "VCC1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-always-on;
+ /* U18 RT9179GB */
+ vin-supply = <_ao3v3>;
};
vcc3v3: regulator-vcc3v3 {
--
2.23.0
[PATCHv2-next 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
As per schematics VDDIO_AO18, VDDIO_AO3V3/VDD3V3 DDR3_1V5/DDR_VDDC:
fixed regulator output which is supplied by P5V0.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
Changes from previous.
- drop the rename and linking vcc3v3 regulator node.
- fix the typo spelling.
---
.../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 30 +++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 3e51f0835c8d..b763b76820ba 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -111,6 +111,36 @@
regulator-max-microvolt = <330>;
};
+ vddio_ao1v8: regulator-vddio-ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ /* U17 RT9179GB */
+ vin-supply = <>;
+ };
+
+ vddio_ao3v3: regulator-vddio-ao3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ /* U11 MP2161GJ-C499 */
+ vin-supply = <>;
+ };
+
+ vddc_ddr: regulator-vddc-ddr {
+ compatible = "regulator-fixed";
+ regulator-name = "DDR3_1V5";
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-always-on;
+ /* U15 MP2161GJ-C499 */
+ vin-supply = <>;
+ };
+
emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
--
2.23.0
[PATCHv2-next 3/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply
As per schematics HDMI_P5V0 is supplied by P5V0 so add missing link.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
As per Martin's suggestion added the HDMI_P5V0 fix regulator node.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index ef2c3b74415b..a520ec0d73ff 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -66,6 +66,15 @@
regulator-always-on;
};
+ hdmi_p5v0: regulator-hdmi_p5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "HDMI_P5V0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ /* AP2331SA-7 */
+ vin-supply = <>;
+ };
+
tflash_vdd: regulator-tflash_vdd {
compatible = "regulator-fixed";
@@ -220,6 +229,7 @@
status = "okay";
pinctrl-0 = <_hpd_pins>, <_i2c_pins>;
pinctrl-names = "default";
+ hdmi-supply = <_p5v0>;
};
_tx_tmds_port {
--
2.23.0
[PATCHv2-next 0/3] Odroid c2 missing regulator linking
Below small changes help re-configure or fix missing inter linking of regulator node. Rebased on linux-next-20190830 Changes based top on my prevoius series. [0] https://patchwork.kernel.org/cover/11125987/ Changes for prevoius changes. Fix some typo. Updated few patches as per Martin's suggetion. Best Regards -Anand Anand Moon (3): arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 53 +-- 1 file changed, 50 insertions(+), 3 deletions(-) -- 2.23.0
[PATCHv4-next 1/3] arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input
As per the schematic Monolithic Power Systems MP2161GJ-C499
supply a fixed output voltage of 5.0V. This supplies linked
to VDD_EE, HDMI_P5V0, USB_POWER, VCCK, VDDIO_AO1V8, VDDIO_AO3V3,
VDD3V3, DDR3_1V5 according to the schematics.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Acked-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
Rebased on linux-next.
Added Acked by Martin.
Fixed the commit message to add misssing VDDIO_AO3V3 and VDD3V3.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 6039adda12ee..0cb5831d9daf 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -50,6 +50,15 @@
};
};
+ p5v0: regulator-p5v0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "P5V0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
tflash_vdd: regulator-tflash_vdd {
/*
* signal name from schematics: TFLASH_VDD_EN
--
2.23.0
[PATCHv4-next 2/3] arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus
Add missing linking regulator node to usb bus for power usb devices.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Acked-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
Re-base on linux-next
Added Ack from Martin.
Changes from previous patch
[1] https://lore.kernel.org/patchwork/patch/1031243/
split the changes and add the comments to power source
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 0cb5831d9daf..d4c8b896dd26 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -36,8 +36,15 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
+ /*
+* signal name from schematics: PWREN
+*/
gpio = <_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
enable-active-high;
+ /*
+* signal name from sehematics: USB_POWER
+*/
+ vin-supply = <>;
};
leds {
--
2.23.0
[PATCHv4-next 3/3] arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power failed warning
130
[3.128575] ret_from_fork+0x10/0x1c
[3.132110] ---[ end trace 51a68f4c0035d6c1 ]---
[3.136753] dwc2: probe of c900.usb failed with error -22
Fixes: 5a0803bd5ae2 ("ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes")
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Acked-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
Rebased on linux-next
Added Acked by Martin
[0] https://patchwork.kernel.org/patch/10757569/
Earlier my approach to initialize the usb0 bus was limited, some more
phy tuning is required both at driver and u-boot to get this feature
working. So for now just disable this.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index d4c8b896dd26..3e51f0835c8d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -312,7 +312,7 @@
};
_phy {
- status = "okay";
+ status = "disabled";
phy-supply = <_otg_pwr>;
};
@@ -322,7 +322,7 @@
};
{
- status = "okay";
+ status = "disabled";
};
{
--
2.23.0
[PATCHv4-next 0/3] Odroid c2 usb fixs rebase on linux-next
Some time ago I had tired to enable usb bus 1 for Odroid C2/C1 but it's look like some more work is needed to u-boot and usb_phy driver to initialize this port. Below patches tries to address the issue regarding usb bus 2 (4 port) while disable the usb bus 1 on this board. Previous patch [0] https://lkml.org/lkml/2019/1/29/325 Re send below series based re based on linux-next-20190830. For review and testing. [1] https://patchwork.kernel.org/cover/3091/ Small changes from previous series. Fix the commit message for patch 1 Best Regards -Anand Anand Moon (3): arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power failed warning .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 20 +-- 1 file changed, 18 insertions(+), 2 deletions(-) -- 2.23.0
Re: [PATCHv1 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
Hi Martin, On Mon, 2 Sep 2019 at 03:23, Martin Blumenstingl wrote: > > Hi Anand, > > On Sun, Sep 1, 2019 at 3:58 PM Anand Moon wrote: > > > > Hi Martin, > > > > Thanks for your review comments. > > > > Their have been some revision changes in S905 Odroid Schematics. > > [0] https://dn.odroid.com/S905/Schematic/ > > > > Well I have make my changes based on old odroid-c2_rev0.2_20151218.pdf > > [...] > > > > > > according to the schematics there's both: > > > - VDDIO_AO3V3 > > > - VCC3V3 (which is turned on by VDDIO_AO3V3, see [0]) > > > > > > > From the schematics it seams same. > > > > VDDIO_AO3V3---DMG340LSQN4 (Q4)---VCC3V3 > yes, they are the same signal. the only difference is that VCC3V3 is > turned on later in the power-up sequence > > > But this name change was done to link TFLASH_VDD_EN to TFLASH_VDD for eMMC > > > > VDDIO_AO3V3-TFLASH_VDD using TFLASH_VDD_EN gpio pin. > > > > Well I have tested this changes on eMMC module. > I cannot see any of the TFLASH_* regulators being linked to eMMC (they > are only linked to the SD card slot, I also checked > odroid-c2_rev0.2_20151218.pdf and odroid-c2_rev0.2_20171114.pdf). > which page of the odroid-c2_rev0.2_20151218.pdf schematics shows how > TFLASH_VDD is linked to eMMC? > > please note that I don't have an Odroid-C2 board myself (so I cannot > test any of this). > > > Martin Thanks I will double check again and re-post then with correction again. Best Regards -Anand
Re: [PATCHv1 3/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply
Hi Martin, On Sun, 1 Sep 2019 at 17:14, Martin Blumenstingl wrote: > > Hi Anand, > > On Wed, Aug 28, 2019 at 10:27 PM Anand Moon wrote: > > > > As per shematics HDMI_P5V0 is supplied by P5V0 so add missing link. > typo: "schematics" > > > Cc: Martin Blumenstingl > > Cc: Jerome Brunet > > Cc: Neil Armstrong > > Signed-off-by: Anand Moon > > --- > > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > > b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > > index a078a1ee5004..47789fd50415 100644 > > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts > > @@ -213,6 +213,8 @@ > > status = "okay"; > > pinctrl-0 = <_hpd_pins>, <_i2c_pins>; > > pinctrl-names = "default"; > > + /* AP2331SA-7 */ > > + hdmi-supply = <>; > > }; > my understanding based on odroid-c2_rev0.1_20150930.pdf is that: > - there's a (fixed) hdmi_p5v0 regulator using p5v0 as input > - the hdmi_p5v0 is the hdmi-supply > > it doesn't change the functionality of this patch (since both supplies > are fixed regulators anyways) > you are already doing a nice cleanup with this series, so it would be > a shame to take a shortcut here > I could not find gpio control pin which could be used to enable hdmi-supply node. So that the reason for direct linking this to p5v0 node. But looking back at the schematics it and datasheet their are two more regulator supplies to HDMI. HDMITX_AVDD33-1 VDDIO_AO3V3 HDMITX_AVDD18-1 VCC1V8 Need to check the hdmi driver if these need to enable. Best Regards -Anand > > Martin
Re: [PATCHv1 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
Hi Martin,
Thanks for your review comments.
Their have been some revision changes in S905 Odroid Schematics.
[0] https://dn.odroid.com/S905/Schematic/
Well I have make my changes based on old odroid-c2_rev0.2_20151218.pdf
On Sun, 1 Sep 2019 at 17:07, Martin Blumenstingl
wrote:
>
> On Wed, Aug 28, 2019 at 10:27 PM Anand Moon wrote:
> >
> > As per shematics VDDIO_AO18, VDDIO_AO3V3/VDD3V3 DDR3_1V5/DDR_VDDC:
> typo: "schematics"
>
OK. next time will run spell check before I send these changes.
> > fixed regulator output which is supplied by P5V0.
> >
> > Rename vcc3v3 regulator node to vddio_ao3v3 as per shematics.
> typo: "schematics"
Ok.
>
> according to the schematics there's both:
> - VDDIO_AO3V3
> - VCC3V3 (which is turned on by VDDIO_AO3V3, see [0])
>
>From the schematics it seams same.
VDDIO_AO3V3---DMG340LSQN4 (Q4)---VCC3V3
But this name change was done to link TFLASH_VDD_EN to TFLASH_VDD for eMMC
VDDIO_AO3V3-TFLASH_VDD using TFLASH_VDD_EN gpio pin.
Well I have tested this changes on eMMC module.
> > Cc: Martin Blumenstingl
> > Cc: Jerome Brunet
> > Cc: Neil Armstrong
> > Signed-off-by: Anand Moon
> > ---
> > .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 29 +--
> > 1 file changed, 26 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > index 792698a60a12..98e742bf44c1 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > @@ -104,11 +104,34 @@
> > regulator-max-microvolt = <180>;
> > };
> >
> > - vcc3v3: regulator-vcc3v3 {
> > + vddio_ao1v8: regulator-vddio-ao1v8 {
> > compatible = "regulator-fixed";
> > - regulator-name = "VCC3V3";
> > + regulator-name = "VDDIO_AO1V8";
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <180>;
> > + regulator-always-on;
> > + /* U17 RT9179GB */
> > + vin-supply = <>;
> > + };
> > +
> > + vddio_ao3v3: regulator-vddio-ao3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VDDIO_AO3V3";
> > regulator-min-microvolt = <330>;
> > regulator-max-microvolt = <330>;
> > + regulator-always-on;
> > + /* U11 MP2161GJ-C499 */
> > + vin-supply = <>;
> > + };
> > +
> > + vddc_ddr: regulator-vddc-ddr {
> > + compatible = "regulator-fixed";
> > + regulator-name = "DDR_VDDC";
> personally I would call this (along with the node name and alias) DDR3_1V5
> odroid-c2_rev0.1_20150930.pdf shows that DDR3_1V5 and DDR_VDDC are
> both the same. however, the DDR_VDDC signal name is not used by any
> component in the datasheet
Ok Thanks I will change this to DDR3_1V5 as per the datasheet.
>
> > + regulator-min-microvolt = <150>;
> > + regulator-max-microvolt = <150>;
> > + regulator-always-on;
> > + /* U15 MP2161GJ-C499 */
> > + vin-supply = <>;
> > };
> >
> > emmc_pwrseq: emmc-pwrseq {
> > @@ -301,7 +324,7 @@
> > mmc-hs200-1_8v;
> >
> > mmc-pwrseq = <_pwrseq>;
> > - vmmc-supply = <>;
> > + vmmc-supply = <_ao3v3>;
> odroid-c2_rev0.1_20150930.pdf uses VCC3V3 as supply
>
>
> Martin
Best Regards
-Anand
Re: [PATCHv1 2/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator
Hi Martin,
Thanks of your review comments.
On Sun, 1 Sep 2019 at 17:11, Martin Blumenstingl
wrote:
>
> On Wed, Aug 28, 2019 at 10:27 PM Anand Moon wrote:
> >
> > As per shematics TFLASH_VDD, TF_IO, VCC3V3 fixed regulator output which
> typo: "schematics"
>
Ok
> > is supplied by VDDIO_AO3V3.
> please add a short sentence to the description (since you probably
> have to re-send a v2) like:
> "While here, move the comment name with the signal name in the
> schematics above the gpio property to make it consistent with other
> regulators"
>
Ok I will append this in next version.
> > Cc: Martin Blumenstingl
> > Cc: Jerome Brunet
> > Cc: Neil Armstrong
> > Signed-off-by: Anand Moon
> with the patch rebased (see below) and the two issues from above addressed:
> Reviewed-by: Martin Blumenstingl
>
> > ---
> > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 13 ++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > index 98e742bf44c1..a078a1ee5004 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > @@ -67,17 +67,19 @@
> > };
> >
> > tflash_vdd: regulator-tflash_vdd {
> > - /*
> > -* signal name from schematics: TFLASH_VDD_EN
> > -*/
> > compatible = "regulator-fixed";
> >
> > regulator-name = "TFLASH_VDD";
> > regulator-min-microvolt = <330>;
> > regulator-max-microvolt = <330>;
> >
> > + /*
> > +* signal name from schematics: TFLASH_VDD_EN
> > +*/
> > gpio = < GPIOY_12 GPIO_ACTIVE_HIGH>;
> > enable-active-high;
> > + /* U16 RT9179GB */
> > + vin-supply = <_ao3v3>;
> > };
> >
> > tf_io: gpio-regulator-tf_io {
> > @@ -95,6 +97,8 @@
> >
> > states = <330 0
> > 180 1>;
> > + /* U12/U13 RT9179GB */
> > + vin-supply = <_ao3v3>;
> > };
> thank you for the patch but I think it won't apply on top of Neil's
> "arm64: dts: meson: fix boards regulators states format" (which was
> applied just after you sent this series)
>
>
> Martin
Ok will re-base these changes on linux-next next time.
Best Regards
-Anand
Re: [PATCHv1 0/3] Odroid c2 missing regulator linking
Hi Neil, On Fri, 30 Aug 2019 at 13:01, Neil Armstrong wrote: > > On 29/08/2019 20:35, Anand Moon wrote: > > Hi Neil, > > > > On Thu, 29 Aug 2019 at 13:58, Neil Armstrong > > wrote: > >> > >> On 28/08/2019 22:27, Anand Moon wrote: > >>> Below small changes help re-configure or fix missing inter linking > >>> of regulator node. > >>> > >>> Changes based top on my prevoius series. > >> > >> For the serie: > >> Reviewed-by: Neil Armstrong > >> > > > > Thanks for your review. > > > >>> > >>> [0] https://patchwork.kernel.org/cover/3091/ > >>> > >>> TOOD: Add support for DVFS GXBB odroid board in next series. > >> > >> I'm curious how you will do this ! > > > > I was just studying you previous series on how you have implemented > > this feature for C1, N2 and VIM3 boards. > > > > [0] https://patchwork.kernel.org/cover/4125/ > > > > I started gathering key inputs needed for this ie *clk / pwm* > > like VDDCPU and VDDE clk changes. > > > > But it looks like of the complex clk framework needed, so I leave this to > > the > > expert like your team of developers to do this much quick and efficiently. > > On GXBB, GXL, GXM and AXG SoCs, CPU Frequency setting and PWM Regulator setup > is > done by the SCPI Co-processor via the SCPI protocol. > > Thus, we should not handle it from Linux, and even if we could, we don't have > the > registers documentation of the CPU clusters clock tree. > Ok thanks. > SCPI works fine on all tested devices, except Odroid-C2, because Hardkernel > left > the > 1.5GHz freq in the initial SCPI tables loaded by the BL2, i.e. packed > with U-Boot. > Nowadays they have removed the bad frequencies, but still some devices uses > the old > bootloader. > > But in the SCPI case we trust the table returned by the firmware and use it > as-in, > and there is no (simple ?) way to override the table and set a max frequency. > > This is why we disabled SCPI. > > See https://patchwork.kernel.org/patch/9500175/ I have quickly enable this on my board and here the cpufreq info [alarm@alarm ~]$ cpupower frequency-info analyzing CPU 0: driver: scpi-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 200 us hardware limits: 100.0 MHz - 1.54 GHz available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 1000 MHz, 1.30 GHz, 1.54 GHz available cpufreq governors: conservative ondemand userspace powersave performance schedutil current policy: frequency should be within 100.0 MHz and 1.54 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: Unable to call hardware current CPU frequency: 250 MHz (asserted by call to kernel) I did some simple stress testing and observed the freq scaling is working fine when cpufreq governor is set to ondemand. Powertop output. Package |CPU 0 100 MHz 5.2% | 100 MHz 1.6% 250 MHz 4.4% | 250 MHz 4.3% 500 MHz 2.6% | 500 MHz 2.4% 1000 MHz 0.5% | 1000 MHz 0.3% 1296 MHz 0.2% | 1296 MHz 0.1% 1.54 GHz 0.2% | 1.54 GHz 0.1% Idle86.9% | Idle91.2% Here the output on the linaro's pm-qa testing for cpufreq. [1] https://pastebin.com/h880WATn Almost all the test case pass with this one as off now. Best Regards -Anand
Re: [PATCHv1 0/3] Odroid c2 missing regulator linking
Hi Neil, On Thu, 29 Aug 2019 at 13:58, Neil Armstrong wrote: > > On 28/08/2019 22:27, Anand Moon wrote: > > Below small changes help re-configure or fix missing inter linking > > of regulator node. > > > > Changes based top on my prevoius series. > > For the serie: > Reviewed-by: Neil Armstrong > Thanks for your review. > > > > [0] https://patchwork.kernel.org/cover/3091/ > > > > TOOD: Add support for DVFS GXBB odroid board in next series. > > I'm curious how you will do this ! I was just studying you previous series on how you have implemented this feature for C1, N2 and VIM3 boards. [0] https://patchwork.kernel.org/cover/4125/ I started gathering key inputs needed for this ie *clk / pwm* like VDDCPU and VDDE clk changes. But it looks like of the complex clk framework needed, so I leave this to the expert like your team of developers to do this much quick and efficiently. Best Regards, -Anand
[PATCHv1 3/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply
As per shematics HDMI_P5V0 is supplied by P5V0 so add missing link.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index a078a1ee5004..47789fd50415 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -213,6 +213,8 @@
status = "okay";
pinctrl-0 = <_hpd_pins>, <_i2c_pins>;
pinctrl-names = "default";
+ /* AP2331SA-7 */
+ hdmi-supply = <>;
};
_tx_tmds_port {
--
2.23.0
[PATCHv1 2/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator
As per shematics TFLASH_VDD, TF_IO, VCC3V3 fixed regulator output which
is supplied by VDDIO_AO3V3.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 98e742bf44c1..a078a1ee5004 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -67,17 +67,19 @@
};
tflash_vdd: regulator-tflash_vdd {
- /*
-* signal name from schematics: TFLASH_VDD_EN
-*/
compatible = "regulator-fixed";
regulator-name = "TFLASH_VDD";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
+ /*
+* signal name from schematics: TFLASH_VDD_EN
+*/
gpio = < GPIOY_12 GPIO_ACTIVE_HIGH>;
enable-active-high;
+ /* U16 RT9179GB */
+ vin-supply = <_ao3v3>;
};
tf_io: gpio-regulator-tf_io {
@@ -95,6 +97,8 @@
states = <330 0
180 1>;
+ /* U12/U13 RT9179GB */
+ vin-supply = <_ao3v3>;
};
vcc1v8: regulator-vcc1v8 {
@@ -102,6 +106,9 @@
regulator-name = "VCC1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-always-on;
+ /* U18 RT9179GB */
+ vin-supply = <_ao3v3>;
};
vddio_ao1v8: regulator-vddio-ao1v8 {
--
2.23.0
[PATCHv1 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
As per shematics VDDIO_AO18, VDDIO_AO3V3/VDD3V3 DDR3_1V5/DDR_VDDC:
fixed regulator output which is supplied by P5V0.
Rename vcc3v3 regulator node to vddio_ao3v3 as per shematics.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
.../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 29 +--
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 792698a60a12..98e742bf44c1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -104,11 +104,34 @@
regulator-max-microvolt = <180>;
};
- vcc3v3: regulator-vcc3v3 {
+ vddio_ao1v8: regulator-vddio-ao1v8 {
compatible = "regulator-fixed";
- regulator-name = "VCC3V3";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ /* U17 RT9179GB */
+ vin-supply = <>;
+ };
+
+ vddio_ao3v3: regulator-vddio-ao3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO3V3";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
+ regulator-always-on;
+ /* U11 MP2161GJ-C499 */
+ vin-supply = <>;
+ };
+
+ vddc_ddr: regulator-vddc-ddr {
+ compatible = "regulator-fixed";
+ regulator-name = "DDR_VDDC";
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-always-on;
+ /* U15 MP2161GJ-C499 */
+ vin-supply = <>;
};
emmc_pwrseq: emmc-pwrseq {
@@ -301,7 +324,7 @@
mmc-hs200-1_8v;
mmc-pwrseq = <_pwrseq>;
- vmmc-supply = <>;
+ vmmc-supply = <_ao3v3>;
vqmmc-supply = <>;
};
--
2.23.0
[PATCHv1 0/3] Odroid c2 missing regulator linking
Below small changes help re-configure or fix missing inter linking of regulator node. Changes based top on my prevoius series. [0] https://patchwork.kernel.org/cover/3091/ TOOD: Add support for DVFS GXBB odroid board in next series. Best Regards -Anand Anand Moon (3): arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 44 --- 1 file changed, 38 insertions(+), 6 deletions(-) -- 2.23.0
Re: [PATCHv4 0/3] Odroid c2 usb fixs
Hi Martin, On Sun, 25 Aug 2019 at 02:48, Martin Blumenstingl wrote: > > Hi Anand, > > thank you for the patches > > On Sat, Aug 24, 2019 at 8:49 PM Anand Moon wrote: > [...] > > Anand Moon (3): > > arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input > > arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus > > arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power > > failed warning > this whole series is: > Acked-by: Martin Blumenstingl Thanks, I have some more patch in line for this board. Best Regards -Anand
[PATCHv4 1/3] arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input
As per the schematic Monolithic Power Systems MP2161GJ-C499
supply a fixed output voltage of 5.0V. This supplies linked
to VDD_EE, HDMI_P5V0, USB_POWER, VCCK, VDDIO_AO1V8, DDR_VDDC
according to the schematics.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
Changes from my previous attempt below
[1] https://lore.kernel.org/patchwork/patch/1031243/
New patch and fix the commit message.
Added regulator-always-on since this is core input regulator.
Split the linking on regulator and usb node in separate patch.
Later more patchs will follow linking more core regulator as per
shematics.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 9972b1515da6..41d5fa370eb3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -50,6 +50,15 @@
};
};
+ p5v0: regulator-p5v0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "P5V0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
tflash_vdd: regulator-tflash_vdd {
/*
* signal name from schematics: TFLASH_VDD_EN
--
2.23.0
[PATCHv4 2/3] arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus
Add missing linking regulator node to usb bus for power usb devices.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
Changes from previous patch
[1] https://lore.kernel.org/patchwork/patch/1031243/
split the changes and add the comments to power source
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 41d5fa370eb3..f3dcabf97c63 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -36,8 +36,15 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
+ /*
+* signal name from schematics: PWREN
+*/
gpio = <_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
enable-active-high;
+ /*
+* signal name from sehematics: USB_POWER
+*/
+ vin-supply = <>;
};
leds {
--
2.23.0
[PATCHv4 3/3] arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power failed warning
130
[3.128575] ret_from_fork+0x10/0x1c
[3.132110] ---[ end trace 51a68f4c0035d6c1 ]---
[3.136753] dwc2: probe of c900.usb failed with error -22
Fixes: 5a0803bd5ae2 ("ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes")
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Signed-off-by: Anand Moon
---
[0] https://patchwork.kernel.org/patch/10757569/
Earlier my approach to initialize the usb0 bus was limited, some more
phy tuning is required both at driver and u-boot to get this feature
working. So for now just disable this.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index f3dcabf97c63..792698a60a12 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -312,7 +312,7 @@
};
_phy {
- status = "okay";
+ status = "disabled";
phy-supply = <_otg_pwr>;
};
@@ -322,7 +322,7 @@
};
{
- status = "okay";
+ status = "disabled";
};
{
--
2.23.0
[PATCHv4 0/3] Odroid c2 usb fixs
Some time ago I had tired to enable usb bus 1 for Odroid C2/C1 but it's look like some more work is needed to u-boot and usb_phy driver to initialize this port. Below patches tries to address the issue regarding usb bus 2 (4 port) while disable the usb bus 1 on this board. Prevoius patch [0] https://lkml.org/lkml/2019/1/29/325 I have tried to split the patchs for now. Anand Moon (3): arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power failed warning .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 20 +-- 1 file changed, 18 insertions(+), 2 deletions(-) -- 2.23.0
Re: [PATCH] arm64: dts: meson: odroid-n2: keep SD card regulator always on
Hi Neil,
On Wed, 24 Jul 2019 at 12:19, Neil Armstrong wrote:
>
> Hi Anand,
>
> On 24/07/2019 07:30, Anand Moon wrote:
> > Hi All,
> >
> > On Mon, 22 Jul 2019 at 12:51, Neil Armstrong
> > wrote:
> >>
> >> On 19/07/2019 21:29, Xavier Ruppen wrote:
> >>> When powering off the Odroid N2, the tflash_vdd regulator is
> >>> automatically turned off by the kernel. This is a problem
> >>> when issuing the "reboot" command while using an SD card.
> >>> The boot ROM does not power this regulator back on, blocking
> >>> the reboot process at the boot ROM stage, preventing the
> >>> SD card from being detected.
> >>>
> >>> Adding the "regulator-always-on" property fixes the problem.
> >>>
> >>> Signed-off-by: Xavier Ruppen
> >>> ---
> >>>
> >>> Here is what the boot ROM output looks like without this patch:
> >>>
> >>> [root@alarm ~]# reboot
> >>> [...]
> >>> [ 24.275860] shutdown[1]: All loop devices detached.
> >>> [ 24.278864] shutdown[1]: Detaching DM devices.
> >>> [ 24.287105] kvm: exiting hardware virtualization
> >>> [ 24.318776] reboot: Restarting system
> >>> bl31 reboot reason: 0xd
> >>> bl31 reboot reason: 0x0
> >>> system cmd 1.
> >>> G12B:BL:6e7c85:7898ac;FEAT:E0F83180:2000;POC:F;RCY:0;
> >>> EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:1;EMMC:800;
> >>> NAND:81;SD?:0;SD:400;USB:8;LOOP:2;EMMC:800;NAND:81;
> >>> SD?:0;SD:400;USB:8;LOOP:3; [...]
> >>>
> >>> Other people can be seen having this problem on the odroid
> >>> forum [1].
> >>>
> >>> The cause of the problem was found by Martin Blumenstingl
> >>> on #linux-amlogic. We may want to add his Suggested-by tag
> >>> if he agrees.
> >>>
> >>> [1] https://forum.odroid.com/viewtopic.php?f=176=33993
> >>>
> >>> arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> >>> b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> >>> index 81780ffcc7f0..4e916e1f71f7 100644
> >>> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> >>> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> >>> @@ -53,6 +53,7 @@
> >>>
> >>> gpio = <_ao GPIOAO_8 GPIO_ACTIVE_HIGH>;
> >>> enable-active-high;
> >>> + regulator-always-on;
> >>> };
> >>>
> >>> tf_io: gpio-regulator-tf_io {
> >>>
> >>
> >> Surely solves the situation, thanks !
> >>
> >> please add a comment on top of "regulator-always-on" to explain why we
> >> always enable it,
> >> note we should always enable it in case of watchdog reboot or other
> >> uncontrolled reset,
> >> this regulator must never be disabled.
> >>
> >> Reviewed-by: Neil Armstrong
> >>
> >> Thanks,
> >> Neil
> >>
> >
> > I am afraid this did not fix the issue I was also facing with
> > Archlinux on Odroid N2 using mainline u-boot.
>
> Seems to be a separate issue, could we start a separate thread with all your
> setup (branch, git SHAa, configs, board setup, ...) for this ?
>
> Thanks,
> Neil
>
Ok sorry for the noise.
Best Regards
-Anand
Re: [PATCH] arm64: dts: meson: odroid-n2: keep SD card regulator always on
Hi All,
On Mon, 22 Jul 2019 at 12:51, Neil Armstrong wrote:
>
> On 19/07/2019 21:29, Xavier Ruppen wrote:
> > When powering off the Odroid N2, the tflash_vdd regulator is
> > automatically turned off by the kernel. This is a problem
> > when issuing the "reboot" command while using an SD card.
> > The boot ROM does not power this regulator back on, blocking
> > the reboot process at the boot ROM stage, preventing the
> > SD card from being detected.
> >
> > Adding the "regulator-always-on" property fixes the problem.
> >
> > Signed-off-by: Xavier Ruppen
> > ---
> >
> > Here is what the boot ROM output looks like without this patch:
> >
> > [root@alarm ~]# reboot
> > [...]
> > [ 24.275860] shutdown[1]: All loop devices detached.
> > [ 24.278864] shutdown[1]: Detaching DM devices.
> > [ 24.287105] kvm: exiting hardware virtualization
> > [ 24.318776] reboot: Restarting system
> > bl31 reboot reason: 0xd
> > bl31 reboot reason: 0x0
> > system cmd 1.
> > G12B:BL:6e7c85:7898ac;FEAT:E0F83180:2000;POC:F;RCY:0;
> > EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:1;EMMC:800;
> > NAND:81;SD?:0;SD:400;USB:8;LOOP:2;EMMC:800;NAND:81;
> > SD?:0;SD:400;USB:8;LOOP:3; [...]
> >
> > Other people can be seen having this problem on the odroid
> > forum [1].
> >
> > The cause of the problem was found by Martin Blumenstingl
> > on #linux-amlogic. We may want to add his Suggested-by tag
> > if he agrees.
> >
> > [1] https://forum.odroid.com/viewtopic.php?f=176=33993
> >
> > arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > index 81780ffcc7f0..4e916e1f71f7 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > @@ -53,6 +53,7 @@
> >
> > gpio = <_ao GPIOAO_8 GPIO_ACTIVE_HIGH>;
> > enable-active-high;
> > + regulator-always-on;
> > };
> >
> > tf_io: gpio-regulator-tf_io {
> >
>
> Surely solves the situation, thanks !
>
> please add a comment on top of "regulator-always-on" to explain why we always
> enable it,
> note we should always enable it in case of watchdog reboot or other
> uncontrolled reset,
> this regulator must never be disabled.
>
> Reviewed-by: Neil Armstrong
>
> Thanks,
> Neil
>
I am afraid this did not fix the issue I was also facing with
Archlinux on Odroid N2 using mainline u-boot.
Here is the log of at my end using latest mainline u-boot with Neil's patches.
[0] https://pastebin.com/HNmeY5uF
Well this issue also persist with eMMC not getting detected after reboot
If I try to change the dts to fix the sdcard.
I am checking this should we enable regulator-boot-on option but still no luck.
Best Regards
-Anand
[RFC/RFT 5/5] phy: exynos5-usbdrd: drop duplicate setting PIPE3 tune signal
Drop duplicate configuration setting of PIPE tune signal. Signed-off-by: Anand Moon --- drivers/phy/samsung/phy-exynos5-usbdrd.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c b/drivers/phy/samsung/phy-exynos5-usbdrd.c index 4f16c4f82ae5..f6d2f359d88a 100644 --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c @@ -410,12 +410,6 @@ static void exynos5_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd) PHYPARAM0_COMPDISTUNE(0x6)); writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_PHYPARAM0); - reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYPARAM1); - /* Set Tx De-Emphasis level */ - reg &= ~PHYPARAM1_PCS_TXDEEMPH_MASK; - reg |= PHYPARAM1_PCS_TXDEEMPH; - writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_PHYPARAM1); - /* UTMI Power Control */ writel(PHYUTMI_OTGDISABLE, phy_drd->reg_phy + EXYNOS5_DRD_PHYUTMI); -- 2.22.0
[RFC/RFT 3/5] phy: exynos5-usbdrd: UTMI tune signal
Tune USB2.0 (UTMI+) TX signal for high speed data transfer. Signed-off-by: Anand Moon --- drivers/phy/samsung/phy-exynos5-usbdrd.c | 42 +--- 1 file changed, 37 insertions(+), 5 deletions(-) diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c b/drivers/phy/samsung/phy-exynos5-usbdrd.c index 135114d51bc1..54a513ca15e4 100644 --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c @@ -33,6 +33,8 @@ #define EXYNOS5_FSEL_24MHZ 0x5 #define EXYNOS5_FSEL_50MHZ 0x7 +#define __set(v, a, b) (((v) << (b)) & GENMASK(a, b)) + /* EXYNOS5: USB 3.0 DRD PHY registers */ #define EXYNOS5_DRD_LINKSYSTEM 0x04 @@ -108,8 +110,17 @@ #define EXYNOS5_DRD_PHYPARAM0 0x1c #define PHYPARAM0_REF_USE_PAD BIT(31) -#define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f << 26) -#define PHYPARAM0_REF_LOSLEVEL (0x9 << 26) +#define PHYPARAM0_REF_LOSLEVEL(x) __set(x, 30, 26) +#define PHYPARAM0_TXVREFTUNE(x)__set(x, 25, 22) +#define PHYPARAM0_TXISETUNE(x) __set(x, 21, 20) +#define PHYPARAM0_TXRESTUNE(x) __set(x, 19, 18) +#define PHYPARAM0_TXPREEMPPULSETUNEBIT(17) +#define PHYPARAM0_TXPREEMPAMPTUNE(x) __set(x, 16, 15) +#define PHYPARAM0_TXHSXVTUNE(x)__set(x, 14, 13) +#define PHYPARAM0_TXFSLSTUNE(x)__set(x, 12, 9) +#define PHYPARAM0_SQRXTUNE(x) __set(x, 8, 6) +#define PHYPARAM0_OTGTUNE(x) __set(x, 5, 3) +#define PHYPARAM0_COMPDISTUNE(x) __set(x, 2, 0) #define EXYNOS5_DRD_PHYPARAM1 0x20 @@ -365,9 +376,30 @@ static void exynos5_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd) u32 reg; reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYPARAM0); - /* Set Loss-of-Signal Detector sensitivity */ - reg &= ~PHYPARAM0_REF_LOSLEVEL_MASK; - reg |= PHYPARAM0_REF_LOSLEVEL; + /* Set Loss-of-Signal Detector sensitivity */ + reg |= (PHYPARAM0_REF_USE_PAD | + /* Sets the sensitivity level for the Loss-of-Signal detector */ + PHYPARAM0_REF_LOSLEVEL(0x9) | + /* Adjusts the high-speed DC level voltage */ + PHYPARAM0_TXVREFTUNE(0x3) | + /* Adjust the rise/fal timie of the high-speed waveform */ + PHYPARAM0_TXISETUNE(0x1) | + /* Adjusts the driver source impedance */ + PHYPARAM0_TXRESTUNE(0x1) | + /* HS Transmitter Pre-Emphasis Duration Control */ + PHYPARAM0_TXPREEMPPULSETUNE | + /* HS Transmitter Pre-Emphasis Current Control */ + PHYPARAM0_TXPREEMPAMPTUNE(0x0) | + /* Transmitter High-Speed Crossover Adjustment */ + PHYPARAM0_TXHSXVTUNE(0x3) | + /* FS/LS Source Impedance Adjustment */ + PHYPARAM0_TXFSLSTUNE(0x3) | + /* Squelch Threshold Adjustment */ + PHYPARAM0_SQRXTUNE(0x3) | + /* VBUS Valid Threshold Adjustment */ + PHYPARAM0_OTGTUNE(0x6) | + /* Disconnect Threshold Adjustment */ + PHYPARAM0_COMPDISTUNE(0x6)); writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_PHYPARAM0); reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYPARAM1); -- 2.22.0
[RFC/RFT 4/5] phy: exynos5-usbdrd: PIPE3 tune signal
Tune USB3.0 (PIPE3) PHY TX signal for high and supper
speed data transfer.
Signed-off-by: Anand Moon
---
drivers/phy/samsung/phy-exynos5-usbdrd.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index 54a513ca15e4..4f16c4f82ae5 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -124,8 +124,10 @@
#define EXYNOS5_DRD_PHYPARAM1 0x20
-#define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f << 0)
-#define PHYPARAM1_PCS_TXDEEMPH (0x1c)
+#define PHYPARAM1_TX0_TERM_OFFSET(x) __set(x, 30, 26)
+#define PHYPARAM1_TX_SWING_FULL(x) __set(x, 18, 12)
+#define PHYPRAAM1_PCS_TX_DEEMPH_6DB(x) __set(x, 11, 6)
+#define PHYPRAAM1_PCS_TX_DEEMPH_3P5DB(x) __set(x, 5, 0)
#define EXYNOS5_DRD_PHYTERM0x24
@@ -360,10 +362,16 @@ static void exynos5_usbdrd_pipe3_init(struct
exynos5_usbdrd_phy *phy_drd)
{
u32 reg;
- reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYPARAM1);
/* Set Tx De-Emphasis level */
- reg &= ~PHYPARAM1_PCS_TXDEEMPH_MASK;
- reg |= PHYPARAM1_PCS_TXDEEMPH;
+ reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYPARAM1);
+ /* Transmitter Termination Offset */
+ reg |= PHYPARAM1_TX0_TERM_OFFSET(0x5) |
+ /* Tx Amplitude (Full Swing mode) */
+ PHYPARAM1_TX_SWING_FULL(0x3F) |
+ /* Tx De-Emphasis at 6 dB */
+ PHYPRAAM1_PCS_TX_DEEMPH_6DB(0x20) |
+ /* Tx De-Emphasis at 3.5 dB */
+ PHYPRAAM1_PCS_TX_DEEMPH_3P5DB(0x15);
writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_PHYPARAM1);
reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYTEST);
--
2.22.0
[RFC/RFT 2/5] phy: exynos5-usbdrd: add missing tuning of the phyutmi signal
Add missing tuning of phyutmi controls to enter suspend and resume state. Signed-off-by: Anand Moon --- drivers/phy/samsung/phy-exynos5-usbdrd.c | 32 ++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c b/drivers/phy/samsung/phy-exynos5-usbdrd.c index 3c14bf7718c1..135114d51bc1 100644 --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c @@ -42,7 +42,13 @@ #define EXYNOS5_DRD_PHYUTMI0x08 +#define PHYUTMI_TXBITSTUFFENH BIT(8) +#define PHYUTMI_TXBITSTUFFEN BIT(7) #define PHYUTMI_OTGDISABLE BIT(6) +#define PHYUTMI_IDPULLUP BIT(5) +#define PHYUTMI_DRVVBUSBIT(4) +#define PHYUTMI_DPPULLDOWN BIT(3) +#define PHYUTMI_DMPULLDOWN BIT(2) #define PHYUTMI_FORCESUSPEND BIT(1) #define PHYUTMI_FORCESLEEP BIT(0) @@ -402,6 +408,23 @@ static int exynos5_usbdrd_phy_init(struct phy *phy) LINKSYSTEM_FLADJ(0x20); writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_LINKSYSTEM); + reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYUTMI); + /* High-Byte Transmit Bit-Stuffing Enable */ + reg |= PHYUTMI_TXBITSTUFFENH; + /* Low-Byte Transmit Bit-Stuffing Enable */ + reg |= PHYUTMI_TXBITSTUFFEN; + /* release force_sleep & force_suspend */ + reg &= ~(PHYUTMI_FORCESLEEP | PHYUTMI_FORCESUSPEND); + /* DP/DM Pull Down Disable */ + reg &= ~(PHYUTMI_DMPULLDOWN | PHYUTMI_DPPULLDOWN); + /* drvvbus controller signal controls the VBUS valid comparator */ + reg &= ~PHYUTMI_OTGDISABLE; + /* controller signal controls the VBUS Valid comparator */ + reg |= PHYUTMI_DRVVBUS; + /* Enable ID Sampling */ + reg |= PHYUTMI_IDPULLUP; + writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_PHYUTMI); + reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYPARAM0); /* Select PHY CLK source */ reg &= ~PHYPARAM0_REF_USE_PAD; @@ -452,9 +475,14 @@ static int exynos5_usbdrd_phy_exit(struct phy *phy) if (ret) return ret; - reg = PHYUTMI_OTGDISABLE | + reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYUTMI); + reg |= PHYUTMI_OTGDISABLE | PHYUTMI_FORCESUSPEND | - PHYUTMI_FORCESLEEP; + PHYUTMI_FORCESLEEP | + PHYUTMI_DMPULLDOWN | + PHYUTMI_DPPULLDOWN; + reg &= ~(PHYUTMI_DRVVBUS | PHYUTMI_IDPULLUP | + PHYUTMI_TXBITSTUFFENH | PHYUTMI_TXBITSTUFFEN); writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_PHYUTMI); /* Resetting the PHYCLKRST enable bits to reduce leakage current */ -- 2.22.0
[RFC/RFT 1/5] phy: exynos5-usbdrd: read from correct offset of xhci linksystem
Read from linksystem offset to update the xhci version. Signed-off-by: Anand Moon --- drivers/phy/samsung/phy-exynos5-usbdrd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c b/drivers/phy/samsung/phy-exynos5-usbdrd.c index 646259bee909..3c14bf7718c1 100644 --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c @@ -397,7 +397,8 @@ static int exynos5_usbdrd_phy_init(struct phy *phy) * Setting the Frame length Adj value[6:1] to default 0x20 * See xHCI 1.0 spec, 5.2.4 */ - reg = LINKSYSTEM_XHCI_VERSION_CONTROL | + reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_LINKSYSTEM); + reg |= LINKSYSTEM_XHCI_VERSION_CONTROL | LINKSYSTEM_FLADJ(0x20); writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_LINKSYSTEM); -- 2.22.0
[RFC/RFT 0/5] Exynos USB 3.0 PHY tune setting
Dear All, Here are some patches which help tune USB 3.0 phy. changes have been testing on Odroid XU3 / XU4 / HC1. with suspend and resume working with usb hdd device connected. These patches have been build on top on Marek Szyprowski Fix USB3.0 DRD PHY calibration issues. [0] https://patchwork.kernel.org/cover/11049823/ Anand Moon (5): phy: exynos5-usbdrd: read from correct offset of xhci linksystem phy: exynos5-usbdrd: add missing tuning of the phyutmi signal phy: exynos5-usbdrd: UTMI tune signal phy: exynos5-usbdrd: PIPE3 tune signal phy: exynos5-usbdrd: drop duplicate setting PIPE3 tune signal drivers/phy/samsung/phy-exynos5-usbdrd.c | 101 ++- 1 file changed, 82 insertions(+), 19 deletions(-) -- 2.22.0
Re: [PATCH 0/3] Fix USB3.0 DRD PHY calibration issues (DWC3/XHCI) on Exynos542x SoCs
Hi Marek,
On Mon, 15 Jul 2019 at 17:49, Marek Szyprowski wrote:
>
> Hi Anand,
>
> On 2019-06-28 17:32, Anand Moon wrote:
> > Hi Marek,
> >
> > On Thu, 27 Jun 2019 at 12:47, Marek Szyprowski
> > wrote:
> >> Dear All,
> >>
> >> Commit d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
> >> exynos5420/5800") added support for Exynos5 USB3.0 DRD PHY calibration,
> >> what enabled proper Super-Speed enumeration of USB3.0 devices connected
> >> to various Exynos5 SoCs. After some time it turned out that the mentioned
> >> patch worked a bit by pure luck and covered only one use case (fresh
> >> boot with all drivers compiled into the kernel).
> >>
> >> If drivers were compiled as modules, due to timing issue, it worked only
> >> if XHCI-plat driver was loaded before the DWC3 driver:
> >> https://patchwork.kernel.org/patch/10773947/
> >>
> >> Also during the system suspend/resume cycle the calibration was not
> >> performed at the proper time and resulted in switching USB 3.0 devices to
> >> USB 2.0 high-speed compatibility mode.
> >>
> >> This patch addresses all those issues. Exynos5 USB3.0 DRD PHY calibration
> >> is moved to the Exynos5 specific variant of the XHCI-plat driver, which
> >> takes care of proper PHY calibration after XHCI core reset. This fixes
> >> all known use cases (XHCI driver compiled as module and loaded on demand
> >> as well as during system suspend/resume cycle).
> >>
> >> Here are the logs taken on Exynos5422-based Odroid HC1 board (with USB3.0
> >> RTL8153 LAN and USB3.0 JMicron SATA-USB bridge):
> >>
> > Thanks for these patch. I have tested on linux-next-20190626
> >
> > *But hotpluging of usb device is not working on usb ports.*
>
> Well, this is a bit poor report. I've checked various USB 3.0 devices
> with my XU4 board and didn't observe any issue with hotplug or
> enumeration. Could you describe a bit more how to trigger the issue?
>
Sorry for the noise one of my usb 3.0 port on XU4 is not working somehow.
I will re-test these patches again on current next and share my result.
> > These patches fix the suspend/resume for XU4.
> > But their is two issue.
> > 1> On warm boot fails to reset the usb hub
> > --
> > [7.019896] usb 4-1.1: new SuperSpeed Gen 1 USB device number 3
> > using xhci-hcd
> > [7.063032] usb 4-1.1: New USB device found, idVendor=152d,
> > idProduct=0578, bcdDevice=63.01
> > [7.070484] usb 4-1.1: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=3
> > [7.077438] usb 4-1.1: Product: JMS567
> > [7.081749] usb 4-1.1: Manufacturer: JMicron
> > [7.086028] usb 4-1.1: SerialNumber: DB12345678A3
> > [7.151572] scsi host0: uas
> > [7.162765] scsi 0:0:0:0: Direct-Access KINGSTON SA400S37120G
> >6301 PQ: 0 ANSI: 6
> > [7.176231] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks:
> > (120 GB/112 GiB)
> > [7.177550] sd 0:0:0:0: Attached scsi generic sg0 type 0
> > [7.183547] sd 0:0:0:0: [sda] 4096-byte physical blocks
> > [7.201150] sd 0:0:0:0: [sda] Write Protect is off
> > [7.204977] sd 0:0:0:0: [sda] Disabling FUA
> > [7.209476] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
> > enabled, doesn't support DPO or FUA
> > [7.219411] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes
> > not a multiple of physical block size (4096 bytes)
> > [7.713603] sda: sda1
> > [7.736338] sd 0:0:0:0: [sda] Attached SCSI disk
> > [ 11.372630] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while
> > waiting for setup device command
> > [ 16.650624] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while
> > waiting for setup device command
> > [ 16.870255] usb 6-1: device not accepting address 2, error -62
> > [ 22.171093] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while
> > waiting for setup device command
> > [ 27.451021] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while
> > waiting for setup device command
> > [ 27.669956] usb 6-1: device not accepting address 3, error -62
> > [ 27.711656] usb usb6-port1: attempt power cycle
> >
> > some how 1250.phy do not de-register when we perform reboot.
>
> Sorry, but this is not related to PHY at all. If I get your log right,
> you have external USB3->SATA bridge which fails to enumerate in your
> case. Does it work right with other boards or vendor kernels? You
> connect it to the XU4 onboard
Re: [PATCH 0/3] Fix USB3.0 DRD PHY calibration issues (DWC3/XHCI) on Exynos542x SoCs
Hi Marek,
On Thu, 27 Jun 2019 at 12:47, Marek Szyprowski wrote:
>
> Dear All,
>
> Commit d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
> exynos5420/5800") added support for Exynos5 USB3.0 DRD PHY calibration,
> what enabled proper Super-Speed enumeration of USB3.0 devices connected
> to various Exynos5 SoCs. After some time it turned out that the mentioned
> patch worked a bit by pure luck and covered only one use case (fresh
> boot with all drivers compiled into the kernel).
>
> If drivers were compiled as modules, due to timing issue, it worked only
> if XHCI-plat driver was loaded before the DWC3 driver:
> https://patchwork.kernel.org/patch/10773947/
>
> Also during the system suspend/resume cycle the calibration was not
> performed at the proper time and resulted in switching USB 3.0 devices to
> USB 2.0 high-speed compatibility mode.
>
> This patch addresses all those issues. Exynos5 USB3.0 DRD PHY calibration
> is moved to the Exynos5 specific variant of the XHCI-plat driver, which
> takes care of proper PHY calibration after XHCI core reset. This fixes
> all known use cases (XHCI driver compiled as module and loaded on demand
> as well as during system suspend/resume cycle).
>
> Here are the logs taken on Exynos5422-based Odroid HC1 board (with USB3.0
> RTL8153 LAN and USB3.0 JMicron SATA-USB bridge):
>
Thanks for these patch. I have tested on linux-next-20190626
*But hotpluging of usb device is not working on usb ports.*
These patches fix the suspend/resume for XU4.
But their is two issue.
1> On warm boot fails to reset the usb hub
--
[7.019896] usb 4-1.1: new SuperSpeed Gen 1 USB device number 3
using xhci-hcd
[7.063032] usb 4-1.1: New USB device found, idVendor=152d,
idProduct=0578, bcdDevice=63.01
[7.070484] usb 4-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[7.077438] usb 4-1.1: Product: JMS567
[7.081749] usb 4-1.1: Manufacturer: JMicron
[7.086028] usb 4-1.1: SerialNumber: DB12345678A3
[7.151572] scsi host0: uas
[7.162765] scsi 0:0:0:0: Direct-Access KINGSTON SA400S37120G
6301 PQ: 0 ANSI: 6
[7.176231] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks:
(120 GB/112 GiB)
[7.177550] sd 0:0:0:0: Attached scsi generic sg0 type 0
[7.183547] sd 0:0:0:0: [sda] 4096-byte physical blocks
[7.201150] sd 0:0:0:0: [sda] Write Protect is off
[7.204977] sd 0:0:0:0: [sda] Disabling FUA
[7.209476] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[7.219411] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes
not a multiple of physical block size (4096 bytes)
[7.713603] sda: sda1
[7.736338] sd 0:0:0:0: [sda] Attached SCSI disk
[ 11.372630] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while
waiting for setup device command
[ 16.650624] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while
waiting for setup device command
[ 16.870255] usb 6-1: device not accepting address 2, error -62
[ 22.171093] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while
waiting for setup device command
[ 27.451021] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while
waiting for setup device command
[ 27.669956] usb 6-1: device not accepting address 3, error -62
[ 27.711656] usb usb6-port1: attempt power cycle
some how 1250.phy do not de-register when we perform reboot.
[ 120.260813] shutdown[1]: All loop devices detached.
[ 120.308592] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 120.425890] usb 4-1.1: reset SuperSpeed Gen 1 USB device number 3
using xhci-hcd
[ 120.500085] wake enabled for irq 155
[ 120.592335] reboot: Restartin
Attach are the reboot logs.
[0] https://pastebin.com/a3d712q4
Second issue is the unbind on usb dwc3 fails.
[root@archl-xu4m ~]# cd /sys/bus/platform/drivers/exynos5_usb3drd_phy/
[root@archl-xu4m exynos5_usb3drd_phy]# ls -la
total 0
drwxr-xr-x 2 root root0 Jun 28 14:08 .
drwxr-xr-x 131 root root0 Jun 28 14:08 ..
lrwxrwxrwx 1 root root0 Jun 28 14:11 1210.phy ->
../../../../devices/platform/soc/1210.phy
lrwxrwxrwx 1 root root0 Jun 28 14:11 1250.phy ->
../../../../devices/platform/soc/1250.phy
--w--- 1 root root 4096 Jun 28 14:11 bind
--w--- 1 root root 4096 Jun 28 14:08 uevent
--w--- 1 root root 4096 Jun 28 14:11 unbind
[root@archl-xu4m exynos5_usb3drd_phy]#
[root@archl-xu4m exynos5_usb3drd_phy]#
[root@archl-xu4m exynos5_usb3drd_phy]# echo 1250.phy > unbind
[ 194.138492] [ cut here ]
[ 194.142104] WARNING: CPU: 6 PID: 292 at
drivers/regulator/core.c:2036 _regulator_put.part.4+0x110/0x118
[ 194.156913] Modules linked in: s5p_mfc s5p_jpeg exynos_gsc
v4l2_mem2mem v4l2_common videobuf2_dma_contig videobuf2_memops
videobuf2_v4l2 videobuf2_common videodev mc s5p_cec
[ 194.171542] CPU: 6 PID: 292 Comm: bash Not tainted
5.2.0-rc6-next-20190626-xu4ml #21
[ 194.178963] Hardware name: SAMSUNG EXYNOS
Re: [PATCH v2 3/4] ARM: dts: exynos: Add regulator suspend configuration to Odroid XU3/XU4/HC1 family
Hi Marek / Krzysztof, On Mon, 24 Jun 2019 at 14:31, Marek Szyprowski wrote: > > Hi Krzysztof, > > On 2019-06-24 09:41, Krzysztof Kozlowski wrote: > > On Mon, 24 Jun 2019 at 09:20, Marek Szyprowski > > wrote: > >> On 2019-06-23 18:02, Anand Moon wrote: > >>> Thanks for this patch. Please add my > >>> > >>> Tested-by: Anand Moon > >>> > >>> [snip] > >>> > >>> Could you integrate below small changes into this patch. > >>> with these below changes suspend and resume work correctly at my end. > >>> > >>> [1] XU4_suspendresume.patch > >>> > >>> As per S2MPS11B PMIC 1.2.1 Regulator (Features) > >>> Fix the min max value for *Buck7* and *Buck8* > >>> > >>> -- Buck7 (VDD_1.0V_LDO) 1.5 A (1.2 V to 1.5 V, 12.5 mV step, default on > >>> 1.35 V) > >>> -- Buck8 (VDD_1.8V_LDO) 2.5 A (1.8 V to 2.1 V, 12.5 mV step, default on > >>> 2.0 V) > >> Could you elaborate why such change for Buck7 and Buck8 is needed? > > Anand has here valid point - the constraints in DTS do not match > > hardware manual. This leads to question whether voltage table in > > driver is proper... Another point is the voltage itself. The > > schematics describes them as at specific voltage (1.35 V and 2.0 V) > > but after boot they are 1.2 V and 1.85 V. Maybe this shift comes from > > the problem above. > > > >>> Also add suspend-off for *Buck9* > >>> Buck9 internally controls the power of USB hub. > >>> Adding suspend the this node help proper reset of USB hub on Odroid > >>> XU4 / HC1/ XU3 > >>> during suspend and resume. Below it the logs from my testing. > >> Disabling Buck9 in suspend indeed reduces the power consumed by the > >> board during suspend-to-ram from about 80mA to as little as 7-10mA, what > >> matches the results of OdroidXU3. Thanks for the hint! > > Although I did not get what is the difference in the logs (Anand > > pasted two logs but they look the same) but the power consumption is > > reason is good enough. I would be happy to put in the changelog entire > > consumption difference. I can measure it on XU3-Lite but can you give > > me the XU4 (before and after)?\ > > > HC1: > > next-20190620: 120mA (@5V) > this patchset: 72mA (@5V) > this patchset + fixup from Anand: 7-10mA (@5V) > > XU4 (SDcard): > > next-20190620: 88mA (@5V) > this patchset: 74mA (@5V), sometimes 42mA (@5V) > this patchset + fixup from Anand: 6-9mA (@5V) > > > XU4 (eMMC): > > next-20190620: 100mA (@5V) > this patchset: 72mA (@5V), sometimes 41mA (@5V) > this patchset + fixup from Anand: 6-9mA (@5V) > > > Best regards > -- > Marek Szyprowski, PhD > Samsung R Institute Poland > Thanks for this results. Best Regards -Anand
Re: [PATCH v2 3/4] ARM: dts: exynos: Add regulator suspend configuration to Odroid XU3/XU4/HC1 family
Hi Krzysztof, Thanks for this patch. Please add my Tested-by: Anand Moon [snip] Could you integrate below small changes into this patch. with these below changes suspend and resume work correctly at my end. [1] XU4_suspendresume.patch As per S2MPS11B PMIC 1.2.1 Regulator (Features) Fix the min max value for *Buck7* and *Buck8* -- Buck7 (VDD_1.0V_LDO) 1.5 A (1.2 V to 1.5 V, 12.5 mV step, default on 1.35 V) -- Buck8 (VDD_1.8V_LDO) 2.5 A (1.8 V to 2.1 V, 12.5 mV step, default on 2.0 V) Also add suspend-off for *Buck9* Buck9 internally controls the power of USB hub. Adding suspend the this node help proper reset of USB hub on Odroid XU4 / HC1/ XU3 during suspend and resume. Below it the logs from my testing. [2] https://pastebin.com/pRJJmWL6 Best Regards -Anand [root@archl-xu4e ~]# rtcwake -d /dev/rtc0 -m mem -s 10 rtcwake: assuming RTC uses UTC ... rtcwake: wakeup from "mem" using /dev/rtc0 at Sun Jun 23 14:29:56 2019 [ 72.707852] PM: suspend entry (deep) [ 72.712727] Filesystems sync: 0.002 seconds [ 72.722108] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 72.730550] OOM killer disabled. [ 72.733462] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 72.815847] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 72.971552] wake enabled for irq 151 [ 73.007942] wake enabled for irq 155 [ 73.128081] samsung-pinctrl 1340.pinctrl: Setting external wakeup interrupt mask: 0xffe7 [ 73.146535] Disabling non-boot CPUs ... [ 73.225374] s3c2410-wdt 101d.watchdog: watchdog disabled [ 73.229930] usb usb1: root hub lost power or was reset [ 73.299725] usb usb2: root hub lost power or was reset [ 73.304474] wake disabled for irq 155 [ 73.314064] wake disabled for irq 151 [ 73.331117] exynos-tmu 1006.tmu: More trip points than supported by this TMU. [ 73.337297] exynos-tmu 1006.tmu: 2 trip points should be configured in polling mode. [ 73.345343] exynos-tmu 10064000.tmu: More trip points than supported by this TMU. [ 73.352807] exynos-tmu 10064000.tmu: 2 trip points should be configured in polling mode. [ 73.360916] exynos-tmu 10068000.tmu: More trip points than supported by this TMU. [ 73.368295] exynos-tmu 10068000.tmu: 2 trip points should be configured in polling mode. [ 73.376429] exynos-tmu 1006c000.tmu: More trip points than supported by this TMU. [ 73.383742] exynos-tmu 1006c000.tmu: 2 trip points should be configured in polling mode. [ 73.394345] usb usb3: root hub lost power or was reset [ 73.394704] s3c-rtc 101e.rtc: rtc disabled, re-enabling [ 73.394840] usb usb5: root hub lost power or was reset [ 73.394864] usb usb6: root hub lost power or was reset [ 73.398063] usb usb4: root hub lost power or was reset [ 73.806876] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-hcd [ 73.986504] usb 3-1: reset high-speed USB device number 2 using xhci-hcd [ 74.026814] usb 5-1: reset high-speed USB device number 2 using xhci-hcd [ 74.266364] usb 4-1.1: reset SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 74.988689] OOM killer enabled. [ 74.990372] Restarting tasks ... done. [ 74.997529] PM: suspend exit [ 75.014009] mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req 40Hz, actual 396825HZ div = 63) [root@archl-xu4e ~]# [ 75.243019] mmc_host mmc0: Bus speed (slot 0) = 2Hz (slot req 2Hz, actual 2HZ div = 0) [ 75.255929] mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req 5200Hz, actual 5000HZ div = 0) [ 75.290096] mmc_host mmc0: Bus speed (slot 0) = 4Hz (slot req 2Hz, actual 2HZ div = 1) [root@archl-xu4e ~]# rtcwake -d /dev/rtc0 -m mem -s 10 rtcwake: assuming RTC uses UTC ... rtcwake: wakeup from "mem" using /dev/rtc0 at Sun Jun 23 14:30:20 2019 [ 86.308500] PM: suspend entry (deep) [ 86.311962] Filesystems sync: 0.001 seconds [ 86.320781] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 86.328542] OOM killer disabled. [ 86.331644] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 86.435700] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 86.591293] wake enabled for irq 151 [ 86.626989] wake enabled for irq 155 [ 86.747140] samsung-pinctrl 1340.pinctrl: Setting external wakeup interrupt mask: 0xffe7 [ 86.765605] Disabling non-boot CPUs ... [ 86.841073] s3c2410-wdt 101d.watchdog: watchdog disabled [ 86.845648] usb usb1: root hub lost power or was reset [ 86.919564] usb usb2: root hub lost power or was reset [ 86.924314] wake disabled for irq 155 [ 86.933852] wake disabled for irq 151 [ 86.950827] exynos-tmu 1006.tmu: More trip points than supported by this TMU. [ 86.957003] exynos-tmu 1006.tmu: 2 trip points should be configured in polling mode. [ 86.965055] exynos-tmu 10064000.tmu: More trip points than supported by this TMU. [ 86.972496] exynos-tmu 1006400
Re: [PATCH v5 3/3] arm64: dts: meson: Add minimal support for Odroid-N2
regulator-name = "FLASH_1V8";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + vin-supply = <_3v3>;
> + regulator-always-on;
> + };
> +
> + main_12v: regulator-main_12v {
> + compatible = "regulator-fixed";
> + regulator-name = "12V";
> + regulator-min-microvolt = <1200>;
> + regulator-max-microvolt = <1200>;
> + regulator-always-on;
> + };
> +
> + vcc_5v: regulator-vcc_5v {
> + compatible = "regulator-fixed";
> + regulator-name = "5V";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
As per odroid-n2_rev0.4_20190307 schematic its missing.
vin-supply = <_12v>;
With this please add my.
Tested-by: Anand Moon
Best Regards
-Anand
> + };
> +
> + vcc_1v8: regulator-vcc_1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_1V8";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + vin-supply = <_3v3>;
> + regulator-always-on;
> + };
> +
> + vcc_3v3: regulator-vcc_3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + vin-supply = <_3v3>;
> + regulator-always-on;
> + /* FIXME: actually controlled by VDDCPU_B_EN */
> + };
> +
> + hub_5v: regulator-hub_5v {
> + compatible = "regulator-fixed";
> + regulator-name = "HUB_5V";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + vin-supply = <_5v>;
> +
> + /* Connected to the Hub CHIPENABLE, LOW sets low power state
> */
> + gpio = < GPIOH_5 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + usb_pwr_en: regulator-usb_pwr_en {
> + compatible = "regulator-fixed";
> + regulator-name = "USB_PWR_EN";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + vin-supply = <_5v>;
> +
> + /* Connected to the microUSB port power enable */
> + gpio = < GPIOH_6 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vddao_1v8: regulator-vddao_1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_1V8";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + vin-supply = <_3v3>;
> + regulator-always-on;
> + };
> +
> + vddao_3v3: regulator-vddao_3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + vin-supply = <_12v>;
> + regulator-always-on;
> + };
> +
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <_tx_tmds_out>;
> + };
> + };
> + };
> +};
> +
> +_AO {
> + pinctrl-0 = <_ao_a_h_pins>;
> + pinctrl-names = "default";
> + status = "disabled";
> + hdmi-phandle = <_tx>;
> +};
> +
> +_AO {
> + pinctrl-0 = <_ao_b_h_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> + hdmi-phandle = <_tx>;
> +};
> +
> +_mdio {
> + external_phy: ethernet-phy@0 {
> + /* Realtek RTL8211F (0x001cc916) */
> + reg = <0>;
> + max-speed = <1000>;
> +
Re: [PATCH v2] arm64: dts: rockchip: Add missing configuration pwr amd rst for PCIe
Hi Manivannan,
Thanks for your review comment.
On Sat, 1 Jun 2019 at 15:21, Manivannan Sadhasivam
wrote:
>
> Hi,
>
> On Fri, May 31, 2019 at 08:19:13PM +, Anand Moon wrote:
> > This patch add missing PCIe gpio pin (#PCIE_PWR) for vcc3v3_pcie power
> > regulator node also add missing reset pinctrl (#PCIE_PERST_L) for PCIe node.
> >
> > Signed-off-by: Anand Moon
> > ---
> > using schematics: thanks for suggested by Manivannan
> > [1]
> > https://dl.vamrs.com/products/rock960/docs/hw/rock960_sch_v12_20180314.pdf
> >
> > Changes from prevoius patch:
> > [2] https://patchwork.kernel.org/patch/10968695/
> >
> > Fix the suject and commit message and corrected the PWR and PERST
> > configuration
> > as per shematics and dts nodes.
> > ---
> > arch/arm64/boot/dts/rockchip/rk3399-ficus.dts| 7 +++
> > arch/arm64/boot/dts/rockchip/rk3399-rock960.dts | 7 +++
> > arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi | 3 +--
> > 3 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
> > b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
> > index 6b059bd7a04f..94e2a59bc1c7 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
> > @@ -89,6 +89,8 @@
> >
> > {
> > ep-gpios = < RK_PD4 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_clkreqn_cpm _perst_l>;
>
> Looks like ep-gpio is wrong here :/ I probably referred old schematics
> at that time. Correct pin mapping is,
>
> ep-gpios = < RK_PD4 GPIO_ACTIVE_HIGH>;
>
> And this should be fixed in a separate patch with "Fixes" tag!
>
Ok I will changes per the above. I have also check this with the
u-boot changes .
> > };
> >
> > {
> > @@ -104,6 +106,11 @@
> > rockchip,pins =
> > <1 RK_PD0 RK_FUNC_GPIO _pull_none>;
> > };
> > +
> > + pcie_perst_l: pcie-perst-l {
> > + rockchip,pins =
> > + <4 RK_PD4 RK_FUNC_GPIO _pull_none>;
> > + };
> > };
> >
> > usb2 {
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
> > b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
> > index 12285c51cceb..665fe09c7c74 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
> > @@ -64,6 +64,8 @@
> >
> > {
> > ep-gpios = < RK_PA2 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_clkreqn_cpm _perst_l>;
> > };
> >
> > {
> > @@ -104,6 +106,11 @@
> > rockchip,pins =
> > <2 RK_PA5 RK_FUNC_GPIO _pull_none>;
> > };
> > +
> > + pcie_perst_l: pcie-perst-l {
> > + rockchip,pins =
> > + <2 RK_PA2 RK_FUNC_GPIO _pull_none>;
> > + };
> > };
> >
> > usb2 {
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > index c7d48d41e184..3df0cd67b4b2 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > @@ -55,6 +55,7 @@
> >
> > vcc3v3_pcie: vcc3v3-pcie-regulator {
> > compatible = "regulator-fixed";
> > + gpio = < RK_PA5 GPIO_ACTIVE_HIGH>;
>
> Actually the PWR pin mapping is defined in a separate node for both Rock960
> and Ficus in respective dts. So defining it here would be wrong as the PWR
> pin mapping is different for both boards.
>
Ok Thanks, so I will move the PWR pin nodes the respective dts files.
PCIE_PERST PCIE_PWR
Rock960 GPIO2_A2 GPIO2_A5
Ficus GPIO2_D4 GPIO1_D0 /* reference u-boot */
Pls confirm this is correct.
Best Regards
-Anand
> Thanks,
> Mani
[PATCH v2] arm64: dts: rockchip: Add missing configuration pwr amd rst for PCIe
This patch add missing PCIe gpio pin (#PCIE_PWR) for vcc3v3_pcie power
regulator node also add missing reset pinctrl (#PCIE_PERST_L) for PCIe node.
Signed-off-by: Anand Moon
---
using schematics: thanks for suggested by Manivannan
[1] https://dl.vamrs.com/products/rock960/docs/hw/rock960_sch_v12_20180314.pdf
Changes from prevoius patch:
[2] https://patchwork.kernel.org/patch/10968695/
Fix the suject and commit message and corrected the PWR and PERST configuration
as per shematics and dts nodes.
---
arch/arm64/boot/dts/rockchip/rk3399-ficus.dts| 7 +++
arch/arm64/boot/dts/rockchip/rk3399-rock960.dts | 7 +++
arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi | 3 +--
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
index 6b059bd7a04f..94e2a59bc1c7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
@@ -89,6 +89,8 @@
{
ep-gpios = < RK_PD4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_clkreqn_cpm _perst_l>;
};
{
@@ -104,6 +106,11 @@
rockchip,pins =
<1 RK_PD0 RK_FUNC_GPIO _pull_none>;
};
+
+ pcie_perst_l: pcie-perst-l {
+ rockchip,pins =
+ <4 RK_PD4 RK_FUNC_GPIO _pull_none>;
+ };
};
usb2 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
index 12285c51cceb..665fe09c7c74 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
@@ -64,6 +64,8 @@
{
ep-gpios = < RK_PA2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_clkreqn_cpm _perst_l>;
};
{
@@ -104,6 +106,11 @@
rockchip,pins =
<2 RK_PA5 RK_FUNC_GPIO _pull_none>;
};
+
+ pcie_perst_l: pcie-perst-l {
+ rockchip,pins =
+ <2 RK_PA2 RK_FUNC_GPIO _pull_none>;
+ };
};
usb2 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
index c7d48d41e184..3df0cd67b4b2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
@@ -55,6 +55,7 @@
vcc3v3_pcie: vcc3v3-pcie-regulator {
compatible = "regulator-fixed";
+ gpio = < RK_PA5 GPIO_ACTIVE_HIGH>;
enable-active-high;
pinctrl-names = "default";
pinctrl-0 = <_drv>;
@@ -382,8 +383,6 @@
{
num-lanes = <4>;
- pinctrl-names = "default";
- pinctrl-0 = <_clkreqn_cpm>;
vpcie3v3-supply = <_pcie>;
status = "okay";
};
--
2.21.0
Re: [PATCH] arm64: dts: rockchip: Add missing PCIe pwr amd rst configuration
Hi Manivannan,
On Fri, 31 May 2019 at 09:32, Manivannan Sadhasivam
wrote:
>
> Hi,
>
> On Thu, May 30, 2019 at 12:58:37PM +, Anand Moon wrote:
> > This patch add missing PCIe gpio and pinctrl for power (#PCIE_PWR)
> > also add PCIe gpio and pinctrl for reset (#PCIE_PERST_L).
> >
> > Signed-off-by: Anand Moon
> > ---
> > Tested on Rock960 Model A
> > ---
> > arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi | 16 ++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > index c7d48d41e184..f5bef6b0fe89 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > @@ -55,9 +55,10 @@
> >
> > vcc3v3_pcie: vcc3v3-pcie-regulator {
> > compatible = "regulator-fixed";
> > + gpio = < RK_PA2 GPIO_ACTIVE_HIGH>;
> > enable-active-high;
> > pinctrl-names = "default";
> > - pinctrl-0 = <_drv>;
> > + pinctrl-0 = <_drv _pwr>;
> > regulator-boot-on;
> > regulator-name = "vcc3v3_pcie";
> > regulator-min-microvolt = <330>;
> > @@ -381,9 +382,10 @@
> > };
> >
> > {
> > + ep-gpio = < RK_PD4 GPIO_ACTIVE_HIGH>;
> > num-lanes = <4>;
> > pinctrl-names = "default";
> > - pinctrl-0 = <_clkreqn_cpm>;
> > + pinctrl-0 = <_clkreqn_cpm _perst_l>;
> > vpcie3v3-supply = <_pcie>;
> > status = "okay";
> > };
> > @@ -408,6 +410,16 @@
> > };
> > };
> >
> > + pcie {
> > + pcie_pwr: pcie-pwr {
> > + rockchip,pins = <2 RK_PA2 RK_FUNC_GPIO
> > _pull_none>;
> > + };
> > +
> > + pcie_perst_l:pcie-perst-l {
> > + rockchip,pins = <2 RK_PD4 RK_FUNC_GPIO
> > _pull_none>;
> > + };
>
> Which schematics did you refer? According to Rock960 v2.1 schematics [1],
> below
> is the pin mapping for PCI-E PWR and PERST:
>
> PCIE_PERST - GPIO2_A2
> PCIE_PWR - GPIO2_A5
>
Opps, I have referred the wrong schematics *RK3399_Rock960_V1.0.pdf*
may be old version.
Thanks for pointing out the correct schematics.
> Above mapping holds true for Rock960 version 1.1, 1.2 and 1.3. Also,
> rk3399-rock960.dtsi is common for both Rock960 and Ficus boards, so the board
> specific parts should go to rk3399-rock960.dts and rk3399-ficus.dts.
>
> Thanks,
> Mani
I have ROCK960-V 1.2 (Model A) for testing so. I will be sending patch
v2 the relevant
node update in rk3399-rock960.dts and rk3399-ficus.dts if below common
for both the boards.
PCIE_PERST - GPIO2_A2
PCIE_PWR - GPIO2_A5
>
> [1] https://dl.vamrs.com/products/rock960/docs/hw/rock960_sch_v12_20180314.pdf
Best Regards
-Anand
[PATCH] arm64: dts: rockchip: Add missing PCIe pwr amd rst configuration
This patch add missing PCIe gpio and pinctrl for power (#PCIE_PWR)
also add PCIe gpio and pinctrl for reset (#PCIE_PERST_L).
Signed-off-by: Anand Moon
---
Tested on Rock960 Model A
---
arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
index c7d48d41e184..f5bef6b0fe89 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
@@ -55,9 +55,10 @@
vcc3v3_pcie: vcc3v3-pcie-regulator {
compatible = "regulator-fixed";
+ gpio = < RK_PA2 GPIO_ACTIVE_HIGH>;
enable-active-high;
pinctrl-names = "default";
- pinctrl-0 = <_drv>;
+ pinctrl-0 = <_drv _pwr>;
regulator-boot-on;
regulator-name = "vcc3v3_pcie";
regulator-min-microvolt = <330>;
@@ -381,9 +382,10 @@
};
{
+ ep-gpio = < RK_PD4 GPIO_ACTIVE_HIGH>;
num-lanes = <4>;
pinctrl-names = "default";
- pinctrl-0 = <_clkreqn_cpm>;
+ pinctrl-0 = <_clkreqn_cpm _perst_l>;
vpcie3v3-supply = <_pcie>;
status = "okay";
};
@@ -408,6 +410,16 @@
};
};
+ pcie {
+ pcie_pwr: pcie-pwr {
+ rockchip,pins = <2 RK_PA2 RK_FUNC_GPIO _pull_none>;
+ };
+
+ pcie_perst_l:pcie-perst-l {
+ rockchip,pins = <2 RK_PD4 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
sdmmc {
sdmmc_bus1: sdmmc-bus1 {
rockchip,pins =
--
2.21.0
Re: [PATCH] ARM: dts: exynos: add CCI-400 PMU nodes support to Exynos542x SoCs
Hi Krzysztof, On Tue, 16 Apr 2019 at 15:49, Krzysztof Kozlowski wrote: > > On Mon, 15 Apr 2019 at 14:24, Anand Moon wrote: > > Cache Coherent Interface (CCI) among Cortex-A15 and Cortex-A7, G2D, G3D and > > SSS > > > > Level 0 > CPU blocks such as Cortex-A15 (CA15), Cortex-A7 (CA7) are > > joined as the member of Level 0 CCI bus > > > > Level 1 > Display engine block (DISP) and 2D graphic engines (G2D) are > > directly connected to Level 1. > > DISP, MDMA, SSS. > > > > Level 2 > While all the other IP is connected to Level 1 bus via Level 2 bus > >G3D, MSCL, MFC, ISP, JPEG/Rotator/DMA/PERI, NAND/SD/EMMC. > > > > So my question is the mapped with the cci ip block correct. > > Level 0 (cci_control0) > > Level 1 (cci_control1) > > Level 2 (cci_control1) > > Hi Anand, > > I do not understand the question - what is mapped with correctly or not? > > Best regards, > Krzysztof Following the https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/cci.txt CCI node linked to CPU and DMA nodes for example. On this line below diagram from Exynos 5422 UM show various IP block linked to CCI level. Below image just elaborate overall architecture of Exynos 5422 CCI. [0] https://imgur.com/gallery/0xJSwGQ So we should map the various IP block to corresponding CCI level. Best Regards -Anand
Re: [PATCH] ARM: dts: exynos: add CCI-400 PMU nodes support to Exynos542x SoCs
Hi Willy,
On Fri, 12 Apr 2019 at 22:55, Willy Wolff wrote:
>
> Add device tree entries for PMU of ARM CCI-400.
>
> $ sudo ./perf stat -a -C 0 -e CCI_400/config=0xff,name=cycles/ sleep 1
>
> Performance counter stats for 'system wide':
>
>420,303,619 cycles
>
>1.019058775 seconds time elapsed
>
> Tested on Odroid-xu3 and 4.
>
> Signed-off-by: Willy Wolff
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi
> index aaff15880761..be58650aca35 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -158,7 +158,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
> reg = <0x10d2 0x1000>;
> - ranges = <0x0 0x10d2 0x6000>;
> + ranges = <0x0 0x10d2 0x1>;
>
> cci_control0: slave-if@4000 {
> compatible = "arm,cci-400-ctrl-if";
> @@ -170,6 +170,16 @@
> interface-type = "ace";
> reg = <0x5000 0x1000>;
> };
> +
> + pmu@9000 {
> + compatible = "arm,cci-400-pmu,r0";
> + reg = <0x9000 0x5000>;
As per Exynos 5422 user manual below interrupts should be as follow.
+ interrupts = , /* CCI_N_EVENT_CNT0_OVF */
+ , /* CCI_N_EVENT_CNT1_OVF */
+ , /* CCI_N_EVENT_CNT2_OVF */
+ , /* CCI_N_EVENT_CNT3_OVF */
+ , /* CCI_N_EVENT_CNT4_OVF */
+ ; /* CCI_NERR */
> + interrupts = <0 105 4>,
> +<0 101 4>,
> +<0 102 4>,
> +<0 103 4>,
> +<0 104 4>;
> + };
> };
>
> clock: clock-controller@1001 {
> --
> 2.11.0
>
But I am observing follow kernel warning after I enable
CONFIG_ARM_CCI_PMU + exynos_defconfig.
[4.557701] mmcblk0: p1
[4.561036] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:908
[4.568075] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
[4.574656] 1 lock held by swapper/0/1:
[4.578397] #0: (ptrval) (>mutex){}, at:
device_driver_attach+0x18/0x60
[4.585900] Preemption disabled at:
[4.585909] [] cci_pmu_probe+0x1cc/0x4a0
[4.594122] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc5-dirty #11
[4.600853] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[4.606928] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[4.614642] [] (show_stack) from []
(dump_stack+0x98/0xc4)
[4.621832] [] (dump_stack) from []
(___might_sleep+0x20c/0x2c0)
[4.629545] [] (___might_sleep) from []
(__mutex_lock+0x3c/0xa34)
[4.637343] [] (__mutex_lock) from []
(mutex_lock_nested+0x1c/0x24)
[4.645318] [] (mutex_lock_nested) from []
(perf_pmu_register+0x20/0x40c)
[4.653812] [] (perf_pmu_register) from []
(cci_pmu_probe+0x2f4/0x4a0)
[4.662044] [] (cci_pmu_probe) from []
(platform_drv_probe+0x48/0x98)
[4.670186] [] (platform_drv_probe) from []
(really_probe+0x24c/0x410)
[4.678418] [] (really_probe) from []
(driver_probe_device+0x78/0x1c0)
[4.686651] [] (driver_probe_device) from []
(device_driver_attach+0x58/0x60)
[4.695492] [] (device_driver_attach) from []
(__driver_attach+0xb8/0x158)
[4.704070] [] (__driver_attach) from []
(bus_for_each_dev+0x74/0xb4)
[4.712213] [] (bus_for_each_dev) from []
(bus_add_driver+0x1c0/0x200)
[4.720446] [] (bus_add_driver) from []
(driver_register+0x74/0x108)
[4.728507] [] (driver_register) from []
(do_one_initcall+0x90/0x434)
[4.736655] [] (do_one_initcall) from []
(kernel_init_freeable+0x448/0x4ec)
[4.745319] [] (kernel_init_freeable) from []
(kernel_init+0x8/0x110)
[4.753460] [] (kernel_init) from []
(ret_from_fork+0x14/0x20)
[4.760995] Exception stack(0xe88e1fb0 to 0xe88e1ff8)
[4.766011] 1fa0:
[4.774170] 1fc0:
[4.782315] 1fe0: 0013
[4.789337] ARM CCI_400 PMU driver probed
[4.797261] NET: Registered protocol family 10
Hi Krzysztof,
Cache Coherent Interface (CCI) among Cortex-A15 and Cortex-A7, G2D, G3D and SSS
Level 0 > CPU blocks such as Cortex-A15 (CA15), Cortex-A7 (CA7) are
joined as the member of Level 0 CCI bus
Re: [PATCH RFC 8/8] ARM: dts: exynos: Add ASV tables for exynos5422/5800
Hi Sylwester,
As per my knowledge HK soc introduce this table to support
overclocking of cpufreq for Odroid XU3 XU4 family for boards.
ARM Cortex-A15 Quad CPU (Eagle) 1800 to 2000
ARM Cortex-A7 Quard CPU (Kingfisher) 1400 to 1500
For Exynos5422 below table
asv-table-[0-3] AVS range from 200 to 2100
asv-table-[100-103] AVS range from 200 to 1500.
Are these setting stable for this board to cover clock the cpu now.
Can you also enable support for this clk-exynos5420.c
For example exynos5800_eglclk_d and exynos5420_kfcclk_d table.
Also can you update exynos5420.dtsi following opp table
For example cluster_a15_opp_table and cluster_a7_opp_table opt binding.
To make this work synchronously with AVS.
Best Regards
-Anand
On Thu, 4 Apr 2019 at 22:55, Sylwester Nawrocki wrote:
>
> This patch ASV (Adaptive Supply Voltage) table entries for
> Exynos5422/5800 SoC.
>
> Signed-off-by: Sylwester Nawrocki
> ---
> arch/arm/boot/dts/exynos5.dtsi| 2 +-
> arch/arm/boot/dts/exynos5800.dtsi | 207 ++
> 2 files changed, 208 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index 67f9b4504a42..22eb951c614c 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -35,7 +35,7 @@
> #size-cells = <1>;
> ranges;
>
> - chipid@1000 {
> + chipid: chipid@1000 {
> compatible = "samsung,exynos4210-chipid";
> reg = <0x1000 0x100>;
> };
> diff --git a/arch/arm/boot/dts/exynos5800.dtsi
> b/arch/arm/boot/dts/exynos5800.dtsi
> index 57d3b319fd65..5358865f5c0b 100644
> --- a/arch/arm/boot/dts/exynos5800.dtsi
> +++ b/arch/arm/boot/dts/exynos5800.dtsi
> @@ -16,6 +16,213 @@
> compatible = "samsung,exynos5800", "samsung,exynos5";
> };
>
> + {
> + asv {
> + compatible = "samsung,exynos-asv-v1";
> + asv-table-0 {
> + /* ARM 0, 1 */
> + samsung,asv-table-size = <20 15>;
> + samsung,asv-table-id = <0x0>;
> + samsung,asv-data =
> + /* ASV0 ASV1ASV2ASV3ASV4
> ASV5ASV6ASV7ASV8ASV9ASV10 ASV11 ASV12 ASV13 */
> + <2100 1362500 1362500 135 1337500 1325000
> 1312500 130 1275000 1262500 125 1237500 1225000 1212500 120>,
> + <2000 1312500 1312500 130 1287500 1275000
> 1262500 125 1237500 1225000 1237500 1225000 1212500 120 1187500>,
> + <1900 125 1237500 1225000 1212500 120
> 1187500 1175000 1162500 115 1162500 115 1137500 1125000 1112500>,
> + <1800 120 1187500 1175000 1162500 115
> 1137500 1125000 1112500 110 1112500 110 1087500 1075000 1062500>,
> + <1700 1162500 115 1137500 1125000 1112500
> 110 1087500 1075000 1062500 1075000 1062500 105 1037500 1025000>,
> + <1600 1125000 1112500 110 1087500 1075000
> 1062500 105 1037500 1025000 1037500 1025000 1012500 100 987500>,
> + <1500 1087500 1075000 1062500 105 1037500
> 1025000 1012500 100 987500 100 987500 975000 962500 95>,
> + <1400 1062500 105 1037500 1025000 1012500
> 100 987500 975000 962500 975000 962500 95 937500 925000>,
> + <1300 105 1037500 1025000 1012500 100
> 987500 975000 962500 95 962500 95 937500 925000 912500>,
> + <1200 1025000 1012500 100 987500 975000
> 962500 95 937500 925000 937500 925000 912500 90 90>,
> + <1100 100 987500 975000 962500 95
> 937500 925000 912500 90 90 90 90 90 90>,
> + <1000 975000 962500 95 937500 925000
> 912500 90 90 90 90 90 90 90 90>,
> + < 900 95 937500 925000 912500 90
> 90 90 90 90 90 90 90 90 90>,
> + < 800 925000 912500 90 90 90
> 90 90 90 90 90 90 90 90 90>;
> +/* ASV0...13 */
> + samsung,asv-common-data = <700 90>,
> + <600 90>,
> + <500 90>,
> + <400 90>,
> + <300 90>,
> +
Re: [PATCH v1] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
hi Krzysztof,
On Tue, 26 Mar 2019 at 16:28, Krzysztof Kozlowski wrote:
>
> On Tue, 26 Mar 2019 at 11:35, Anand Moon wrote:
>
> (...)
>
> > > This is third or fourth submission but you marked it as v1. This makes
> > > it very difficult to discuss and reference previous versions.
> > >
> > > The commit message did not change since beginning (first version). I
> > > asked twice that you need to explain exactly why you put the the
> > > regulator to off or on state in suspend. Why?
> > > Because:
> > > 1. This change looks without justification - once you put on, then you
> > > put off, now again on,
> > > 2. Anyone reading the code later must know the rationale why this was
> > > done,
> > > 3. I am not quite sure whether this is good setting so I would be
> > > happy to be convinced.
> > >
> >
> > Like I mention in the patch summary that this.
> >
> > Current changes are based on
> > [0]
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/max77686.txt
> >
> > Regulators which can be turned off during system suspend:
> > -LDOn : 2, 6-8, 10-12, 14-16,
> > -BUCKn : 1-4.
> > Use standard regulator bindings for it ('regulator-off-in-suspend').
>
> I do not see how this is related to my questions.
>
> > > How to provide such explanation? The best in commit message. Sometimes
> > > in the comment in the code, depends.
> >
> > Ok I have been testing with following regulator debug prints to catch error.
> > [0] max77686-regulator.patch
> >
> > below is the console logs during suspend and resume.
> > ---
> > Last login: Sat Mar 23 18:22:46 on ttySAC1
> > [root@archl-u3e ~]# echo no > /sys/module/printk/parameters/console_suspend
> > [root@archl-u3e ~]# rtcwake -d /dev/rtc0 -m mem -s 10
> > rtcwake: wakeup from "mem" using /dev/rtc0 at Sat Mar 23 19:56:17 2019
> > [ 38.595854] PM: suspend entry (deep)
> > [ 38.596603] PM: Syncing filesystems ... done.
> > [ 38.629351] Freezing user space processes ... (elapsed 0.002 seconds)
> > done.
> > [ 38.633192] OOM killer disabled.
> > [ 38.636035] Freezing remaining freezable tasks ... (elapsed 0.001
> > seconds) done.
> > [ 38.675059] smsc95xx 1-2:1.0 eth0: entering SUSPEND2 mode
> > [ 38.753120] dwc2 1248.hsotg: suspending usb gadget g_ether
> > [ 38.754007] dwc2 1248.hsotg: new device is full-speed
> > [ 38.758960] dwc2 1248.hsotg: dwc2_hsotg_ep_disable: called for ep0
> > [ 38.765507] dwc2 1248.hsotg: dwc2_hsotg_ep_disable: called for ep0
> > [ 38.774050] wake enabled for irq 119
> > [ 38.775761] BUCK9: No configuration
> > [ 38.779191] BUCK8_P3V3: No configuration
> > [ 38.782852] BUCK7_2.0V: No configuration
> > [ 38.786851] BUCK6_1.35V: No configuration
> > [ 38.790752] VDDQ_CKEM1_2_1.2V: No configuration
> > [ 38.796220] BUCK4: regulator suspend disable supported
> > [ 38.800769] BUCK3: regulator suspend disable supported
> > [ 38.806002] BUCK1: regulator suspend disable supported
> > [ 38.810644] LDO26: No configuration
> > [ 38.814169] VDDQ_LCD_1.8V: No configuration
> > [ 38.818267] LDO24: No configuration
> > [ 38.821732] LDO23: No configuration
> > [ 38.825262] LDO22_VDDQ_MMC4_2.8V: No configuration
> > [ 38.829992] TFLASH_2.8V: No configuration
> > [ 38.834040] LDO20_1.8V: No configuration
> > [ 38.837883] LDO19: No configuration
> > [ 38.841349] LDO18: No configuration
> > [ 38.844878] LDO17: No configuration
> > [ 38.848667] LDO16: regulator suspend disable supported
> > [ 38.853889] LDO15: regulator suspend disable supported
> > [ 38.858931] LDO14: regulator suspend disable supported
> > [ 38.863771] VDDQ_C2C_W_1.8V: No configuration
> > [ 38.868378] LDO12: regulator suspend disable supported
> > [ 38.873508] LDO11: regulator suspend disable supported
> > [ 38.878545] LDO10: regulator suspend disable supported
> > [ 38.883384] LDO9: No configuration
> > [ 38.887190] LDO8: regulator suspend disable supported
> > [ 38.892168] LDO7: regulator suspend disable supported
> > [ 38.897279] LDO6: regulator suspend disable supported
> > [ 38.901872] VDDQ_MMC1_3_1.8V: No configuration
> > [ 38.906363] VDDQ_MMC2_2.8V: No configuration
> > [ 38.910541] VDDQ_EXT_1.8V: No configuration
> > [ 38.915134] LDO2: regulator suspend disable supported
> > [ 38.919753] VDD_ALIVE_1.0V: No conf
Re: [PATCH v1] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
Hi Krzysztof,
Thanks your for your valuable comments.
I will try to answer your queries to best of my knowledge.
On Mon, 25 Mar 2019 at 18:16, Krzysztof Kozlowski wrote:
>
> On Sun, 24 Mar 2019 at 09:33, Anand Moon wrote:
> >
> > Add suspend-to-mem node to regulator core to be enabled or disabled
> > during system suspend and also support changing the regulator operating
> > mode during runtime and when the system enter sleep mode (stand by mode).
> >
> > Cc: Marek Szyprowski
> > Cc: Krzysztof Kozlowski
> > Cc: Chanwoo Choi
> > Signed-off-by: Anand Moon
> > ---
> > Current patch:
> >
> > Note: Both microSD and eMMC suspend resume works this changes at my end.
> >
> > regulator-off-in-suspend:
> > set the regulator node into suspend state i.e. standby mode during suspend
> > operation.
> >
> > Current changes are based on
> > [0]
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/max77686.txt
> >
> > Regulators which can be turned off during system suspend:
> > -LDOn : 2, 6-8, 10-12, 14-16,
> > -BUCKn : 1-4.
> > Use standard regulator bindings for it ('regulator-off-in-suspend').
> >
> > drop the suspend off binding which are not supported by the driver.
> >
> > RFC version
> > [1] https://patchwork.kernel.org/patch/10810909/
> > These changes had some problem with eMMC not entering into suspend mode.
> > with some miss configuration in regulator-off-in-suspend mode.
> >
> > Changes from previos patch.
> > [2] https://patchwork.kernel.org/patch/10712549/
> >
> > Set all the non used regulator in suspend-odd state
> > LD02, LD03, LD05, LD06, LD07, LD011, LD013, LDO14, LD016
> >
> > BUCK5, BUCK6, BUCK7 and not confirable as per driver max77686-regulator
> > ---
> > .../boot/dts/exynos4412-odroid-common.dtsi| 39 +++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > index 08d3a0a7b4eb..375156ad5454 100644
> > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > @@ -288,6 +288,9 @@
> > regulator-min-microvolt = <180>;
> > regulator-max-microvolt = <180>;
> > regulator-always-on;
> > + regulator-state-mem {
> > + regulator-off-in-suspend;
>
> Please maintain proper versioning of patches.
> First patch sent to lists should be either RFC or v1. Second
> release/submission is then always v2. Third v3.
I tried to mixed up some changes that's the reason.
Ok if needed next version will be Patch V3.
>
> This is third or fourth submission but you marked it as v1. This makes
> it very difficult to discuss and reference previous versions.
>
> The commit message did not change since beginning (first version). I
> asked twice that you need to explain exactly why you put the the
> regulator to off or on state in suspend. Why?
> Because:
> 1. This change looks without justification - once you put on, then you
> put off, now again on,
> 2. Anyone reading the code later must know the rationale why this was done,
> 3. I am not quite sure whether this is good setting so I would be
> happy to be convinced.
>
Like I mention in the patch summary that this.
Current changes are based on
[0]
https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/max77686.txt
Regulators which can be turned off during system suspend:
-LDOn : 2, 6-8, 10-12, 14-16,
-BUCKn : 1-4.
Use standard regulator bindings for it ('regulator-off-in-suspend').
> How to provide such explanation? The best in commit message. Sometimes
> in the comment in the code, depends.
Ok I have been testing with following regulator debug prints to catch error.
[0] max77686-regulator.patch
below is the console logs during suspend and resume.
---
Last login: Sat Mar 23 18:22:46 on ttySAC1
[root@archl-u3e ~]# echo no > /sys/module/printk/parameters/console_suspend
[root@archl-u3e ~]# rtcwake -d /dev/rtc0 -m mem -s 10
rtcwake: wakeup from "mem" using /dev/rtc0 at Sat Mar 23 19:56:17 2019
[ 38.595854] PM: suspend entry (deep)
[ 38.596603] PM: Syncing filesystems ... done.
[ 38.629351] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 38.633192] OOM killer disabled.
[ 38.636035] Freezing remaining freezable ta
[PATCH v1] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
Add suspend-to-mem node to regulator core to be enabled or disabled
during system suspend and also support changing the regulator operating
mode during runtime and when the system enter sleep mode (stand by mode).
Cc: Marek Szyprowski
Cc: Krzysztof Kozlowski
Cc: Chanwoo Choi
Signed-off-by: Anand Moon
---
Current patch:
Note: Both microSD and eMMC suspend resume works this changes at my end.
regulator-off-in-suspend:
set the regulator node into suspend state i.e. standby mode during suspend
operation.
Current changes are based on
[0]
https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/max77686.txt
Regulators which can be turned off during system suspend:
-LDOn : 2, 6-8, 10-12, 14-16,
-BUCKn : 1-4.
Use standard regulator bindings for it ('regulator-off-in-suspend').
drop the suspend off binding which are not supported by the driver.
RFC version
[1] https://patchwork.kernel.org/patch/10810909/
These changes had some problem with eMMC not entering into suspend mode.
with some miss configuration in regulator-off-in-suspend mode.
Changes from previos patch.
[2] https://patchwork.kernel.org/patch/10712549/
Set all the non used regulator in suspend-odd state
LD02, LD03, LD05, LD06, LD07, LD011, LD013, LDO14, LD016
BUCK5, BUCK6, BUCK7 and not confirable as per driver max77686-regulator
---
.../boot/dts/exynos4412-odroid-common.dtsi| 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 08d3a0a7b4eb..375156ad5454 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -288,6 +288,9 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo3_reg: LDO3 {
@@ -317,6 +320,9 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo7_reg: LDO7 {
@@ -324,18 +330,27 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo8_reg: LDO8 {
regulator-name = "VDD10_HDMI_1.0V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo10_reg: LDO10 {
regulator-name = "VDDQ_MIPIHSI_1.8V";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo11_reg: LDO11 {
@@ -343,6 +358,9 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo12_reg: LDO12 {
@@ -351,6 +369,9 @@
regulator-max-microvolt = <330>;
regulator-always-on;
regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo13_reg: LDO13 {
@@ -367,6 +388,9 @@
regulator-max-microvolt = <180&
Re: [PATCH] ARM: dts: exynos: Add pin configuration for read strobe for Odroid XU3/XU4 eMMC
Hi Marek,
On Fri, 22 Feb 2019 at 15:59, Marek Szyprowski wrote:
>
> Hi Anand,
>
> On 2019-02-22 11:19, Anand Moon wrote:
> > Add Read Strobe RDQS pin configuration for eMMC to support higher data rate
> > read/write.
> >
> > Signed-off-by: Anand Moon
> > ---
> > arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 6 ++
> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 2 +-
> > 2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> > b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> > index b82af7c89654..4fb3865e082a 100644
> > --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> > +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> > @@ -206,6 +206,12 @@
> > samsung,pin-drv = ;
> > };
> >
> > + sd0_rdqs: sd0-rdqs {
> > + samsung,pins = "gpc0-7";
> > + samsung,pin-function = ;
> > + samsung,pin-pud = ;
> > + };
> > +
>
> The above lines are not needed. There is already a sd0_rclk node with
> exactly the same configuration just above your change.
>
Sorry once again, I failed to look closely., sorry for the noise.
Best Regards
-Anand
> > sd1_clk: sd1-clk {
> > samsung,pins = "gpc1-0";
> > samsung,pin-function = ;
> > diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > index b299e541cac0..d41397748ed2 100644
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > @@ -411,7 +411,7 @@
> > samsung,dw-mshc-hs400-timing = <0 2>;
> > samsung,read-strobe-delay = <90>;
> > pinctrl-names = "default";
> > - pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
> > _rclk>;
> > + pinctrl-0 = <_clk _cmd _rdqs _bus1 _bus4
> > _bus8 _cd _rclk>;
> > bus-width = <8>;
> > cap-mmc-highspeed;
> > mmc-hs200-1_8v;
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R Institute Poland
>
[PATCH] ARM: dts: exynos: Add pin configuration for read strobe for Odroid XU3/XU4 eMMC
Add Read Strobe RDQS pin configuration for eMMC to support higher data rate
read/write.
Signed-off-by: Anand Moon
---
arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 6 ++
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index b82af7c89654..4fb3865e082a 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -206,6 +206,12 @@
samsung,pin-drv = ;
};
+ sd0_rdqs: sd0-rdqs {
+ samsung,pins = "gpc0-7";
+ samsung,pin-function = ;
+ samsung,pin-pud = ;
+ };
+
sd1_clk: sd1-clk {
samsung,pins = "gpc1-0";
samsung,pin-function = ;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index b299e541cac0..d41397748ed2 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -411,7 +411,7 @@
samsung,dw-mshc-hs400-timing = <0 2>;
samsung,read-strobe-delay = <90>;
pinctrl-names = "default";
- pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
_rclk>;
+ pinctrl-0 = <_clk _cmd _rdqs _bus1 _bus4 _bus8
_cd _rclk>;
bus-width = <8>;
cap-mmc-highspeed;
mmc-hs200-1_8v;
--
2.20.1
Re: [PATCH v2] ARM: pm: fix HYP/SVC mode mismatch when MCPM is used
Hi Marek,
On Fri, 15 Feb 2019 at 21:40, Marek Szyprowski wrote:
>
> MCPM does a soft reset of the CPUs and uses common cpu_resume() routine to
> perform low-level platform initialization. This results in a try to install
> HYP stubs for the second time for each CPU and results in false HYP/SVC
> mode mismatch detection. The HYP stubs are already installed at the
> beginning of the kernel initialization on the boot CPU (head.S) or in the
> secondary_startup() for other CPUs. To fix this issue MCPM code should use
> a cpu_resume() routine without HYP stubs installation.
>
> This change fixes HYP/SVC mode mismatch on Samsung Exynos5422-based Odroid
> XU3/XU4/HC1 boards.
>
> Fixes: 3721924c8154 ("ARM: 8081/1: MCPM: provide infrastructure to allow for
> MCPM loopback")
> Signed-off-by: Marek Szyprowski
> Acked-by: Nicolas Pitre
> ---
Please add my.
Tested-by: Anand Moon
[0.701094] smp: Brought up 1 node, 8 CPUs
[0.701212] SMP: Total of 8 processors activated (384.00 BogoMIPS).
[0.701329] CPU: All CPU(s) started in HYP mode.
[0.701421] CPU: Virtualization extensions available.
> v2:
> - fixed support for Thumb-mode kernel
> ---
> arch/arm/common/mcpm_entry.c | 2 +-
> arch/arm/include/asm/suspend.h | 1 +
> arch/arm/kernel/sleep.S| 12
> 3 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/common/mcpm_entry.c b/arch/arm/common/mcpm_entry.c
> index ad574d20415c..1b1b82b37ce0 100644
> --- a/arch/arm/common/mcpm_entry.c
> +++ b/arch/arm/common/mcpm_entry.c
> @@ -381,7 +381,7 @@ static int __init nocache_trampoline(unsigned long _arg)
> unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> phys_reset_t phys_reset;
>
> - mcpm_set_entry_vector(cpu, cluster, cpu_resume);
> + mcpm_set_entry_vector(cpu, cluster, cpu_resume_no_hyp);
> setup_mm_for_reboot();
>
> __mcpm_cpu_going_down(cpu, cluster);
> diff --git a/arch/arm/include/asm/suspend.h b/arch/arm/include/asm/suspend.h
> index 452bbdcbcc83..506314265c6f 100644
> --- a/arch/arm/include/asm/suspend.h
> +++ b/arch/arm/include/asm/suspend.h
> @@ -10,6 +10,7 @@ struct sleep_save_sp {
> };
>
> extern void cpu_resume(void);
> +extern void cpu_resume_no_hyp(void);
> extern void cpu_resume_arm(void);
> extern int cpu_suspend(unsigned long, int (*)(unsigned long));
>
> diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
> index a8257fc9cf2a..5dc8b80bb693 100644
> --- a/arch/arm/kernel/sleep.S
> +++ b/arch/arm/kernel/sleep.S
> @@ -120,6 +120,14 @@ ENDPROC(cpu_resume_after_mmu)
> .text
> .align
>
> +#ifdef CONFIG_MCPM
> + .arm
> +THUMB( .thumb )
> +ENTRY(cpu_resume_no_hyp)
> +ARM_BE8(setend be) @ ensure we are in BE mode
> + b no_hyp
> +#endif
> +
> #ifdef CONFIG_MMU
> .arm
> ENTRY(cpu_resume_arm)
> @@ -135,6 +143,7 @@ ARM_BE8(setend be) @ ensure we are in BE
> mode
> bl __hyp_stub_install_secondary
> #endif
> safe_svcmode_maskall r1
> +no_hyp:
> mov r1, #0
> ALT_SMP(mrc p15, 0, r0, c0, c0, 5)
> ALT_UP_B(1f)
> @@ -163,6 +172,9 @@ ENDPROC(cpu_resume)
>
> #ifdef CONFIG_MMU
> ENDPROC(cpu_resume_arm)
> +#endif
> +#ifdef CONFIG_MCPM
> +ENDPROC(cpu_resume_no_hyp)
> #endif
>
> .align 2
> --
> 2.17.1
>
Re: [RFC 1/2] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
Hi Krzysztof,
On Fri, 15 Feb 2019 at 13:01, Krzysztof Kozlowski wrote:
>
> On Thu, 14 Feb 2019 at 19:35, Anand Moon wrote:
> >
> > hi Krzysztof,
> >
> > Thanks fro your review comments.
> >
> > On Thu, 14 Feb 2019 at 18:11, Krzysztof Kozlowski wrote:
> > >
> > > Hi Anand,
> > >
> > > Thanks for the patch. See comments below.
> > >
> > > On Wed, 13 Feb 2019 at 22:41, Anand Moon wrote:
> > > >
> > > > Add suspend-to-mem node to regulator core to be enabled or disabled
> > > > during system suspend and also support changing the regulator operating
> > > > mode during runtime and when the system enter sleep mode.
> > > >
> > > > Cc: Marek Szyprowski
> > > > Cc: Krzysztof Kozlowski
> > > > Cc: Chanwoo Choi
> > > > Signed-off-by: Anand Moon
> > > > ---
> > > >
> > > > Changes from previos patch
> > > > [0] https://patchwork.kernel.org/patch/10712549/
> > > >
> > > > Set all the WAKEUP source regulator in suspend-on state.
> > > > LD04, LD012, LD015, LD020, LD022
> > > > Set all the non used regulator in suspend-odd state
> > > > LD02, LD03, LD05, LD06, LD07, LD011, LD013, LDO14, LD016
> > > >
> > > > BUCK5, BUCK6, BUCK7 and not confirable as per driver max77686-regulator
> > > >
> > > > Tested on microSD card and it resumes correcly after suspend.
> > > > eMMC is not able to resume after entering into suspend state,
> > > > which need to be investigated and how to debug more.
> > > > ---
> > > > .../boot/dts/exynos4412-odroid-common.dtsi| 63 +++
> > > > arch/arm/boot/dts/exynos4412-odroidu3.dts | 3 +
> > > > 2 files changed, 66 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > index 08d3a0a7b4eb..e984461c37d9 100644
> > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > @@ -288,6 +288,9 @@
> > > > regulator-min-microvolt = <180>;
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > + regulator-state-mem {
> > > > + regulator-off-in-suspend;
> > > > + };
> > >
> > > I see my comment from previous patch was not addressed.
> >
> > I left this unchanged since this regulator is not active linked and used.
> > Ok I will change this to regulator-on-in-suspend,
>
> Why?
>
> Previous patch was setting this to "on". I said that this is noop and
> if you want to add it, I need explanation why this regulator has to
> stay on during suspend.
>
> So you changed to "off"... which is still noop... and you did not
> provide explanation. Now you replied that you will change to "on"...
> so this will be circle. Still without explanation.
>
I have added some debug prints to get more inputs.
Here is the boot logs for sdcard suspend resume
[1] https://pastebin.com/wvJvJidp
[root@archl-u3m ~]# rtcwake -d /dev/rtc0 -m mem -s 10
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup from "mem" using /dev/rtc0 at Fri Feb 15 13:28:06 2019
[ 97.165349] PM: suspend entry (deep)
[ 97.165846] PM: Syncing filesystems ... done.
[ 97.344436] Freezing user space processes ... (elapsed 0.006 seconds) done.
[ 97.354738] OOM killer disabled.
[ 97.356028] Freezing remaining freezable tasks ... (elapsed 0.004
seconds) done.
[ 97.413453] smsc95xx 1-2:1.0 eth0: entering SUSPEND2 mode
[ 97.423227] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 97.444346] dwc2 1248.hsotg: suspending usb gadget g_ether
[ 97.446728] dwc2 1248.hsotg: dwc2_hsotg_ep_disable: called for ep0
[ 97.451287] dwc2 1248.hsotg: dwc2_hsotg_ep_disable: called for ep0
[ 97.457742] dwc2 1248.hsotg: new device is full-speed
[ 97.465766] wake enabled for irq 119
[ 97.466979] BUCK9: No configuration
[ 97.470417] BUCK8_P3V3: No configuration
[ 97.474131] BUCK7_2.0V: No configuration
[ 97.477954] BUCK6_1.35V: No configuration
[ 97.481946] VDDQ_CKEM1_2_1.2V: No configuration
[ 97.487930] BUCK4: regulator suspend
Re: [RFC 1/2] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
Hi Krzysztof,
On Fri, 15 Feb 2019 at 13:01, Krzysztof Kozlowski wrote:
>
> On Thu, 14 Feb 2019 at 19:35, Anand Moon wrote:
> >
> > hi Krzysztof,
> >
> > Thanks fro your review comments.
> >
> > On Thu, 14 Feb 2019 at 18:11, Krzysztof Kozlowski wrote:
> > >
> > > Hi Anand,
> > >
> > > Thanks for the patch. See comments below.
> > >
> > > On Wed, 13 Feb 2019 at 22:41, Anand Moon wrote:
> > > >
> > > > Add suspend-to-mem node to regulator core to be enabled or disabled
> > > > during system suspend and also support changing the regulator operating
> > > > mode during runtime and when the system enter sleep mode.
> > > >
> > > > Cc: Marek Szyprowski
> > > > Cc: Krzysztof Kozlowski
> > > > Cc: Chanwoo Choi
> > > > Signed-off-by: Anand Moon
> > > > ---
> > > >
> > > > Changes from previos patch
> > > > [0] https://patchwork.kernel.org/patch/10712549/
> > > >
> > > > Set all the WAKEUP source regulator in suspend-on state.
> > > > LD04, LD012, LD015, LD020, LD022
> > > > Set all the non used regulator in suspend-odd state
> > > > LD02, LD03, LD05, LD06, LD07, LD011, LD013, LDO14, LD016
> > > >
> > > > BUCK5, BUCK6, BUCK7 and not confirable as per driver max77686-regulator
> > > >
> > > > Tested on microSD card and it resumes correcly after suspend.
> > > > eMMC is not able to resume after entering into suspend state,
> > > > which need to be investigated and how to debug more.
> > > > ---
> > > > .../boot/dts/exynos4412-odroid-common.dtsi| 63 +++
> > > > arch/arm/boot/dts/exynos4412-odroidu3.dts | 3 +
> > > > 2 files changed, 66 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > index 08d3a0a7b4eb..e984461c37d9 100644
> > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > @@ -288,6 +288,9 @@
> > > > regulator-min-microvolt = <180>;
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > + regulator-state-mem {
> > > > + regulator-off-in-suspend;
> > > > + };
> > >
> > > I see my comment from previous patch was not addressed.
> >
> > I left this unchanged since this regulator is not active linked and used.
> > Ok I will change this to regulator-on-in-suspend,
>
> Why?
>
> Previous patch was setting this to "on". I said that this is noop and
> if you want to add it, I need explanation why this regulator has to
> stay on during suspend.
>
> So you changed to "off"... which is still noop... and you did not
> provide explanation. Now you replied that you will change to "on"...
> so this will be circle. Still without explanation.
>
I will re check with my previous patch and the driver code which
support suspend state.
Ok check the regulator driver max77686-regulator and enable the logs their.
> >
> > From documentation device tree binding regulator.txt
> > "- regulator-always-on: boolean, regulator should never be disabled"
> >
> > But some regulator switches to a low power mode under light current loads
> > and the device automatically switches back to a fast response mode as the
> > output load increases.
> >
> > >
> > > > };
> > > >
> > > > ldo3_reg: LDO3 {
> > > > @@ -295,6 +298,9 @@
> > > > regulator-min-microvolt = <180>;
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > + regulator-state-mem {
> > > > + regulator-off-in-suspend;
> > > > + };
> > >
> > > The same...
> >
> > Ok I will change this to regulator-on-in-suspend,
>
> The same - why changing this to
Re: [RFC 2/2] soc: samsung: pmu: Add the PMU data of exynos4412 to support low-power state
Hi Krzysztof,
On Fri, 15 Feb 2019 at 13:03, Krzysztof Kozlowski wrote:
>
> On Thu, 14 Feb 2019 at 19:37, Anand Moon wrote:
> >
> > Hi Krzysztof,
> >
> > Thanks for your review comments.
> >
> > On Thu, 14 Feb 2019 at 18:29, Krzysztof Kozlowski wrote:
> > >
> > > On Wed, 13 Feb 2019 at 22:41, Anand Moon wrote:
> > > >
> > > > This patch adds configration for PMU (Power Management Unit) state
> > > > tuning for exynos4412 SoC in order to enter low-power mode during
> > > > suspend power modes and help resume from suspend state.
> > >
> > > The U3 and Trats2 already enter STOP/S2R so please describe what
> > > exactly you change.
> > >
> > > > Fixes: bfce552d0b1 ("drivers: soc: Add support for Exynos PMU driver")
> > >
> > > How it fixes it? What was broken in that commit?
> >
> > * I was not aware on their is common framework for suspend and resume
> > other than setting this here.I only look in to some the other exynos
> > pmu architecture
> > and referring 3.10.x kernel to model my changes.*
>
> Suspend in general should be working already so adding this code just
> because is not a valid reason. Please specify what is not working
> first.
>
Please accept *my apology* for not studying the code changes required.
Sorry for wasting your precious time in review.
My only intention with this patch was to correctly initialize some PMU
parameters.
which might be wrong. so lets drop this.
> > >
> > > > Cc: Marek Szyprowski
> > > > Cc: Krzysztof Kozlowski
> > > > Cc: Chanwoo Choi
> > > > Signed-off-by: Anand Moon
> > > > ---
> > > >
> > > > Changes from previous patch.
> > > > New patch to this series to support suspend and resume state
> > > >
> > > > Changes have been tested on microSD card but fails to resume on cMMC.
> > > > It need to be investigated and more debuging
> > > > ---
> > > > drivers/soc/samsung/exynos4-pmu.c | 83 +
> > > > include/linux/soc/samsung/exynos-regs-pmu.h | 21 ++
> > > > 2 files changed, 104 insertions(+)
> > > >
> > > > diff --git a/drivers/soc/samsung/exynos4-pmu.c
> > > > b/drivers/soc/samsung/exynos4-pmu.c
> > > > index a7cdbf1aac0c..d261a0d2371e 100644
> > > > --- a/drivers/soc/samsung/exynos4-pmu.c
> > > > +++ b/drivers/soc/samsung/exynos4-pmu.c
> > > > @@ -200,10 +200,93 @@ static const struct exynos_pmu_conf
> > > > exynos4412_pmu_config[] = {
> > > > { PMU_TABLE_END,},
> > > > };
> > > >
> > > > +static unsigned int const exynos4412_list_feed[] = {
> > > > + EXYNOS4_ARM_CORE0_OPTION,
> > > > + EXYNOS4_ARM_CORE1_OPTION,
> > > > + EXYNOS4_ARM_CORE2_OPTION,
> > > > + EXYNOS4_ARM_CORE3_OPTION,
> > > > + EXYNOS4_ARM_COMMON_OPTION,
> > > > + EXYNOS4_CAM_OPTION,
> > > > + EXYNOS4_TV_OPTION,
> > > > + EXYNOS4_MFC_OPTION,
> > > > + EXYNOS4_G3D_OPTION,
> > > > + EXYNOS4_LCD0_OPTION,
> > > > + EXYNOS4_ISP_OPTION,
> > > > + EXYNOS4_MAUDIO_OPTION,
> > > > + EXYNOS4_GPS_OPTION,
> > > > + EXYNOS4_GPS_ALIVE_OPTION,
> > > > +};
> > > > +
> > > > +static void exynos4412_pmu_central_seq(bool enable)
> > >
> > > You name the argument as "enable" but during initialization and
> > > system running you pass here false. It confuses me. What do you enable
> > > here?
> > >
> >
> > Yep your are correct need to drop this function as already done in
> > common frame work.
> >
> > > > +{
> > > > + unsigned int value;
> > > > +
> > > > + value = pmu_raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
> > > > + if (enable)
> > > > + value &= ~S5P_CENTRAL_LOWPWR_CFG;
> > > > + else
> > > > + value |= S5P_CENTRAL_LOWPWR_CFG;
> > > > + pmu_raw_writel(value, S5P_CENTRAL_SEQ_CONFIGURATION);
> > >
> > > You duplicate exynos_pm_central_suspend() without removing the original
> > > code.
> > >
> > > > +
> > > > + value = pmu_raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION_COREBLK);
> > > > + if (enable)
&
Re: [RFC 2/2] soc: samsung: pmu: Add the PMU data of exynos4412 to support low-power state
Hi Krzysztof,
Thanks for your review comments.
On Thu, 14 Feb 2019 at 18:29, Krzysztof Kozlowski wrote:
>
> On Wed, 13 Feb 2019 at 22:41, Anand Moon wrote:
> >
> > This patch adds configration for PMU (Power Management Unit) state
> > tuning for exynos4412 SoC in order to enter low-power mode during
> > suspend power modes and help resume from suspend state.
>
> The U3 and Trats2 already enter STOP/S2R so please describe what
> exactly you change.
>
> > Fixes: bfce552d0b1 ("drivers: soc: Add support for Exynos PMU driver")
>
> How it fixes it? What was broken in that commit?
* I was not aware on their is common framework for suspend and resume
other than setting this here.I only look in to some the other exynos
pmu architecture
and referring 3.10.x kernel to model my changes.*
>
> > Cc: Marek Szyprowski
> > Cc: Krzysztof Kozlowski
> > Cc: Chanwoo Choi
> > Signed-off-by: Anand Moon
> > ---
> >
> > Changes from previous patch.
> > New patch to this series to support suspend and resume state
> >
> > Changes have been tested on microSD card but fails to resume on cMMC.
> > It need to be investigated and more debuging
> > ---
> > drivers/soc/samsung/exynos4-pmu.c | 83 +
> > include/linux/soc/samsung/exynos-regs-pmu.h | 21 ++
> > 2 files changed, 104 insertions(+)
> >
> > diff --git a/drivers/soc/samsung/exynos4-pmu.c
> > b/drivers/soc/samsung/exynos4-pmu.c
> > index a7cdbf1aac0c..d261a0d2371e 100644
> > --- a/drivers/soc/samsung/exynos4-pmu.c
> > +++ b/drivers/soc/samsung/exynos4-pmu.c
> > @@ -200,10 +200,93 @@ static const struct exynos_pmu_conf
> > exynos4412_pmu_config[] = {
> > { PMU_TABLE_END,},
> > };
> >
> > +static unsigned int const exynos4412_list_feed[] = {
> > + EXYNOS4_ARM_CORE0_OPTION,
> > + EXYNOS4_ARM_CORE1_OPTION,
> > + EXYNOS4_ARM_CORE2_OPTION,
> > + EXYNOS4_ARM_CORE3_OPTION,
> > + EXYNOS4_ARM_COMMON_OPTION,
> > + EXYNOS4_CAM_OPTION,
> > + EXYNOS4_TV_OPTION,
> > + EXYNOS4_MFC_OPTION,
> > + EXYNOS4_G3D_OPTION,
> > + EXYNOS4_LCD0_OPTION,
> > + EXYNOS4_ISP_OPTION,
> > + EXYNOS4_MAUDIO_OPTION,
> > + EXYNOS4_GPS_OPTION,
> > + EXYNOS4_GPS_ALIVE_OPTION,
> > +};
> > +
> > +static void exynos4412_pmu_central_seq(bool enable)
>
> You name the argument as "enable" but during initialization and
> system running you pass here false. It confuses me. What do you enable
> here?
>
Yep your are correct need to drop this function as already done in
common frame work.
> > +{
> > + unsigned int value;
> > +
> > + value = pmu_raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
> > + if (enable)
> > + value &= ~S5P_CENTRAL_LOWPWR_CFG;
> > + else
> > + value |= S5P_CENTRAL_LOWPWR_CFG;
> > + pmu_raw_writel(value, S5P_CENTRAL_SEQ_CONFIGURATION);
>
> You duplicate exynos_pm_central_suspend() without removing the original code.
>
> > +
> > + value = pmu_raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION_COREBLK);
> > + if (enable)
> > + value &= ~S5P_CENTRAL_LOWPWR_CFG;
> > + else
> > + value |= S5P_CENTRAL_LOWPWR_CFG;
>
> As manual says - set this register only if you disable C2C. Our entire
> low power configuration for STOP mode is for C2C enabled case so you
> add inconsistent configuration.
Ok Sorry I overlook this code change.
Enable system power down. Set only CENTRAL_SEQ_CONFIGURATION register
if you disable C2C.
Set both CENTRAL_SEQ_CONFIGURATION and
CENTRAL_SEQ_CONFIGURATION_COREBLK registers if you enable C2C.
> > + pmu_raw_writel(value, S5P_CENTRAL_SEQ_CONFIGURATION_COREBLK);
> > +}
> > +
> > +static void exynos4412_pmu_init(void)
> > +{
> > + unsigned int value;
> > + int i;
> > +
> > + /* Enable USE_STANDBY_WFI for all CORE */
> > + pmu_raw_writel(S5P_USE_STANDBY_WFI_ALL, S5P_CENTRAL_SEQ_OPTION);
>
> This does not look related to improving suspend... it looks unrelated.
>
Ok yes your are correct all ready done in comment frame work.
"Execute WFI/WFE for all CPU cores. As soon as all the CPU cores in
Exynos 4412 SCP enter STANDBY mode"
> > +
> > + /* Decides whether to use retention capability */
> > + value = pmu_raw_readl(S5P_ARM_L2_0_OPTION);
> > + value &= ~EXYNOS_L2_USE_RETENTION;
> > + pmu_raw_writel(value, S5P_ARM_L2_0_OPTION);
> > +
