linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: "Michael G. Katzmann" <michaelk@IEEE.org>
Cc: "Charles Yeh" <charlesyeh522@gmail.com>,
	"Yeh.Charles [葉榮鑫]" <charles-yeh@prolific.com.tw>,
	linux-serial@vger.kernel.org, linux-usb@vger.kernel.org,
	"Joe Abbott" <jabbott@rollanet.org>
Subject: Re: non-standard baud rates with Prolific 2303 USB-serial
Date: Thu, 11 Mar 2021 17:08:08 +0100	[thread overview]
Message-ID: <YEpAaL9QtVMduEpi@hovoldconsulting.com> (raw)
In-Reply-To: <ddc0e424-21c2-b8f4-1b00-f589267d2b51@IEEE.org>

On Sat, Mar 06, 2021 at 11:15:52PM -0500, Michael G. Katzmann wrote:
> 
> On 3/5/21 4:36 AM, Johan Hovold wrote:
> 
> oops I should have looked at the previous code determining variants...
> 
> take 2...
>
> #define PL2303_QUIRK_DIVISOR_TA                 BIT(3)
> 
> enum pl2303_type {
> 	TYPE_01,	/* Type 0 and 1 (difference unknown) */
> 	TYPE_HX,	/* HX version of the pl2303 chip */
> 	TYPE_HXN,	/* HXN version of the pl2303 chip */
> 	TYPE_TA,	/* TA version of the pl2303 chip */
> 	TYPE_COUNT
> };
> 
> 
> static const struct pl2303_type_data pl2303_type_data[TYPE_COUNT] =
> ....
>         [TYPE_TA] = {
>                 .max_baud_rate          = 6000000,
>                 .quirks                 = PL2303_QUIRK_DIVISOR_TA,

I think we should just a new flag for the alternate divisor encoding
named "alt_divisors" (cf. no_divisors).

Chances are this encoding is used for other types as well.

>         },
> };
> 
> static int pl2303_startup(struct usb_serial *serial)
> {
> ....
> 	if ( serial->dev->descriptor.bcdDevice == 0x0300 && serial->dev->descriptor.bcdUSB == 0x0200 )
> 		type = TYPE_TA;

This needs to go after the bDeviceClass == 0x02 check, and the 
descriptor fields need to be accessed using le16_to_cpu().

I've prepared a patch series that clean up and tighten the type
detection which I suggest you built upon instead.

I'll post the series after replying here.

> 	else if (serial->dev->descriptor.bDeviceClass == 0x02)
> ....
> }
> 
> static speed_t pl2303_encode_baud_rate_divisor( struct usb_serial_port *port,
> 							unsigned char buf[4],
> 								speed_t baud)
> {
> 	unsigned int baseline, mantissa, exponent;
> 	struct usb_serial *serial = port->serial;
> 	struct pl2303_serial_private *spriv = usb_get_serial_data(serial);
> 
> 	/*
> 	 * Apparently the formula is:
> 	 * baudrate = 12M * 32 / (mantissa * 4^exponent)
> 	 * where
> 	 *   mantissa = buf[8:0]
> 	 *   exponent = buf[11:9]
> 	 *
> 	 * TA version has more precision
> 	 *      uses mantissa = buf[bits 10:0 ]

So you discovered that there were even more bits here? Your first
version used ten bits, I believe.

I got an offline mail from a third person having problems with the TA
and who had also verified eleven bits here.

> 	 *           exponent = buf[bits 15:13]
> 	 *  and x2 prescaler enable by buf[bit 16]
> 	 */
> 	baseline = 12000000 * 32;
> 	mantissa = baseline / baud;
> 	if (mantissa == 0)
> 		mantissa = 1;    /* Avoid dividing by zero if baud > 32*12M. */
> 	exponent = 0;
> 
> 	if (spriv->quirks & PL2303_QUIRK_DIVISOR_TA) {
> 		while (mantissa >= 2048) {
> 			// exponent is three bits (after shifting right)
> 			if (exponent < 15) {   // we are going to divide this by 2 later
> 				mantissa >>= 1;    // divide by 2
> 				exponent++;        // currently log2 ... will become log4
> 			} else {
> 				/* Exponent is maxed. Trim mantissa and leave. */
> 				mantissa = 2047 ;
> 				break;
> 			}
> 		}
> 		buf[2] = exponent & 0x01;  // activate x2 prescaler if needed
> 		exponent >>= 1;            // now log base 4 (losing LSB)
> 		buf[1] = (exponent << 5) | (mantissa >> 8);

Again, this is really nice work.

But it seems to me that we should simply think about the encoding as
using base-2 with the LSB of the exponent in bit 16. That should make it
easier to follow what's going on here.

I've been thinking about ways of merging the two schemes (both using
base 2), and I even checked if my HXD happened to have a 2-prescaler bit
somewhere as well but I couldn't find one.

It's probably not worth it at this point (and may not end up being more
readable anyway) so I therefore suggest adding a separate function for
the alternate scheme for now. You can just call it at the start of the
"default" function:

	if (spriv->type->alt_divisors)
		return pl2303_encode_baud_rate_divisor_alt(buf, baud);

