[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] [PATCH] Brainbox 620 Pcmcia card at 921600 baud
I must admit that I'm not familiar with the WMSR,
the baudbase/divisor feature was added to configure the baudrate
on the ETRAX100LX chip that supports the standard baudrates +
3125000/x where x=2-65536 or an external baudrate clk,
although I think it could be useful for other cpu's as well
(if the set_serial implementation is "smart" enough...)
It was needed to be able to test a module from Texas that
runs at either 1000000 bps or 111111 bps
(though they claim it's 115200, but it's not really close enough:)
----- Original Message -----
From: Jean Tourrilhes <firstname.lastname@example.org>
To: Johan Adolfsson <email@example.com>
Cc: <firstname.lastname@example.org>; Peter Kjellerstedt
Sent: Wednesday, October 31, 2001 18:58
Subject: Re: [bluetooth-dev] [PATCH] Brainbox 620 Pcmcia card at 921600 baud
> On Wed, Oct 31, 2001 at 11:19:24AM +0100, Johan Adolfsson wrote:
> > I don't know if it will work for you, but I added support to OpenBT
> > to specifiy the baudrate as "baudbase/divisor" that will use the
> > SETSERIAL ioctl() to specify baudbase and custom _divisor.
> > In theory you shouldn't need setserial but I guess it only works if
> > the driver knows how to change to the correct baudbase...
> > /Johan
> You have to be careful there. The baudbase and custom divisor
> is a property of the UART, not of the BlueTooth chip, and the two
> things are orthogonal. You may have a CSR chip mated with a wide
> variety of UARTs (example : the Brainboxes Pcmcia and CF cards use two
> totally different UARTs, and the Casira board will use the regular
> 16550 UART).
> In the case of the Brainboxes Pcmcia card, it make sense to
> change the baud_base *only* if you set the WMSR to the corresponding
> value. In other words, if you add support for baud_base but not WMSR,
> the result will be undefined. But this is specific to this precise
> implementation of the UART.
> I don't know what's the proper approach here. My approach was
> that before to start the BlueTooth stack, it was the responsability of
> the user (or whatever init script) to put the UART in a sensible
> configuration through setserial.
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com