* [Bug 210351] New: Wrong setting baudrate for FTDI chip FT230X
@ 2020-11-25 5:14 bugzilla-daemon
2021-01-08 10:37 ` [Bug 210351] " bugzilla-daemon
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: bugzilla-daemon @ 2020-11-25 5:14 UTC (permalink / raw)
To: linux-usb
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: drivers_usb@kernel-bugs.kernel.org
Reporter: svv75@mail.ru
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug 210351] Wrong setting baudrate for FTDI chip FT230X
2020-11-25 5:14 [Bug 210351] New: Wrong setting baudrate for FTDI chip FT230X bugzilla-daemon
@ 2021-01-08 10:37 ` bugzilla-daemon
2021-01-08 11:37 ` bugzilla-daemon
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: bugzilla-daemon @ 2021-01-08 10:37 UTC (permalink / raw)
To: linux-usb
https://bugzilla.kernel.org/show_bug.cgi?id=210351
--- Comment #1 from Johan Hovold (johan@kernel.org) ---
On Wed, Nov 25, 2020 at 05:14:18AM +0000, bugzilla-daemon@bugzilla.kernel.org
wrote:
> 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: drivers_usb@kernel-bugs.kernel.org
> Reporter: svv75@mail.ru
> 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.
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug 210351] Wrong setting baudrate for FTDI chip FT230X
2020-11-25 5:14 [Bug 210351] New: Wrong setting baudrate for FTDI chip FT230X bugzilla-daemon
2021-01-08 10:37 ` [Bug 210351] " bugzilla-daemon
@ 2021-01-08 11:37 ` bugzilla-daemon
2021-01-08 13:30 ` bugzilla-daemon
2021-01-26 14:09 ` bugzilla-daemon
3 siblings, 0 replies; 5+ messages in thread
From: bugzilla-daemon @ 2021-01-08 11:37 UTC (permalink / raw)
To: linux-usb
https://bugzilla.kernel.org/show_bug.cgi?id=210351
--- Comment #2 from Vladimir (svv75@mail.ru) ---
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug 210351] Wrong setting baudrate for FTDI chip FT230X
2020-11-25 5:14 [Bug 210351] New: Wrong setting baudrate for FTDI chip FT230X bugzilla-daemon
2021-01-08 10:37 ` [Bug 210351] " bugzilla-daemon
2021-01-08 11:37 ` bugzilla-daemon
@ 2021-01-08 13:30 ` bugzilla-daemon
2021-01-26 14:09 ` bugzilla-daemon
3 siblings, 0 replies; 5+ messages in thread
From: bugzilla-daemon @ 2021-01-08 13:30 UTC (permalink / raw)
To: linux-usb
https://bugzilla.kernel.org/show_bug.cgi?id=210351
--- Comment #3 from Johan Hovold (johan@kernel.org) ---
On Fri, Jan 08, 2021 at 11:37:13AM +0000, bugzilla-daemon@bugzilla.kernel.org
wrote:
> 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:
> 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);
>
> }
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?
> 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.
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug 210351] Wrong setting baudrate for FTDI chip FT230X
2020-11-25 5:14 [Bug 210351] New: Wrong setting baudrate for FTDI chip FT230X bugzilla-daemon
` (2 preceding siblings ...)
2021-01-08 13:30 ` bugzilla-daemon
@ 2021-01-26 14:09 ` bugzilla-daemon
3 siblings, 0 replies; 5+ messages in thread
From: bugzilla-daemon @ 2021-01-26 14:09 UTC (permalink / raw)
To: linux-usb
https://bugzilla.kernel.org/show_bug.cgi?id=210351
--- Comment #5 from Johan Hovold (johan@kernel.org) ---
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-01-26 14:12 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-11-25 5:14 [Bug 210351] New: Wrong setting baudrate for FTDI chip FT230X bugzilla-daemon
2021-01-08 10:37 ` [Bug 210351] " bugzilla-daemon
2021-01-08 11:37 ` bugzilla-daemon
2021-01-08 13:30 ` bugzilla-daemon
2021-01-26 14:09 ` bugzilla-daemon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).