[linux-dvb] AV7110 stable protocol proposal

[Ralph Metzler <rjkm@metzlerbros.de>]

Emard writes:
 > Let me present some thinkering on stable av7110 transport
 > protocol over only one interrupt - DEBI. No more oops or
 > race conditions with DEBI/GPIO in this approach.
 > 
 > shared RAM area will be divided in two disjunct ring buffers, 
 > one is for PC->ARM, other is ARM->PC. This will support
 > even full-duplex operation.

Again, I do not understand what you mean.
How are you going to do "full-duplex" over DEBI with one DMA?
If you mean accessing the DPRAM from both sides at the same time, 
this is already being done.

 
 > PC->ARM ring buffer should be 4-8 times smaller than ARM->PC
 > because basically we will upload less and download more.

Currently it is twice as big. 
I don't know how you want to have usable buffer sizes with
such big ratios. Upload buffer 500 bytes, download buffer 4K?
Good look with those playbacks ...

There also is not much space to make them real ring buffers 
(with more than one ore two elements) and still get useful 
memory copying throughput from the ARM. 


 > Memory will contain also additional pointers to start of each buffer.
 > Complete allocation will look like this:
 > 
 > struct pc2arm_buffer *pc2arm = &pc2arm_data;
 > struct pc2arm_buffer pc2arm_data;
 > struct arm2pc_buffer *arm2pc = &arm2pc_data;
 > struct arm2pc_buffer arm2pc_data;
 > 
 > Such organization allows for various buffer sizes without the
 > need of firmware recompilation if someone wants to change balance
 > between the size of input and output buffer. PC sets pc2arm and
 > arm2pc, pointers to the starts of the buffers and in the data
 > structure itself is wriiten its length; 
 > 
 > The data transport protocol is basically this: first upload data[]
 > starting from ring_position, update new ring_position and increment
 > requested_sequence_number. Other end will process the data and respond 
 > with incrementing completed_sequence_number;
 > 
 > Changing of requested_sequence_number will trigger the other end to 
 > retrieve data and process them. Other end should not take any action if data
 > or ring position is changed until requested_sequence_number is incremented.


How are you going to keep this running? By polling? How else can you know
the ARM finished a transfer?
How can the ARM tell the PC what kind of data it wants?
What will it e.g. do with video data if the video buffer is full but
the audio buffer is empty and it needs this data to keep up
synchronized playback? (Using that mechanism is what removed most of the 
problems with muxing we used to have 2 years ago).

 
 > After ARM has processed data from pc2arm buffer, some response
 > can follow in same manner in arm2pc but it doesn't have to if ARM 
 > has nothing to say. Also the vice versa.

How is this response transferred? Again by polling on the other side?
Or do we need some kind of interrupt to keep this running without 
much overhead? Hmm, let's just call it GPIO interrupt ...

Finally, what exactly is the problem you are having with the 
combined GPIO/DEBI IRQs?
When do problems occur and with which firmware/driver?

Maybe something went wrong when moving to tasklets, which I (for
good reasons) did not yet do.


 > Ralph, can you implement this in the firmware or give as hint or
 > function for ARM gcc that can read/write one byte of shared RAM?

It is memory mapped on the ARM side. I think somebody already pointed 
out where you find the offsets in the gnufirm stuff.


Ralph


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.