On Tue, Nov 17, 2020 at 02:02:30PM +, Christoph Hellwig wrote:
> On Tue, Nov 17, 2020 at 03:00:32PM +0100, Arnaud POULIQUEN wrote:
> > The dma_declare_coherent_memory allows to associate vdev0buffer memory
> > region
> > to the remoteproc virtio device (vdev parent). This region is used to
>
On 11/16/20 5:39 PM, Christoph Hellwig wrote:
> Btw, I also still don't understand why remoteproc is using
> dma_declare_coherent_memory to start with. The virtio code has exactly
> one call to dma_alloc_coherent vring_alloc_queue, a function that
> already switches between two different alloca
On Tue, Nov 17, 2020 at 03:00:32PM +0100, Arnaud POULIQUEN wrote:
> The dma_declare_coherent_memory allows to associate vdev0buffer memory region
> to the remoteproc virtio device (vdev parent). This region is used to
> allocated
> the rpmsg buffers.
> The memory for the rpmsg buffer is allocated
From: Christoph Hellwig
Date: Mon, 16 Nov 2020 16:27:44 +
> On Mon, Nov 16, 2020 at 04:51:49AM -0500, Michael S. Tsirkin wrote:
>> On Mon, Nov 16, 2020 at 09:19:50AM +, Christoph Hellwig wrote:
>>> I just noticed this showing up in Linus' tree and I'm not happy.
>>>
>>> This whole model o
Btw, I also still don't understand why remoteproc is using
dma_declare_coherent_memory to start with. The virtio code has exactly
one call to dma_alloc_coherent vring_alloc_queue, a function that
already switches between two different allocators. Why can't we just
add a third allocator specifical
On Mon, Nov 16, 2020 at 01:07:28PM +, Alexander Lobakin wrote:
> But lots of subsystems like netdev for example uses dev->parent for
> DMA operations. I know that their pointers go directly to the
> platform/PCI/etc. device, but still.
Oh, every drivers is perfectly fine to use ->parent as it
On Mon, Nov 16, 2020 at 04:51:49AM -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 16, 2020 at 09:19:50AM +, Christoph Hellwig wrote:
> > I just noticed this showing up in Linus' tree and I'm not happy.
> >
> > This whole model of the DMA subdevices in remoteproc is simply broken.
> >
> > We r
On Mon, Nov 16, 2020 at 11:46:59AM +0100, Arnaud POULIQUEN wrote:
> Hi all,
>
> On 11/16/20 10:19 AM, Christoph Hellwig wrote:
> > I just noticed this showing up in Linus' tree and I'm not happy.
> >
> > This whole model of the DMA subdevices in remoteproc is simply broken.
> >
> > We really nee
On Mon, Nov 16, 2020 at 01:07:28PM +, Alexander Lobakin wrote:
> From: "Michael S. Tsirkin"
> Date: Mon, 16 Nov 2020 07:25:31 -0500
>
> > On Mon, Nov 16, 2020 at 09:19:50AM +, Christoph Hellwig wrote:
> >> I just noticed this showing up in Linus' tree and I'm not happy.
> >
> > Are you su
From: "Michael S. Tsirkin"
Date: Mon, 16 Nov 2020 07:25:31 -0500
> On Mon, Nov 16, 2020 at 09:19:50AM +, Christoph Hellwig wrote:
>> I just noticed this showing up in Linus' tree and I'm not happy.
>
> Are you sure? I think it's in next.
Nope, it goes to fixes since it just fixes the regress
On Mon, Nov 16, 2020 at 09:19:50AM +, Christoph Hellwig wrote:
> I just noticed this showing up in Linus' tree and I'm not happy.
Are you sure? I think it's in next.
> This whole model of the DMA subdevices in remoteproc is simply broken.
>
> We really need to change the virtio code pass an
Hi all,
On 11/16/20 10:19 AM, Christoph Hellwig wrote:
> I just noticed this showing up in Linus' tree and I'm not happy.
>
> This whole model of the DMA subdevices in remoteproc is simply broken.
>
> We really need to change the virtio code pass an expicit DMA device (
> similar to what e.g. th
On Mon, Nov 16, 2020 at 09:19:50AM +, Christoph Hellwig wrote:
> I just noticed this showing up in Linus' tree and I'm not happy.
>
> This whole model of the DMA subdevices in remoteproc is simply broken.
>
> We really need to change the virtio code pass an expicit DMA device (
> similar to w
I just noticed this showing up in Linus' tree and I'm not happy.
This whole model of the DMA subdevices in remoteproc is simply broken.
We really need to change the virtio code pass an expicit DMA device (
similar to what e.g. the USB and RDMA code does), instead of faking up
devices with broken
On 2020/11/5 下午8:22, Alexander Lobakin wrote:
From: Jason Wang
Date: Thu, 5 Nov 2020 11:10:24 +0800
Hi Jason,
On 2020/11/4 下午11:31, Alexander Lobakin wrote:
Since commit 086d08725d34 ("remoteproc: create vdev subdevice with
specific dma memory pool"), every remoteproc has a DMA subdevice
(
From: Jason Wang
Date: Thu, 5 Nov 2020 11:10:24 +0800
Hi Jason,
> On 2020/11/4 下午11:31, Alexander Lobakin wrote:
>> Since commit 086d08725d34 ("remoteproc: create vdev subdevice with
>> specific dma memory pool"), every remoteproc has a DMA subdevice
>> ("remoteprocX#vdevYbuffer") for each virti
On 2020/11/4 下午11:31, Alexander Lobakin wrote:
Since commit 086d08725d34 ("remoteproc: create vdev subdevice with
specific dma memory pool"), every remoteproc has a DMA subdevice
("remoteprocX#vdevYbuffer") for each virtio device, which inherits
DMA capabilities from the corresponding platform
On Wed, Nov 04, 2020 at 03:31:36PM +, Alexander Lobakin wrote:
> Since commit 086d08725d34 ("remoteproc: create vdev subdevice with
> specific dma memory pool"), every remoteproc has a DMA subdevice
> ("remoteprocX#vdevYbuffer") for each virtio device, which inherits
> DMA capabilities from the
Since commit 086d08725d34 ("remoteproc: create vdev subdevice with
specific dma memory pool"), every remoteproc has a DMA subdevice
("remoteprocX#vdevYbuffer") for each virtio device, which inherits
DMA capabilities from the corresponding platform device. This allowed
to associate different DMA poo
19 matches
Mail list logo
