From: Jason Gunthorpe
When using mmu_notifer_unregister_no_release() the caller must ensure
there is a SRCU synchronize before the mn memory is freed, otherwise use
after free races are possible, for instance:
CPU0 CPU1
From: Jason Gunthorpe
This is a significant simplification, it eliminates all the remaining
'hmm' stuff in mm_struct, eliminates krefing along the critical notifier
paths, and takes away all the ugly locking and abuse of page_table_lock.
mmu_notifier_get() provides the single struct hmm per
From: John Hubbard
Hi,
This consolidates everything into a "here's what's remaining for Andrew
to add to his tree (for now)" series:
* The first patch is an updated version of one that is already in the akpm tree.
* The next two patches are already in the akpm tree, included here for
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
> > +/**
> > + * drm_gem_ttm_mmap_offset() - Returns a GEM ttm object's mmap offset
> > + * @gbo: the GEM ttm object
> > + *
> > + * See drm_vma_node_offset_addr() for more information.
> > + *
> > + * Returns:
> > + * The buffer object's offset for userspace mappings on success, or
> > + * 0 if
On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote:
> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix wrote:
> >
> > On 2019-08-06 13:44, Jason Gunthorpe wrote:
> > > On Tue, Aug 06, 2019 at 07:05:53PM +0300, Christoph Hellwig wrote:
> > >> The option is just used to select HMM mirror
> > It's not obvious to me when it actually needs to be enabled. Besides the
> > errata, it's only when... device_nr=1 for a compute-only job in kbase?
> >
> > I'm afraid I don't know nearly enough about how kbase plumbs CL to grok
> > the signifiance...
>
> Figuring out the nr_core_groups was
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder
On Tue, Aug 06, 2019 at 06:33:10PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide
https://bugzilla.kernel.org/show_bug.cgi?id=203781
Steffen Schröter (stef...@vexar.de) changed:
What|Removed |Added
CC||stef...@vexar.de
Am 06.08.19 um 22:03 schrieb Jason Gunthorpe:
> On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote:
>> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix
>> wrote:
>>> On 2019-08-06 13:44, Jason Gunthorpe wrote:
On Tue, Aug 06, 2019 at 07:05:53PM +0300, Christoph Hellwig wrote:
>
On Tue, Aug 06, 2019 at 12:09:38PM -0700, Matthew Wilcox wrote:
> Has anyone looked at turning the interface inside-out? ie something like:
>
> struct mm_walk_state state = { .mm = mm, .start = start, .end = end, };
>
> for_each_page_range(, page) {
> ... do something
On Tue, Aug 06, 2019 at 11:50:42AM -0700, Linus Torvalds wrote:
>
> In fact, I do note that a lot of the users don't actually use the
> "void *private" argument at all - they just want the walker - and just
> pass in a NULL private pointer. So we have things like this:
>
> > + if
On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> Though personally I'm averse to managing "f"objects through
> "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> on the virtual address of a mapping, but the huge-or-not alignment of
> that mapping must have been
On Tue, Aug 06, 2019 at 09:23:51AM -0700, Rob Clark wrote:
> On Tue, Aug 6, 2019 at 8:50 AM Christoph Hellwig wrote:
> >
> > On Tue, Aug 06, 2019 at 07:11:41AM -0700, Rob Clark wrote:
> > > Agreed that drm_cflush_* isn't a great API. In this particular case
> > > (IIUC), I need wb+inv so that
DPI sample the data both rising and falling edge.
It can reduce half data io pins.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
The factor depends on the divider of DPI in MT8183, therefore,
we should fix this factor to the right and new one.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
Add decriptions about supported chips, including MT2701 & MT8173 &
mt8183
Signed-off-by: Jitao Shi
---
.../bindings/display/mediatek/mediatek,dpi.txt| 11 +++
1 file changed, 11 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
Changes since v4:
- move pin mode control and dual edge control to deveice tree.
- update dt-bindings document for pin mode swap and dual edge control.
Changes since v3:
- add dpi pin mode control when dpi on or off.
- update dpi dual edge comment.
Changes since v2:
- update dt-bindings
Pull dpi pins low when dpi has nothing to display. Aovid leakage
current from some dpi pins (Hsync Vsync DE ... ).
Some chips have dpi pins, but there are some chip don't have pins.
So this function is controlled by device tree.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c |
201 - 221 of 221 matches
Mail list logo
