linux-kernel - Re: Using remoteproc with ST-Ericsson modem.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK=WgbbxVhbw2fdPb=T5giKmu1Hb=CjvS0D1vaSG27Vr+33nNQ@mail.gmail.com>
Date:	Sun, 1 Apr 2012 09:15:55 +0300
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Sjur Brændeland <sjurbren@...il.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: Using remoteproc with ST-Ericsson modem.

Hi Sjur,

On Sun, Apr 1, 2012 at 12:25 AM, Sjur Brændeland <sjurbren@...il.com> wrote:
> Good stuff. One question from top of my mind: Have you considered
> option of using rpmsg without the protocol, eg something like
> RPMSG_RAW, where I can take advantage of rpmsg transport features
> without needing the muxing feature. Then I could use CAIF muxing layer
> without the rpmsg protocol and naming services....?

I think you may already be able to do so: the naming services are only
enabled when VIRTIO_RPMSG_F_NS is present. About the rest of the rpmsg
protocol - I think you can largely ignore it. Rpmsg drivers shouldn't
really care about it, they just need to use the send/receive API and
everything would just work.

> Another option is using virtio_console, but I realise virtio_console is doing
> normal kmalloc so memory handling in virtio_console would have to change
> then. (I have a memory addressing issue, so modem cannot access all
> kernel memory).

What's the limitation you have? only a certain range of addresses is
visible to the modem?

OMAP4 has a related problem: the memory that virtio_console allocates
isn't immediately visible to the OMAP4's remote processors, because it
isn't mapped in the relevant IOMMU. To fix this, we may need
virtio_console to start allocating its memory with the DMA API (but
we'll only start discussing it when the IOMMU-based DMA API will be
merged). I guess that something along these lines would work out for
you too ?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/