Re: iuu_phoenix new driver latency problem.... idea needed...

Oliver Neukum <[email protected]>
Newsgroups gmane.linux.usb.devel
Message-ID <[email protected]>
Am Donnerstag 19 Juli 2007 schrieb Alain Degreffe:
> I have a newbie question :-)
> 
> I would like to have to threads: 1 reading process and one writing
> process...
> 
> For the moment as soon I write to device, I begin to read the answer but it
> is not very efficient because the iso7816 don't give a real way to know if
> the write is finish or if the read will give an answer...
> 
> In the usb-serial classical implementation, the bulk read return all
> incoming characters and the callback function permit to write those
> characters into the tty device. In my case, the problem is the next one: to
> read character I must send a command to the device with a bulk write.. In
> the read call back, may I use the port stored in the context to call a bul
> write function to ask to the device to read ?

Yes, this no problem. You may submit URBs from a callback handler.
Just use GFP_ATOMIC.

> Second problem, the protocol of the device works like this: To read
> character, I must ( as I said before ) , send a command to read ( a bulk
> write message ) , after try to read one byte to know how much byte are
> waiting in the device buffer and finally bulk read the len given at the
> previous step...
> 
> So ideally, a thread dedicated to this sequence is the solution to the
> latency observed in the current implementation ( the smart routine is not
> magic and the cases to stop waiting are limited ) because the function wait
> during 200 round to be sure to read all datas...

A kernel thread is overkill for that.

You could use something like:

1. Send command via bulk
2. In callback of 1 - read the length byte
3. In callback of 2 - read data bytes
4. In callback of 3 - feed data to the tty layer

What exactly do you mean by command?
Does your device reply only when spoken to? In this case you can trigger
the sequence I described above in your write() method. If the device can send
data on its own, 4 should do also 1.

	Regards
		Oliver

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.