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

[jonsmirl at gmail.com]

On Wed, Jan 4, 2017 at 12:29 PM, André Przywara <andre.przywara at arm.com> wrote:
> 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.

In the datasheet there is a note recommending not to change this
600Mhz (2x 1.2Ghz).

>
> 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
>>>
>>
>>
>>
>



-- 
Jon Smirl
jonsmirl at gmail.com