All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Peres <martin.peres@linux.intel.com>
To: "Ser, Simon" <simon.ser@intel.com>,
	"igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>
Cc: "Peres, Martin" <martin.peres@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t 2/3] lib/igt_edid: add support for Speaker Allocation Data blocks
Date: Mon, 3 Jun 2019 16:34:19 +0300	[thread overview]
Message-ID: <192f3e30-7567-dedb-641c-212078f6cb73@linux.intel.com> (raw)
In-Reply-To: <e4dbf6ea6aae9bdcf26746416f53bcc367f160a1.camel@intel.com>

On 03/06/2019 16:28, Ser, Simon wrote:
> On Mon, 2019-06-03 at 16:13 +0300, Martin Peres wrote:
>> On 27/05/2019 15:03, Simon Ser wrote:
>>> Speaker Allocation Data blocks describe which speakers are present in the
>>> display device.
>>>
>>> This block is required to make DisplayPort audio work.
>>>
>>> Signed-off-by: Simon Ser <simon.ser@intel.com>
>>> ---
>>>  lib/igt_edid.c | 12 ++++++++++++
>>>  lib/igt_edid.h | 18 ++++++++++++++++++
>>>  2 files changed, 30 insertions(+)
>>>
>>> diff --git a/lib/igt_edid.c b/lib/igt_edid.c
>>> index fbdb0c06b8d7..e71136f48e14 100644
>>> --- a/lib/igt_edid.c
>>> +++ b/lib/igt_edid.c
>>> @@ -348,6 +348,18 @@ size_t edid_cea_data_block_set_vsd(struct edid_cea_data_block *block,
>>>  	return sizeof(struct edid_cea_data_block) + vsd_size;
>>>  }
>>>  
>>> +size_t edid_cea_data_block_set_speaker_alloc(struct edid_cea_data_block *block,
>>> +					     const struct cea_speaker_alloc *speakers)
>>> +{
>>> +	size_t size;
>>> +
>>> +	size = sizeof(struct cea_speaker_alloc);
>>> +	edid_cea_data_block_init(block, EDID_CEA_DATA_SPEAKER_ALLOC, size);
>>> +	memcpy(block->data.speakers, speakers, size);
>>> +
>>> +	return sizeof(struct edid_cea_data_block) + size;
>>> +}
>>> +
>>>  void edid_ext_set_cea(struct edid_ext *ext, size_t data_blocks_size,
>>>  		      uint8_t flags)
>>>  {
>>> diff --git a/lib/igt_edid.h b/lib/igt_edid.h
>>> index 7edd7e38f41e..39d1842d32df 100644
>>> --- a/lib/igt_edid.h
>>> +++ b/lib/igt_edid.h
>>> @@ -195,6 +195,21 @@ struct cea_vsd {
>>>  	char data[];
>>>  };
>>>  
>>> +enum cea_speaker_alloc_item {
>>
>> Is that the official name? Having alloc in the name of an enum is a
>> little odd...
> 
> Yes, "Speaker Allocation Data" is the official name.

ACK

> 
>>> +	CEA_SPEAKER_FRONT_LEFT_RIGHT = 1 << 0,
>>> +	CEA_SPEAKER_LFE = 1 << 1,
>>> +	CEA_SPEAKER_FRONT_CENTER = 1 << 2,
>>> +	CEA_SPEAKER_REAR_LEFT_RIGHT = 1 << 3,
>>> +	CEA_SPEAKER_REAR_CENTER = 1 << 4,
>>> +	CEA_SPEAKER_FRONT_LEFT_RIGHT_CENTER = 1 << 5,
>>> +	CEA_SPEAKER_REAR_LEFT_RIGHT_CENTER = 1 << 6,
>>> +};
>>> +
>>> +struct cea_speaker_alloc {
>>> +	uint8_t speakers; /* enum cea_speaker_alloc_item */
>>> +	uint8_t reserved[2];
>>> +} __attribute__((packed));
>>> +
>>>  enum edid_cea_data_type {
>>>  	EDID_CEA_DATA_AUDIO = 1,
>>>  	EDID_CEA_DATA_VIDEO = 2,
>>> @@ -207,6 +222,7 @@ struct edid_cea_data_block {
>>>  	union {
>>>  		struct cea_sad sads[0];
>>>  		struct cea_vsd vsds[0];
>>> +		struct cea_speaker_alloc speakers[0];
>>
>> Why [0]? Shouldn't this all be [1]?
> 
> EDID allows a variable number of these, so this struct has variable
> length. The array must have a zero size otherwise sizeof-based
> computations will be off (each of the members of the union have a
> different size). The idea is to allow indexing any of these from the
> end of the header block.
> 
> Alternatively, in all places where we access these fields we could cast
> the edid_cea_data_block to a char *, then add sizeof(struct
> edid_cea_data_block), then cast to a struct cea_speaker_alloc *. This
> sounds a little annoying to write and to read, though.

I see... Well, sounds like an acceptable reasoning. Is it documented on
top of the union already?

Regardless:

Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
> 
>>>  	} data;
>>>  } __attribute__((packed));
>>>  
>>> @@ -295,6 +311,8 @@ size_t edid_cea_data_block_set_sad(struct edid_cea_data_block *block,
>>>  				   const struct cea_sad *sads, size_t sads_len);
>>>  size_t edid_cea_data_block_set_vsd(struct edid_cea_data_block *block,
>>>  				   const struct cea_vsd *vsd, size_t vsd_size);
>>> +size_t edid_cea_data_block_set_speaker_alloc(struct edid_cea_data_block *block,
>>> +					     const struct cea_speaker_alloc *speakers);
>>>  void edid_ext_set_cea(struct edid_ext *ext, size_t data_blocks_size,
>>>  		      uint8_t flags);
>>>  
>>>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-06-03 13:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-27 12:03 [igt-dev] [PATCH i-g-t 0/3] Unify HDMI audio EDID generation Simon Ser
2019-05-27 12:03 ` [igt-dev] [PATCH i-g-t 1/3] lib/tests/igt_edid: introduce EDID sanity checks Simon Ser
2019-06-03 13:11   ` Martin Peres
2019-05-27 12:03 ` [igt-dev] [PATCH i-g-t 2/3] lib/igt_edid: add support for Speaker Allocation Data blocks Simon Ser
2019-06-03 13:13   ` Martin Peres
2019-06-03 13:28     ` Ser, Simon
2019-06-03 13:34       ` Martin Peres [this message]
2019-05-27 12:03 ` [igt-dev] [PATCH i-g-t 3/3] lib/igt_kms: introduce igt_kms_get_hdmi_audio_edid Simon Ser
2019-06-03 13:18   ` Martin Peres
2019-05-27 12:57 ` [igt-dev] ✓ Fi.CI.BAT: success for Unify HDMI audio EDID generation Patchwork
2019-05-27 23:35 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=192f3e30-7567-dedb-641c-212078f6cb73@linux.intel.com \
    --to=martin.peres@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=martin.peres@intel.com \
    --cc=simon.ser@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.