Re: [PATCH V7 0/6] Use CCF to describe the UART baud rate clock

[Yu Tu]

Hi Jerome,

On 2022/3/1 16:36, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
>
> On Tue 01 Mar 2022 at 13:54, Yu Tu <yu.tu@xxxxxxxxxxx> wrote:
>
> > Hi Jerome,
> >
> > On 2022/2/28 18:59, Jerome Brunet wrote:
> > > [ EXTERNAL EMAIL ]
> > >
> > > On Fri 25 Feb 2022 at 15:39, Yu Tu <yu.tu@xxxxxxxxxxx> wrote:
> > >
> > > > Using the common Clock code to describe the UART baud rate
> > > > clock makes it easier for the UART driver to be compatible
> > > > with the baud rate requirements of the UART IP on different
> > > > meson chips. Add Meson S4 SoC compatible.
> > > >
> > > > The test method:
> > > > Start the console and run the following commands in turn:
> > > > stty -F /dev/ttyAML0 115200 and stty -F /dev/ttyAML0 921600.
> > > >
> > > > Since most SoCs are too old, I was able to find all the platforms myself
> > > > such as Meson6, Meson8, Meson8b, GXL and so on. I only tested it with
> > > > G12A and S4.
> > > GXL based board are still very common an easy to come by.
> > > I'm quite surprised that you are unable to test on this SoC family
> > The fact of the matter is that the S4 is our end-2020 chip, the G12A is
> > five years old, and the GXL is seven years old. If you must ask for a
> > test, I will report this problem to the leadership to coordinate resources.
>
> The age of the SoC is irrelevant. SoCs don't get deprecated based on age
> in mainline. It is not just GXL, same goes for meson8.
>
> These SoCs are actively used. Boards with these SoCs are still sold and
> easily available. See the VIM1 or the Libretech boards.
>
> Breaking things for the the users of these SoCs is not acceptable.
> So yes, looking at your series, I strongly recommend you do more tests.
You have a point there. Let's go back to the root of the problem. I aim 
to increase S4. The S4 uses 12MHZ to calculate baud. That's all.
Change it to CCF as you suggested. The changes are so large that you ask 
to test all the chips.
I also mentioned last time that using CCF would lead to a longer drive 
probe time and affect the board startup time. If this problem is not 
solved, can we reject the way you suggest using CCF?
> > > > Yu Tu (6):
> > > >     tty: serial: meson: Move request the register region to probe
> > > >     tty: serial: meson: Use devm_ioremap_resource to get register mapped
> > > >       memory
> > > >     tty: serial: meson: Describes the calculation of the UART baud rate
> > > >       clock using a clock frame
> > > >     tty: serial: meson: Make some bit of the REG5 register writable
> > > >     tty: serial: meson: The system stuck when you run the stty command on
> > > >       the console to change the baud rate
> > > >     tty: serial: meson: Added S4 SOC compatibility
> > > >
> > > > V6 -> V7: To solve the system stuck when you run the stty command on
> > > > the console to change the baud rate.
> > > > V5 -> V6: Change error format as discussed in the email.
> > > > V4 -> V5: Change error format.
> > > > V3 -> V4: Change CCF to describe the UART baud rate clock as discussed
> > > > in the email.
> > > > V2 -> V3: add compatible = "amlogic,meson-gx-uart". Because it must change
> > > > the DTS before it can be deleted
> > > > V1 -> V2: Use CCF to describe the UART baud rate clock.Make some changes as
> > > > discussed in the email
> > > >
> > > > Link:https://lore.kernel.org/linux-amlogic/20220118030911.12815-4-yu.tu@xxxxxxxxxxx/
> > > >
> > > >    drivers/tty/serial/meson_uart.c | 221 ++++++++++++++++++++++----------
> > > >    1 file changed, 154 insertions(+), 67 deletions(-)
> > > >
> > > >
> > > > base-commit: a603ca60cebff8589882427a67f870ed946b3fc8