James McKenzie <[EMAIL PROTECTED]> writes:
> GRR, the oboe is a seriously broken peice of hardware, I have
> two problems left. The first I think is probably not worth
> solving and the second is I hope easy.
>
> 1) The oboe can only do back to back transmittion without
> intervention, if both frames are submitted together.
Yes, this is true for most chips!
> At the time of queueing the frame to be transmitted you have
> to decide what happens at the end of the frame you can choose.
> a) Stop transmitter and generate interrupt or
> b) Don't generate interrupt, and transmit next
> frame in queue.
>
> The obvious scenario below illustrates the problem.
>
> hard_xmit(frame A)
> queue frame A since we do not know if frame A is the last frame
> before receiving we must chose a) above.
>
> hard_xmit(frame B)
> queue frame B, we cannot atomically change the mode for frame A
> so we have to wait for the Txdone interrupt + latency and then
> reenable the transmitter.
>
> I can't see an obvious fix unless (which I am definitely not
> encouraging you to do) I can receive packets in groups or
> queue them up myself and have a timer interrupt to spit them
> out.
I don't think I understand this last sentence. What do you mean by timer
interrupt? In Linux they are usually 10 ms or more, so how can you use a
timer interrupt in the driver?
I'm not sure if I understand your problem, but think of hard_xmit() as the
"producer" and tx_interrupt() as the "consumer". With proper locking,
things should be pretty easy.
The hard_xmit() function just adds the frame to the tx_queue. It only
initiates transmission if detects that the queue len is 1 after adding a
frame since that indicates that transmission has been stopped. It should
only start tx if it detects that tx is stopped and there are 1 frame to be
sent.
The tx_interrupt() function should restart transmission and send out any
frames left in the tx queue. A good driver could avoid stopping
transmission and even aviod re-initiating dma. So the tx_interrupt()
function should take care of any frames queued by hard_xmit() while some
other frame was being sent.
Take a look at (latest) nsc-ircc.c. Even when re-initiating DMA for every
frame, I can reach FTP speeds of 413 Kbytes/s so this is fast enough!! It
burnes a few cycles but this is not where we should waste our time with
optimizing! You can always fix such things later ;-)
> 2) The register on the oboe for increasing the Preamble in MIR
> and FIR modes is only 5 bits big, what do I do about being
> limited to a maximum of 31? Do I transmit multiple packets
> in the turn time?
You could send out frames to burn the min turn time if you are sure they
would generate CRC error in the remote device.
> 3) (Mathematicians can never count) could you export the
> crc table from wrapper.c so it is visible in toshoboe?
Sure, but what do you need it for?
> Otherwise I have a stable new wizzy driver
Great!
-- Dag
--
/ Dag Brattli | The Linux-IrDA Project /
// University of Tromsoe, Norway | Infrared communication for Linux //
/// http://www.cs.uit.no/~dagb | http://www.cs.uit.no/linux-irda/ ///
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda
