On 03/14/2016 05:13 PM, Ladislav Michl wrote:
Hi there!
seems it's been three years since:
[PATCH 1/1] Fix sprz319 erratum 2.1
http://article.gmane.org/gmane.linux.ports.arm.omap/71633
errata: http://www.ti.com/lit/er/sprz319f/sprz319f.pdf
Nice summary (third post by Rodrigo Lemos) can be found here:
https://github.com/RobertCNelson/stable-kernel/issues/26
so I'm not going to repeat it here.
Company I'm working for has few thousands of IGEPv2 boards in field. They
have hub connected to usb port with udlfb display, 3G modem and usbserial:
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=udlfb, 480M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 3: Dev 4, If 1, Class=Vendor Specific Class, Driver=, 480M
|__ Port 3: Dev 4, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 3: Dev 4, If 3, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 3: Dev 4, If 4, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 3: Dev 4, If 5, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 6, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 3: Dev 6, If 1, Class=CDC Data, Driver=cdc_acm, 12M
Few tens of those disconnects USB after while (one minute to few hours) with:
"usb usb3-port1: disabled by hub (EMI?), re-enabling..."
IGEPv2 uses DM3730 with 26MHz crystal divided by two providing 13MHz SYS_CLK,
therefore it is good candidate to fix. Patch bellow was used as a dirty hack
to test if usb disconnects go away with errata applied. And indeed, device
is already running for few days without any issues. Now question is, how should
a proper fix look like as modifiing omap2_dpll_round_rate seems easy enough.
Is that acceptable? How to test proper clock to apply errata? Comparing string is
suboptimal. Should we introduce some flag?
The hack applied seems rather bad to me, as it doesn't take any input
frequencies into consideration. Basically you just force the divider /
multiplier to the value required for 13MHz input clock, but this is
going to be wrong with any other input clock.
I think a proper fix would probably be to implement new clock ops for
DPLL5, something similar to what was done with the original patch a few
years back. This would select the divider/multiplier factors for the
DPLL based on table values provided by the erratum.
-Tero
ladis
--- linux-4.5/drivers/clk/ti/dpll3xxx.c.orig 2016-03-14 12:43:58.085003085 +0100
+++ linux-4.5/drivers/clk/ti/dpll3xxx.c 2016-03-14 13:17:57.893417000 +0100
@@ -308,6 +308,7 @@
u8 dco, sd_div, ai = 0;
u32 v;
bool errata_i810;
+ const char *clk_name;
/* 3430 ES2 TRM: 4.7.6.9 DPLL Programming Sequence */
_omap3_noncore_dpll_bypass(clk);
@@ -370,6 +371,12 @@
}
}
+ clk_name = clk_hw_get_name(&clk->hw);
+ if (strcmp(clk_name, "dpll5_ck") == 0) {
+ pr_info("fixing %s (%04lx), %06x -> 01bb05\n", clk_name, dd->mult_div1_reg, v);
+ v = 0x1bb05;
+ }
+
ti_clk_ll_ops->clk_writel(v, dd->mult_div1_reg);
/* Set 4X multiplier and low-power mode */
--- linux-4.5/drivers/clk/ti/divider.c.orig 2016-03-14 12:44:06.509211022 +0100
+++ linux-4.5/drivers/clk/ti/divider.c 2016-03-14 13:18:21.793417000 +0100
@@ -215,6 +215,7 @@
struct clk_divider *divider;
unsigned int div, value;
u32 val;
+ const char *clk_name;
if (!hw || !rate)
return -EINVAL;
@@ -234,6 +235,13 @@
val &= ~(div_mask(divider) << divider->shift);
}
val |= value << divider->shift;
+
+ clk_name = clk_hw_get_name(hw);
+ if (strcmp(clk_name, "dpll5_m2_ck") == 0) {
+ pr_info("fixing %s (%04lx), %04x -> 0008\n", clk_name, divider->reg, val);
+ val = 8;
+ }
+
ti_clk_ll_ops->clk_writel(val, divider->reg);
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
