Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1662072 > unrolled thread

RE: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate calculation method

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate  calculation method "A.S. Dong" <aisheng.dong@nxp.com> - 2017-06-09 10:10 +0200
    Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate  calculation method Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-06-09 11:30 +0200
      RE: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate  calculation method "A.S. Dong" <aisheng.dong@nxp.com> - 2017-06-09 16:30 +0200
        Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate  calculation method Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-06-09 17:50 +0200
          RE: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate  calculation method "A.S. Dong" <aisheng.dong@nxp.com> - 2017-06-12 16:30 +0200

#1662072 — RE: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate calculation method

Hi Andy,

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Saturday, June 03, 2017 1:11 AM
> To: A.S. Dong
> Cc: linux-serial@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm
> Mailing List; Greg Kroah-Hartman; Jiri Slaby; Andy Duan; Stefan Agner;
> Mingkai Hu; Y.B. Lu
> Subject: Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud
> rate calculation method
> 
> On Wed, May 31, 2017 at 5:18 PM, A.S. Dong <aisheng.dong@nxp.com> wrote:
> >> On Tue, May 9, 2017 at 10:50 AM, Dong Aisheng <aisheng.dong@nxp.com>
> wrote:
> 
> By some reason my previous message went privately.
> It didn't have anything major anyway and here I'm suggesting optimization
> of finding factors of the formula in use. See below.
> 
> >> > +       u32 sbr, osr, baud_diff, tmp_osr, tmp_sbr, tmp_diff, tmp;
> >> > +       u32 clk = sport->port.uartclk;
> >> > +
> >> > +       /*
> >> > +        * The idea is to use the best OSR (over-sampling rate)
> possible.
> >> > +        * Note, OSR is typically hard-set to 16 in other LPUART
> >> instantiations.
> >> > +        * Loop to find the best OSR value possible, one that
> >> > + generates
> >> minimum
> >> > +        * baud_diff iterate through the rest of the supported
> >> > + values of
> >> OSR.
> >> > +        *
> >> > +        * Calculation Formula:
> >> > +        *  Baud Rate = baud clock / ((OSR+1) × SBR)
> >> > +        */
> >> > +       baud_diff = baudrate;
> >> > +       osr = 0;
> >> > +       sbr = 0;
> >> > +
> >>
> >> > +       for (tmp_osr = 4; tmp_osr <= 32; tmp_osr++) {
> 
> I missed one thing, what happened by default to OSR? What is the value in
> use?
> 

No valid default value. (osc/sbr are 0 by default)
If no proper osc and sbr calculated, a WARNING will show.

> >> I _think_ you may simplify this and avoid for-loop if you reconsider
> >> approach.
> 
> > But there is indeed a optimization way, see below.
> 
> > To optimize the looping, we probably could do:
> > If (!baud_diff)
> >         Break;
> 
> It's a small one, we may have more interesting approach.
> 
> So, the algo is the following:
> 
> Assume the ranges like this:
> OSR = [4 ... 32]
> SBR = [2 ... 8192]
> 

Baud Rate = baud clock / ((OSR+1) × SBR)

In HW:
OSR range : 3 – 31
SBR range: 1 – 8191

> Then:
> 
> 1. Get ratio factor as
>       ratio = CLK / desired baud rate
> 2. If ratio < 8192 * 9 / 2, just use (ratio / 4, 4) as (OSR, SBR) setting.
> (Needs clarification on OSR < 4) 

Sorry that I'm a bit mess here.
What is 8192 * 9 /2 meaning?

And for (ratio / 4, 4) as (OSR,SBR), take 115200 as an example:
Assuming baud clock 24Mhz.

Ratio = 24000000 / 115200 = 208
OSR = Ratio / 4 = 52 
Then OSR is out of range which seems wrong.

> 3. if ratio >= 8192 * 31, just use those
> two numbers (8192, 31). You can't do anything better there.

This actually may not happen.
Even take a 9600 as example, the clk becomes:
8191 * 31 * 9600 = 2.4GHz
Which is theoretically not exist.

> 4. Otherwise, get a minimum required factor of OSR
>       osr_min = ratio / 8192
> 5. Start your loop from osr_min + 1 to 31.
> 
> 6 (optional). Of course you may not consider baud_diff > osr_min, it's I
> suppose obvious
> 
> P.S. Note, all divisions by 2^n are just simple right shifts. Diffs are
> calculated as multiplication of OSR and SBR in comparison to ratio. One
> division so far.
> 

I'm not quite understand the approach.

How about you send a separate baud algorithm improvement patch later?
Then it first can provide us a good patch history and also better to
understand for review.

Last, very appreciate for your kind and professional review.

Regards
Dong Aisheng

[toc] | [next] | [standalone]

#1662176

On Fri, Jun 9, 2017 at 11:01 AM, A.S. Dong <aisheng.dong@nxp.com> wrote:

>> >> > +       u32 sbr, osr, baud_diff, tmp_osr, tmp_sbr, tmp_diff, tmp;
>> >> > +       u32 clk = sport->port.uartclk;
>> >> > +
>> >> > +       /*
>> >> > +        * The idea is to use the best OSR (over-sampling rate)
>> possible.
>> >> > +        * Note, OSR is typically hard-set to 16 in other LPUART
>> >> instantiations.
>> >> > +        * Loop to find the best OSR value possible, one that
>> >> > + generates
>> >> minimum
>> >> > +        * baud_diff iterate through the rest of the supported
>> >> > + values of
>> >> OSR.
>> >> > +        *
>> >> > +        * Calculation Formula:
>> >> > +        *  Baud Rate = baud clock / ((OSR+1) × SBR)
>> >> > +        */
>> >> > +       baud_diff = baudrate;
>> >> > +       osr = 0;
>> >> > +       sbr = 0;
>> >> > +
>> >>
>> >> > +       for (tmp_osr = 4; tmp_osr <= 32; tmp_osr++) {
>>
>> I missed one thing, what happened by default to OSR? What is the value in
>> use?
>>
>
> No valid default value. (osc/sbr are 0 by default)
> If no proper osc and sbr calculated, a WARNING will show.

Okay, so, it means the maximum supported speed is UART clock / 4. Correct?

>> So, the algo is the following:
>>
>> Assume the ranges like this:
>> OSR = [4 ... 32]
>> SBR = [2 ... 8192]
>>
>
> Baud Rate = baud clock / ((OSR+1) × SBR)
>
> In HW:
> OSR range : 3 – 31
> SBR range: 1 – 8191

I've read that, but think outside the box.

>> Then:
>>
>> 1. Get ratio factor as
>>       ratio = CLK / desired baud rate
>> 2. If ratio < 8192 * 9 / 2, just use (ratio / 4, 4) as (OSR, SBR) setting.
>> (Needs clarification on OSR < 4)
>
> Sorry that I'm a bit mess here.
> What is 8192 * 9 /2 meaning?

I forgot the details...

> And for (ratio / 4, 4) as (OSR,SBR), take 115200 as an example:
> Assuming baud clock 24Mhz.
>
> Ratio = 24000000 / 115200 = 208
> OSR = Ratio / 4 = 52
> Then OSR is out of range which seems wrong.

...yes...

>> 3. if ratio >= 8192 * 31, just use those
>> two numbers (8192, 31). You can't do anything better there.
>
> This actually may not happen.
> Even take a 9600 as example, the clk becomes:
> 8191 * 31 * 9600 = 2.4GHz
> Which is theoretically not exist.
>
>> 4. Otherwise, get a minimum required factor of OSR
>>       osr_min = ratio / 8192
>> 5. Start your loop from osr_min + 1 to 31.
>>
>> 6 (optional). Of course you may not consider baud_diff > osr_min, it's I
>> suppose obvious
>>
>> P.S. Note, all divisions by 2^n are just simple right shifts. Diffs are
>> calculated as multiplication of OSR and SBR in comparison to ratio. One
>> division so far.

> I'm not quite understand the approach.

...lemme prepare a python script demonstrating it.

> How about you send a separate baud algorithm improvement patch later?

Why not to do it right a way?

Just describe it in a comment if you afraid of reader can't understand
from the code.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1662509

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Friday, June 09, 2017 5:26 PM
> To: A.S. Dong
> Cc: linux-serial@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm
> Mailing List; Greg Kroah-Hartman; Jiri Slaby; Andy Duan; Stefan Agner;
> Mingkai Hu; Y.B. Lu; Dong Aisheng
> Subject: Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud
> rate calculation method
> 
> On Fri, Jun 9, 2017 at 11:01 AM, A.S. Dong <aisheng.dong@nxp.com> wrote:
> 
> >> >> > +       u32 sbr, osr, baud_diff, tmp_osr, tmp_sbr, tmp_diff, tmp;
> >> >> > +       u32 clk = sport->port.uartclk;
> >> >> > +
> >> >> > +       /*
> >> >> > +        * The idea is to use the best OSR (over-sampling rate)
> >> possible.
> >> >> > +        * Note, OSR is typically hard-set to 16 in other LPUART
> >> >> instantiations.
> >> >> > +        * Loop to find the best OSR value possible, one that
> >> >> > + generates
> >> >> minimum
> >> >> > +        * baud_diff iterate through the rest of the supported
> >> >> > + values of
> >> >> OSR.
> >> >> > +        *
> >> >> > +        * Calculation Formula:
> >> >> > +        *  Baud Rate = baud clock / ((OSR+1) × SBR)
> >> >> > +        */
> >> >> > +       baud_diff = baudrate;
> >> >> > +       osr = 0;
> >> >> > +       sbr = 0;
> >> >> > +
> >> >>
> >> >> > +       for (tmp_osr = 4; tmp_osr <= 32; tmp_osr++) {
> >>
> >> I missed one thing, what happened by default to OSR? What is the
> >> value in use?
> >>
> >
> > No valid default value. (osc/sbr are 0 by default) If no proper osc
> > and sbr calculated, a WARNING will show.
> 
> Okay, so, it means the maximum supported speed is UART clock / 4. Correct?
> 

Yes.

> >> So, the algo is the following:
> >>
> >> Assume the ranges like this:
> >> OSR = [4 ... 32]
> >> SBR = [2 ... 8192]
> >>
> >
> > Baud Rate = baud clock / ((OSR+1) × SBR)
> >
> > In HW:
> > OSR range : 3 – 31
> > SBR range: 1 – 8191
> 
> I've read that, but think outside the box.
> 
> >> Then:
> >>
> >> 1. Get ratio factor as
> >>       ratio = CLK / desired baud rate 2. If ratio < 8192 * 9 / 2,
> >> just use (ratio / 4, 4) as (OSR, SBR) setting.
> >> (Needs clarification on OSR < 4)
> >
> > Sorry that I'm a bit mess here.
> > What is 8192 * 9 /2 meaning?
> 
> I forgot the details...
> 
> > And for (ratio / 4, 4) as (OSR,SBR), take 115200 as an example:
> > Assuming baud clock 24Mhz.
> >
> > Ratio = 24000000 / 115200 = 208
> > OSR = Ratio / 4 = 52
> > Then OSR is out of range which seems wrong.
> 
> ...yes...
> 
> >> 3. if ratio >= 8192 * 31, just use those two numbers (8192, 31). You
> >> can't do anything better there.
> >
> > This actually may not happen.
> > Even take a 9600 as example, the clk becomes:
> > 8191 * 31 * 9600 = 2.4GHz
> > Which is theoretically not exist.
> >
> >> 4. Otherwise, get a minimum required factor of OSR
> >>       osr_min = ratio / 8192
> >> 5. Start your loop from osr_min + 1 to 31.
> >>
> >> 6 (optional). Of course you may not consider baud_diff > osr_min,
> >> it's I suppose obvious
> >>
> >> P.S. Note, all divisions by 2^n are just simple right shifts. Diffs
> >> are calculated as multiplication of OSR and SBR in comparison to
> >> ratio. One division so far.
> 
> > I'm not quite understand the approach.
> 
> ...lemme prepare a python script demonstrating it.
> 

Great, thanks

> > How about you send a separate baud algorithm improvement patch later?
> 
> Why not to do it right a way?
> 

Because I thought that could be a separate patch which is doing algorithm
improvement, then we can have the full history and a clear comparison.

And also we are still not sure whether it works, we don't want to block on it
too long.

But if you're pretty sure about it, I would wait for some more time.

However, personally I would still rather keep them in two separate Patches
for clearer history and comparison.

> Just describe it in a comment if you afraid of reader can't understand
> from the code.
> 

That is good.

Regards
Dong Aisheng

> --
> With Best Regards,
> Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1662564

On Fri, Jun 9, 2017 at 5:20 PM, A.S. Dong <aisheng.dong@nxp.com> wrote:
>> > How about you send a separate baud algorithm improvement patch later?
>>
>> Why not to do it right a way?
>>
>
> Because I thought that could be a separate patch which is doing algorithm
> improvement, then we can have the full history and a clear comparison.
>
> And also we are still not sure whether it works, we don't want to block on it
> too long.
>
> But if you're pretty sure about it, I would wait for some more time.
>
> However, personally I would still rather keep them in two separate Patches
> for clearer history and comparison.

Since we already near to -rc5, I would rather agree with you.
So, please proceed with your approach and we can modify it in relaxing
mode later on.

Thanks, and sorry for the delay!

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1663556

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Friday, June 09, 2017 11:49 PM
> To: A.S. Dong
> Cc: linux-serial@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm
> Mailing List; Greg Kroah-Hartman; Jiri Slaby; Andy Duan; Stefan Agner;
> Mingkai Hu; Y.B. Lu; Dong Aisheng
> Subject: Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud
> rate calculation method
> 
> On Fri, Jun 9, 2017 at 5:20 PM, A.S. Dong <aisheng.dong@nxp.com> wrote:
> >> > How about you send a separate baud algorithm improvement patch later?
> >>
> >> Why not to do it right a way?
> >>
> >
> > Because I thought that could be a separate patch which is doing
> > algorithm improvement, then we can have the full history and a clear
> comparison.
> >
> > And also we are still not sure whether it works, we don't want to
> > block on it too long.
> >
> > But if you're pretty sure about it, I would wait for some more time.
> >
> > However, personally I would still rather keep them in two separate
> > Patches for clearer history and comparison.
> 
> Since we already near to -rc5, I would rather agree with you.
> So, please proceed with your approach and we can modify it in relaxing
> mode later on.
> 
> Thanks, and sorry for the delay!

Never mind.
A professional review is always respectable and appreciated.

Thanks

Regards
Dong Aisheng

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web