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. I tried that on the Allwinner 3.10 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.
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.
Is the PERIPH0(2x) clock always running? 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