Closed rfmerrill closed 11 years ago
What is the deprecated interface you are referring to?
I do have a patch that enables arbitrary baud rates. It seems to enabled CBAUDEX: tios->c_cflag |= CBAUDEX; and then write the baud rate to: /proc/uart_cur_freq which doesn't seem very standard. What's your scheme like?
setting custom_divisor with the TIOCSSERIAL ioctl
Can you point out where amba-pl010.c is handling this, and amba-pl011.c is not?
You can vary the clock given to the uart with config.txt parameter init_uart_clock. See: http://www.siliconstuff.com/2012/08/serial-port-midi-on-raspberry-pi.html
amba-pl010.c calls uart_get_divisor to get the divisor, while -pl011 calculates it by hand. uart_get_divisor will return the custom divisor if it's set.
Have you tried patching amba-pl011.c?
Sorry, no I have not. Been a while since I recompiled a kernel, haven't had the time to attempt it.
I was able to set 25000 custom baudrate on FT232R chip http://www.embeddedunveiled.com/set-custom-baud-rate. I am now going to try it on raspberry pi as a part of porting this library to raspberry pi.
Linux has an (admittedly deprecated) interface from setting custom baud rates, but it appears that some drivers, including the raspberry pi's, silently ignore it.
This is a bit of a shame because the chip is actually quite flexible with baud rates.
I came upon this issue while trying to get the Pi to receive DMX. DMX is a mostly-standard serial interface that uses the unfortunate baud rate of 250000 bps.
I set the UART clock to 4 megahertz, which would make 250000 an easy division (it's just /16), but the documented method for setting custom baud rates just did nothing. What's interesting is that the amba-pl010 driver appears to support it but the amba-pl011 driver does not.
In a last-ditch attempt to get it working, I set the serial port up for 230400, which worked fine, and then I manually poked the right divisor into the UART's register and the driver continued on happily.
If you guys don't want to modify the driver, is there a way I can completely disable it without recompiling the kernel? That way I could maybe just bang on it the ugly way or insert another driver that does the same thing.