New: Wrong setting baudrate for FTDI chip FT230X

https://bugzilla.kernel.org/show_bug.cgi?id=210351

Bug ID: 210351
Summary: Wrong setting baudrate for FTDI chip FT230X
Product: Drivers
Version: 2.5
Kernel Version: all
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: No

Hello!

I have three chips FT232BL, FT232R and FT230X. I am using them as a VCP on Linux (Ubuntu 18.04). According to Application Note AN_120 from FTDI, the baud rate generators of all these chips have 8 sub-integer prescalers. Divisor = 3000000 / baudrate = n + 0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875. Where n is an integer between 2 and16384.
So, I measured real baud rates, for n = 2 in combination with all possible sub-integer prescalers.
And it turned out that all sub-integer prescalers worked for FT232BL, FT232R chips.

And for the FT230X, only a few prescalers work correctly. The following shows exactly how prescalers behave:
0 - correct
0.125 - correct
0.25 - correct
0.375 - WRONG! (works like 0.125)
0.5 - correct
0.625 - WRONG! (works like 0.5)
0.75 - WRONG! (works like 0.25)
0.875 - WRONG! (works like 0.125)

The same for the other n.

I think it is a driver problem, it initializes the sub-integer prescaler incorrectly. Since under Windows FT230X works fine with all sub-integer prescalers.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=210351

--- Comment #1 from Johan Hovold ([email protected]) ---

Thanks for the report.

It sounds like your device behaves like a FT8U232AM, which only supports 0.125, 0.25 or 0.5, then. Are you sure Windows is able to use the others?

Is the device type being detected correctly? What does the log say when you plug your device in? Please also post the output of "lsusb -v" for the device.

Johan

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=210351

--- Comment #2 from Vladimir ([email protected]) ---
Hello, Johan.

Unfortunately, I don't have a device at hand right now. But I remember the lsusb output was showing FT-X type. And under Windows, all three chips I mentioned work correctly with all prescalers. I contacted FTDI tech support with this problem. They advised me to have such a patch for ftdi_sio.c and it solved the problem. Here's the patch:

static int change_speed (struct tty_struct * tty, struct usb_serial_port * port)

...

      index_value = get_ftdi_divisor (tty, port);

      value = (u16) index_value;

      index = (u16) (index_value >> 16);

      if ((priv-> chip_type == FT2232C) || (priv-> chip_type == FT2232H) ||

            (priv-> chip_type == FT4232H) || (priv-> chip_type == FT232H)) {

            / * Probably the BM type needs the MSB of the encoded fractional

            * divider also moved like for the chips above. Any infos? * /

            index = (u16) ((index << 8) | priv-> interface);

      }

So, the high bit of the factional part is lost on the FT-X chips. To fix it in the kernel try:

      if ((priv-> chip_type == FT2232C) || (priv-> chip_type == FT2232H) ||

            (priv-> chip_type == FT4232H) || (priv-> chip_type == FT232H) ||

(priv-> chip_type == FTX)) {

/ * Probably the BM type needs the MSB of the encoded fractional

* divider also moved like for the chips above. Any infos? * /

index = (u16) ((index << 8) | priv-> interface);

}

But I don't know why the most significant bit of the prescaler is masked by something. I have no information about the chip configuration registers. It looks like this is confidential information. But they could provide it to you as the driver developer.

Vladimir

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=210351

--- Comment #3 from Johan Hovold ([email protected]) ---

Ah, that's good to hear. Do you want to submit that as a proper patch that I can apply, or do you want me to do that?

I don't have access to any details about these chips apart from the public sources either, I'm afraid.

But here it seems the upper bits simply needs to be shifted to make room for the interface number just like for the H-types (which can have more than one port).

Johan

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=210351

--- Comment #5 from Johan Hovold ([email protected]) ---
Your reply never made it to the linux-usb list so I didn't see it until today when I was preparing the patch I just CCed you on.

I'll queue it up for 5.12, but then I think we can backport it to the stable trees as well.

Thanks again for reporting this.

Johan

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.