On Wed, Jun 12, 2019 at 12:42 PM Russell King - ARM Linux admin
wrote:
>
> I think you're confusing tda998x_derive_cts_n() and tda998x_get_adiv().
> tda998x_derive_cts_n() only returns 0 or -EINVAL.
>
True. Apologies for the confusion.
___
dri-devel
On Wed, Jun 12, 2019 at 12:28 PM Russell King - ARM Linux admin
wrote:
>
> The platform data path has never supported the HDMI codec way of doing
> things, so that really isn't a concern here. The platform data way
> was sufficient to allow SPDIF streams to work with a static setup of
> the
On Tue, Jun 11, 2019 at 7:02 AM Russell King wrote:
>
> The TDA998x derives the CTS value using the supplied I2S bit clock
> (ACLK, in TDA998x parlence) rather than 128·fs. TDA998x uses two
> constants named m and k in the CTS generator such that we have this
> relationship between the I2S
On Wed, Jun 12, 2019 at 12:37:57PM -0400, Sven Van Asbroeck wrote:
> On Wed, Jun 12, 2019 at 12:28 PM Russell King - ARM Linux admin
> wrote:
> >
> > The platform data path has never supported the HDMI codec way of doing
> > things, so that really isn't a concern here. The platform data way
> >
On Wed, Jun 12, 2019 at 11:27:16AM -0400, Sven Van Asbroeck wrote:
> On Tue, Jun 11, 2019 at 7:02 AM Russell King
> wrote:
> >
> > The TDA998x derives the CTS value using the supplied I2S bit clock
> > (ACLK, in TDA998x parlence) rather than 128·fs. TDA998x uses two
> > constants named m and k
The TDA998x derives the CTS value using the supplied I2S bit clock
(ACLK, in TDA998x parlence) rather than 128·fs. TDA998x uses two
constants named m and k in the CTS generator such that we have this
relationship between the I2S source ACLK and the sink fs:
128·fs_sink = ACLK·m / k
