From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kuninori Morimoto <kuninori.morimoto.gx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [alsa-devel] [PATCH 8/8] ASoC: add snd-soc-dummy DT support
Date: Thu, 28 Aug 2014 17:41:00 -0700 (PDT)
Message-ID: <87ha0wb012.wl%kuninori.morimoto.gx@gmail.com>
References: <87wq9vmyyc.wl%kuninori.morimoto.gx@gmail.com>
	<20140826091120.GC17528@sirena.org.uk>
	<53FC5105.6070901@metafoo.de>
	<20140826094211.GF17528@sirena.org.uk>
	<87r403mtip.wl%kuninori.morimoto.gx@gmail.com>
	<20140826105028.GK17528@sirena.org.uk>
	<87d2bmpwi2.wl%kuninori.morimoto.gx@gmail.com>
	<87a96qpqsy.wl%kuninori.morimoto.gx@gmail.com>
	<53FD95AB.6080903@metafoo.de>
	<87fvghihaq.wl%kuninori.morimoto.gx@gmail.com>
	<20140828080251.GG17528@sirena.org.uk>
	<87sikghohq.wl%kuninori.morimoto.gx@gmail.com>
Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Return-path: <devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
In-Reply-To: <87sikghohq.wl%kuninori.morimoto.gx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-ALSA <alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org>, Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>, Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Simon <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
List-Id: devicetree@vger.kernel.org


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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html