On Tue, 2 Jul 2013 at 18:31, Frank Schäfer wrote:
I've set up a test environment (currently limited to 115.2 kbps) and
can confirm that this works ONLY with the following (currently
supported) baud rates: 75, 150, 300, 600, 1200, 1800, 2400, 3600,
4800, 7200, 9600, 14400, 19200, 28800, 38400, 57600, 115200.
Any other baud rate value results in 9600 bps.
Further tests with baud rates > 115.2 kbps are planned (because of
the different programming method the driver uses for these values),
but I need to upgrade my test environment first. ;)
Bingo, it's the programming method that matters!
IIRC I had only tested values above 115200.
Up to 115200 the driver sends the baud rate to the device as a literal
32bit integer and the chip appears to have a builtin mapping table
from standard baud rates to the respective divider parameters for the
baud rate generator with a fallback to 9600 for unknown values.
For values above 115200 the driver sets the MSB of buf[3], which
apparently allows to program the dividers directly, which removes the
limitation to standard values.
Further tests on my device have shown that
a) the first method also works for standard baud rates above 115200.
b) the second method also works for arbitrary values from 115200 down
to about 30 Baud.
For the 2nd method bits 1..3 of buf[1] appear to enable dividers by 4,
16 and 256 as the comment in the driver says. I found, that setting
bit 0 enables a divider by 3 and that the four dividers can be
combined to divide the base clock of 12MHz*32 by up to 49152.
In buf[0] only values of 64 or more seem to be interpreted as an
additional divider as per the comment. For values below 64 the device
behaves different, but I wasn't yet able to find a consistent
explanation of that behaviour.
Could you please check this on your device?
cu
Reinhard
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
