Messages in this thread | | | From | Stephen GALLIMORE <> | Date | Thu, 23 May 2013 18:26:09 +0200 | Subject | RE: [RFC 1/8] serial:st-asc: Add ST ASC driver. |
| |
On Wednesday 22 May 2013, Arnd Bergmann wrote: > > Also all of the custom_divisor functionality is basically commented as "old" > > or has a kernel warning saying it is deprecated (see uart_set_info), so as > > far as I can see for our (and I suspect most) hardware it is completely > > irrelevant functionality. > > What may have happened here is that custom_divisor was used in a different > way when I added that code than it is today, and the change was not propagated > into the of_serial driver. However, going back to 2.6.20 shows no different > code than what we have today in this regard. It may simply have been > a mistake on my side.
Thanks for looking into this and digging around in the history. At least I didn't miss something really obvious.
> I looked it up in the original serial port binding at > http://www.openfirmware.org/1275/bindings/devices/html/serial.ht > ml, which does > not specify the property, and in ePAPR, which does have it in the > section about > "serial class devices": > > 18 6.2.1.2 current-speed > 19 Property: current-speed > 20 Value type: <u32> > 21 Description: > 22 Specifies the current speed of a serial device in bits per second. A > boot program should set > 23 this property if it has initialized the serial device. > 24 Example: > 25 current - speed = <115200>; # 115200 baud > > The reason you want this is so that the driver can initialize the hardware from > scratch more easily and get back to the same settings. Why they only specified > the baud rate but not also start/stop bits and flow control I don't understand > though.
Yes, I had been made aware of the ePAPR definition by Srini after I sent the post. In fact I had exactly the same question in my head about the other settings as well.
> > I guess you can ignore my original comment. > OK.
Thanks again for your time.
Regards, -stephen
| |