[linux-dvb] AV7110 stable protocol proposal

[Emard <emard@softhome.net>]

HI

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.

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

Data structure of each buffer will look like this:

struct pc2arm_buffer {
  u32 length = sizeof(struct pc2arm_buffer);
  u32 ring_position = 0;
  u8 requested_sequence_number = 0;
  u8 completed_sequence_number = 0;
  u8 data[1000];
};

struct arm2pc_buffer {
  u32 length = sizeof(struct arm2pc_buffer);
  u32 ring_position = 0;
  u8 requested_sequence_number = 0;
  u8 completed_sequence_number = 0;
  u8 data[8000];
};

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.

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.

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?

Emard


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