Hi Martin, On Fri, Mar 11, 2011 at 12:36:09PM +0100, Martin Bugge (marbugge) wrote: > Not every tx status is applicable for all modes, see table 1. > > |-----------------------------------------------------| > | Av link Mode | CEC | 1 | 2 | 3 | > |-----------------------------------------------------| > | Status | | | | | > |-----------------------------------------------------| > | TX_OK | a | n/a | a | n/a | > |-----------------------------------------------------| > | TX_ARB_LOST | a | n/a | a | a | > |-----------------------------------------------------| > | TX_RETRY_TIMEOUT | a | n/a | a | a | > |-----------------------------------------------------| > | TX_BROADCAST_REJECT | a | n/a | a | n/a | > |-----------------------------------------------------| TX_ARB_LOST is applicable to mode 1. Arbitration loss will also be caused by receivers detecting a bad pulse. > * AV link mode 1: > In mode 1 the frame length is fixed to 21 bits (including the > start sequence). > Some of these bits (Qty 1 - 6) can be arbitrated by the > receiver to signal supported formats/standards. > conf: > enable: true/false > upstream_Qty: QTY bits 1-6 > downstream_Qty: QTY bits 1-6 > |------------------------------------------------| > | Bits: | 31 - 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | > |------------------------------------------------| > | Qty bits | x | x | 6 | 5 | 4 | 3 | 2 | 1 | > |------------------------------------------------| > Qty bits 1-6 mapping (x: not used) If the Linux system is a video source, it must stop arbitrating those Qty bits as soon as another video source wants to become active. As this includes the message where the new source announces itself, this can't be handled by reconfiguration after reception of the message. If the Linux system is a video sink, the announcement of a new source should not affect the Qty bits to arbitrate. And don't get me startet about systems capable of being a video source and sink at the same time, capturing their own signal until a new source becomes active... > * AV link mode 1: > Frame received/transmitted: > head: > |-------------------------------------------------| > | Bits: | 31 - 4 | 3 | 2 | 1 | 0 | > |-------------------------------------------------| > | head bits: | x | DIR | /PAS | /NAS | /DES | > |-------------------------------------------------| > Qty: Quality bits 1 - 16; > |---------------------------------------| > | Bits: | 31 - 16 | 15 | 14 - 1 | 0 | > |---------------------------------------| > | Qty bits | x | 16 | 15 - 2 | 1 | > |---------------------------------------| > x: not used Is Qty-1 or Qty-16 the bit sent after /DES? > In blocking mode only: > tx_status: tx status. > tx_status_Qty: which Qty bits 1 - 6 bits was arbitrated > during transmit. It may be interesting to know what other devices did to the /PAS and /DES bits when they were sent as 1. > * AV link mode 3: TBD. Chances are that nobody ever used this > len: length of message in bits, maximum 96 bits. > msg: the raw message received/transmitted. (without the start > sequence). > tx_status: tx status in blocking mode. Google turned up this: http://fmt.cs.utwente.nl/publications/files/111_heerink.pdf It suggests that at least Philips' variant of AV.link mode 3 - EasyLink - is even closer to CEC than mode 2. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
