On Mon, Aug 04, 2025 at 11:35:35PM +0200, Martin Blumenstingl wrote: > On Mon, Aug 4, 2025 at 2:32 PM Johan Hovold <johan@xxxxxxxxxx> wrote: > > On Tue, Jul 29, 2025 at 10:45:20PM +0200, Martin Blumenstingl wrote: > > > My general flow is: > > > - check if we have received THRE - if not: don't transmit more data on this port > > > - submit up to two URBs with up to 512 - 3 (CH348_TX_HDRSIZE) bytes to > > > not exceed the HW TX FIFO size of 1024 bytes (page 1 in the datasheet) > > > if the kfifo has enough data > > > > If you're going to wait for the device fifo to clear completely you can > > just use a single urb with larger (1k) buffer too. > I set .bulk_out_size = 1024 in struct usb_serial_driver. Writing a 1k > buffer immediately results in: > ch348 1-1:1.0: device disconnected > > I don't know if I need to set some kind of flag on the URB to have it > split or whether the kernel / USB controller does that automatically > (as you can tell: I'm not familiar with USB). > If not: 512 byte transfers at a time it is. The host controller should split the buffer, but apparently this crashes the device firmware. > > > > > On my test board the CFG pin is HIGH. From how I understand you, RTS > > > > > should at least change (even if DTR is in TNOW mode). > > > > > No matter what I do: both pins are always LOW (right after modprobe, > > > > > after opening the console, closing the console again, ...). > > > > > I even set up the vendor driver to test this: it's the same situation there. > > > > > > > > I don't think the console code will assert DTR/RTS, you need to open the > > > > port as a regular tty. > > > > Yes, even if the device is configured in hardware for TNOW mode (instead > > of DTR function) you should still be able to control RTS (at least as > > long as the device is not configured for automatic hardware flow control). > I think I made it work, sort of. > It's a bit annoying because of code I don't understand. It seems that > R_4 has the following settings: > 0x00 DTR off > 0x01 DTR on > 0x10 RTS off > 0x11 RTS on > 0x08 activate (used during port initialization) > 0x50 HW flow on > 0x51 no RTS / HW flow off > > That said, poking 0x00, 0x01, 0x10 and 0x11 by themselves didn't do much. > One also has to write 0x06 to the per-port VEN_R register. > The vendor driver only does that in .set_termios, which I call > questionable until someone calls me out on this and is willing to > share a good reason why that's a good idea ;-) > > However, I'm unable to control the RTS line of port 1. It works for > port 0, port 2 and 3 but not for port 1. > Ports 4-7 don't have the TNOW/DTR and RTS lines routed outside the > package, so I can't test these. Sounds like good progress. Have you made sure HW flow isn't just enabled by default on port 1 or similar? Johan
