[PATCH] arm64: dts: rockchip: Change serial baud rate for Pinephone Pro to 1.5 MB

[Javier Martinez Canillas]

Heiko Stübner <heiko at sntech.de> writes:

Hello Heiko,

> Hi,
>
> Am Dienstag, 18. April 2023, 14:11:53 CEST schrieb Javier Martinez Canillas:
>> Heiko Stübner <heiko at sntech.de> writes:
>> 
>> Hello Heiko,
>> 
>> > Hi Peter,
>> >
>> > Am Dienstag, 4. April 2023, 14:52:02 CEST schrieb Peter Geis:
>> >> On Tue, Apr 4, 2023 at 3:55 AM Heiko Stübner <heiko at sntech.de> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > Am Montag, 3. April 2023, 19:59:37 CEST schrieb Javier Martinez Canillas:
>> >> > > This baud rate is set for the device by mainline u-boot and is also what
>> >> > > is set in the Pinebook Pro Device Tree, which is a device similar to the
>> >> > > PinePhone Pro but with a different form factor.
>> >> > >
>> >> > > Otherwise, the baud rate of the firmware and Linux don't match by default
>> >> > > and a 'console=ttyS2,1500000n8' kernel command line parameter is required
>> >> > > to have proper output for both.
>> >> >
>> >> > The interesting question is always if this will break someone else's setup.
>> >> > I've never really understood the strange setting of 1.5MBps, but on the
>> >> > other hand it _is_ a reality on most boards.
>> >
>> >> The 1.5M baud is default because the clock structure on rockchip
>> >> devices does not allow a clean 115200 baud. By attempting to force
>> >> 115200, it will always be slightly off (either low or high depending
>> >> on how the driver decided to round). If this actually causes any
>> >> problems is the subject of much debate.
>> >
>> > thanks so much for this piece of clock-detail. As I wrote, I never really
>> > understood the why _before_ but also never cared that much to dive
>> > into it and find out.
>> >
>> > So your explanation closes one knowledge gap in my head.
>> >
>> > Thanks a lot :-)
>> 
>> Did you make a decision about this? I guess the clock explanation is yet
>> another argument in favour of switching the PPP to a 1.5 Mbps baud rate ?
>
> Sorry, but no decision made here. Either way it's breaking for someone,
> which makes this quite hard.
>

Another ping on this patch.

> The rate accuracy is the one side, the two-boot issue is the other side.
> And mainline u-boot (and levinboot - whatever that is) provides a 3rd side.
>
> People starting with the phone probably won't replace the bootloader
> in a first step but instead might play with a system image or newer kernel.
> So if the uart will break for everyone using the default bootloader from
> the factory that is somewhat bad.
>

Probably won't replace the DTB shipped with the firmware either? If one is
replacing the firmware provided DTB witch the one in the mainline kernel,
probably such person is also using mainline u-boot?

> I don't have a Pinephone Pro myself, so I really hoped for some Acks
> or similar to appear in the meantime.
>

For someone like me who is only using mainline u-boot, linux, etc then
having a consistent uart baud rate across all components is really useful.

Otherwise I either have serial console for u-boot or the kernel, but can't
have both working so is annoying.

It would be good to have a definite answer on this. Since every time that
I try to hack on my PPP, I end changing my DTS and remember this patch :)

> Do we have someone with an actual Pine64 affiliation in this loop?
>

I don't think pine64 cares that much about the software. They just build
the hardware and expect the community to add the support I believe.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat