On Tue, Feb 26, 2019 at 05:03:49PM +, Russell King - ARM Linux admin wrote:
> On Tue, Feb 26, 2019 at 11:31:15AM -0500, Sven Van Asbroeck wrote:
> > There is talk in the manual about "network mode", which could work by
> > changing
> > the LRCLK only at the first slot - thereby allowing clien
On Tue, Feb 26, 2019 at 4:11 AM Russell King - ARM Linux admin
wrote:
>
> Given that it is normal to talk about I2S being clocked at "64fs",
> "32fs" etc, wouldn't it just be much neater to specify _this_ value
> in DT, rather than half that value?
>
Would we be able to reach consensus on Russell
On Tue, Feb 26, 2019 at 10:45 AM Russell King - ARM Linux admin
wrote:
>
>
> I can't see how you'd extend a single I2S setup to support multi-
> channel audio without either adding more I2S data lines or adding
> additional WS signals (so making it e.g., a binary number).
>
That's a very good poi
On Tue, Feb 26, 2019 at 4:11 AM Russell King - ARM Linux admin
wrote:
>
> This code actually requires a lot more thought - while it may solve
> Sven's issue, it isn't generic.
Wholeheartedly agree. My patches are marked RFC in the hope that they will be
picked apart by folks much more in touch wi
On Tue, Feb 26, 2019 at 11:31:15AM -0500, Sven Van Asbroeck wrote:
> On Tue, Feb 26, 2019 at 10:45 AM Russell King - ARM Linux admin
> wrote:
> >
> >
> > I can't see how you'd extend a single I2S setup to support multi-
> > channel audio without either adding more I2S data lines or adding
> > addi
On Tue, Feb 26, 2019 at 11:31:15AM -0500, Sven Van Asbroeck wrote:
> That's a very good point too. In light of this, I struggle to understand how
> the ssl_ssi can specify this:
> static struct snd_soc_dai_driver fsl_ssi_dai_template = {
> .playback = {
> .stream_name = "C
On Tue, Feb 26, 2019 at 03:45:19PM +, Russell King - ARM Linux admin wrote:
> Adding more WS signals makes the bus deviate from the I2S standard,
> thereby making it impossible to connect a set of standard DACs to
> such a source, whereas adding more I2S data lines, you just connect
> each DAC
On Tue, Feb 26, 2019 at 09:53:22AM -0500, Sven Van Asbroeck wrote:
> On Tue, Feb 26, 2019 at 4:11 AM Russell King - ARM Linux admin
> > If the signal continues toggling, what does it do for the inactive
> > channel - is that just one BCLK period long or does it assume there
> > is still the second
On Tue, Feb 26, 2019 at 09:53:22AM -0500, Sven Van Asbroeck wrote:
> I notice that hdmi-codec.c supports up to 8 channels in hdmi multi-channel
> playback mode. If we had a _theoretical_ hdmi xmitter with 8chan support,
> would the bclk_ratio not be 8 x slot_size - or 8 x 32 if using an fsl_ssi
> i
On Tue, Feb 26, 2019 at 09:35:47AM +0900, Kuninori Morimoto wrote:
> > @@ -97,7 +98,7 @@ static int asoc_simple_card_hw_params(struct
> > snd_pcm_substream *substream,
> > struct simple_card_data *priv = snd_soc_card_get_drvdata(rtd->card);
> > struct simple_dai_props *dai_props =
> >
In some situations, codec configuration will depend on the
bclk_ratio generated by the cpu dai. The tda998x hdmi transmitter
is an example of this.
Allow simple-card to set the bclk_ratio via the 'bclk-slot-ratio'
devicetree property, which describes the bclk to slot rate ratio.
This value is con
Hi Sven
Thank you for your patch
> In some situations, codec configuration will depend on the
> bclk_ratio generated by the cpu dai. The tda998x hdmi transmitter
> is an example of this.
>
> Allow simple-card to set the bclk_ratio via the 'bclk-slot-ratio'
> devicetree property, which describes
12 matches
Mail list logo
