From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre-Louis Bossart Subject: Re: [v4,00/14] ASoC: Sound Open Firmware (SOF) core Date: Thu, 21 Feb 2019 17:49:16 -0600 Message-ID: References: <20190213220734.10471-1-pierre-louis.bossart@linux.intel.com> <1550520188-9253-1-git-send-email-xiaoxiang@xiaomi.com> <2ad7bf66-a0a9-b97d-e1b1-48e3f9c699c5@linaro.org> <20190221043925.GF2736@vkoul-mobl> <1af21f7e-1ea1-98a0-cf6d-74d0f4e5b186@st.com> <20190221112824.GC5970@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20190221112824.GC5970@sirena.org.uk> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" To: Mark Brown , Arnaud Pouliquen Cc: Daniel Baluta , Kumar Gala , "andriy.shevchenko@intel.com" , xiang xiao , "tiwai@suse.de" , "linux-remoteproc@vger.kernel.org" , "alsa-devel@alsa-project.org" , Bjorn Andersson , "liam.r.girdwood@linux.intel.com" , Vinod Koul , "wendy.liang@xilinx.com" , Srinivas Kandagatla , Xiang Xiao , Alan Cox , "sound-open-firmware@alsa-project.org" List-Id: alsa-devel@alsa-project.org >> Just for information... ST Microelectronics plans to port SOF to at >> least one of its platforms (based on ARM cores). Today, for the >> co-processor management we use the rpmsg and remoteproc frameworks on >> the Linux kernel side and OpenAMP on the remote processor side. We are >> therefore interested in xiang's work. >> An advantage we see in this generic solution is that compatibility >> between the Linux kernel frameworks and the OpenAMP library is ensured >> through discussions in the Linux and OpenAMP communities, involving >> maintainers and several vendors. Thanks Arnaud for sharing this information. You made my day.=A0 We've had = to deal with a number of hurdles related to platform and tools = availability, so it's good news indeed if there are more platforms = endorsing SOF. > This is a very good point, especially with people actually jumping on it > if we can avoid having multiple ABIs to worry about that would make life > a lot easier. We should at least figure out if it will be disruptive to > adapt it later on, even if Intel ends up continuing to use a custom > system integration. Yes indeed. At a high level we only have very generic send/receive IPC = messages, and it really shouldn't matter how the transport happens. However the actual contents/semantics of the messages do matter, and = I'll have to run a check to make sure it scales.