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

[André Przywara]

On 04/01/17 16:40, jonsmirl at gmail.com wrote:
> 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.

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.

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 at lists.denx.de
>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>
> 
> 
>