[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1f16f430-677e-d1f0-1a7f-bf1d1a7c3c47@amlogic.com>
Date: Tue, 4 Jan 2022 16:20:33 +0800
From: Yu Tu <yu.tu@...ogic.com>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
CC: <linux-serial@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-amlogic@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
Neil Armstrong <narmstrong@...libre.com>,
Vyacheslav <adeep@...ina.in>,
Kevin Hilman <khilman@...libre.com>,
Jerome Brunet <jbrunet@...libre.com>
Subject: Re: [PATCH V3 4/6] tty: serial: meson: The UART baud rate calculation
is described using the common clock code. Also added S4 chip uart Compatible.
Hi Martin,
Thank you very much for your reply.
On 2022/1/3 3:36, Martin Blumenstingl wrote:
> [ EXTERNAL EMAIL ]
>
> Hi,
>
> On Sat, Jan 1, 2022 at 2:30 PM Yu Tu <yu.tu@...ogic.com> wrote:
> [...]
>>> Interesting, thanks for sharing that u-boot turns these clocks on.
>>> Let's say someone wanted to make u-boot save power and turn off all
>>> UART clocks except the one for uart_AO (where we typically connect the
>>> serial console).
>>> In that case the pclk of uart_C (just to choose an example here) is
>>> turned off. Would there be a problem then accessing the registers of
>>> uart_C before clk_prepare_enable is called?
>> The way you describe it, it does hang. This would not be recommended on
>> actual projects.
>>
>> At present, AmLogic chips are older than S4 Soc, and we have no way to
>> deal with this problem. We have to tell customers not to use it in this
>> wayćCustomers rarely use it in real projects.On the S4 SOC we will use
>> a clock like the UART pclk to control the shutdown using two registers,
>> one safe (need to operate in EL3) and one normal (EL1). It will only be
>> closed if both registers are closed. This mainly prevents misoperation.
> oh, interesting that there's some updates specifically with the S4 SoCs :-)
>
>> With your experience, I'd like to know how you deal with this kind of
>> problem.
> Before this patch the driver simply turns on the clock from within
> meson_uart_probe() (specifically it does so in
> meson_uart_probe_clock()).
> I think there's advanced power-saving techniques. Maybe for now we
> keep it simple and just enable the clock(s) at probe time and disable
> them at driver remove time. What do you think?
>
I agree with you.
>
> Best regards,
> Martin
>
Powered by blists - more mailing lists