On Thu, Feb 21, 2019 at 11:42:25AM +0100, Arnaud Pouliquen wrote: > On 2/21/19 5:39 AM, Vinod Koul wrote: > > On 19-02-19, 09:55, Pierre-Louis Bossart wrote: > >> On 2/19/19 9:09 AM, xiang xiao wrote: > > Rather than evolve the IPC, i would say it makes more sense that we > > "reuse" existing upstream frameworks.. As given below by xiang > > this seems to have support for RTOSes (see point 4 below) and looking at > > below it seems to have much better coverage across systems. > > This should also help in easy adoption of SoF for non Intel people... > > Also looking at it, lot of IPC code, DSP loading etc would go away > > making SoF code lesser in footprint. > > I think benefits outweigh the effort of porting to a framework which is > > already upstream and used on many platforms for different vendors! > 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. 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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
