Am 03.07.2013 22:07, schrieb Reinhard Max: > 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. Great, that was my hope ! When I wrote the patch in 2009, only the first baud rate programming method was in place. The second method has been added later with commit 8d48fdf6. > > Further tests on my device have shown that > > a) the first method also works for standard baud rates above 115200. ... which is what I had tested in 2009. > > 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. Hmm... the comment says that 12MHz*32 / baud = divisor = (2^buf[1]) * buf[0] But the code below does something different... > > Could you please check this on your device? > I hope I'll get a FTDI-device for testing tomorrow. It seems like we can improve the driver. :) Regards, Frank > > 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