On 04/15/2014 05:34 PM, Johan Hovold wrote:
On Tue, Apr 15, 2014 at 04:06:11PM +0200, Johan Hovold wrote:
Specifically, I asked if you are able to make sense of the values of
register 0x2518. The reason I ask is that your patch changes the value
of that register from 0x50 (set in ch341_configure) to 0xc3 (when no
parity is used) and I want to make sure that you're not inadvertently
changing some other setting.
You're right, I realised I'd forgotten some of your other comments earlier, but
wasn't back to a computer to update, my apologies.
Do you know what those other bits do? Do they encode the number of data
and stop bits?
From a quick glance it seems like
0xc0 parity mode (2 bits)
0x08 parity enable
but your patch now also sets bits 0x83 and clears bit 0x10.
That should have been:
0x30 parity mode (2 bits)
0x08 parity enable
and your patch now always sets bits 0x83.
No, I have no idea what these bits mean. We can go and look at FreeBSD's code
and make assumptions about whether their decode is any more correct or not.
(They break things into parts and declare 8bit registers, that must be set two
at a time) As I mentioned, this was based on wireshark tracing of windows
programs opening the serial port, and without any better documentation, it's all
I've got to go on.
Without better documentation, how do we even know that what _was_ being done was
any more or less correct than what it will be doing now? All I can say is that
8-n-1 works as it did before, and 8-e-1, 8-o-1 and 8-m-1/8-s-1 now actually work
at all.
Maybe it's setting data bits to 8? (the ch340 doesn't support variable data
bits, the ch341 does) Data bit support / stop bit support is still not supported
by this driver anyway, I believe that's a project for another day.
Your other comment was about using the #define for 0x9a labelled "write
register" I can if you would like, but that would make some of the code use the
define others not. Unless you want me to redo the _rest_ of existing code to
use this define. Further, while "write register" _seems_ like a believable
interpretation of the magic number, unless someone has some better
documentation, it's just an educated guess. _Only_ the break support code,
which came from FreeBSD even attempts to make up/assign names to some of these
magic numbers. I'm happy to go and do this, (replacing magic numbers with the
recently added #defines) but I had endeavoured to follow the style of the
existing code.
Sincerely,
Karl Palsson
--
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
