[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e643b3be45d342adb331d5c07139b505@SFHDAG7NODE2.st.com>
Date: Fri, 22 Feb 2019 14:02:20 +0000
From: Loic PALLARDY <loic.pallardy@...com>
To: Christoph Hellwig <hch@....de>,
Stephen Rothwell <sfr@...b.auug.org.au>
CC: Bjorn Andersson <bjorn.andersson@...aro.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: linux-next: build failure after merge of the rpmsg tree
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@....de>
> Sent: vendredi 22 février 2019 13:51
> To: Stephen Rothwell <sfr@...b.auug.org.au>
> Cc: Bjorn Andersson <bjorn.andersson@...aro.org>; Christoph Hellwig
> <hch@....de>; Linux Next Mailing List <linux-next@...r.kernel.org>; Linux
> Kernel Mailing List <linux-kernel@...r.kernel.org>; Loic PALLARDY
> <loic.pallardy@...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.
Powered by blists - more mailing lists