[U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support

[jonsmirl at gmail.com]

On Wed, Jan 4, 2017 at 8:36 AM, André Przywara <andre.przywara at 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 at openedev.com> wrote:
> >> On Tue, Jan 3, 2017 at 2:52 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> >>> On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
> >>>> On Tue, Jan 3, 2017 at 3:38 AM, jonsmirl at gmail.com <jonsmirl at 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 at lists.denx.de
> >> http://lists.denx.de/mailman/listinfo/u-boot
>



-- 
Jon Smirl
jonsmirl at gmail.com