Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 31.10.2013 12:09, schrieb Mika Westerberg:
> On Wed, Oct 30, 2013 at 11:14:34PM +0100, Frank Schäfer wrote:
>> Hmm... try to replace the whole pl2303.c from 3.12 with the one from 3.11.
>> If it makes no difference, it's not a pl2303 issue.
> I did that and the 3.11 pl2303.c works (whereas 3.12 doesn't).

Ok, here a two more things to test (on top of 3.12-rc + patch):

1) move the line

    port->port.drain_delay = 256;

from pl2303_port_probe() back to the end pl2303_open().

2) comment out the following line at the end of
pl2303_baudrate_encode_divisor_HXD():

baud = 12000000 * 32 / ((1 << buf[1]) * buf[0]);

3) Verify that the chip is detected as HXD_EA_RA_SA (in debug mode,
there should be a corresponding dmesg line).

These are the only remaining differences between 3.11 and 3.12.

>
> Can you tell me why do we even want to use this "divisor" based calculation
> if we can do the same with direct method?

It seems that some of the newer chips don't work with the direct method
at baud rates > 115200.
See commit 8d48fdf689fe "USB: PL2303: correctly handle baudrates above
115200").
As a said, the commit description is awful and the author doesn't reply
to emails.
But Prolific states that newer chips need a different baud rate
handling, too, which indicates that this commit makes sense.

So if we revert this old commit, we likely cause a regression with other
pl2303 chips.
Apart from that, the divisor based baud rate encoding has been working
well since kernel 3.1.

The divisor based baud rate method also allows (nearly) continious baud
rate adjustment, while the direct method only supports a fixed set of
standrad baud rates.

Regards,
Frank

>
> I mean why the driver can't do this:
>
>  1) Try direct method for *all* chips.
>  2) If it succeeds, use that value. Then we don't get any difference
>     between actual and set baud rate.
>  3) If it fails, then and only then use "divisor" based method.
>
> I would expect that the above cures my problem and possibly others who
> might have affected by this regression.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux