From: Loic PALLARDY <loic.pallardy@st.com>
To: Christoph Hellwig <hch@lst.de>, Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: RE: linux-next: build failure after merge of the rpmsg tree
Date: Fri, 22 Feb 2019 14:02:20 +0000 [thread overview]
Message-ID: <e643b3be45d342adb331d5c07139b505@SFHDAG7NODE2.st.com> (raw)
In-Reply-To: <20190222125046.GB29125@lst.de>
Hi,
Changes in remoteproc have been introduced to associate dedicated dma coherent memory pool to each virtio device.
It is needed when we have several virtio devices for which buffers can't be allocated from the same memory region.
Patch introduces support in both ways:
- memory region declared thanks to reserved memory and associated thanks to of_reserved_mem_device_init_by_idx(): mainly used for regions located in DDR.
- memory region specified in rproc driver itself and defined as dma coherent thanks to dma_declare_coherent_memory(): These regions are generally located in coprocessor/SoC internal memories and declared in different ways by the different rproc drivers (regs in DT, hard coded values in drivers...).
For me, dma_declare_coherent_memory based solution is there to allow a smooth transition from current rproc drivers implementations to a cleaner and unified one based on reserved memory declaration.
Regards,
Loic
> -----Original Message-----
> From: Christoph Hellwig <hch@lst.de>
> Sent: vendredi 22 février 2019 13:51
> To: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>; Christoph Hellwig
> <hch@lst.de>; Linux Next Mailing List <linux-next@vger.kernel.org>; Linux
> Kernel Mailing List <linux-kernel@vger.kernel.org>; Loic PALLARDY
> <loic.pallardy@st.com>
> Subject: Re: linux-next: build failure after merge of the rpmsg tree
>
> FYI, can I please get an explanation for the remoteproc changes?
>
> We really should avoid adding new callers of
> dma_declare_coherent_memory,
> which is a rather badly designed interface.
next prev parent reply other threads:[~2019-02-22 14:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 5:18 linux-next: build failure after merge of the rpmsg tree Stephen Rothwell
2019-02-22 12:50 ` Christoph Hellwig
2019-02-22 14:02 ` Loic PALLARDY [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-01-27 7:02 Stephen Rothwell
2023-01-30 8:51 ` Joerg Roedel
2020-10-15 4:55 Stephen Rothwell
2018-04-26 3:33 Stephen Rothwell
2018-04-26 3:46 ` Bjorn Andersson
2017-08-31 6:54 Stephen Rothwell
2017-08-31 17:47 ` Bjorn Andersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e643b3be45d342adb331d5c07139b505@SFHDAG7NODE2.st.com \
--to=loic.pallardy@st.com \
--cc=bjorn.andersson@linaro.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).