[PATCH] sh-sci: fix SCBRR value calculation

[PATCH] sh-sci: fix SCBRR value calculation

[Kuninori Morimoto]

Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
---
>> Iwamatsu-san

Please check this patch to make sure it doesn't break any boards. 
I checked this patch by AP325 (for SCIFA)
and Diamond Head (for SCIF)
It works well
But I don't know about some strange Hitachi ULSI board with magical clock settings.

 drivers/serial/sh-sci.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/sh-sci.h b/drivers/serial/sh-sci.h
index d0aa82d..f8c0b87 100644
--- a/drivers/serial/sh-sci.h
+++ b/drivers/serial/sh-sci.h
@@ -761,9 +761,9 @@ static inline int sci_rxd_in(struct uart_port *port)
 static inline int scbrr_calc(struct uart_port *port, int bps, int clk)
 {
 	if (port->type = PORT_SCIF)
-		return (clk+16*bps)/(32*bps)-1;
+		return (clk/(32*bps)) - 1;
 	else
-		return ((clk*2)+16*bps)/(16*bps)-1;
+		return ((clk*2)/(16*bps)) - 1;
 }
 #define SCBRR_VALUE(bps, clk) scbrr_calc(port, bps, clk)
 #elif defined(__H8300H__) || defined(__H8300S__)
-- 
1.5.6.3

Re: [PATCH] sh-sci: fix SCBRR value calculation

[yoshii.takashi]

Please don't omit that term, that is for "round to near" operation.

round_to_near(clk/(32*bps)) -1
--> round_to_zero(clk/(32*bps) + 0.5) -1
--> (int)((clk+16*bps)/(32*bps)) -1

> -		return (clk+16*bps)/(32*bps)-1;
> +		return (clk/(32*bps)) - 1;
Former one is correct.

> -		return ((clk*2)+16*bps)/(16*bps)-1;
> +		return ((clk*2)/(16*bps)) - 1;
Both incorrect? Perhaps,
		return ((clk*2)+8*bps)/(16*bps) - 1;

I don't have read 7723 HW manual, though.
/yoshii

Re: [PATCH] sh-sci: fix SCBRR value calculation

[morimoto.kuninori]

Dear yoshii

> Please don't omit that term, that is for "round to near" operation.

Ahhhhhh....
Now I could understand !!!
Sorry I didn't know that this calculation is "round to near" operation.

Best regards
--
Kuninori Morimoto
 

Re: [PATCH] sh-sci: fix SCBRR value calculation

[Paul Mundt]

On Tue, Apr 14, 2009 at 02:53:13PM +0900, morimoto.kuninori@renesas.com wrote:
> 
> Dear yoshii
> 
> > Please don't omit that term, that is for "round to near" operation.
> 
> Ahhhhhh....
> Now I could understand !!!
> Sorry I didn't know that this calculation is "round to near" operation.
> 
Is there an updated patch forthcoming for this, or do we just leave SCBRR
as it is?

Re: [PATCH] sh-sci: fix SCBRR value calculation

[Kuninori Morimoto]

Dear Paul

> > > Please don't omit that term, that is for "round to near" operation.
> > 
> > Ahhhhhh....
> > Now I could understand !!!
> > Sorry I didn't know that this calculation is "round to near" operation.
> > 
> Is there an updated patch forthcoming for this, or do we just leave SCBRR
> as it is?

There is no problem at present for me.
Sorry for my stupid question/patch.

Best regards
--
Kuninori Morimoto
 

Re: [PATCH] sh-sci: fix SCBRR value calculation

[Paul Mundt]

On Wed, Apr 22, 2009 at 11:50:11AM +0900, Kuninori Morimoto wrote:
> 
> Dear Paul
> 
> > > > Please don't omit that term, that is for "round to near" operation.
> > > 
> > > Ahhhhhh....
> > > Now I could understand !!!
> > > Sorry I didn't know that this calculation is "round to near" operation.
> > > 
> > Is there an updated patch forthcoming for this, or do we just leave SCBRR
> > as it is?
> 
> There is no problem at present for me.
> Sorry for my stupid question/patch.
> 
No problem, there are so many variations that it is pretty easy for there
to be an incorrect setting that still "works" for the general cases. It
is always better to be certain if you spot something that looks
questionable, especially as a lot of this code has not changed
fundamentally in years, while the CPUs have.