Marcel ??:
>>> I have some issues with the usbsprl driver:
>>>
>>> 1. hardware flow ctl is always enabled
>>>
>>> I use only RX,TX and GND in my cable and peripheral
>>>
>> hardware and cannot communicate via Prolific adapter
>> because hw flow ctl appears to be always
>>
>>> enabled.
>>> If I remove the following initialization code
>>>
>> (which enables hw flow ctl for a
>>
>>> rev. H chip) from pl2303_open_hw_port(), my
>>>
>> problems are gone:
>>
>>> /* Set DCR0 */
>>> if ((rval =
>>>
>> pl2303_cmd_vendor_write0(plp, SET_DCR0,
>>
>>> DCR0_INIT_H)) != USB_SUCCESS) {
>>>
>>> return (rval);
>>> }
>>>
>>>
>> usbsprl driver is written according to Prolific's
>> specification and its parameters configuration can
>> satisfy most common devices. Current information is
>> not enough to describe why it can't work with your
>> special device.
>>
>>
>
> The reason why it can't work is because hardware flow control in the Prolific
> chip is enabled when the port is opened, and there appears to be no code
> anywhere in the driver that allows hardware flow control to be disabled.
>
> Looking at the Linux source code provided by Prolific, the DCR0 register is
> initialized with a value 0x01 upon port open and then 0x41 or 0x61 (depending
> on chip rev) is written to enable hw flow ctl.
>
> My suggested change would be to add a function that disables hardware flow
> control. E.g.:
>
> /*
> * Disable Hardware flow control
> */
> static int
> pl2303_cmd_clear_rtscts(pl2303_state_t *plp)
> {
>
> return (pl2303_cmd_vendor_write0(plp, SET_DCR0, 0x01));
> }
>
> And then change the DS_PARAM_FLOW_CTL case in pl2303_set_port_params() to:
>
> case DS_PARAM_FLOW_CTL:
> /* Hardware flow control */
> if (pe->val.ui & CTSXON) {
> if ((rval = pl2303_cmd_set_rtscts(plp))
> != USB_SUCCESS) {
>
> USB_DPRINTF_L3(DPRINT_CTLOP,
> plp->pl_lh,
> "pl2303_set_port_params: "
> "pl2303_cmd_set_rtscts failed");
> }
> }
> else {
> if ((rval = pl2303_cmd_clear_rtscts(plp))
> != USB_SUCCESS) {
>
> USB_DPRINTF_L3(DPRINT_CTLOP,
> plp->pl_lh,
> "pl2303_set_port_params: "
> "pl2303_cmd_clear_rtscts failed");
> }
> }
>
> break;
>
> That fixes it for me too.
>
> Disabling hardware flow control in my opinion is not an exotic feature, so I
> would expect that to be supported by a serial driver.
Maybe this is exactly a issue. I need do further investigation about
this and I will contact you ASAP after I can get some conclusions.
> The manual page mentions that the driver "supports the termio(7I) device
> control functions", which is not true for the current driver.
>
Why do you come to this conclusion? Only because of the above flow
control issue or there were other control functions you found were not
supported?
What OS builds did you use? If s10, you need do somethings to push
ttcompat and ldterm modules on usb serial driver to support most device
control functions. You can refer to:
http://www.sun.com/io_technologies/usb/USB-Faq.html#Serial
14. My serial application hangs or I get a tcflush error. What is the fix?
To address this, add the following line to /etc/iu.ap file.
<usb serial driver name> -1 0 ldterm ttcompat
(<usb serial driver name> could be usbsprl, usbsksp or usbser_edge )
Run the following command and ignore error messages :
# autopush -f /etc/iu.ap
Connect USB serial device to the system.
Run the following command to verify ldterm and ttcompat modules have
been pushed on top of the usb serial driver:
# strconf < /dev/term/0
The output should look like:
ttcompat
ldterm
<usb serial driver name>
Now, try your application again.
> There remains the issue of inbound and outbound hw flow control, which is
> not handled separately currently. But since I do not have the Prolific spec I
> do not know if it is supported at all and therefore cannot comment on that.
>
This seems not supported by Prolific.
Thanks
Guoqing
> Marcel
>
