On Wed, Jan 4, 2017 at 12:29 PM, André Przywara <andre.przyw...@arm.com> wrote: > On 04/01/17 16:40, jonsm...@gmail.com wrote: >> On Wed, Jan 4, 2017 at 8:36 AM, André Przywara <andre.przyw...@arm.com> >> wrote: >>> >>> On 04/01/17 11:25, Chen-Yu Tsai wrote: >>>> On Wed, Jan 4, 2017 at 6:28 PM, Jagan Teki <ja...@openedev.com> wrote: >>>>> On Tue, Jan 3, 2017 at 2:52 PM, jonsm...@gmail.com <jonsm...@gmail.com> >>>>> wrote: >>>>>> On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki <jagannadh.t...@gmail.com> >>>>>> wrote: >>>>>>> On Tue, Jan 3, 2017 at 3:38 AM, jonsm...@gmail.com <jonsm...@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.
In the Allwinner UART driver they use a look up table for setting the UART divider. It has entries in it for when the 1.2Ghz x2 clock is used. This table limits the max baud to 4Mb/s. > >> 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-b...@lists.denx.de >>>>> http://lists.denx.de/mailman/listinfo/u-boot >>> >> >> >> > -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.