Message ID | ud4bf3jpm.wl%morimoto.kuninori@renesas.com (mailing list archive) |
---|---|
State | Not Applicable |
Delegated to: | Paul Mundt |
Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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__)