Hi
Am 05.11.20 um 11:07 schrieb Linus Walleij:
> Overall I like this, just an inline question:
>
> On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann wrote:
>
>> To do framebuffer updates, one needs memcpy from system memory and a
>> pointer-increment function. Add both interfaces with
On Thu, Nov 05, 2020 at 11:37:08AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.11.20 um 11:07 schrieb Linus Walleij:
> > Overall I like this, just an inline question:
> >
> > On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann
> > wrote:
> >
> >> To do framebuffer updates, one needs memcpy
Overall I like this, just an inline question:
On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
(...)
> +/**
> + * dma_buf_map_memcpy_to - Memcpy
Just a backport of the two patches for v5.9 that you'll want to apply.
The first one was Cc'd to stable, but I forgot to Cc the second one as
well.
Lyude Paul (2):
drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid()
drm/nouveau/kms/nv50-: Fix clock checking algorithm in
Ville also pointed out that I got a lot of the logic here wrong as well, whoops.
While I don't think anyone's likely using 3D output with nouveau, the next patch
will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get
rid of it and open-code it like before, while taking care
While I thought I had this correct (since it actually did reject modes
like I expected during testing), Ville Syrjala from Intel pointed out
that the logic here isn't correct. max_clock refers to the max data rate
supported by the DP encoder. So, limiting it to the output of ds_clock (which
refers
On 11/6/20 12:03 AM, Christoph Hellwig wrote:
I hate the extra pin count magic here. IMHO we really need to finish
off the series to get rid of the extra references on the ZONE_DEVICE
pages first.
First, thanks for the review comments.
I don't like the extra refcount either, that is why I
On 11/5/20 11:55 PM, Christoph Hellwig wrote:
On Thu, Nov 05, 2020 at 04:51:42PM -0800, Ralph Campbell wrote:
+extern void prep_transhuge_device_private_page(struct page *page);
No need for the extern.
Right, I was just copying the style.
Would you like to see a preparatory patch that
On 11/6/20 4:14 AM, Matthew Wilcox wrote:
On Thu, Nov 05, 2020 at 04:51:42PM -0800, Ralph Campbell wrote:
Add a helper function to allow device drivers to create device private
transparent huge pages. This is intended to help support device private
THP migrations.
I think you'd be better
On Fri, Nov 06, 2020 at 02:31:44PM +0100, Karol Herbst wrote:
> On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline wrote:
> >
> > Make use of the devm_drm_dev_alloc() API to bind the lifetime of
> > nouveau_drm structure to the drm_device. This is important because a
> > reference to nouveau_drm is
On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline wrote:
>
> Make use of the devm_drm_dev_alloc() API to bind the lifetime of
> nouveau_drm structure to the drm_device. This is important because a
> reference to nouveau_drm is accessible from drm_device, which is
> provided to a number of DRM layer
On Thu, Nov 05, 2020 at 04:51:42PM -0800, Ralph Campbell wrote:
> Add a helper function to allow device drivers to create device private
> transparent huge pages. This is intended to help support device private
> THP migrations.
I think you'd be better off with these calling conventions:
-void
I hate the extra pin count magic here. IMHO we really need to finish
off the series to get rid of the extra references on the ZONE_DEVICE
pages first.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +extern struct page *alloc_transhugepage(struct vm_area_struct *vma,
> + unsigned long addr);
No need for the extern. And also here: do we actually need the stub,
or can the caller make sure (using IS_ENABLED and
14 matches
Mail list logo
