Hi Geert,
I'm sorry for late reply. Some unrelated happenings here in south Germany.
Geert Uytterhoeven, Mon, Mar 30, 2020 10:32:47 +0200:
> On Thu, Mar 26, 2020 at 11:55 AM Alex Riesen <alexander.riesen@xxxxxxxxxxx> wrote:
> > --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > @@ -510,6 +511,15 @@ adv7482_txb: endpoint {
> > remote-endpoint = <&csi20_in>;
> > };
> > };
> > +
> > + port@c {
> > + reg = <12>;
> > +
> > + adv7482_i2s: endpoint {
> > + remote-endpoint = <&rsnd_endpoint3>;
> > + system-clock-direction-out;
> > + };
> > + };
>
> As the adv748x driver just ignores "invalid" endpoints...
>
> > @@ -758,8 +769,19 @@ &rcar_sound {
> > <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
> > <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
> > <&audio_clk_a>, <&cs2000>,
> > - <&audio_clk_c>,
> > + <&adv7482_hdmi_in>,
> > <&cpg CPG_CORE CPG_AUDIO_CLK_I>;
>
> ... and the rsnd driver ignores nonexistent-clocks, the DT change has no
> hard dependency on the driver change, and won't introduce regressions
> when included, right?
Well, it maybe won't, but isn't it a little ... implicit?
And I'm no haste to include the changes, if you mean I can (or should) submit
the device tree patch separately.
> > @@ -777,6 +799,21 @@ rsnd_endpoint0: endpoint {
> > capture = <&ssi1 &src1 &dvc1>;
> > };
> > };
> > + rsnd_port3: port@3 {
> > + reg = <3>;
> > + rsnd_endpoint3: endpoint {
> > + remote-endpoint = <&adv7482_i2s>;
> > +
> > + dai-tdm-slot-num = <8>;
> > + dai-tdm-slot-width = <32>;
> > + dai-format = "left_j";
> > + mclk-fs = <256>;
> > + bitclock-master = <&adv7482_i2s>;
> > + frame-master = <&adv7482_i2s>;
> > +
> > + capture = <&ssi4>;
> > + };
> > + };
> > };
> > };
>
> However, as salvator-common.dtsi is shared by all Salvator-X(S) variants,
> you'll have to add a dummy ssi4 node to r8a77961.dtsi first.
I see. There are even two dummy SSI nodes already. I would prefer to submit
the change together with other Salvator device tree changes. Is that alright?
Regards,
Alex
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
