I'm trying to find how to use higher baud rate through modifying uart clock.
I followed your u-boot patch. But there's nothing changed. After patching u-boot, uart clock still has 24MHz. I checked using this command "cat /sys/class/tty/ttyS1/uartclk". Should I modify dts file also? On Thursday, January 5, 2017 at 7:36:24 AM UTC+9, André Przywara wrote: > On 04/01/17 19:00, jons...@gmail.com <javascript:> wrote: > > On Wed, Jan 4, 2017 at 12:29 PM, André Przywara <andre.p...@arm.com > <javascript:>> wrote: > >> On 04/01/17 16:40, jons...@gmail.com <javascript:> wrote: > >>> On Wed, Jan 4, 2017 at 8:36 AM, André Przywara <andre.p...@arm.com > <javascript:>> 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 > <javascript:>> wrote: > >>>>>> On Tue, Jan 3, 2017 at 2:52 PM, jons...@gmail.com <javascript:> < > jons...@gmail.com <javascript:>> wrote: > >>>>>>> On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki <jaganna...@gmail.com > <javascript:>> wrote: > >>>>>>>> On Tue, Jan 3, 2017 at 3:38 AM, jons...@gmail.com <javascript:> < > jons...@gmail.com <javascript:>> 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). > > That refers to PERIPH0, I was asking for the APB2 frequency. Looking at > the achievable baud rates and error rates for common speeds (115200) I > came up with a divider of 5: > 1200 MHz / 5 = 240 MHz APB2 frequency > 240 MHz / 16 = 15 Mbps maximum baud rate > divider|baud rate | error > 5 3 Mbps 0.0% > 10 1.5 Mbps 0.0% > 16 921600 1.7% > 130 115200 0.16% > > Reports seems to indicate that at least 12.5 Mbps is feasible with the > UARTs, so this maximum of 15 Mbps seems like a good approach, because it > gives 3 and 1.5 Mbps without errors. > > Alternatives would be max. baud rate of 3 Mbps (still limiting) or the > system maximum of 75 Mbps, but clocking APB2 at 1.2 GHz sounds a bit > over the top for me. > > Jon, can you try this U-Boot patch (copy & pasted in, so probably won't > apply cleanly): > > --- a/arch/arm/mach-sunxi/clock_sun6i.c > +++ b/arch/arm/mach-sunxi/clock_sun6i.c > @@ -65,9 +65,9 @@ void clock_init_uart(void) > (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; > > /* uart clock source is apb2 */ > - writel(APB2_CLK_SRC_OSC24M| > + writel(APB2_CLK_SRC_PLL6| > APB2_CLK_RATE_N_1| > - APB2_CLK_RATE_M(1), > + APB2_CLK_RATE_M(5), > &ccm->apb2_div); > > /* open the clock for uart */ > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -42,7 +42,7 @@ > /* Serial & console */ > #define CONFIG_SYS_NS16550_SERIAL > /* ns16550 reg in the low bits of cpu reg */ > -#define CONFIG_SYS_NS16550_CLK 24000000 > +#define CONFIG_SYS_NS16550_CLK 240000000 > #ifndef CONFIG_DM_SERIAL > # define CONFIG_SYS_NS16550_REG_SIZE -4 > # define CONFIG_SYS_NS16550_COM1 SUNXI_UART0_BASE > > Cheers, > Andre. > > > > >> > >> 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-b...@lists.denx.de <javascript:> > >>>>>> http://lists.denx.de/mailman/listinfo/u-boot > >>>> > >>> > >>> > >>> > >> > > > > > > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
