linux-kernel - Re: [PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140703154325.GY32514@n2100.arm.linux.org.uk>
Date:	Thu, 3 Jul 2014 16:43:25 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Jean-Francois Moine <moinejf@...e.fr>
Cc:	Mark Brown <broonie@...nel.org>, Andrew Lunn <andrew@...n.ch>,
	devicetree@...r.kernel.org, alsa-devel@...a-project.org,
	lgirdwood@...il.com, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org, Rob Clark <robdclark@...il.com>,
	Dave Airlie <airlied@...il.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] ASoC: tda998x: add a codec to the HDMI transmitter

On Thu, Jul 03, 2014 at 05:29:09PM +0200, Jean-Francois Moine wrote:
> I think that you did not look at my code.
> 
> Both S/PDIF and I2S work with the TDA998x. It is a choice of the audio
> subsystem to do this choice, not Russell King.

If you think I'm arguing because I personally want something, then we're
not going to make any progress.

What I want is for this to be _correct_ and _not_ to introduce silly
restrictions which break people's setups.

> When DPCM will handle the formats and rates, the audio subsystem will
> find by itself if such stream will go to the HDMI only or to the S/PDIF
> only or to both. The kirwood audio driver will work as it is and the tda998x
> CODEC will work as it is. There will be no need to change these drivers.

Except, as Mark has already pointed out, and as I keep pointing out to
you, and you keep refusing to accept, the kirkwood driver as it stands
is *not* a DPCM driver.  It makes no use of that stuff at all.

What you're doing in kirkwood-i2s is providing two plain DAI links,
and then insisting that only one can be active any any one time.

A DPCM solution provides at least one frontend DAI link and at least
one backend DAI link.  Your code does not do this.

The second point is that - and as I keep telling you - that as soon
as you couple your existing code (which restricts things like the
sample rates) you can no longer output anything else through the
optical out ON THE CUBOX.  For this statement, I'm not talking
_generally_,  I'm talking _specifically_ about _one_ _platform_.

> All we need actually is some more code in DPCM or multi-codec or
> whatever mechanism which will route the stream according to the rates
> and formats.

Yes, DPCM currently lacks full support, that's been known about for
some time - I've reported it to Mark, but it seems that this isn't
something that is going to get fixed until others put work into it.

> Eventually, the TDA998x is used in other machines. Are you sure that
> the audio controllers of all these machines have a S/PDIF output
> connected to the S/PDIF input of the tda998x?

Which bit of "we need to support both I2S and SPDIF" in my previous
emails was not clear.  Which bit of "We should only support SPDIF
on the Cubox" was not clear?

I *fully* acknowledge that we need to support both, but I'm putting
a _strong_ recommendation to you _with_ technical reasons why we
should _only_ support SPDIF on the Cubox.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/