On 01/01/2017 11:21 AM, Mathias Kresin wrote:
> The clock source is set by the ltq-hcd driver but are not by the
> dwc2 driver. Without having the correct clock set the dwc driver
> fails to reset the usb core and errors out. The values for supported
> lantiq targets are exactly the same as set by the ltq-hcd driver and
> should not cause any regressions.
>
> Fixes FS#351
>
> Signed-off-by: Mathias Kresin <d...@kresin.me>
> ---
>
> Well the code works but is not really a beauty. But I need some input
> to _possibly_ improve the code or at least the commit message.
>
> Based on the disabled code in the ltq-hcd driver I guess for all
> targets two bits are used to set the clock source.
>
> I know that on vr9 the bits set to 00 or 11 means "XTAL 36 MHz input
> devide by 3" where 00 is the default value.
>
> After playing a bit with the bits, I'm the opinion the same applies to
> Danube a well.
>
> It's kinda strange that for Amazon only one bit is cleared within the
> ltq-hcd driver. It looks more like an error or yet unknown workaround.
> Setting the interface clock bits to 00 (default) does make more sense
> to me. I've changed this in contrast to the ltq-hcd driver but do not
> have any hardware to check this change or the dwc2 at all on Amazon.
>
> For some reason the usb clock source has already the correct value on
> vr9. I'm not sure if any vr9 board uses a clock source different than
> the default "XTAL 36 MHz input devide by 3". For completeness I tend to
> add the clock source for vr9 as well. Any opinions?
>
> Albeit we obviously don't have an alien board which need a different
> clock source than the others, setting the clock source to a fixed value
> seams to me a really bad idea. And since it is the second time I had to
> touch the CGU_IFCCR register [0][1] I've somehow the impression we need
> some glue code to set the different clock sources via some kind of glue
> code. I'm not sure what is the best way to do this. Should I add
> something similar to the lantiq,phy-clk-src? Is there any chance that
> this code is accepted upstream or should we consider it as LEDE hack?
> Is the common clock framework maybe the saviour?
>
> Would anyone with access to the datasheets be so kind to confirm:
>
> - all lantiq targets are using two bits to set the clock source
> - the meaning of the usbclk bit combinations are the same for all
> lantiq targets (including 00 == 11)
> - it is safe to set the usb clock to 00 or 11 for Amazon
>
> If 00 == 11 on Amazon/Danube, the lantiq,ase and lantiq,danube
> conditions can be merged.
>
> The lantiq,ar9 can be extended to cover vr9 as well.
>
> [0] https://git.lede-project.org/44cace4dabe186a486d6713de6196bc7cea2228b
> [1] https://git.lede-project.org/d4de9f72f31c4716f78fea8950261a3bdafdbccb
This is copied from the different documentations:
On Danube it looks like this:
USB Clock Source
Clock config is configured to:
00 B Internal, 12 MHz internal
01 B External, from USB XTAL (default)
10 B External/4, from USB XTAL then divided by 4
11 B 12, special internal clock generated from 36 MHz source
Bit 5:4 on reg 0x0018, reset value of this bit is 01 B
On Amazon SE it looks like this:
12 MHz USB Clock Source
Clock config is configured to:
0 B Divider after divider
1 B XTALInput From XTAL only
Bit 5 on reg 0x0018, reset value of this bit is 0 B
On xRX200 (VR9) it looke like this:
USB 12 MHz Clock Source
Clock config is configured to:
00 B 12 MHz XTAL 36 MHz input divide by 3 (default)
01 B 12 MHz XTAL 36 MHz input is directly provided to USB (This is
reserved for running with 12 MHz XTAL)
10 B 12 MHz 12 MHz USB clock derived from PLL0 300 MHz output as
divide by 25 (for 25 MHz XTAL input, this is only valid option)
11 B 12 MHz XTAL 36 MHz input divide by 3
Bit 1:0 on reg 0x0024, reset value of this bit is 00 B
On xRX200 this depends on the confiuration of the CLK_OUT0, CLK_OUT1 and
CLK_OUT3.
Currently I do not have the documentation of the AR9 at hand, will
search for it later.
> .../0032-lantiq-set-the-usb-clock-source.patch | 52
> ++++++++++++++++++++++
> ...MIPS-lantiq-danube-initialize-usb-on-boot.patch | 2 +-
> .../linux/lantiq/patches-4.4/0047-poweroff.patch | 4 +-
> 3 files changed, 55 insertions(+), 3 deletions(-)
> create mode 100644
> target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
>
> diff --git
> a/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
> b/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
> new file mode 100644
> index 0000000..bfc41aa
> --- /dev/null
> +++
> b/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
> @@ -0,0 +1,52 @@
> +From 6e6569954319ef5f3e8c6a2c56056a90dd3c4ca0 Mon Sep 17 00:00:00 2001
> +From: Mathias Kresin <d...@kresin.me>
> +Date: Sat, 31 Dec 2016 10:46:18 +0100
> +Subject: [PATCH] MIPS: lantiq: set the usb clock source
> +
> +The clock source is set by the ltq-hcd driver but are not by the
> +dwc2 driver. Without having the correct clock set the dwc driver
> +fails to reset the usb core and errors out. The values for supported
> +lantiq targets are exactly the same as set by the ltq-hcd driver and
> +should not cause any regressions.
> +
> +Signed-off-by: Mathias Kresin <d...@kresin.me>
> +---
> +
> + arch/mips/lantiq/xway/reset.c | 14 ++++++++++++++
> + 1 file changed, 14 insertions(+)
> +
> +--- a/arch/mips/lantiq/xway/reset.c
> ++++ b/arch/mips/lantiq/xway/reset.c
> +@@ -95,6 +95,14 @@
> + #define PMU_USB0_P BIT(0)
> + #define PMU_USB1_P BIT(26)
> +
> ++/* USB clock */
> ++#define CGU_IFCCR 0x0018
> ++#define CGU_USBCLK_MASK 0x3
These bits are named USBSEL in the Dabube and Amazon SE and USB_SEL in
xrx200 documentation.
> ++#define CGU_USBCLK_DEFAULT 0x0
> ++#define CGU_USBCLK_DIRECT 0x1
> ++#define CGU_USBCLK_PPL0 0x2
> ++#define CGU_USBCLK_XTAL 0x3
> ++
> + /* remapped base addr of the reset control unit */
> + static void __iomem *ltq_rcu_membase;
> + static struct device_node *ltq_rcu_np;
> +@@ -317,6 +325,17 @@ static void ltq_usb_init(void)
> + ltq_rcu_w32(ltq_rcu_r32(RCU_CFG1A) | BIT(0), RCU_CFG1A);
> + ltq_rcu_w32(ltq_rcu_r32(RCU_CFG1B) | BIT(0), RCU_CFG1B);
> +
> ++ /* set usb clock source */
> ++ if (of_machine_is_compatible("lantiq,ase"))
> ++ ltq_cgu_w32((ltq_cgu_r32(CGU_IFCCR) & ~(CGU_USBCLK_MASK << 4))
> ++ | (CGU_USBCLK_DEFAULT << 4), CGU_IFCCR);
This is wrong.
> ++ else if (of_machine_is_compatible("lantiq,danube"))
> ++ ltq_cgu_w32((ltq_cgu_r32(CGU_IFCCR) & ~(CGU_USBCLK_MASK << 4))
> ++ | (CGU_USBCLK_XTAL << 4), CGU_IFCCR);
> ++ else if (of_machine_is_compatible("lantiq,ar9"))
> ++ ltq_cgu_w32((ltq_cgu_r32(CGU_IFCCR) & ~CGU_USBCLK_MASK)
> ++ | CGU_USBCLK_XTAL, CGU_IFCCR);
> ++
> + /* Enable USB PHY power for cores 1 & 2 */
> + ltq_pmu_enable(PMU_USB0_P);
> + ltq_pmu_enable(PMU_USB1_P);
> diff --git
> a/target/linux/lantiq/patches-4.4/0039-MIPS-lantiq-danube-initialize-usb-on-boot.patch
>
> b/target/linux/lantiq/patches-4.4/0039-MIPS-lantiq-danube-initialize-usb-on-boot.patch
> index bd42f38..75d5457 100644
> ---
> a/target/linux/lantiq/patches-4.4/0039-MIPS-lantiq-danube-initialize-usb-on-boot.patch
> +++
> b/target/linux/lantiq/patches-4.4/0039-MIPS-lantiq-danube-initialize-usb-on-boot.patch
> @@ -1,6 +1,6 @@
> --- a/arch/mips/lantiq/xway/reset.c
> +++ b/arch/mips/lantiq/xway/reset.c
> -@@ -370,6 +370,7 @@ static int __init mips_reboot_setup(void
> +@@ -389,6 +389,7 @@ static int __init mips_reboot_setup(void
> panic("Failed to remap core memory");
>
> if (of_machine_is_compatible("lantiq,ar9") ||
> diff --git a/target/linux/lantiq/patches-4.4/0047-poweroff.patch
> b/target/linux/lantiq/patches-4.4/0047-poweroff.patch
> index 88aed2c..d34ec99 100644
> --- a/target/linux/lantiq/patches-4.4/0047-poweroff.patch
> +++ b/target/linux/lantiq/patches-4.4/0047-poweroff.patch
> @@ -1,6 +1,6 @@
> --- a/arch/mips/lantiq/xway/reset.c
> +++ b/arch/mips/lantiq/xway/reset.c
> -@@ -301,12 +301,6 @@ static void ltq_machine_halt(void)
> +@@ -309,12 +309,6 @@ static void ltq_machine_halt(void)
> unreachable();
> }
>
> @@ -13,7 +13,7 @@
> static void ltq_usb_init(void)
> {
> /* Power for USB cores 1 & 2 */
> -@@ -380,7 +374,6 @@ static int __init mips_reboot_setup(void
> +@@ -399,7 +393,6 @@ static int __init mips_reboot_setup(void
>
> _machine_restart = ltq_machine_restart;
> _machine_halt = ltq_machine_halt;
>
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
