On Tue, Jan 13, 2015 at 09:41:01PM +0200, Jyri Sarha wrote:
> On 01/13/2015 09:26 PM, Russell King - ARM Linux wrote:
> >SCLK: _~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_
> > WS: __~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~________________________________~
> >I2S1: llmm............................llmm............................llm
> >I2S2: llmm............................llmm............................llm
> >I2S3: llmm............................llmm............................llm
> >I2S4: llmm............................llmm............................llm
> >
> >So, what I'm saying is that it is_impossible_ to drive the TDA998x using
> >multiple I2S streams which are not produced by the same I2S block.
>
> This is besides the point, but it is possible that one of the multiple I2S
> blocks is the bit-clock and frame-clock master to the i2s bus and the others
> are slaves to it (banging their bits according to SCLK and WS of the I2S
> master). However, in this situation there really is only one i2s bus with
> multiple data pins.
>
> Just my 0.02€ to this discussion.
Right, that's about the only way it could work.
To represent that in DT, I would imagine we'd need something like this:
#address-cells = <1>;
#size-cells = <0>;
...
port@1 { /* AP1,2 = I2S */
#address-cells = <1>;
#size-cells = <0>;
port-type = "i2s";
reg = <0x01>; /* WS */
tda998x_i2s1: endpoint@2 {
reg = <0x02>; /* AP1 */
remote-endpoint = <&audio1_i2s>;
};
tda998x_i2s2: endpoint@4 {
reg = <0x04>; /* AP2 */
remote-endpoint = <&audio2_i2s>;
};
};
where audio1_i2s is operating in master mode, and audio2_i2s is
operating in slave mode for both WS and SCLK.
If we can agree on that, then I'm happy with the proposed binding.
(Remember that #address-cells and #size-cells are required in the
parent where we have reg= in the child.)
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
