From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Koul Subject: Re: Question about struct snd_soc_dai() :: cpu_dai->codec Date: Fri, 29 Jul 2016 21:37:02 +0530 Message-ID: <20160729160702.GK9681@localhost> References: <20160727172125.GF9681@localhost> <20160727180456.GQ11806@sirena.org.uk> <20160727182233.GV11806@sirena.org.uk> <20160728034643.GH9681@localhost> <579A6C1B.2060904@metafoo.de> <579AA39B.5030100@sakamocchi.jp> <884bd15f-da5e-49f5-73ee-d8173dc0720a@metafoo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <884bd15f-da5e-49f5-73ee-d8173dc0720a@metafoo.de> Sender: linux-renesas-soc-owner@vger.kernel.org To: Lars-Peter Clausen Cc: Takashi Sakamoto , Takashi Iwai , Linux-ALSA , Kuninori Morimoto , Mark Brown , Liam Girdwood , linux-renesas-soc@vger.kernel.org, Simon List-Id: alsa-devel@alsa-project.org On Fri, Jul 29, 2016 at 11:07:49AM +0200, Lars-Peter Clausen wrote: > On 07/29/2016 02:30 AM, Takashi Sakamoto wrote: > > Lars, > > > > On Jul 29 2016 05:33, Lars-Peter Clausen wrote: > >> Hotplug is something that always pops up sooner or later. E.g. if someone > >> puts a ASoC supported CODEC on a hot-pluggable device (maybe USB) we > >> don't want to duplicate the code, but be able to reuse. > > > > (A bit to sidetrack) > > > > To me, it's unclear for devices on USB. When ALSA SoC part supports these > > devices, what is the scenario you assumed? In short, assuming we put codes > > to ALSA SoC part, what is the shape of the corresponding devices and links > > of pairs of endpoints? Additionally, in this case, what codes are able to be > > reused? > > Lets say you have USB stick with a small micro controller or FPGA which has > a USB interface on one side and a I2S and I2C interface on the other side. > The I2S and I2C are connected to a CODEC. I2S for data, I2C for control. If > the interface is implemented in a way so that it is just a simple USB to I2C > bridge, this means the raw I2C commands are send over the USB interface you > can implement a I2C adapter driver for this bridge. If you have that you can > instantiate the existing ASoC CODEC driver, which is a I2C device driver, on > the bus registered by the adapter. That still seems a bit fancy hardware :) If we can reasonably support this, I am for it. But not making stuff overtly complex... -- ~Vinod