Hi Mark, Lars
> > > sound {
> > > compatible = "simple-audio-card";
> > > ...
> > >
> > > cpu {
> > > sound-dai = <&rcar_sound 0>;
> > > };
> > > codec {
> > > sound-dai = <&ak4643>;
> > > };
> > > };
> (snip)
> > There's two separate things here. One is how the code is implemented
> > (which does look very much like it should be doing DPCM) and the other
> > is how the DT binding looks - the DT binding is supposed to be a
> > hardware neutral thing and not depend on Linux implementation details.
> > If you've already got the hardware described well enough to discover
> > everything then that generally indicates that the DT binding should not
> > need to change.
>
> In my case, I need DPCM if CPU want to use "sampling rate convert",
> otherwise, I don't need it.
> So, DPCM <-> non DPCM switching happen if DTS has
> sampling-rate-convert = <xxxxxxx> or something like that.
> Does my understanding correct ?
I re-considered about above, and checked current code.
If my above understanding was correct,
simple-card driver needs many patches to support it.
And, it is not easy
I want to synchronize basic agreement before starting it.
Otherwise, it is easy to reject my many weeks work,
and I don't want it.
# 1st simple-card DT support used 1 year...
My understanding is below.
It is good match for my current purpose,
and "sampling-rate-convert feature via DPCM" can be standard on simple-card.
My concern is simple card code will be not simple...
-- non DPCM ----
sound {
compatible = "simple-audio-card";
...
cpu {
sound-dai = <&cpu-dai>;
};
codec {
sound-dai = <&codec-dai>;
};
};
same as current style
-- DPCM ----
sound {
compatible = "simple-audio-card";
...
cpu {
sound-dai = <&cpu-dai>;
};
codec {
sound-dai = <&codec-dai>;
fixed-sampling-rate = <44100>;
};
};
DPCM FE/BE will be
FE cpu : cpu-dai
codec : dummy
BE cpu : dummy
codec : codec-dai
required route will be created automatically
but, it needs "enable DAI name on DAPM route" method anyway
--
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
