On Fri, Aug 16, 2019 at 06:44:48AM +0200, Christoph Hellwig wrote:
> On Fri, Aug 16, 2019 at 12:43:07AM +, Jason Gunthorpe wrote:
> > On Thu, Aug 15, 2019 at 04:51:33PM -0400, Jerome Glisse wrote:
> >
> > > struct page. In this case any way we can update the
> > > nouveau_dmem_page() to check
On Fri, Aug 16, 2019 at 12:30:41PM +, Jason Gunthorpe wrote:
>
> For instance, a system may have multiple DEVICE_PRIVATE map's owned by
> the same driver - but multiple physical devices using that driver.
>
> Each physical device's driver should only ever get DEVICE_PRIVATE
> pages for it's
On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote:
> On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote:
> > Hello
> >
> > Since lot of release (at least since 4.19), I hit the following error
> > message:
> > DMA-API: cacheline tracking ENOMEM, dma-debug disabled
> >
>
On Wed, Aug 14, 2019 at 09:59:28AM +0200, Christoph Hellwig wrote:
> CONFIG_MIGRATE_VMA_HELPER guards helpers that are required for proper
> devic private memory support. Remove the option and just check for
> CONFIG_DEVICE_PRIVATE instead.
>
> Signed-off-by: Christoph Hellwig
> ---
>
On Thu, Aug 15, 2019 at 08:54:46PM -0700, Dan Williams wrote:
> > However, this means we cannot do any processing of ZONE_DEVICE pages
> > outside the driver lock, so eg, doing any DMA map that might rely on
> > MEMORY_DEVICE_PCI_P2PDMA has to be done in the driver lock, which is
> > a bit
On Fri, Aug 16, 2019 at 08:51:41AM +0200, Christoph Hellwig wrote:
> Jason,
>
> are you going to look into picking this up? Unfortunately there is
> a hole pile in this area still pending, including the kvmppc secure
> memory driver from Bharata that depends on the work.
>
> mm folks:
On Wed, Aug 14, 2019 at 09:59:27AM +0200, Christoph Hellwig wrote:
> No one ever checks this flag, and we could easily get that information
> from the page if needed.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Ralph Campbell
> ---
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +--
>
On Wed, Aug 14, 2019 at 09:59:19AM +0200, Christoph Hellwig wrote:
> There isn't any good reason to pass callbacks to migrate_vma. Instead
> we can just export the three steps done by this function to drivers and
> let them sequence the operation without callbacks. This removes a lot
> of
On Wed, Aug 14, 2019 at 09:59:18AM +0200, Christoph Hellwig wrote:
> Hi Jérôme, Ben and Jason,
>
> below is a series against the hmm tree which starts revamping the
> migrate_vma functionality. The prime idea is to export three slightly
> lower level functions and thus avoid the need for
On Fri, Aug 16, 2019 at 08:51:41AM +0200, Christoph Hellwig wrote:
> Jason,
>
> are you going to look into picking this up? Unfortunately there is
> a hole pile in this area still pending, including the kvmppc secure
> memory driver from Bharata that depends on the work.
Done,
Lets see if Dan
On Fri, Aug 16, 2019 at 5:24 AM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 08:54:46PM -0700, Dan Williams wrote:
>
> > > However, this means we cannot do any processing of ZONE_DEVICE pages
> > > outside the driver lock, so eg, doing any DMA map that might rely on
> > >
On Fri, Aug 16, 2019 at 4:31 PM Corentin Labbe
wrote:
> On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote:
> > > Hello
> > >
> > > Since lot of release (at least since 4.19), I hit the following error
> > > message:
On Fri, Aug 16, 2019 at 10:21:41AM -0700, Dan Williams wrote:
> > We can do a get_dev_pagemap inside the page_walk and touch the pgmap,
> > or we can do the 'device mutex && retry' pattern and touch the pgmap
> > in the driver, under that lock.
> >
> > However in all cases the current
Jason,
are you going to look into picking this up? Unfortunately there is
a hole pile in this area still pending, including the kvmppc secure
memory driver from Bharata that depends on the work.
mm folks: migrate.c is mostly a classic MM file except for the hmm
additions. Do you want to also
On Mon, Aug 12, 2019 at 12:42:30PM -0700, Ralph Campbell wrote:
>
> On 8/10/19 4:13 AM, Christoph Hellwig wrote:
>> On something vaguely related to this patch:
>>
>> You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are
>> a little odd as we only ever set these bits, but they
From: Dhinakaran Pandiyan
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
Also removing the
On Mon, Aug 05, 2019 at 04:01:10PM +0200, Gerd Hoffmann wrote:
> Drop vma_node from ttm_buffer_object, use the gem struct
> (base.vma_node) instead.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
>
On Fri, 2019-08-16 at 21:29 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/connector: Allow max possible encoders to attach to a
> connector (rev2)
> URL : https://patchwork.freedesktop.org/series/62743/
> State : warning
>
> == Summary ==
>
> $ dim sparse origin/drm-tip
>
On 8/16/19 10:28 AM, Jason Gunthorpe wrote:
On Fri, Aug 16, 2019 at 10:21:41AM -0700, Dan Williams wrote:
We can do a get_dev_pagemap inside the page_walk and touch the pgmap,
or we can do the 'device mutex && retry' pattern and touch the pgmap
in the driver, under that lock.
However in all
On Fri, Aug 16, 2019 at 5:11 PM Christoph Hellwig wrote:
>
> On Mon, Aug 12, 2019 at 12:42:30PM -0700, Ralph Campbell wrote:
> >
> > On 8/10/19 4:13 AM, Christoph Hellwig wrote:
> >> On something vaguely related to this patch:
> >>
> >> You use the NVIF_VMM_PFNMAP_V0_V* defines from
20 matches
Mail list logo