> 	} else {
> 		while (mantissa >= 512) {
> 			if (exponent < 7) {
> 				mantissa >>= 2; /* divide by 4 */
> 				exponent++;
> 			} else {
> 				/* Exponent is maxed. Trim mantissa and leave. */
> 				mantissa = 511;
> 				break;
> 			}
> 		}
> 		buf[2] = 0;
> 		buf[1] = exponent << 1 | mantissa >> 8;
> 	}
> 
> 	buf[3] = 0x80;
> 	buf[0] = mantissa & 0xff;
> 
> 	/* Calculate and return the exact baud rate. */
> 	baud = (baseline / mantissa / (buf[2] == 0x01 ? 2:1)) >> (exponent << 1);
> 	return baud;
> }
> 
> static void pl2303_encode_baud_rate(struct tty_struct *tty,
> 					struct usb_serial_port *port,
> 					u8 buf[4])
> {
> ....
> 	else
> 		baud = pl2303_encode_baud_rate_divisor(port, buf, baud);
> ....
> }

Johan

  reply	other threads:[~2021-03-11 16:08 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3aee5708-7961-f464-8c5f-6685d96920d6@IEEE.org>
     [not found] ` <dc3458f1-830b-284b-3464-20124dc3900a@IEEE.org>
2021-02-22  8:52   ` non-standard baud rates with Prolific 2303 USB-serial Johan Hovold
2021-02-22 12:39     ` Michael G. Katzmann
2021-02-22 13:18       ` Johan Hovold
     [not found]         ` <fb1489c2-b972-619b-b7ce-4ae8e1d2cc0f@IEEE.org>
2021-02-22 15:34           ` Johan Hovold
2021-02-22 15:42             ` Michael G. Katzmann
2021-02-22 15:50               ` Johan Hovold
2021-02-22 16:37                 ` Michael G. Katzmann
2021-02-22 16:48                   ` Johan Hovold
2021-02-24 23:08                     ` Joe Abbott
2021-02-25  8:44                       ` Johan Hovold
     [not found]                   ` <43da22ced8e14442bbc8babea77e4ed7@MailHC2.prolific.com.tw>
2021-02-23 10:18                     ` Johan Hovold
2021-02-23 13:25                     ` Michael G. Katzmann
2021-02-23 14:58                 ` Michael G. Katzmann
2021-02-23 15:43                   ` Johan Hovold
2021-02-23 15:57                     ` Michael G. Katzmann
2021-02-23 16:14                       ` Johan Hovold
2021-02-23 16:30                         ` Michael G. Katzmann
2021-02-23 16:52                           ` Johan Hovold
2021-02-23 19:15                             ` Michael G. Katzmann
2021-02-24 17:04                               ` Johan Hovold
2021-02-24 18:13                                 ` Michael G. Katzmann
2021-02-25  8:42                                   ` Johan Hovold
2021-04-08 15:35                                     ` Johan Hovold
2021-02-24  7:34                             ` Charles Yeh
2021-02-24 17:00                               ` Johan Hovold
2021-02-24 17:12                                 ` Michael G. Katzmann
2021-03-05  9:32                                 ` Charles Yeh
2021-03-05  9:36                                   ` Johan Hovold
2021-03-06 20:18                                     ` Michael G. Katzmann
2021-03-07  4:15                                     ` Michael G. Katzmann
2021-03-11 16:08                                       ` Johan Hovold [this message]
2021-03-12 13:17                                         ` Michael G. Katzmann
2021-03-12 13:44                                           ` Johan Hovold
2021-03-12 20:29                                             ` Michael G. Katzmann
2021-03-13  1:28                                             ` Michael G. Katzmann
2021-03-15  9:07                                               ` Johan Hovold
2021-03-15 10:07                                                 ` Charles Yeh
2021-03-15 10:24                                                   ` Johan Hovold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YEpAaL9QtVMduEpi@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=charles-yeh@prolific.com.tw \
    --cc=charlesyeh522@gmail.com \
    --cc=jabbott@rollanet.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=michaelk@IEEE.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).