Hi Daniel and thank you,
On 03/12/2011 01:42 AM, Daniel Glöckner wrote:
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.
You are correct, a typo.
However, it looks like also TX_OK will be used for Mode 3.
And maybe also TX_BROADCAST_REJECT.
In particular with reference to your link in below.
* 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...
I assume this must be handled by logic in the driver if it supports this
mode.
* 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?
Even though I find it a bit confusing in the standard, the plan
was to send Qty-1 just after the /DES bit.
It was an attempt to make the configuration and status the same.
Such that we could use the same bit masks.
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.
Maybe I should change this such that we actually send up the whole frame
as tx_status.
In that way we will avoid the confusion of the Qty bit orders also.
But then this should apply to the configuration as well.
* 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.
Yes I see that. However CEC don't have the start sequence (to
differenciate between mode 1 - 3),
and the application id.
In addition can't I see that mode 3 describe the ACK and EOM bits.
It might be difficult to "force" easylink into the mode 3 as it is.
If we could use the application id it might be possible for the driver to
change behaviour.
Or we will end up with
#define AV_LINK_CAP_MODE_EASY_LINK (1 << 4)
And so on, which might be ok also.
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
Martin
--
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
