On Thu, Sep 13, 2012 at 12:49:23AM +0200, Marcin Slusarz wrote:
> nv_object uses nv_assert, nv_assert uses nv_printk and nv_printk uses
> nv_object - which leads to recursion:
>
> drivers/gpu/drm/nouveau/core/include/core/object.h:31:1: sorry, unimplemented:
> inlining failed in call to ‘nv_object
On Fri, Sep 14, 2012 at 12:21:33AM +0200, Marcin Slusarz wrote:
> Otherwise my card (nv92) never resumes from suspend to ram, hanging on
> nv_mask in nv50_gpio_drive. Before rework, initialization was done only
> from POST, so this patch restores previous behaviour.
This patch would break the cold-
On Fri, Sep 14, 2012 at 01:45:18PM +0200, Marcin Slusarz wrote:
> On Fri, Sep 14, 2012 at 04:44:59PM +1000, Ben Skeggs wrote:
> > On Fri, Sep 14, 2012 at 12:21:33AM +0200, Marcin Slusarz wrote:
> > > Otherwise my card (nv92) never resumes from suspend to ram, hanging o
On Mon, Sep 17, 2012 at 01:15:24AM +0200, Marcin Slusarz wrote:
> On Fri, Sep 14, 2012 at 01:45:18PM +0200, Marcin Slusarz wrote:
> > On Fri, Sep 14, 2012 at 04:44:59PM +1000, Ben Skeggs wrote:
> > > On Fri, Sep 14, 2012 at 12:21:33AM +0200, Marcin Slusarz wrote:
> > >
On Tue, Sep 18, 2012 at 08:25:32PM +0400, Dmitry Eremin-Solenikov wrote:
> Hello,
>
> I saw in the "core" commit message that you worked on the nouveau core
> code in userspace. I'm currently digging into some old cards support and
> would benefit from not having to tickle with kernel/reboot/etc
On Sat, Sep 22, 2012 at 09:33:50PM +0400, Dmitry Eremin-Solenikov wrote:
> Fix typo introduced when converting to core infrastructure.
>
> Signed-off-by: Dmitry Eremin-Solenikov
Thanks, pushed! I'll likely squash this into the offending commit and
note your corrections in the commit log.
Ben.
On Tue, Sep 25, 2012 at 10:31:40AM +0400, Dmitry Eremin-Solenikov wrote:
> If nouveau_pm_perflvl_get() fails, pm->profiles list will be left
> uninitialized, which causes oops during nouveau_pm_fini().
>
> Move INIT_LIST_HEAD before call to nouveau_pm_perflvl_get().
Pushed, thanks!
>
> Signed-of
On Mon, Oct 08, 2012 at 12:49:31AM +0200, Marcin Slusarz wrote:
> Signed-off-by: Marcin Slusarz
> ---
> This patch relies on "drm/nouveau: remove >1 sclass support from
> nouveau_parent_create_".
>
> There are *many* *more* code paths without proper error handling -
This is *not* a bug. An obje
On Mon, Oct 08, 2012 at 12:49:30AM +0200, Marcin Slusarz wrote:
> It's unused (only one codepath passes sclass at all and it's always one),
> broken (overwrites the same field, leaking previous one) and confusing.
It's only *currently* unused, I have WIP code in branches that uses it,
otherwise it
On Mon, Oct 08, 2012 at 12:49:28AM +0200, Marcin Slusarz wrote:
> Signed-off-by: Marcin Slusarz
> ---
> drivers/gpu/drm/nouveau/core/core/parent.c | 2 ++
> drivers/gpu/drm/nouveau/core/include/core/parent.h | 3 +++
> 2 files changed, 5 insertions(+)
Feel free to just kill it completely.
On Tue, Oct 09, 2012 at 12:50:59AM +0200, Marcin Slusarz wrote:
> On Mon, Oct 08, 2012 at 11:05:33AM +1000, Ben Skeggs wrote:
> > On Mon, Oct 08, 2012 at 12:49:31AM +0200, Marcin Slusarz wrote:
> > > Signed-off-by: Marcin Slusarz
> > > ---
> > > This patch reli
On Tue, Oct 09, 2012 at 01:02:08AM +0200, Marcin Slusarz wrote:
> On Mon, Oct 08, 2012 at 11:06:46AM +1000, Ben Skeggs wrote:
> > On Mon, Oct 08, 2012 at 12:49:30AM +0200, Marcin Slusarz wrote:
> > > It's unused (only one codepath passes sclass at all and it's always on
On Fri, Oct 05, 2012 at 09:37:59PM +0200, Marcin Slusarz wrote:
> It's questionable use case, but weston/wayland already relies on this
> behaviour,
> and other drivers don't care about it, so it's a matter of compatibility.
> Without it, process invoking such page flip hangs in unkillable state,
On Tue, Oct 16, 2012 at 11:45:30PM +0200, Marcin Slusarz wrote:
> Signed-off-by: Marcin Slusarz
NACK on this one. I did ponder doing such a thing myself when I first
added the defines for the class names too, and decided against it as
this will (at some point) become a user-facing header, and I w
On Thu, Oct 11, 2012 at 11:53:09PM +0200, Marcin Slusarz wrote:
> Signed-off-by: Marcin Slusarz
> ---
> drivers/gpu/drm/nouveau/core/core/gpuobj.c | 6 +-
> drivers/gpu/drm/nouveau/core/include/core/gpuobj.h | 3 +++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/
On Mon, Oct 22, 2012 at 12:19:35AM +0200, Marcin Slusarz wrote:
> On Fri, Oct 19, 2012 at 04:05:14PM +1000, Ben Skeggs wrote:
> > On Thu, Oct 11, 2012 at 11:53:09PM +0200, Marcin Slusarz wrote:
> > > Signed-off-by: Marcin Slusarz
> > > ---
> > > driver
On Tue, Nov 06, 2012 at 10:48:52PM +0100, Marcin Slusarz wrote:
> Now it outputs:
> nouveau E[ PGRAPH][:02:00.0] PGRAPH TLB flush idle timeout fail
> nouveau E[ PGRAPH][:02:00.0] PGRAPH_STATUS: BUSY DISPATCH VFETCH
> CCACHE_UNK4 STRMOUT_GSCHED_UNK5 UNK14XX UNK1CXX CLIPID ZCULL ENG2D UNK3
ubc, class, mthd,
> + data);
> }
>
> if (nv_rd32(priv, 0x400824) & (1 << 31))
> diff --git a/drivers/gpu/drm/nouveau/core/include/core/client.h
> b/drivers/gpu/drm/nouveau/core/include/core/client.h
> index 0193532..8feba2f 10064
On Sun, Dec 09, 2012 at 12:26:42AM +0100, Marcin Slusarz wrote:
> On Fri, Dec 07, 2012 at 02:46:53PM +1000, Ben Skeggs wrote:
> > On Wed, Dec 05, 2012 at 11:56:22PM +0100, Marcin Slusarz wrote:
> > > Full piglit run with this patch:
> > > http://people.freedesktop.or
On Sun, Dec 09, 2012 at 12:04:54PM +0100, Marcin Slusarz wrote:
> On Sun, Dec 09, 2012 at 02:48:49PM +1000, Ben Skeggs wrote:
> > > > > diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c
> > > > > b/drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c
> &
On Thu, Dec 20, 2012 at 11:37:12PM +0100, Marcin Slusarz wrote:
> When hash collision occurs and it's near ramht object boundary, we could
> read and possibly overwrite some memory after ramht object.
>
> Signed-off-by: Marcin Slusarz
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/nouveau/
On Fri, Jan 04, 2013 at 06:39:13PM +0200, Aleksi Torhamo wrote:
> Fixes regression introduced in commit 70790f4f
> "drm/nouveau/clock: pull in the implementation from all over the place"
>
> When code was moved from nv50_crtc_set_clock to nvc0_clock_pll_set,
> the PLLs it is used for got limited t
On Mon, Jan 21, 2013 at 12:15:38AM +0100, Marcin Slusarz wrote:
> Keeping it in VRAM wastes CPU time, because cursor_set ioctl reads
> handed BO back to RAM, just to write it to actual cursor BO.
>
> Here (nv92/core i7), this patch decreases overall cpu usage of
> drmmode_load_cursor_argb from 4.6
On Mon, Feb 04, 2013 at 10:59:28PM +0100, Maarten Lankhorst wrote:
> Op 04-02-13 22:30, Marcin Slusarz schreef:
> > 1) Lockdep thinks all nouveau subdevs belong to the same class and can be
> > locked in arbitrary order, which is not true (at least in general case).
> > Tell it to distinguish subde
On Tue, 12 May 2020 at 09:06, Ilia Mirkin wrote:
>
> On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote:
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> > b/drivers/gpu/drm/nouveau/nouveau_connector.c
> > index 43bcbb6d73c4..6dae00da5d7e 100644
> > --- a/drivers/gpu/drm/nouveau/nouv
On Thu, 21 May 2020 at 07:05, Ralph Campbell wrote:
>
>
> On 5/20/20 12:20 PM, Jason Gunthorpe wrote:
> > On Wed, May 20, 2020 at 11:36:52AM -0700, Ralph Campbell wrote:
> >> When calling OpenCL clEnqueueSVMMigrateMem() on a region of memory that
> >> is backed by pte_none() or zero pages, migrate
On Sat, 30 May 2020 at 19:42, Dinghao Liu wrote:
>
> When gk20a_clk_ctor() returns an error code, pointer "clk"
> should be released. It's the same when gm20b_clk_new()
> returns from elsewhere following this call.
This shouldn't be necessary. If a subdev constructor fails, and
returns a pointer,
On Mon, 1 Jun 2020 at 13:27, wrote:
>
>
> Hi Ben,
>
> > > When gk20a_clk_ctor() returns an error code, pointer "clk"
> > > should be released. It's the same when gm20b_clk_new()
> > > returns from elsewhere following this call.
> > This shouldn't be necessary. If a subdev constructor fails, and
>
On Mon, 1 Jun 2020 at 13:37, Ben Skeggs wrote:
>
> On Mon, 1 Jun 2020 at 13:27, wrote:
> >
> >
> > Hi Ben,
> >
> > > > When gk20a_clk_ctor() returns an error code, pointer "clk"
> > > > should be released. It's the same wh
On Thu, 4 Jun 2020 at 01:43, Emil Velikov wrote:
>
> On Wed, 3 Jun 2020 at 15:20, Thierry Reding wrote:
> >
> > From: Thierry Reding
> >
> > Tegra firmware doesn't actually use any version numbers and passing -1
> > causes the existing firmware binaries not to be found. Use version 0 to
> > find
Thanks,
I've grabbed this, and the others of the same sort you sent out at the
same time.
Ben.
On Mon, 15 Jun 2020 at 17:29, Aditya Pakki wrote:
>
> nouveau_debugfs_strap_peek() calls pm_runtime_get_sync() that
> increments the reference count. In case of failure, decrement the
> ref count befo
On Tue, 23 Jun 2020 at 10:51, John Hubbard wrote:
>
> On 2020-06-22 16:38, Ralph Campbell wrote:
> > The patch to add zero page migration to GPU memory inadvertantly included
>
> inadvertently
>
> > part of a future change which broke normal page migration to GPU memory
> > by copying too much dat
On Thu, 25 Jun 2020 at 15:23, Ben Skeggs wrote:
>
> On Tue, 23 Jun 2020 at 10:51, John Hubbard wrote:
> >
> > On 2020-06-22 16:38, Ralph Campbell wrote:
> > > The patch to add zero page migration to GPU memory inadvertantly included
> >
> > inadvertently
Cc: sta...@vger.kernel.org
> Signed-off-by: Ralph Campbell
> Reviewed-by: Jason Gunthorpe
> ---
>
> This is based on Linux-5.8.0-rc2 and is for Ben Skeggs nouveau tree.
> It doesn't depend on any of the other nouveau/HMM changes I have
> recently posted.
>
> Resend
On Thu, 2 Jul 2020 at 08:54, Ralph Campbell wrote:
>
> The nvif_object_ioctl() method NVIF_VMM_V0_PFNMAP wasn't correctly
> setting the hardware specific GPU page table entries for 2MB sized
> pages. Fix this by adding functions to set and clear PD0 GPU page
> table entries.
I can take this one in
On Wed, 8 Jul 2020 at 03:31, Gustavo A. R. Silva wrote:
>
> Replace the existing /* fall through */ comments and its variants with
> the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
> fall-through markings when it is the case.
I really like this! I was not a fan of explicitly
On Sat, 18 Jul 2020 at 13:34, James Jones wrote:
>
> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
> family of modifiers to handle broken userspace
> Xorg modesetting and Mesa drivers. Existing Mesa
> drivers are still aware of only these older
> format modifiers which do not differentiate
> betw
On Wed, 29 Jul 2020 at 12:48, Dave Airlie wrote:
>
> On Tue, 28 Jul 2020 at 04:51, James Jones wrote:
> >
> > On 7/23/20 9:06 PM, Ben Skeggs wrote:
> > > On Sat, 18 Jul 2020 at 13:34, James Jones wrote:
> > >>
> > >> Accept the DRM_FORMAT_MOD
On Tue, 11 Aug 2020 at 07:18, Lyude Paul wrote:
>
> Just two CRC related fixes for the new CRC functionality in 5.9. One of
> these unbreaks CRC reporting on volta+, which accidentally got broken
> when converting over to nvidia's class headers. The other simply removes
> an unneeded CRC method ca
On Wed, 12 Aug 2020 at 06:05, Lyude Paul wrote:
>
> Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b
On Wed, 12 Aug 2020 at 06:06, Lyude Paul wrote:
>
> Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_
e.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
happen if the user plugs the dongle in before
> plugging something into the dongle.
>
> So, let's fix this by checking the sink count in both
> nouveau_dp_probe_dpcd() and nouveau_dp_irq(), and reprobing the
> connector if things change.
>
> Signed-off-by: Lyude Paul
Reviewed
On Tue, 25 Aug 2020 at 04:33, Lyude Paul wrote:
>
> Not entirely sure why this never came up when I originally tested this
> (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> appears to cause the display engine to throw an exception on driver
> init, at least on my ThinkPad
On Wed, 26 Aug 2020 at 02:52, Lyude Paul wrote:
>
> On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote:
> > On Tue, 25 Aug 2020 at 04:33, Lyude Paul wrote:
> > > Not entirely sure why this never came up when I originally tested this
> > > (maybe some BIOSes alr
;
> while (intr0 & 0x001f) {
> u32 chid = __ffs(intr0 & 0x001f) - 16;
> nv50_disp_intr_error(disp, chid);
> intr0 &= ~(0x0001 << chid);
> }
> ...
> }
>
> Could this be in any way related to this series of commi
On Wed, 2 Sep 2020 at 01:05, Christian König
wrote:
>
> We are trying to remove the io_lru handling and depend
> on zero init base, offset and addr here.
>
> v2: init addr as well
Looks like the issues I noticed in the previous version have been
dealt with, so, for the series:
R
On Wed, 2 Sep 2020 at 09:43, Lyude Paul wrote:
>
> Not entirely sure why this never came up when I originally tested this
> (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> appears to cause the display engine to throw an exception on driver
> init, at least on my ThinkPad P
On Tue, 1 Sep 2020 at 06:31, Ralph Campbell wrote:
>
> The user level OpenCL code shouldn't have to align start and end
> addresses to a page boundary. That is better handled in the nouveau
> driver. The npages field is also redundant since it can be computed
> from the start and end addresses.
>
On Sat, 5 Sep 2020 at 06:28, Lyude Paul wrote:
>
> Not entirely sure why this never came up when I originally tested this
> (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> appears to cause the display engine to throw an exception on driver
> init, at least on my ThinkPad P
On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote:
>
> Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
> new gp1xx temperature sensor") added support for reading finer-grain
> temperatures, but continued to report temperatures in 1 degree Celsius
> increments via nvkm_therm
On Thu, 10 Sep 2020 at 00:07, Jeremy Cline wrote:
>
> On Wed, Sep 09, 2020 at 10:22:14AM +0200, Karol Herbst wrote:
> > On Wed, Sep 9, 2020 at 6:06 AM Ben Skeggs wrote:
> > >
> > > On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote:
> > > >
> > &
e with atomic: With atomic the bo pinning and
> > > > actual modeset commit is completely separated in the code patsh.
> > > >
> > > > This annotation was originally added in
> > > >
> > > > commit 060810d7abaabcab282e062c595871d661561400
>
On Wed, 30 Sep 2020 at 19:37, Daniel Vetter wrote:
>
> On Wed, Sep 30, 2020 at 10:45:05AM +1000, Ben Skeggs wrote:
> > On Wed, 30 Sep 2020 at 00:52, Daniel Vetter wrote:
> > >
> > > On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter
> > > wrote:
> > >
On Wed, 7 Oct 2020 at 08:08, Karol Herbst wrote:
>
> we can't use nouveau_bo_ref here as no ttm object was allocated and
> nouveau_bo_ref mainly deals with that. Simply deallocate the object.
I suspect this was fallout from when that whole process was split into
stages, seems reasonable to me, app
; [ 18.785646] __kmalloc_track_caller+0x1be/0x390
> >>> [ 18.792165] kstrdup_const+0x46/0x70
> >>> [ 18.797686] kobject_set_name_vargs+0x2f/0xb0
> >>> [ 18.803992] kobject_init_and_add+0x9d/0xf0
> >>> [ 18.810117] ttm_mem_global_init+0x12c/0
I've merged all of these. Sent the first to 5.10-fixes for the
regression there, the rest will go in with a later -next pull request.
Thanks,
Ben.
On Sat, 14 Nov 2020 at 10:14, Lyude Paul wrote:
>
> It turns out that I forgot to go through and make sure that I converted all
> encoder callbacks
On Mon, 16 Nov 2020 at 05:19, Karol Herbst wrote:
>
> On Sun, Nov 15, 2020 at 6:43 PM Salvatore Bonaccorso
> wrote:
> >
> > Hi,
> >
> > On Fri, Aug 28, 2020 at 11:28:46AM +0200, Frantisek Hrbata wrote:
> > > Unprivileged user can crash kernel by using
> > > DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC
> > >
On Tue, 23 Mar 2021 at 17:03, Zou Wei wrote:
>
> Fix the following sparse warning:
>
> drivers/gpu/drm/nouveau/nvkm/core/client.c:64:1: warning: symbol
> 'nvkm_uclient_sclass' was not declared. Should it be static?
>
> Signed-off-by: Zou Wei
Applied, thanks.
> ---
> drivers/gpu/drm/nouveau/nvk
On Fri, 19 Mar 2021 at 09:04, Lyude Paul wrote:
>
> Found this while trying to make some changes to the kms_cursor_crc test.
> curs507a_acquire checks that the width and height of the cursor framebuffer
> are equal (asyw->image.{w,h}). This isn't entirely correct though, as the
> height of the cur
On Wed, 17 Mar 2021 at 19:51, ChunyouTang wrote:
>
> From: tangchunyou
>
> disable,delete disable and return 0
>
> Signed-off-by: tangchunyou
Thanks!
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/devinit/mcp89.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/g
On Mon, 8 Mar 2021 at 03:49, Ilia Mirkin wrote:
>
> The struct is giant, and triggers an order-7 allocation (512K). There is
> no reason for this to be kmalloc-type memory, so switch to vmalloc. This
> should help loading nouveau on low-memory and/or long-running systems.
>
> Reported-by: Nathan E
notifiers to revoke the atomic access. The original page table
> entries are then restored allowing CPU access to proceed.
>
> Signed-off-by: Alistair Popple
The Nouveau bits at least look good to me.
For patches 7/8:
Reviewed-by: Ben Skeggs
>
> ---
>
> v7:
> * Removed magic v
On Fri, 7 May 2021 at 00:50, Bjorn Helgaas wrote:
>
> [+cc Ben]
>
> Hi Marc,
>
> Thanks for paying attention to these things. I added Ben (who
> probably would see this via nouveau@lists.freedesktop.org anyway).
> I don't see a PCI issue here, but the nouveau timeout, which I know
> nothing about
On Thu, 2 Sept 2021 at 08:25, Karol Herbst wrote:
>
> On Wed, Sep 1, 2021 at 11:19 PM Przemo Firszt wrote:
> >
> > Hi,
> >
> > Can you advise if there is any work happening on NV174 / GA104 (market
> > name RTX 3070)? I checked the features matrix and searched the code of
> > kernel, mesa, libdrm
On Fri, 8 Oct 2021 at 07:46, Karol Herbst wrote:
>
> Reviewed-by: Karol Herbst
Reviewed-by: Ben Skeggs
>
> I haven't checked if other places need fixing up yet, and I still want
> to test this patch, but I won't get to it until Monday. But if
> everything is in
eeded assignment in the
> if condition.")
> Signed-off-by: Karol Herbst
Reviewed-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/
so it is way more
> straightforward to evaluate the latter directly instead of passing
> the handle produced by the former to acpi_bus_get_device().
>
> Modify nouveau_acpi_edid() accordingly (no intentional functional
> impact).
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Ben Sk
From: Ben Skeggs
The code which constructs the modules for each engine present on the GPU
passes -1 for 'instance' on non-instanced engines, which affects how the
name for a sub-device is generated. This is then stored as 'instance 0'
in nvkm_subdev.inst, so code can potent
of 1 in the HDMI Vendor
> InfoFrame when transmitting 4kp30.
>
> Signed-off-by: Hans Verkuil
> Fixes: 290ffeafcc1a (drm/nouveau/disp/gv100: initial support)
Reviewed-by: Ben Skeggs
> ---
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigv100.c
> b/drivers/gpu/drm/
InfoFrame correctly. Now displays that advertise RGB Selectable
> Quantization Range in their EDID will understand that full range is
> transmitted
> by the HDMI output. This is consistent to how the Nvidia's driver behaves.
>
> Signed-off-by: Hans Verkuil
Reviewed-by: Ben Skeggs
&g
ave push access to drm-misc
> (where changes are pushed to after landing in gitlab) and are known
> nouveau developers.
> We did this already for some trivial changes and critical bug fixes
> already, we just weren't thinking about updating the MAINTAINERS file.
>
> Cc: Ben Skeggs
From: Ben Skeggs
I've got HW now, appears to work as expected so far.
Signed-off-by: Ben Skeggs
---
.../gpu/drm/nouveau/nvkm/engine/device/base.c | 22 +++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gp
On Fri, 19 Nov 2021 at 00:14, Karol Herbst wrote:
>
> Cc: stable?
Yeah, that probably makes sense actually.
>
> On Thu, Nov 18, 2021 at 4:04 AM Ben Skeggs wrote:
> >
> > From: Ben Skeggs
> >
> > I've got HW now, appears to work as expected
On Thu, 18 Nov 2021 at 21:13, Dan Carpenter wrote:
>
> The nvkm_acr_lsfw_add() function never returns NULL. It returns error
> pointers on error.
>
> Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace
> "secure boot"")
> Signed-off-b
sch
>
> Thanks.
>
> >
> > Please also add a cc for linux-stable, so that this is fixed in 5.15.x
>
> Sure, but I still need some acked-by or rb from one of the Nouveau guys.
> So gentle ping on that.
Acked-by: Ben Skeggs
>
> Regards,
> Christian.
>
>
On Sat, 19 Mar 2022 at 04:11, Lyude Paul wrote:
>
> Whoops, sorry! I was unsure of the preference in name we should go with so I
> poked Ben on the side to ask them, but I can see they haven't yet responded.
> I'll poke thme again and see if I can get a response.
Yeah, please keep _prom as opposed
On Mon, 16 Jan 2023 at 22:27, Diogo Ivo wrote:
>
> On Mon, Jan 16, 2023 at 07:45:05AM +1000, David Airlie wrote:
> > On Thu, Dec 29, 2022 at 12:58 AM Diogo Ivo
> > wrote:
> > As a quick check can you try changing
> >
> > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:nvkm_firmware_mem_target
> > f
- first part of a rename
- later patches remove remaining usage
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_drv.h | 5 -
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
- removing nouveau_drm.master, and will transition to these
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 25 -
drivers/gpu/drm/nouveau/nouveau_drv.h | 3 +++
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau
- zero reason to do otherwise
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 3 +--
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 ---
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +-
drivers/gpu/drm
- both of these are stored in nouveau_cli already
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c | 17 +
drivers/gpu/drm/nouveau/nouveau_chan.h | 3 ++-
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 ++--
4
e independently.
After all classes have been ported, some final cleanups are made to
the DRM driver to complete the series.
Ben Skeggs (156):
drm/nouveau: add nouveau_drm.device/mmu
drm/nouveau: alias nouveau_drm.client to nouveau_drm.cli
drm/nouveau: pass drm to nouveau_mem_new(), instead of cl
- preparation for upcoming api changes
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 91 +--
drivers/gpu/drm/nouveau/nouveau_drv.h | 3 +-
drivers/gpu/drm/nouveau/nouveau_mem.c | 20 +++---
3 files changed, 56 insertions(+), 58 deletions(-)
diff
- probably a touch safer...
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
- can be accessed via chan->cli->drm
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo0039.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c
- not required for anything
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 3 +--
drivers/gpu/drm/nouveau/nouveau_chan.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
- these only operate on drm.master these days, not per-client
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_mem.c | 20 ++--
drivers/gpu/drm/nouveau/nouveau_mem.h | 4 ++--
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 2 +-
drivers/gpu/drm/nouveau
- removes the need for a nvkm_device_find(), which is going away
- will be needed later when cleaning up nvif_driver init
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 13 +
drivers/gpu/drm/nouveau/nouveau_drv.h | 1 +
2 files changed, 6 insertions(+), 8
- removes some dubious void casts
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 9 +
drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 +
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau
- hasn't been needed since 2015...
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.h
b/drivers/gpu/drm/nouveau/nouveau_abi16.h
index 4743459ea14c..af6b4e1cefd2 100644
--- a/dr
- left-overs from the past
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ---
drivers/gpu/drm/nouveau/dispnv50/disp.h | 9 -
2 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
- not used anymore other than device info, use drm->device instead
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 24 ++--
drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 -
2 files changed, 2 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/
HW isn't touched anymore (aside from detection) until the first
nvif_device has been allocated, so we no longer need a separate
probe-only step before kicking efifb (etc) off the HW.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 11 ++-
1 file chang
AL
to userspace for everything else.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/Kbuild | 1 -
drivers/gpu/drm/nouveau/nouveau_abi16.c | 277
drivers/gpu/drm/nouveau/nouveau_abi16.h | 3 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +-
drivers/gp
- rd/wr apis are being removed, require device to be mapped
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 5 -
drivers/gpu/drm/nouveau/include/nvif/device.h | 1 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +
drivers/gpu/drm/nouveau/nvif
- will help later in the series where display channel apis are modified
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 35 +++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ---
drivers/gpu/drm/nouveau/include/nvif/push.h | 12 +--
3 files
- the struct itself lives in nouveau_channel already, just use that
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +--
drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 +--
drivers/gpu/drm/nouveau/nouveau_bo5039.c | 4 +--
drivers/gpu/drm/nouveau/nouveau_bo74c1.c
- now unused
Signed-off-by: Ben Skeggs
---
.../gpu/drm/nouveau/include/nvkm/core/pci.h | 1 -
.../gpu/drm/nouveau/include/nvkm/core/tegra.h | 1 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 6 +-
.../gpu/drm/nouveau/nvkm/engine/device/base.c | 422 +-
.../gpu/drm
- just use the struct itself
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 18 +--
drivers/gpu/drm/nouveau/dispnv50/base827c.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/base907c.c | 10 +++---
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 6 ++--
drivers
101 - 200 of 1240 matches
Mail list logo
