u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: Sean Anderson <seanga2@gmail.com>
To: Heiko Thiery <heiko.thiery@gmail.com>
Cc: u-boot@lists.denx.de, Marek Vasut <marex@denx.de>,
	Michale Walle <michael@walle.cc>, Angus Ainslie <angus@akkea.ca>,
	Angus Ainslie <angus.ainslie@puri.sm>,
	lukma@denx.de, sbabic@denx.de, festevam@gmail.com,
	uboot-imx@nxp.com, peng.fan@nxp.com
Subject: Re: [RFC] serial: mxc: get the clock frequency from the used clock for the device
Date: Thu, 17 Mar 2022 22:19:34 -0400	[thread overview]
Message-ID: <513bb930-59b5-d42d-70dc-f3e0d57801d8@gmail.com> (raw)
In-Reply-To: <CAEyMn7Y_1h1_12bgf-5p+_gKipvA1P40OqoERh6W5=MH0AW36A@mail.gmail.com>

On 3/17/22 3:14 PM, Heiko Thiery wrote:
> Hi Sean,
> 
> Am Do., 17. März 2022 um 15:38 Uhr schrieb Sean Anderson <seanga2@gmail.com>:
>>
>> Hi Heiko,
>>
>> On 3/17/22 8:41 AM, Heiko Thiery wrote:
>>> With the clock driver enabled for the imx8mq, it was noticed that the
>>> frequency used to calculate the baud rate is always taken from the root
>>> clock of UART1. This can cause problems if UART1 is not used as console
>>> and the settings are different from UART1. The result is that the console
>>> output is garbage. To do this correctly the UART frequency is taken from
>>> the used device. For the implementations that don't have the igp clock
>>> frequency written or can't return it the old way is tried.
>>>
>>> Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
>>> ---
>>>    drivers/serial/serial_mxc.c | 15 +++++++++++++--
>>>    1 file changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
>>> index e4970a169b..6fdb2b2397 100644
>>> --- a/drivers/serial/serial_mxc.c
>>> +++ b/drivers/serial/serial_mxc.c
>>> @@ -3,6 +3,7 @@
>>>     * (c) 2007 Sascha Hauer <s.hauer@pengutronix.de>
>>>     */
>>>
>>> +#include <clk.h>
>>>    #include <common.h>
>>>    #include <dm.h>
>>>    #include <errno.h>
>>> @@ -266,9 +267,19 @@ __weak struct serial_device *default_serial_console(void)
>>>    int mxc_serial_setbrg(struct udevice *dev, int baudrate)
>>>    {
>>>        struct mxc_serial_plat *plat = dev_get_plat(dev);
>>> -     u32 clk = imx_get_uartclk();
>>> +     u32 rate = 0;
>>> +
>>> +     if (IS_ENABLED(CONFIG_CLK)) {
>>
>> CONFIG_IS_ENABLED?
> 
> This should be correct. The CONFIG_IS_ENABLED is a preprocessor macro
> and the IS_ENABLED can be used in c code. Or do you mean something
> else?

I mean you should be using CONFIG_IS_ENABLED(CLK) so that this code is
correct for both SPL and U-Boot proper. But it is also fine to "try and
fail" (making this check unnecessary).

>>
>> mx6ull at least does not have CONFIG_SPL_CLK enabled.
> 
> I expect that in that case it will fallback to the old behavior ... not?

Yes, if you handle -ENOSYS correctly.

>>
>>> +             struct clk clk;
>>> +             if(!clk_get_by_name(dev, "ipg", &clk))
>>> +                     rate = clk_get_rate(&clk);

You may also need to enable this clock.

>>> +     }
>>> +
>>> +     /* as fallback we try to get the clk rate that way */
>>> +     if (rate == 0)
>>
>> !rate || IS_ERR_VALUE(rate)
>>
>>> +             rate = imx_get_uartclk();
>>>
>>> -     _mxc_serial_setbrg(plat->reg, clk, baudrate, plat->use_dte);
>>> +     _mxc_serial_setbrg(plat->reg, rate, baudrate, plat->use_dte);
>>>
>>>        return 0;
>>>    }
>>>
>> --Sean
> 



  reply	other threads:[~2022-03-18  2:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-17 12:41 [RFC] serial: mxc: get the clock frequency from the used clock for the device Heiko Thiery
2022-03-17 13:19 ` Angus Ainslie
2022-03-18 19:06   ` Heiko Thiery
2022-03-19 14:32     ` Angus Ainslie
2022-03-21 13:50       ` Heiko Thiery
2022-03-22 12:47         ` Angus Ainslie
2022-03-24  2:08           ` Adam Ford
2022-03-24  9:58             ` Heiko Thiery
2022-03-24 10:57               ` Adam Ford
2022-03-17 14:38 ` Sean Anderson
2022-03-17 14:47   ` Michael Walle
2022-03-18  2:15     ` Sean Anderson
2022-03-17 16:31   ` Lukasz Majewski
2022-03-17 19:14   ` Heiko Thiery
2022-03-18  2:19     ` Sean Anderson [this message]
2022-03-18  8:05       ` Heiko Thiery
2022-03-18 13:26         ` Sean Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=513bb930-59b5-d42d-70dc-f3e0d57801d8@gmail.com \
    --to=seanga2@gmail.com \
    --cc=angus.ainslie@puri.sm \
    --cc=angus@akkea.ca \
    --cc=festevam@gmail.com \
    --cc=heiko.thiery@gmail.com \
    --cc=lukma@denx.de \
    --cc=marex@denx.de \
    --cc=michael@walle.cc \
    --cc=peng.fan@nxp.com \
    --cc=sbabic@denx.de \
    --cc=u-boot@lists.denx.de \
    --cc=uboot-imx@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).