On 04/01/17 22:59, jonsmirl@gmail.com wrote:
On Wed, Jan 4, 2017 at 5:36 PM, André Przywara andre.przywara@arm.com wrote:
On 04/01/17 19:00, jonsmirl@gmail.com wrote:
On Wed, Jan 4, 2017 at 12:29 PM, André Przywara andre.przywara@arm.com wrote:
On 04/01/17 16:40, jonsmirl@gmail.com wrote:
On Wed, Jan 4, 2017 at 8:36 AM, André Przywara andre.przywara@arm.com wrote:
On 04/01/17 11:25, Chen-Yu Tsai wrote: > On Wed, Jan 4, 2017 at 6:28 PM, Jagan Teki jagan@openedev.com wrote: >> On Tue, Jan 3, 2017 at 2:52 PM, jonsmirl@gmail.com jonsmirl@gmail.com wrote: >>> On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>> On Tue, Jan 3, 2017 at 3:38 AM, jonsmirl@gmail.com jonsmirl@gmail.com wrote: >>>>> I recently ran into a probably with the UARTs on the A64. Many >>>>> Bluetooth modules (like Ampak) use the UART. The data rate of EDR BT >>>>> is 3Mb/s with about 2.1Mb/s though put. To handle this most systems >>>>> set the speed of the BT UART to 3Mb/s. >>>>> >>>>> By default the Allwinner UART clock input is OSC24. When using OSC24 >>>>> the maximum speed the UART can be set to is 1.5Mb/s. The clock input >>>>> (apb2) can be changed over to PERIPH0x2 (1.2ghz) via the device tree >>>>> and 3Mb/s is then supported. >>>>> >>>>> But... there's a problem, UART0 (the console) is using the same master >>>>> clock source. So when you change the clock input over to PERIPH0x2 the >>>>> console stops working. There is no mechanism in Linux to handle this >>>>> clock source change and adjust the dividers on active uarts. So it >>>>> would be best if this master clock was set very early in u-boot and >>>>> then the console is adjusted to use it. >>>>> >>>>> Are there any downsides to making this change in u-boot? >>>> >>>> I don't understand, did you find this behaviour with these SPL changes >>>> or general sunxi u-boot? >> >> I think, this issue need to resolve, Andre any comments? > > This is a completely different issue unrelated to A64 SPL support.
I agree that's a completely orthogonal issue. Someone needs to bake a patch (easy?) and post it. This doesn't depend in any way on this series, in fact would affect many sunxi boards.
> What Jon is saying is that for the UART to go faster than 1.5 Mb/s, > The APB2 clock has to be reparented to the peripheral PLL. When do > we do this is the question. This is a generic sunxi issue.
On the first glance this approach sounds a bit hackish, since we use firmware to setup the clocks in a way to solves a particular issue.
On the other hand using PERIPH0(2x) as a base for APB2 seems like a completely proper setup, even somewhat recommended by Allwinner (after all the UARTs are based on this special clock for a reason).
> Now, I think doing this as soon as possible (with regards to the > running system) would be best. Reparenting the clk on the fly > would change the baud rate, and result in the uart glitching.
Can't we change it when observing the proper order: turning TX/RX off, programming new divisors, changing the clock source, turning TX/RX back on?
You would expect to be able to achieve this reparenting by simply changing the device tree in Linux.
Why would this be done in DT? The APB2 clock is capable of being driven by 32KHz, 24 MHz or PERIPH0(2x), the DT should express this. The old Allwinner binding certainly did, the new hides this in the driver. But as the hardware allows it, the DT shouldn't have a say in the parenting decision - apart from listing the alternatives. This is actually a driver or clock system decision.
I tried that on the Allwinner 3.10
<connection lost>
kernel and it actually works. But... it causes the console to quit working.
Do Linux clk_notifiers work soon enough to handle reparenting the console in the device tree? It is not clear to me that they do. Plus the 8250_dw driver doesn't support it.
I believe Chen-Yu meant that clk_notifiers would allow to notify all clock users of some changed situation (like a different parent clock). As you know, _all_ UARTs plus I2C use this clock, so if *one* requires a higher base clock, *all* users have to notified to change their clock divisors to match the new base frequency. This has nothing to do with device tree directly.
Next I considered changing it in the u-boot device tree. But again, console is set up before u-boot loads that device tree. In Allwinner uboot console is set up in the SPL code before the device tree is loaded.
Traditionally for sunxi boards in upstream U-Boot we use the DT only sparingly. IIRC DT clock information is completely ignored and there is just some static setup - which is way easier and sufficient for our needs. The SPL doesn't use DT at all (mostly for space constraints).
So as I said changing this in U-Boot looks like an easy patch, PLL6 is setup to 600 MHz already, so we just need to change the clock source for APB2 to that and adjust the dividers.
Do you have an idea what a good APB2 frequency would be? IIRC someone one IRC mentioned that the UARTs can't do much higher than 3 Mb/s anyway, so I guess 48 MHz or 96 MHz would be enough? Allwinner's I2C is limited to 400 KHz anyway, so there is no need for a higher clock here.
In the datasheet there is a note recommending not to change this 600Mhz (2x 1.2Ghz).
That refers to PERIPH0, I was asking for the APB2 frequency. Looking at the achievable baud rates and error rates for common speeds (115200) I came up with a divider of 5: 1200 MHz / 5 = 240 MHz APB2 frequency 240 MHz / 16 = 15 Mbps maximum baud rate divider|baud rate | error 5 3 Mbps 0.0% 10 1.5 Mbps 0.0% 16 921600 1.7% 130 115200 0.16%
Reports seems to indicate that at least 12.5 Mbps is feasible with the UARTs, so this maximum of 15 Mbps seems like a good approach, because it gives 3 and 1.5 Mbps without errors.
Alternatives would be max. baud rate of 3 Mbps (still limiting) or the system maximum of 75 Mbps, but clocking APB2 at 1.2 GHz sounds a bit over the top for me.
Jon, can you try this U-Boot patch (copy & pasted in, so probably won't apply cleanly):
What is uboot is this against? I am not using mainline u-boot, we are on the Allwinner stuff.
Sorry, but you are on your own then. This thread is a reply on a mainline U-Boot patch series, so I assumed you were interested in that. My time is far too precious to waste it on that AW crap. Either you switch to mainline or you "port" this patch over to your tree.
Cheers, Andre.
--- a/arch/arm/mach-sunxi/clock_sun6i.c +++ b/arch/arm/mach-sunxi/clock_sun6i.c @@ -65,9 +65,9 @@ void clock_init_uart(void) (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
/* uart clock source is apb2 */
writel(APB2_CLK_SRC_OSC24M|
writel(APB2_CLK_SRC_PLL6| APB2_CLK_RATE_N_1|
APB2_CLK_RATE_M(1),
APB2_CLK_RATE_M(5), &ccm->apb2_div); /* open the clock for uart */--- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -42,7 +42,7 @@ /* Serial & console */ #define CONFIG_SYS_NS16550_SERIAL /* ns16550 reg in the low bits of cpu reg */ -#define CONFIG_SYS_NS16550_CLK 24000000 +#define CONFIG_SYS_NS16550_CLK 240000000 #ifndef CONFIG_DM_SERIAL # define CONFIG_SYS_NS16550_REG_SIZE -4 # define CONFIG_SYS_NS16550_COM1 SUNXI_UART0_BASE
Cheers, Andre.
It would be great if someone could do experiments to get the highest usable baudrate.
Is the PERIPH0(2x) clock always running?
It seems so, anyway the Linux clock system would take care of this now, as the console UART would be at least one user. Though I believe there are more users, so it's unlikely that it would get turned off anyway.
Cheers, Andre.
Maybe defaulting UARTs/I2C to OSC24 was done to save power?
After investigating this I now understand why Allwinner modified the standard Broadcom Bluetooth driver in AOSP. They fixed it to run with a 1.5Mb UART. Everyone else in AOSP uses it with a 3Mb/s UART. All of this started because we were unaware of the changes Allwinner had made to the Broadcom AOSP code and we couldn't get AOSP Bluetooth to work. Who knows why Allwinner didn't just adjust the UART to run at 3Mb/s. Probably two different programmer groups.
Nevertheless it seems worthwhile to give this rather simple U-Boot approach a go. But I would like to see some testing, since this will affect many sunxi boards.
> Also, as Jon mentioned, the 8250_dw driver in the kernel doesn't > support clk notifiers. And it won't work with earlycon anyway...
As a long-term goal teaching the Linux driver to reparent APB2 seems like a good thing, though I expect some nastiness in this.
Cheers, Andre.
>> >>> >>> Previously the boot console uart0 was getting setup in the SPL code. I >>> have not been closely following these changes, is that still true? >>> >>> Changing the clock parent needs to be done before uart0 is >>> initialized. Changing this parent should have no other impact on >>> u-boot other than changing the clock divisor uart0 is using. >>> >>> Once Linux is up, the Linux uart code will see the changed clock >>> parent and allow higher baud rates to be set. >>> >>> This clock parent also impacts the I2C clocks, but I don't believe I2C >>> is enabled in A64 uboot. >> >> Jagan. >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot