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

[André Przywara]

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?

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