alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Arnaud Pouliquen <arnaud.pouliquen@st.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Jean-Francois Moine <moinejf@free.fr>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	David Airlie <airlied@linux.ie>,
	Liam Girdwood <lgirdwood@gmail.com>, Jyri Sarha <jsarha@ti.com>,
	Takashi Iwai <tiwai@suse.de>, Mark Brown <broonie@kernel.org>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>
Subject: Re: [RFC 1/6] video: hdmi: add helper function for N and CTS
Date: Wed, 20 Jan 2016 14:26:08 +0100	[thread overview]
Message-ID: <569F8AF0.9000300@st.com> (raw)
In-Reply-To: <20160119165430.GN19062@n2100.arm.linux.org.uk>



On 01/19/2016 05:54 PM, Russell King - ARM Linux wrote:
> On Tue, Jan 19, 2016 at 02:40:31PM +0100, Arnaud Pouliquen wrote:
>> From: Moise Gergaud <moise.gergaud@st.com>
>>
>> Add helper function to compute HDMI CTS and N parameters
>> Implementation is based on HDMI 1.4b specification.
> 
> You should note that these CTS/N parameters are for where the audio and
> video clocks are coherent: iow, they are derived from the same source.
> If they can drift (because they're generated from different sources)
> then a hardware implementation which automatically calculates CTS is
> needed.
Yes this is the case on STI platform, CTS is computed by hardware. In
this case hdmi driver only takes into account the N value.
> 
> However, some of the values given in the HDMI specs for CTS are actually
> two values, because a single value does not specify the audio clock even
> with the N values given.  For these, the values returned will not give
> an accurate clock - this should also be noted.
In HDMI specs i only see a double value for 32 kHz with TMDS clock at
74.324  MHz. I can add a  alt_CTS params in hdmi_audio_n_cts that will
be not null if alternate a value is needed. Is this something reasonable
for you?
As also suggest Mark, i need to add all the restriction info in code.

> 
> Next, does "pixel clock" make sense when you have pixel repetition?
> Would calling this "tdms_clock" be more accurate to the specification
> and less mis-leading to users?
> 
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
>> ---
>>  drivers/video/hdmi.c | 146 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/hdmi.h |  11 ++++
>>  2 files changed, 157 insertions(+)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
>> index 1626892..8af33c1 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -1242,3 +1242,149 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer)
>>  	return ret;
>>  }
>>  EXPORT_SYMBOL(hdmi_infoframe_unpack);
>> +
>> +/**
>> + * audio clock regeneration (acr) parameters
>> + * N and CTS computation are based on HDMI specification 1.4b
>> + */
>> +enum audio_rate {
>> +	HDMI_AUDIO_N_CTS_32KHZ,
>> +	HDMI_AUDIO_N_CTS_44_1KHZ,
>> +	HDMI_AUDIO_N_CTS_48KHZ,
>> +};
>> +
>> +struct hdmi_audio_acr {
>> +	unsigned long pixel_clk;
>> +	struct hdmi_audio_n_cts n_cts;
>> +};
>> +
>> +static const struct hdmi_audio_acr hdmi_audio_standard_acr[3][12] = {
>> +	{ /*32 kHz*/
>> +		{  25175, {  4576,  28125 } }, /* 25,20/1.001  MHz */
>> +		{  25200, {  4096,  25200 } }, /* 25.20        MHz */
>> +		{  27000, {  4096,  27000 } }, /* 27.00        MHz */
>> +		{  27027, {  4096,  27027 } }, /* 27.00*1.001  MHz */
>> +		{  54000, {  4096,  54000 } }, /* 54.00        MHz */
>> +		{  54054, {  4096,  54054 } }, /* 54.00*1.001  MHz */
>> +		{  74176, { 11648, 310938 } }, /* 74.25/1.001  MHz */
>> +		{  74250, {  4096,  74250 } }, /* 74.25        MHz */
>> +		{ 148352, { 11648, 421875 } }, /* 148.50/1.001 MHz */
>> +		{ 148500, {  4096, 148500 } }, /* 148.50       MHz */
>> +		{ 296703, {  5824, 421875 } }, /* 297/1.001    MHz */
>> +		{ 297000, {  3072, 222750 } }, /* 297          MHz */
>> +	},
>> +	{ /*44.1 kHz, 88.2 kHz  176.4 kHz*/
>> +		{  25175, {  7007,  31250 } }, /* 25,20/1.001  MHz */
>> +		{  25200, {  6272,  28000 } }, /* 25.20        MHz */
>> +		{  27000, {  6272,  30000 } }, /* 27.00        MHz */
>> +		{  27027, {  6272,  30030 } }, /* 27.00*1.001  MHz */
>> +		{  54000, {  6272,  60000 } }, /* 54.00        MHz */
>> +		{  54054, {  6272,  60060 } }, /* 54.00*1.001  MHz */
>> +		{  74176, { 17836, 234375 } }, /* 74.25/1.001  MHz */
>> +		{  74250, {  6272,  82500 } }, /* 74.25        MHz */
>> +		{ 148352, {  8918, 234375 } }, /* 148.50/1.001 MHz */
>> +		{ 148500, {  6272, 165000 } }, /* 148.50       MHz */
>> +		{ 296703, {  4459, 234375 } }, /* 297/1.001    MHz */
>> +		{ 297000, {  4704, 247500 } }, /* 297          MHz */
>> +	},
>> +	{ /*48 kHz, 96 kHz  192 kHz*/
>> +		{  25175, {  6864,  28125 } }, /* 25,20/1.001  MHz */
>> +		{  25200, {  6144,  25200 } }, /* 25.20        MHz */
>> +		{  27000, {  6144,  27000 } }, /* 27.00        MHz */
>> +		{  27027, {  6144,  27027 } }, /* 27.00*1.001  MHz */
>> +		{  54000, {  6144,  54000 } }, /* 54.00        MHz */
>> +		{  54054, {  6144,  54054 } }, /* 54.00*1.001  MHz */
>> +		{  74176, { 11648, 140625 } }, /* 74.25/1.001  MHz */
>> +		{  74250, {  6144,  74250 } }, /* 74.25        MHz */
>> +		{ 148352, {  5824, 140625 } }, /* 148.50/1.001 MHz */
>> +		{ 148500, {  6144, 148500 } }, /* 148.50       MHz */
>> +		{ 296703, {  5824, 281250 } }, /* 297/1.001    MHz */
>> +		{ 297000, {  5120, 247500 } }, /* 297          MHz */
>> +	}
>> +};
>> +
>> +/**
>> + * hdmi_compute_n_cts() - compute N and CTS parameters
>> + * @audio_fs: audio frame clock frequency in kHz
> 
> This is wrong.  You're expecting values such as 32000 here.  32000kHz
> would be 32MHz, which is way too high for an audio frame clock.  I
> think you mean Hz.
> 
Oops, yes Hz not kHz
>> + * @pixel_clk: pixel clock frequency in kHz
> 
> This is correct though.
> 
>> + * @n_cts: N and CTS parameter returned to user
>> + *
>> + * Values computed are based on table described in HDMI specification 1.4b
>> + *
>> + * Returns 0 on success or a negative error code on failure.
>> + */
>> +int hdmi_audio_compute_n_cts(unsigned int audio_fs, unsigned long pixel_clk,
>> +			     struct hdmi_audio_n_cts *n_cts)
>> +{
>> +	int audio_freq_id, i;
>> +	int ratio = 1;
>> +	const struct hdmi_audio_acr  *acr_table;
>> +	const struct hdmi_audio_n_cts *predef_n_cts = NULL;
>> +
>> +	switch (audio_fs) {
>> +	case 32000:
>> +		audio_freq_id = HDMI_AUDIO_N_CTS_32KHZ;
>> +		n_cts->n = 4096;
>> +		break;
>> +
>> +	case 44100:
>> +		audio_freq_id = HDMI_AUDIO_N_CTS_44_1KHZ;
>> +		n_cts->n = 6272;
>> +		break;
>> +
>> +	case 48000:
>> +		audio_freq_id = HDMI_AUDIO_N_CTS_48KHZ;
>> +		n_cts->n = 6144;
>> +		break;
>> +
>> +	case 88200:
>> +		audio_freq_id = HDMI_AUDIO_N_CTS_44_1KHZ;
>> +		ratio = 2;
>> +		n_cts->n = 6272 * 2;
>> +		break;
>> +
>> +	case 96000:
>> +		audio_freq_id = HDMI_AUDIO_N_CTS_48KHZ;
>> +		ratio = 2;
>> +		n_cts->n = 6144 * 2;
>> +		break;
>> +
>> +	case 176400:
>> +		audio_freq_id = HDMI_AUDIO_N_CTS_44_1KHZ;
>> +		ratio = 4;
>> +		n_cts->n = 6272 * 4;
>> +		break;
>> +
>> +	case 192000:
>> +		audio_freq_id = HDMI_AUDIO_N_CTS_48KHZ;
>> +		ratio = 4;
>> +		n_cts->n = 6144 * 4;
>> +		break;
>> +
>> +	default:
>> +		return -EINVAL;
>> +	}
>> +
>> +	acr_table = hdmi_audio_standard_acr[audio_freq_id];
>> +	for (i = 0; i < ARRAY_SIZE(hdmi_audio_standard_acr[0]); i++) {
>> +		if (pixel_clk == acr_table[i].pixel_clk) {
>> +			predef_n_cts = &acr_table[i].n_cts;
>> +			break;
>> +		}
>> +	}
>> +
>> +	if (!predef_n_cts) {
>> +		/*
>> +		 * predefined frequency not found. Compute CTS using formula:
>> +		 * CTS = (Ftdms_clk * N) / (128* audio_fs)
>> +		 */
>> +		n_cts->cts =  pixel_clk * n_cts->n / (128 * audio_fs);
> 
> This looks like it could overflow.  192kHz audio clock, 297MHz tdms
> clock -> (297000 * 6144 * 4) = 7299072000.  32 bit unsigned math
> overflows beyond 4294967295.
> 
Yes, need to use intermediate 64 bits variable for calculation

  parent reply	other threads:[~2016-01-20 13:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19 13:40 [RFC 0/6] sti: add audio interface to the hdmi driver Arnaud Pouliquen
2016-01-19 13:40 ` [RFC 1/6] video: hdmi: add helper function for N and CTS Arnaud Pouliquen
2016-01-19 16:54   ` Russell King - ARM Linux
2016-01-19 17:14     ` Mark Brown
2016-01-20 13:26     ` Arnaud Pouliquen [this message]
2016-01-20 13:39       ` Russell King - ARM Linux
2016-01-19 13:40 ` [RFC 2/6] ALSA: pcm: add IEC958 channel status control helper Arnaud Pouliquen
2016-01-19 17:00   ` Russell King - ARM Linux
2016-01-20 14:16     ` Arnaud Pouliquen
2016-01-19 13:40 ` [RFC 3/6] ASoC: core: add code to complete dai init after pcm creation Arnaud Pouliquen
2016-01-19 13:40 ` [RFC 4/6] drm: sti: Add ASoC generic hdmi codec support Arnaud Pouliquen
2016-01-19 17:06   ` Russell King - ARM Linux
2016-01-19 13:40 ` [RFC 5/6] ASoc: hdmi-codec: add IEC control Arnaud Pouliquen
2016-01-19 13:40 ` [RFC 6/6] ARM: DT: b2120: add audio HDMI dai link in audio card Arnaud Pouliquen

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=569F8AF0.9000300@st.com \
    --to=arnaud.pouliquen@st.com \
    --cc=airlied@linux.ie \
    --cc=alsa-devel@alsa-project.org \
    --cc=benjamin.gaignard@linaro.org \
    --cc=broonie@kernel.org \
    --cc=jsarha@ti.com \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux@arm.linux.org.uk \
    --cc=moinejf@free.fr \
    --cc=p.zabel@pengutronix.de \
    --cc=tiwai@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).