Re: [PATCH] drm/nouveau/nvkm/dp: Add hack to fix DP 1.3+ DPCD issues

2023-07-18 Thread Ben Skeggs
On Sat, 8 Jul 2023 at 07:59, Lyude Paul  wrote:
>
> Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of
> nouveau in order to read the DPCD of a DP connector, which makes sure we do
> the right thing and also check for extended DPCD caps. However, it turns
> out we're not currently doing this on the nvkm side since we don't have
> access to the drm_dp_aux structure there - which means that the DRM side of
> the driver and the NVKM side can end up with different DPCD capabilities
> for the same connector.
>
> Ideally to fix this, we want to start setting up the drm_dp_aux device in
> NVKM before we've made contact with the DRM side - which should be pretty
> easy to accomplish (I'm already working on it!). Until then however, let's
> workaround this problem by porting a copy of drm_dp_read_dpcd_caps() into
> NVKM - which should fix this issue.
I wouldn't worry about this.  I'm moving basically everything to the
DRM side of the driver for the GSP work anyway.

Ben.
>
> Issue: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 48 ++-
>  1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> index 40c8ea43c42f..b8ac66b4a2c4 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> @@ -26,6 +26,8 @@
>  #include "head.h"
>  #include "ior.h"
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -634,6 +636,50 @@ nvkm_dp_enable_supported_link_rates(struct nvkm_outp 
> *outp)
> return outp->dp.rates != 0;
>  }
>
> +/* XXX: This is a big fat hack, and this is just drm_dp_read_dpcd_caps()
> + * converted to work inside nvkm. This is a temporary holdover until we start
> + * passing the drm_dp_aux device through NVKM
> + */
> +static int
> +nvkm_dp_read_dpcd_caps(struct nvkm_outp *outp)
> +{
> +   struct nvkm_i2c_aux *aux = outp->dp.aux;
> +   u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> +   int ret;
> +
> +   ret = nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd, 
> DP_RECEIVER_CAP_SIZE);
> +   if (ret < 0)
> +   return ret;
> +
> +   /*
> +* Prior to DP1.3 the bit represented by
> +* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
> +* If it is set DP_DPCD_REV at h could be at a value less than
> +* the true capability of the panel. The only way to check is to
> +* then compare h and 2200h.
> +*/
> +   if (!(outp->dp.dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
> +   return 0;
> +
> +   ret = nvkm_rdaux(aux, DP_DP13_DPCD_REV, dpcd_ext, sizeof(dpcd_ext));
> +   if (ret < 0)
> +   return ret;
> +
> +   if (outp->dp.dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV]) {
> +   OUTP_DBG(outp, "Extended DPCD rev less than base DPCD rev (%d 
> > %d)\n",
> +outp->dp.dpcd[DP_DPCD_REV], dpcd_ext[DP_DPCD_REV]);
> +   return 0;
> +   }
> +
> +   if (!memcmp(outp->dp.dpcd, dpcd_ext, sizeof(dpcd_ext)))
> +   return 0;
> +
> +   memcpy(outp->dp.dpcd, dpcd_ext, sizeof(dpcd_ext));
> +
> +   return 0;
> +}
> +
>  void
>  nvkm_dp_enable(struct nvkm_outp *outp, bool auxpwr)
>  {
> @@ -689,7 +735,7 @@ nvkm_dp_enable(struct nvkm_outp *outp, bool auxpwr)
> memset(outp->dp.lttpr, 0x00, sizeof(outp->dp.lttpr));
> }
>
> -   if (!nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd, 
> sizeof(outp->dp.dpcd))) {
> +   if (!nvkm_dp_read_dpcd_caps(outp)) {
> const u8 rates[] = { 0x1e, 0x14, 0x0a, 0x06, 0 };
> const u8 *rate;
> int rate_max;
> --
> 2.40.1
>


Re: [Nouveau] [PATCH v2] drm/nouveau: bring back blit subchannel for pre nv50 GPUs

2023-07-12 Thread Ben Skeggs
On Fri, 26 May 2023 at 19:11, Karol Herbst  wrote:
>
> 1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128
> was important as otherwise the GPU spams us with `CACHE_ERROR` messages.
>
> We use the blit subchannel inside our vblank handling, so we should keep
> at least this part.
>
> v2: Only do it for NV11+ GPUs
>
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201
> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> Signed-off-by: Karol Herbst 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nouveau_chan.c |  1 +
>  drivers/gpu/drm/nouveau/nouveau_chan.h |  1 +
>  drivers/gpu/drm/nouveau/nouveau_drm.c  | 20 +---
>  3 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
> b/drivers/gpu/drm/nouveau/nouveau_chan.c
> index e648ecd0c1a0..3dfbc374478e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_chan.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
> @@ -90,6 +90,7 @@ nouveau_channel_del(struct nouveau_channel **pchan)
> if (cli)
> nouveau_svmm_part(chan->vmm->svmm, chan->inst);
>
> +   nvif_object_dtor(>blit);
> nvif_object_dtor(>nvsw);
> nvif_object_dtor(>gart);
> nvif_object_dtor(>vram);
> diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h 
> b/drivers/gpu/drm/nouveau/nouveau_chan.h
> index e06a8ffed31a..bad7466bd0d5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_chan.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
> @@ -53,6 +53,7 @@ struct nouveau_channel {
> u32 user_put;
>
> struct nvif_object user;
> +   struct nvif_object blit;
>
> struct nvif_event kill;
> atomic_t killed;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index cc7c5b4a05fd..9512f1c2f871 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -369,15 +369,29 @@ nouveau_accel_gr_init(struct nouveau_drm *drm)
> ret = nvif_object_ctor(>channel->user, "drmNvsw",
>NVDRM_NVSW, nouveau_abi16_swclass(drm),
>NULL, 0, >channel->nvsw);
> +
> +   if (ret == 0 && device->info.chipset >= 0x11) {
> +   ret = nvif_object_ctor(>channel->user, "drmBlit",
> +  0x005f, 0x009f,
> +  NULL, 0, >channel->blit);
> +   }
> +
> if (ret == 0) {
> struct nvif_push *push = drm->channel->chan.push;
> -   ret = PUSH_WAIT(push, 2);
> -   if (ret == 0)
> +   ret = PUSH_WAIT(push, 8);
> +   if (ret == 0) {
> +   if (device->info.chipset >= 0x11) {
> +   PUSH_NVSQ(push, NV05F, 0x, 
> drm->channel->blit.handle);
> +   PUSH_NVSQ(push, NV09F, 0x0120, 0,
> +  0x0124, 1,
> +  0x0128, 2);
> +   }
> PUSH_NVSQ(push, NV_SW, 0x, 
> drm->channel->nvsw.handle);
> +   }
> }
>
> if (ret) {
> -   NV_ERROR(drm, "failed to allocate sw class, %d\n", 
> ret);
> +   NV_ERROR(drm, "failed to allocate sw or blit class, 
> %d\n", ret);
> nouveau_accel_gr_fini(drm);
> return;
> }
> --
> 2.40.1
>


Re: [Nouveau] [PATCH] drm/nouveau/acr: Abort loading ACR if no firmware was found

2023-07-12 Thread Ben Skeggs
On Thu, 13 Jul 2023 at 05:31, Dave Airlie  wrote:
>
> On Tue, 23 May 2023 at 19:37, Karol Herbst  wrote:
> >
> > On Mon, May 22, 2023 at 10:18 PM Karol Herbst  wrote:
> > >
> > > This fixes a NULL pointer access inside nvkm_acr_oneinit in case necessary
> > > firmware files couldn't be loaded.
> > >
> > > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/212
> > > Fixes: 4b569ded09fd ("drm/nouveau/acr/ga102: initial support")
> > > Signed-off-by: Karol Herbst 
> > > ---
> > >  drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c 
> > > b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
> > > index 795f3a649b12..6388234c352c 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
> > > @@ -224,7 +224,7 @@ nvkm_acr_oneinit(struct nvkm_subdev *subdev)
> > > u64 falcons;
> > > int ret, i;
> > >
> > > -   if (list_empty(>hsfw)) {
> > > +   if (list_empty(>hsfw) || !acr->func->wpr_layout) {
> >
> > Now thinking about this, it should probably also check acr->func...
>
> with that fixed if you think you need it,
I don't *think* you do.  I believe modprobe will fail for any case it
can be NULL.

>
> Reviewed-by: Dave Airlie 
>
> >
> > > nvkm_debug(subdev, "No HSFW(s)\n");
> > > nvkm_acr_cleanup(acr);
> > > return 0;
> > > --
> > > 2.40.1
> > >
> >


Re: [PATCH] drm/nouveau/fb: add missing sysmen flush callbacks

2023-04-10 Thread Ben Skeggs
On Wed, 5 Apr 2023 at 21:05, Karol Herbst  wrote:
>
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/203
> Fixes: 5728d064190e1 ("drm/nouveau/fb: handle sysmem flush page from common 
> code")
> Signed-off-by: Karol Herbst 
Oops, that must've gotten lost in a rebase somehow.

Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c | 1 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c | 1 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c | 1 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c | 1 +
>  4 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c
> index 76678dd60f93f..c4c6f67af7ccc 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c
> @@ -31,6 +31,7 @@ gf108_fb = {
> .init = gf100_fb_init,
> .init_page = gf100_fb_init_page,
> .intr = gf100_fb_intr,
> +   .sysmem.flush_page_init = gf100_fb_sysmem_flush_page_init,
> .ram_new = gf108_ram_new,
> .default_bigpage = 17,
>  };
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c
> index f73442ccb424b..433fa966ba231 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c
> @@ -77,6 +77,7 @@ gk104_fb = {
> .init = gf100_fb_init,
> .init_page = gf100_fb_init_page,
> .intr = gf100_fb_intr,
> +   .sysmem.flush_page_init = gf100_fb_sysmem_flush_page_init,
> .ram_new = gk104_ram_new,
> .default_bigpage = 17,
> .clkgate_pack = gk104_fb_clkgate_pack,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
> index 45d6cdffafeed..4dc283dedf8b5 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
> @@ -59,6 +59,7 @@ gk110_fb = {
> .init = gf100_fb_init,
> .init_page = gf100_fb_init_page,
> .intr = gf100_fb_intr,
> +   .sysmem.flush_page_init = gf100_fb_sysmem_flush_page_init,
> .ram_new = gk104_ram_new,
> .default_bigpage = 17,
> .clkgate_pack = gk110_fb_clkgate_pack,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c
> index de52462a92bf0..90bfff616d35b 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c
> @@ -31,6 +31,7 @@ gm107_fb = {
> .init = gf100_fb_init,
> .init_page = gf100_fb_init_page,
> .intr = gf100_fb_intr,
> +   .sysmem.flush_page_init = gf100_fb_sysmem_flush_page_init,
> .ram_new = gm107_ram_new,
> .default_bigpage = 17,
>  };
> --
> 2.39.2
>


Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

2023-02-20 Thread Ben Skeggs
On Mon, 20 Feb 2023 at 21:27, Karol Herbst  wrote:
>
> On Mon, Feb 20, 2023 at 11:51 AM Chris Clayton  
> wrote:
> >
> >
> >
> > On 20/02/2023 05:35, Ben Skeggs wrote:
> > > On Sun, 19 Feb 2023 at 04:55, Chris Clayton  
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 18/02/2023 15:19, Chris Clayton wrote:
> > >>>
> > >>>
> > >>> On 18/02/2023 12:25, Karol Herbst wrote:
> > >>>> On Sat, Feb 18, 2023 at 1:22 PM Chris Clayton 
> > >>>>  wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 15/02/2023 11:09, Karol Herbst wrote:
> > >>>>>> On Wed, Feb 15, 2023 at 11:36 AM Linux regression tracking #update
> > >>>>>> (Thorsten Leemhuis)  wrote:
> > >>>>>>>
> > >>>>>>> On 13.02.23 10:14, Chris Clayton wrote:
> > >>>>>>>> On 13/02/2023 02:57, Dave Airlie wrote:
> > >>>>>>>>> On Sun, 12 Feb 2023 at 00:43, Chris Clayton 
> > >>>>>>>>>  wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On 10/02/2023 19:33, Linux regression tracking (Thorsten 
> > >>>>>>>>>> Leemhuis) wrote:
> > >>>>>>>>>>> On 10.02.23 20:01, Karol Herbst wrote:
> > >>>>>>>>>>>> On Fri, Feb 10, 2023 at 7:35 PM Linux regression tracking 
> > >>>>>>>>>>>> (Thorsten
> > >>>>>>>>>>>> Leemhuis)  wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On 08.02.23 09:48, Chris Clayton wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I'm assuming  that we are not going to see a fix for this 
> > >>>>>>>>>>>>>> regression before 6.2 is released.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Yeah, looks like it. That's unfortunate, but happens. But 
> > >>>>>>>>>>>>> there is still
> > >>>>>>>>>>>>> time to fix it and there is one thing I wonder:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Did any of the nouveau developers look at the netconsole 
> > >>>>>>>>>>>>> captures Chris
> > >>>>>>>>>>>>> posted more than a week ago to check if they somehow help to 
> > >>>>>>>>>>>>> track down
> > >>>>>>>>>>>>> the root of this problem?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I did now and I can't spot anything. I think at this point it 
> > >>>>>>>>>>>> would
> > >>>>>>>>>>>> make sense to dump the active tasks/threads via sqsrq keys to 
> > >>>>>>>>>>>> see if
> > >>>>>>>>>>>> any is in a weird state preventing the machine from shutting 
> > >>>>>>>>>>>> down.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Many thx for looking into it!
> > >>>>>>>>>>
> > >>>>>>>>>> Yes, thanks Karol.
> > >>>>>>>>>>
> > >>>>>>>>>> Attached is the output from dmesg when this block of code:
> > >>>>>>>>>>
> > >>>>>>>>>> /bin/mount /dev/sda7 /mnt/sda7
> > >>>>>>>>>> /bin/mountpoint /proc || /bin/mount /proc
> > >>>>>>>>>> /bin/dmesg -w > /mnt/sda7/sysrq.dmesg.log &
> > >>>>>>>>>> /bin/echo t > /proc/sysrq-trigger
> > >>>>>>>>>> /bin/sleep 1
> > >>>>>>>>>>  

Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

2023-02-19 Thread Ben Skeggs
ion. :-/ I don't
> >>>>> really like it, but for regression tracking I'm now putting this on the
> >>>>> back-burner, as a fix is not in sight.
> >>>>>
> >>>>> #regzbot monitor:
> >>>>> https://lore.kernel.org/lkml/e0b80506-b3cf-315b-4327-1b988d860...@googlemail.com/
> >>>>> #regzbot backburner: hard to debug and apparently rare
> >>>>> #regzbot ignore-activity
> >>>>>
> >>>>
> >>>> yeah.. this bug looks a little annoying. Sadly the only Turing based
> >>>> laptop I got doesn't work on Nouveau because of firmware related
> >>>> issues and we probably need to get updated ones from Nvidia here :(
> >>>>
> >>>> But it's a bit weird that the kernel doesn't shutdown, because I don't
> >>>> see anything in the logs which would prevent that from happening.
> >>>> Unless it's waiting on one of the tasks to complete, but none of them
> >>>> looked in any way nouveau related.
> >>>>
> >>>> If somebody else has any fancy kernel debugging tips here to figure
> >>>> out why it hangs, that would be very helpful...
> >>>>
> >>>
> >>> I think I've figured this out. It's to do with how my system is 
> >>> configured. I do have an initrd, but the only thing on
> >>> it is the cpu microcode which, it is recommended, should be loaded early. 
> >>> The absence of the NVidia firmare from an
> >>> initrd doesn't matter because the drivers for the hardware that need to 
> >>> load firmware are all built as modules, So, by
> >>> the time the devices are configured via udev, the root partition is 
> >>> mounted and the drivers can get at the firmware.
> >>>
> >>> I've found, by turning on nouveau debug and taking a video of the screen 
> >>> as the system shuts down, that nouveau seems to
> >>> be trying to run the scrubber very very late in the shutdown process. The 
> >>> problem is that by this time, I think the root
> >>> partition, and thus the scrubber binary, have become inaccessible.
> >>>
> >>> I seem to have two choices - either make the firmware accessible on an 
> >>> initrd or unload the module in a shutdown script
> >>> before the scrubber binary becomes inaccessible. The latter of these is 
> >>> the workaround I have implemented whilst the
> >>> problem I reported has been under investigation. For simplicity, I think 
> >>> I'll promote my workaround to being the
> >>> permanent solution.
> >>>
> >>> So, apologies (and thanks) to everyone whose time I have taken up with 
> >>> this non-bug.
> >>>
> >>
> >> Well.. nouveau shouldn't prevent the system from shutting down if the
> >> firmware file isn't available. Or at least it should print a
> >> warning/error. Mind messing with the code a little to see if skipping
> >> it kind of works? I probably can also come up with a patch by next
> >> week.
> >>
> > Well, I'd love to but a quick glance at the code caused me to bump into 
> > this obscenity:
> >
> > int
> > gm200_flcn_reset_wait_mem_scrubbing(struct nvkm_falcon *falcon)
> > {
> > nvkm_falcon_mask(falcon, 0x040, 0x, 0x);
> >
> > if (nvkm_msec(falcon->owner->device, 10,
> > if (!(nvkm_falcon_rd32(falcon, 0x10c) & 0x0006))
> > break;
> > ) < 0)
> > return -ETIMEDOUT;
> >
> > return 0;
> > }
> >
> > nvkm_msec is #defined to nvkm_usec which in turn is #defined to nvkm_nsec 
> > where the loop that the break is related to
> > appears
>
> I think someone who knows the code needs to look at this. What I can confirm 
> is that after a freeze, I waited for 90
> seconds for a timeout to occur, but it didn't.
Hey,

Are you able to try the attached patch for me please?

Thanks,
Ben.

>
>
> .> Chris
> >>>
> >>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >>>>> --
> >>>>> Everything you wanna know about Linux kernel regression tracking:
> >>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> >>>>> That page also explains what to do if mails like this annoy you.
> >>>>>
> >>>>> #regzbot 

Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

2023-01-30 Thread Ben Skeggs
On Tue, 31 Jan 2023 at 09:09, Chris Clayton  wrote:
>
> Hi again.
>
> On 30/01/2023 20:19, Chris Clayton wrote:
> > Thanks, Ben.
>
> 
>
> >> Hey,
> >>
> >> This is a complete shot-in-the-dark, as I don't see this behaviour on
> >> *any* of my boards.  Could you try the attached patch please?
> >
> > Unfortunately, the patch made no difference.
> >
> > I've been looking at how the graphics on my laptop is set up, and have a 
> > bit of a worry about whether the firmware might
> > be playing a part in this problem. In order to offload video decoding to 
> > the NVidia TU117 GPU, it seems the scrubber
> > firmware must be available, but as far as I know,that has not been released 
> > by NVidia. To get it to work, I followed
> > what ubuntu have done and the scrubber in /lib/firmware/nvidia/tu117/nvdec/ 
> > is a symlink to
> > ../../tu116/nvdev/scrubber.bin. That, of course, means that some of the 
> > firmware loaded is for a different card is being
> > loaded. I note that processing related to firmware is being changed in the 
> > patch. Might my set up be at the root of my
> > problem?
> >
> > I'll have a fiddle an see what I can work out.
> >
> > Chris
> >
> >>
> >> Thanks,
> >> Ben.
> >>
> >>>
>
> Well, my fiddling has got my system rebooting and shutting down successfully 
> again. I found that if I delete the symlink
> to the scrubber firmware, reboot and shutdown work again. There are however, 
> a number of other files in the tu117
> firmware directory tree that that are symlinks to actual files in its tu116 
> counterpart. So I deleted all of those too.
> Unfortunately, the absence of one or more of those symlinks causes Xorg to 
> fail to start. I've reinstated all the links
> except scrubber and I now have a system that works as it did until I tried to 
> run a kernel that includes the bad commit
> I identified in my bisection. That includes offloading video decoding to the 
> NVidia card, so what ever I read that said
> the scrubber firmware was needed seems to have been wrong. I get a new 
> message that (nouveau :01:00.0: fb: VPR
> locked, but no scrubber binary!), but, hey, we can't have everything.
>
> If you still want to get to the bottom of this, let me know what you need me 
> to provide and I'll do my best. I suspect
> you might want to because there will a n awful lot of Ubuntu-based systems 
> out there with that scrubber.bin symlink in
> place. On the other hand,m it could but quite a while before ubuntu are 
> deploying 6.2 or later kernels.
The symlinks are correct - whole groups of GPUs share the same FW, and
we use symlinks in linux-firmware to represent this.

I don't really have any ideas how/why this patch causes issues with
shutdown - it's a path that only gets executed during initialisation.
Can you try and capture the kernel log during shutdown ("dmesg -w"
over ssh? netconsole?), and see if there's any relevant messages
providing a hint at what's going on?  Alternatively, you could try
unloading the module (you will have to stop X/wayland/gdm/etc/etc
first) and seeing if that hangs too.

Ben.

>
> Thanks,
>
> Chris
>
> 


Re: [PATCH 1/3] drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETED

2023-01-30 Thread Ben Skeggs
On Tue, 31 Jan 2023 at 09:19, Lyude Paul  wrote:
>
> For the whole series:
>
> Reviewed-by: Lyude Paul 
>
> Will push to drm-misc-fixes in just a moment
Thank you Lyude!  Much appreciated.

Ben.

>
> On Tue, 2023-01-31 at 08:37 +1000, Ben Skeggs wrote:
> > Starting from Turing, the driver is no longer responsible for initiating
> > DEVINIT when required as the GPU started loading a FW image from ROM and
> > executing DEVINIT itself after power-on.
> >
> > However - we apparently still need to wait for it to complete.
> >
> > This should correct some issues with runpm on some systems, where we get
> > control of the HW before it's been fully reinitialised after resume from
> > suspend.
> >
> > Signed-off-by: Ben Skeggs 
> > ---
> >  .../drm/nouveau/nvkm/subdev/devinit/tu102.c   | 23 +++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c 
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c
> > index 634f64f88fc8..81a1ad2c88a7 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c
> > @@ -65,10 +65,33 @@ tu102_devinit_pll_set(struct nvkm_devinit *init, u32 
> > type, u32 freq)
> >   return ret;
> >  }
> >
> > +static int
> > +tu102_devinit_wait(struct nvkm_device *device)
> > +{
> > + unsigned timeout = 50 + 2000;
> > +
> > + do {
> > + if (nvkm_rd32(device, 0x118128) & 0x0001) {
> > + if ((nvkm_rd32(device, 0x118234) & 0x00ff) == 
> > 0xff)
> > + return 0;
> > + }
> > +
> > + usleep_range(1000, 2000);
> > + } while (timeout--);
> > +
> > + return -ETIMEDOUT;
> > +}
> > +
> >  int
> >  tu102_devinit_post(struct nvkm_devinit *base, bool post)
> >  {
> >   struct nv50_devinit *init = nv50_devinit(base);
> > + int ret;
> > +
> > + ret = tu102_devinit_wait(init->base.subdev.device);
> > + if (ret)
> > + return ret;
> > +
> >   gm200_devinit_preos(init, post);
> >   return 0;
> >  }
>
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
>


[PATCH 3/3] drm/nouveau/acr/gm20b: regression fixes

2023-01-30 Thread Ben Skeggs
Missed some Tegra-specific quirks when reworking ACR to support Ampere.

Fixes: 2541626cfb79 ("drm/nouveau/acr: use common falcon HS FW code for ACR 
FWs")
Signed-off-by: Ben Skeggs 
Tested-by: Diogo Ivo 
Tested-By: Nicolas Chauvet 
---
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c|  3 +++
 drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c | 14 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c |  2 +-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
index fcf2a002f6cb..91fb494d4009 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
@@ -151,6 +151,9 @@ nvkm_firmware_mem_page(struct nvkm_memory *memory)
 static enum nvkm_memory_target
 nvkm_firmware_mem_target(struct nvkm_memory *memory)
 {
+   if (nvkm_firmware_mem(memory)->device->func->tegra)
+   return NVKM_MEM_TARGET_NCOH;
+
return NVKM_MEM_TARGET_HOST;
 }
 
diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c 
b/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
index 393ade9f7e6c..b7da3ab44c27 100644
--- a/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
@@ -48,6 +48,16 @@ gm200_flcn_pio_dmem_rd(struct nvkm_falcon *falcon, u8 port, 
const u8 *img, int l
img += 4;
len -= 4;
}
+
+   /* Sigh.  Tegra PMU FW's init message... */
+   if (len) {
+   u32 data = nvkm_falcon_rd32(falcon, 0x1c4 + (port * 8));
+
+   while (len--) {
+   *(u8 *)img++ = data & 0xff;
+   data >>= 8;
+   }
+   }
 }
 
 static void
@@ -64,6 +74,8 @@ gm200_flcn_pio_dmem_wr(struct nvkm_falcon *falcon, u8 port, 
const u8 *img, int l
img += 4;
len -= 4;
}
+
+   WARN_ON(len);
 }
 
 static void
@@ -74,7 +86,7 @@ gm200_flcn_pio_dmem_wr_init(struct nvkm_falcon *falcon, u8 
port, bool sec, u32 d
 
 const struct nvkm_falcon_func_pio
 gm200_flcn_dmem_pio = {
-   .min = 4,
+   .min = 1,
.max = 0x100,
.wr_init = gm200_flcn_pio_dmem_wr_init,
.wr = gm200_flcn_pio_dmem_wr,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
index a72403777329..2ed04da3621d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
@@ -225,7 +225,7 @@ gm20b_pmu_init(struct nvkm_pmu *pmu)
 
pmu->initmsg_received = false;
 
-   nvkm_falcon_load_dmem(falcon, , addr_args, sizeof(args), 0);
+   nvkm_falcon_pio_wr(falcon, (u8 *), 0, 0, DMEM, addr_args, 
sizeof(args), 0, false);
nvkm_falcon_start(falcon);
return 0;
 }
-- 
2.35.1



[PATCH 2/3] drm/nouveau/fb/tu102-: fix register used to determine scrub status

2023-01-30 Thread Ben Skeggs
Turing apparently needs to use the same register we use on Ampere.

Not executing the scrubber ucode when required would result in large
areas of VRAM being inaccessible to the driver.

Signed-off-by: Ben Skeggs 
---
 .../gpu/drm/nouveau/include/nvkm/subdev/fb.h  |  1 +
 .../gpu/drm/nouveau/nvkm/engine/device/base.c | 10 ++--
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild |  1 +
 .../gpu/drm/nouveau/nvkm/subdev/fb/ga102.c|  8 +--
 .../gpu/drm/nouveau/nvkm/subdev/fb/gv100.c|  5 --
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h |  2 +
 .../gpu/drm/nouveau/nvkm/subdev/fb/tu102.c| 55 +++
 7 files changed, 65 insertions(+), 17 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/tu102.c

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h 
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
index 40768373cdd9..c5a4f49ee206 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
@@ -97,6 +97,7 @@ int gp100_fb_new(struct nvkm_device *, enum nvkm_subdev_type, 
int inst, struct n
 int gp102_fb_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, struct 
nvkm_fb **);
 int gp10b_fb_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, struct 
nvkm_fb **);
 int gv100_fb_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, struct 
nvkm_fb **);
+int tu102_fb_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, struct 
nvkm_fb **);
 int ga100_fb_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, struct 
nvkm_fb **);
 int ga102_fb_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, struct 
nvkm_fb **);
 
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 364fea320cb3..1c81e5b34d29 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2405,7 +2405,7 @@ nv162_chipset = {
.bus  = { 0x0001, gf100_bus_new },
.devinit  = { 0x0001, tu102_devinit_new },
.fault= { 0x0001, tu102_fault_new },
-   .fb   = { 0x0001, gv100_fb_new },
+   .fb   = { 0x0001, tu102_fb_new },
.fuse = { 0x0001, gm107_fuse_new },
.gpio = { 0x0001, gk104_gpio_new },
.gsp  = { 0x0001, gv100_gsp_new },
@@ -2440,7 +2440,7 @@ nv164_chipset = {
.bus  = { 0x0001, gf100_bus_new },
.devinit  = { 0x0001, tu102_devinit_new },
.fault= { 0x0001, tu102_fault_new },
-   .fb   = { 0x0001, gv100_fb_new },
+   .fb   = { 0x0001, tu102_fb_new },
.fuse = { 0x0001, gm107_fuse_new },
.gpio = { 0x0001, gk104_gpio_new },
.gsp  = { 0x0001, gv100_gsp_new },
@@ -2475,7 +2475,7 @@ nv166_chipset = {
.bus  = { 0x0001, gf100_bus_new },
.devinit  = { 0x0001, tu102_devinit_new },
.fault= { 0x0001, tu102_fault_new },
-   .fb   = { 0x0001, gv100_fb_new },
+   .fb   = { 0x0001, tu102_fb_new },
.fuse = { 0x0001, gm107_fuse_new },
.gpio = { 0x0001, gk104_gpio_new },
.gsp  = { 0x0001, gv100_gsp_new },
@@ -2510,7 +2510,7 @@ nv167_chipset = {
.bus  = { 0x0001, gf100_bus_new },
.devinit  = { 0x0001, tu102_devinit_new },
.fault= { 0x0001, tu102_fault_new },
-   .fb   = { 0x0001, gv100_fb_new },
+   .fb   = { 0x0001, tu102_fb_new },
.fuse = { 0x0001, gm107_fuse_new },
.gpio = { 0x0001, gk104_gpio_new },
.gsp  = { 0x0001, gv100_gsp_new },
@@ -2545,7 +2545,7 @@ nv168_chipset = {
.bus  = { 0x0001, gf100_bus_new },
.devinit  = { 0x0001, tu102_devinit_new },
.fault= { 0x0001, tu102_fault_new },
-   .fb   = { 0x0001, gv100_fb_new },
+   .fb   = { 0x0001, tu102_fb_new },
.fuse = { 0x0001, gm107_fuse_new },
.gpio = { 0x0001, gk104_gpio_new },
.gsp  = { 0x0001, gv100_gsp_new },
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild
index 5d0bab8ecb43..6ba5120a2ebe 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild
@@ -32,6 +32,7 @@ nvkm-y += nvkm/subdev/fb/gp100.o
 nvkm-y += nvkm/subdev/fb/gp102.o
 nvkm-y += nvkm/subdev/fb/gp10b.o
 nvkm-y += nvkm/subdev/fb/gv100.o
+nvkm-y += nvkm/subdev/fb/tu102.o
 nvkm-y += nvkm/subdev/fb/ga100.o
 nvkm-y += nvkm/subdev/fb/ga102.o
 
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga102.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga102.c
index 8b7c8ea5e8a5..5a21b0ae4595 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga102.c
@@ -40,12 +40,6

[PATCH 1/3] drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETED

2023-01-30 Thread Ben Skeggs
Starting from Turing, the driver is no longer responsible for initiating
DEVINIT when required as the GPU started loading a FW image from ROM and
executing DEVINIT itself after power-on.

However - we apparently still need to wait for it to complete.

This should correct some issues with runpm on some systems, where we get
control of the HW before it's been fully reinitialised after resume from
suspend.

Signed-off-by: Ben Skeggs 
---
 .../drm/nouveau/nvkm/subdev/devinit/tu102.c   | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c
index 634f64f88fc8..81a1ad2c88a7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c
@@ -65,10 +65,33 @@ tu102_devinit_pll_set(struct nvkm_devinit *init, u32 type, 
u32 freq)
return ret;
 }
 
+static int
+tu102_devinit_wait(struct nvkm_device *device)
+{
+   unsigned timeout = 50 + 2000;
+
+   do {
+   if (nvkm_rd32(device, 0x118128) & 0x0001) {
+   if ((nvkm_rd32(device, 0x118234) & 0x00ff) == 0xff)
+   return 0;
+   }
+
+   usleep_range(1000, 2000);
+   } while (timeout--);
+
+   return -ETIMEDOUT;
+}
+
 int
 tu102_devinit_post(struct nvkm_devinit *base, bool post)
 {
struct nv50_devinit *init = nv50_devinit(base);
+   int ret;
+
+   ret = tu102_devinit_wait(init->base.subdev.device);
+   if (ret)
+   return ret;
+
gm200_devinit_preos(init, post);
return 0;
 }
-- 
2.35.1



Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

2023-01-29 Thread Ben Skeggs
On Sat, 28 Jan 2023 at 21:29, Chris Clayton  wrote:
>
>
>
> On 28/01/2023 05:42, Linux kernel regression tracking (Thorsten Leemhuis) 
> wrote:
> > On 27.01.23 20:46, Chris Clayton wrote:
> >> [Resend because the mail client on my phone decided to turn HTML on behind 
> >> my back, so my reply got bounced.]
> >>
> >> Thanks Thorsten.
> >>
> >> I did try to revert but it didnt revert cleanly and I don't have the 
> >> knowledge to fix it up.
> >>
> >> The patch was part of a merge that included a number of related patches. 
> >> Tomorrow, I'll try to revert the lot and report
> >> back.
> >
> > You are free to do so, but there is no need for that from my side. I
> > only wanted to know if a simple revert would do the trick; if it
> > doesn't, it in my experience often is best to leave things to the
> > developers of the code in question,
>
> Sound advice, Thorsten. Way to many conflicts for me to resolve.
Hey,

This is a complete shot-in-the-dark, as I don't see this behaviour on
*any* of my boards.  Could you try the attached patch please?

Thanks,
Ben.

>
> as they know it best and thus have a
> > better idea which hidden side effect a more complex revert might have.
> >
> > Ciao, Thorsten
> >
> >> On 27/01/2023 11:20, Linux kernel regression tracking (Thorsten Leemhuis) 
> >> wrote:
> >>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> >>> to make this easily accessible to everyone.
> >>>
> >>> @nouveau-maintainers, did anyone take a look at this? The report is
> >>> already 8 days old and I don't see a single reply. Sure, we'll likely
> >>> get a -rc8, but still it would be good to not fix this on the finish line.
> >>>
> >>> Chris, btw, did you try if you can revert the commit on top of latest
> >>> mainline? And if so, does it fix the problem?
> >>>
> >>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >>> --
> >>> Everything you wanna know about Linux kernel regression tracking:
> >>> https://linux-regtracking.leemhuis.info/about/#tldr
> >>> If I did something stupid, please tell me, as explained on that page.
> >>>
> >>> #regzbot poke
> >>>
> >>> On 19.01.23 15:33, Linux kernel regression tracking (Thorsten Leemhuis)
> >>> wrote:
>  [adding various lists and the two other nouveau maintainers to the list
>  of recipients]
> >>>
>  On 18.01.23 21:59, Chris Clayton wrote:
> > Hi.
> >
> > I build and installed the lastest development kernel earlier this week. 
> > I've found that when I try the laptop down (or
> > reboot it), it hangs right at the end of closing the current session. 
> > The last line I see on  the screen when rebooting is:
> >
> >   sd 4:0:0:0: [sda] Synchronising SCSI cache
> >
> > when closing down I see one additional line:
> >
> >   sd 4:0:0:0 [sda]Stopping disk
> >
> > In both cases the machine then hangs and I have to hold down the power 
> > button fot a few seconds to switch it off.
> >
> > Linux 6.1 is OK but 6.2-rc1 hangs, so I bisected between this two and 
> > landed on:
> >
> >   # first bad commit: [0e44c21708761977dcbea9b846b51a6fb684907a] 
> > drm/nouveau/flcn: new code to load+boot simple HS FWs
> > (VPR scrubber)
> >
> > I built and installed a kernel with 
> > f15cde64b66161bfa74fb58f4e5697d8265b802e (the parent of the bad commit) 
> > checked out
> > and that shuts down and reboots fine. It the did the same with the bad 
> > commit checked out and that does indeed hang, so
> > I'm confident the bisect outcome is OK.
> >
> > Kernels 6.1.6 and 5.15.88 are also OK.
> >
> > My system had dual GPUs - one intel and one NVidia. Related extracts 
> > from 'lscpi -v' is:
> >
> > 00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 
> > [UHD Graphics] (rev 05) (prog-if 00 [VGA controller])
> > Subsystem: CLEVO/KAPOK Computer CometLake-H GT2 [UHD Graphics]
> >
> > Flags: bus master, fast devsel, latency 0, IRQ 142
> >
> > Memory at c200 (64-bit, non-prefetchable) [size=16M]
> >
> > Memory at a000 (64-bit, prefetchable) [size=256M]
> >
> > I/O ports at 5000 [size=64]
> >
> > Expansion ROM at 000c [virtual] [disabled] [size=128K]
> >
> > Capabilities: [40] Vendor Specific Information: Len=0c 
> >
> > Capabilities: [70] Express Root Complex Integrated Endpoint, 
> > MSI 00
> >
> > Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
> >
> > Capabilities: [d0] Power Management version 2
> >
> > Kernel driver in use: i915
> >
> > Kernel modules: i915
> >
> >
> > 01:00.0 VGA compatible controller: NVIDIA Corporation TU117M [GeForce 
> > GTX 1650 Ti Mobile] (rev a1) (prog-if 00 [VGA
> > controller])
> > Subsystem: 

Re: [REGRESSION] GM20B probe fails after commit 2541626cfb79

2023-01-29 Thread Ben Skeggs
On Fri, 27 Jan 2023 at 20:42, Diogo Ivo  wrote:
>
> On Fri, Jan 27, 2023 at 04:00:59PM +1000, Ben Skeggs wrote:
> > On Fri, 20 Jan 2023 at 21:37, Diogo Ivo  
> > wrote:
> > >
> > > On Wed, Jan 18, 2023 at 11:28:49AM +1000, Ben Skeggs wrote:
> > > > On Mon, 16 Jan 2023 at 22:27, Diogo Ivo  
> > > > wrote:
> > > > > On Mon, Jan 16, 2023 at 07:45:05AM +1000, David Airlie wrote:
> > > > > > As a quick check can you try changing
> > > > > >
> > > > > > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:nvkm_firmware_mem_target
> > > > > > from NVKM_MEM_TARGET_HOST to NVKM_MEM_TARGET_NCOH ?
> > >
> > > > In addition to Dave's change, can you try changing the
> > > > nvkm_falcon_load_dmem() call in gm20b_pmu_init() to:
> > > >
> > > > nvkm_falcon_pio_wr(falcon, (u8 *), 0, 0, DMEM, addr_args,
> > > > sizeof(args), 0, false);
> > >
> > > Chiming in just to say that with this change I see the same as Nicolas
> > > except that the init message size is 255 instead of 0:
> > >
> > > [2.196934] nouveau 5700.gpu: pmu: unexpected init message size 
> > > 255 vs 42
> > I've attached an entirely untested patch (to go on top of the other
> > hacks/fixes so far), that will hopefully get us a little further.
>
> Hello,
>
> Thank you for the patch! I can confirm that it fixes the problem
> on the Pixel C, and everything works as before the regression.
> With this, for the combination of patches
>
> Tested-by: Diogo Ivo 
>
> which I can resend after testing the final patch version.
Thank you (both!) for testing!

I've attached a "final" version of a patch that I'll send (assuming it
still works ;)) after re-testing.  There's only a minor change to
avoid breaking the non-Tegra path, so I expect it should be fine.

Ben.
>
> Thanks,
> Diogo
From bfc1b84d26ca28f78a07d494b0813fe642e80bbe Mon Sep 17 00:00:00 2001
From: Ben Skeggs 
Date: Fri, 27 Jan 2023 15:42:27 +1000
Subject: [PATCH] drm/nouveau/acr/gm20b: regression fixes

Missed some Tegra-specific quirks when reworking ACR to support Ampere.

Fixes: 2541626cfb79 ("drm/nouveau/acr: use common falcon HS FW code for	ACR FWs")
Signed-off-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c|  3 +++
 drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c | 14 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c |  2 +-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
index fcf2a002f6cb..91fb494d4009 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
@@ -151,6 +151,9 @@ nvkm_firmware_mem_page(struct nvkm_memory *memory)
 static enum nvkm_memory_target
 nvkm_firmware_mem_target(struct nvkm_memory *memory)
 {
+	if (nvkm_firmware_mem(memory)->device->func->tegra)
+		return NVKM_MEM_TARGET_NCOH;
+
 	return NVKM_MEM_TARGET_HOST;
 }
 
diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c b/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
index 393ade9f7e6c..b7da3ab44c27 100644
--- a/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
@@ -48,6 +48,16 @@ gm200_flcn_pio_dmem_rd(struct nvkm_falcon *falcon, u8 port, const u8 *img, int l
 		img += 4;
 		len -= 4;
 	}
+
+	/* Sigh.  Tegra PMU FW's init message... */
+	if (len) {
+		u32 data = nvkm_falcon_rd32(falcon, 0x1c4 + (port * 8));
+
+		while (len--) {
+			*(u8 *)img++ = data & 0xff;
+			data >>= 8;
+		}
+	}
 }
 
 static void
@@ -64,6 +74,8 @@ gm200_flcn_pio_dmem_wr(struct nvkm_falcon *falcon, u8 port, const u8 *img, int l
 		img += 4;
 		len -= 4;
 	}
+
+	WARN_ON(len);
 }
 
 static void
@@ -74,7 +86,7 @@ gm200_flcn_pio_dmem_wr_init(struct nvkm_falcon *falcon, u8 port, bool sec, u32 d
 
 const struct nvkm_falcon_func_pio
 gm200_flcn_dmem_pio = {
-	.min = 4,
+	.min = 1,
 	.max = 0x100,
 	.wr_init = gm200_flcn_pio_dmem_wr_init,
 	.wr = gm200_flcn_pio_dmem_wr,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
index a72403777329..2ed04da3621d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
@@ -225,7 +225,7 @@ gm20b_pmu_init(struct nvkm_pmu *pmu)
 
 	pmu->initmsg_received = false;
 
-	nvkm_falcon_load_dmem(falcon, , addr_args, sizeof(args), 0);
+	nvkm_falcon_pio_wr(falcon, (u8 *), 0, 0, DMEM, addr_args, sizeof(args), 0, false);
 	nvkm_falcon_start(falcon);
 	return 0;
 }
-- 
2.35.1



Re: [REGRESSION] GM20B probe fails after commit 2541626cfb79

2023-01-26 Thread Ben Skeggs
On Fri, 20 Jan 2023 at 21:37, Diogo Ivo  wrote:
>
> On Wed, Jan 18, 2023 at 11:28:49AM +1000, Ben Skeggs wrote:
> > On Mon, 16 Jan 2023 at 22:27, Diogo Ivo  
> > wrote:
> > > On Mon, Jan 16, 2023 at 07:45:05AM +1000, David Airlie wrote:
> > > > As a quick check can you try changing
> > > >
> > > > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:nvkm_firmware_mem_target
> > > > from NVKM_MEM_TARGET_HOST to NVKM_MEM_TARGET_NCOH ?
>
> > In addition to Dave's change, can you try changing the
> > nvkm_falcon_load_dmem() call in gm20b_pmu_init() to:
> >
> > nvkm_falcon_pio_wr(falcon, (u8 *), 0, 0, DMEM, addr_args,
> > sizeof(args), 0, false);
>
> Hello!
>
> Chiming in just to say that with this change I see the same as Nicolas
> except that the init message size is 255 instead of 0:
>
> [2.196934] nouveau 5700.gpu: pmu: unexpected init message size 255 vs 
> 42
I've attached an entirely untested patch (to go on top of the other
hacks/fixes so far), that will hopefully get us a little further.

Would be great if you guys could test it out for me.

Thanks,
Ben.
diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c b/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
index 393ade9f7e6c..b7da3ab44c27 100644
--- a/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
@@ -48,6 +48,16 @@ gm200_flcn_pio_dmem_rd(struct nvkm_falcon *falcon, u8 port, const u8 *img, int l
 		img += 4;
 		len -= 4;
 	}
+
+	/* Sigh.  Tegra PMU FW's init message... */
+	if (len) {
+		u32 data = nvkm_falcon_rd32(falcon, 0x1c4 + (port * 8));
+
+		while (len--) {
+			*(u8 *)img++ = data & 0xff;
+			data >>= 8;
+		}
+	}
 }
 
 static void
@@ -64,6 +74,8 @@ gm200_flcn_pio_dmem_wr(struct nvkm_falcon *falcon, u8 port, const u8 *img, int l
 		img += 4;
 		len -= 4;
 	}
+
+	WARN_ON(len);
 }
 
 static void
@@ -74,7 +86,7 @@ gm200_flcn_pio_dmem_wr_init(struct nvkm_falcon *falcon, u8 port, bool sec, u32 d
 
 const struct nvkm_falcon_func_pio
 gm200_flcn_dmem_pio = {
-	.min = 4,
+	.min = 1,
 	.max = 0x100,
 	.wr_init = gm200_flcn_pio_dmem_wr_init,
 	.wr = gm200_flcn_pio_dmem_wr,


Re: [REGRESSION] GM20B probe fails after commit 2541626cfb79

2023-01-17 Thread Ben Skeggs
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
> > from NVKM_MEM_TARGET_HOST to NVKM_MEM_TARGET_NCOH ?
>
> Hello!
>
> Applying this change breaks probing in a different way, with a
> bad PC=0x0. From a quick look at nvkm_falcon_load_dmem it looks like this
> could happen due to the .load_dmem() callback not being properly
> initialized. This is the kernel log I got:
In addition to Dave's change, can you try changing the
nvkm_falcon_load_dmem() call in gm20b_pmu_init() to:

nvkm_falcon_pio_wr(falcon, (u8 *), 0, 0, DMEM, addr_args,
sizeof(args), 0, false);

Ben.

>
> [2.010601] Unable to handle kernel NULL pointer dereference at virtual 
> address 
> [2.019436] Mem abort info:
> [2.022273]   ESR = 0x8605
> [2.026066]   EC = 0x21: IABT (current EL), IL = 32 bits
> [2.031429]   SET = 0, FnV = 0
> [2.034528]   EA = 0, S1PTW = 0
> [2.037694]   FSC = 0x05: level 1 translation fault
> [2.042572] [] user address but active_mm is swapper
> [2.048961] Internal error: Oops: 8605 [#1] SMP
> [2.054529] Modules linked in:
> [2.057582] CPU: 0 PID: 36 Comm: kworker/u8:1 Not tainted 6.2.0-rc3+ #2
> [2.064190] Hardware name: Google Pixel C (DT)
> [2.068628] Workqueue: events_unbound deferred_probe_work_func
> [2.074463] pstate: 4005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [2.081417] pc : 0x0
> [2.083600] lr : nvkm_falcon_load_dmem+0x58/0x80
> [2.088218] sp : ffc009ddb6f0
> [2.091526] x29: ffc009ddb6f0 x28: ff808028a008 x27: 
> ff8081e43c38
> [2.098658] x26: 00ff x25: ff808028a0a0 x24: 
> 
> [2.105788] x23: ff8080c328f8 x22: 002c x21: 
> 5fd4
> [2.112917] x20: ffc009ddb76c x19: ff8080c328b8 x18: 
> 
> [2.120047] x17: 2e74696e695f646f x16: 6874656d5f77732f x15: 
> 
> [2.127176] x14: 02f546c2 x13:  x12: 
> 01ce
> [2.134306] x11: 0001 x10: 0a90 x9 : 
> ffc009ddb600
> [2.141436] x8 : ff80803d19f0 x7 : ff80bf971180 x6 : 
> 01b9
> [2.148565] x5 :  x4 :  x3 : 
> 002c
> [2.155693] x2 : 5fd4 x1 : ffc009ddb76c x0 : 
> ff8080c328b8
> [2.162822] Call trace:
> [2.165264]  0x0
> [2.167099]  gm20b_pmu_init+0x78/0xb4
> [2.170762]  nvkm_pmu_init+0x20/0x34
> [2.174334]  nvkm_subdev_init_+0x60/0x12c
> [2.178339]  nvkm_subdev_init+0x60/0xa0
> [2.182171]  nvkm_device_init+0x14c/0x2a0
> [2.186178]  nvkm_udevice_init+0x60/0x9c
> [2.190097]  nvkm_object_init+0x48/0x1b0
> [2.194013]  nvkm_ioctl_new+0x168/0x254
> [2.197843]  nvkm_ioctl+0xd0/0x220
> [2.201239]  nvkm_client_ioctl+0x10/0x1c
> [2.205160]  nvif_object_ctor+0xf4/0x22c
> [2.209079]  nvif_device_ctor+0x28/0x70
> [2.212910]  nouveau_cli_init+0x150/0x590
> [2.216916]  nouveau_drm_device_init+0x60/0x2a0
> [2.221442]  nouveau_platform_device_create+0x90/0xd0
> [2.226489]  nouveau_platform_probe+0x3c/0x9c
> [2.230841]  platform_probe+0x68/0xc0
> [2.234500]  really_probe+0xbc/0x2dc
> [2.238070]  __driver_probe_device+0x78/0xe0
> [2.242334]  driver_probe_device+0xd8/0x160
> [2.246511]  __device_attach_driver+0xb8/0x134
> [2.250948]  bus_for_each_drv+0x78/0xd0
> [2.254782]  __device_attach+0x9c/0x1a0
> [2.258612]  device_initial_probe+0x14/0x20
> [2.262789]  bus_probe_device+0x98/0xa0
> [2.266619]  deferred_probe_work_func+0x88/0xc0
> [2.271142]  process_one_work+0x204/0x40c
> [2.275150]  worker_thread+0x230/0x450
> [2.278894]  kthread+0xc8/0xcc
> [2.281946]  ret_from_fork+0x10/0x20
> [2.285525] Code: bad PC value
> [2.288576] ---[ end trace  ]---
>
> Diogo


[PULL] nouveau-next

2022-11-07 Thread Ben Skeggs
Hey Dave,

This is the pull request for a whole bunch of fixes and prep-work that
was done to support Ampere acceleration prior to GSP-RM being
available.  It uses the ACR firmware released by NVIDIA in
linux-firmware, as we do on earlier GPUs.  The work to support running
on top of GSP-RM also heavily depends on various pieces of this
series.

In addition to the new HW support, general stability of the driver
should be improved, especially around recovering HW from bugs that can
be generated by userspace driver components.

Thanks,
Ben.

The following changes since commit 60ba8c5bd94e17ab4b024f5cecf8b48e2cf36412:

  Merge tag 'drm-intel-gt-next-2022-11-03' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-11-04
17:33:34 +1000)

are available in the Git repository at:

  https://gitlab.freedesktop.org/skeggsb/nouveau.git 00.06-gr-ampere

for you to fetch changes up to 6dd08133e9f705f6565e18f114cfeca3f3a6970a:

  drm/nouveau/gr/ga102: initial support (2022-11-08 15:46:01 +1000)


Ben Skeggs (124):
  drm/nouveau/disp: move and extend the role of outp acquire/release methods
  drm/nouveau/disp: move LVDS protocol information into acquire
  drm/nouveau/disp: move HDMI config into acquire + infoframe methods
  drm/nouveau/disp: move HDA ELD method
  drm/nouveau/disp: move DP link config into acquire
  drm/nouveau/disp: add method to control DPAUX pad power
  drm/nouveau/kms: switch hpd_lock from mutex to spinlock
  drm/nouveau/kms: pass event mask to hpd handler
  drm/nouveau/disp: add method to trigger DP link retrain
  drm/nouveau/disp: move DP MST payload config method
  drm/nouveau/disp: add head class
  drm/nouveau/disp: move head scanoutpos method
  drm/nouveau/nvkm: add a replacement for nvkm_notify
  drm/nouveau/fault: switch non-replayable faults to nvkm_event_ntfy
  drm/nouveau/fault: expose replayable fault buffer event class
  drm/nouveau/disp: switch vblank semaphore release to nvkm_event_ntfy
  drm/nouveau/disp: expose head event class
  drm/nouveau/disp: expose conn event class
  drm/nouveau/disp: expose page flip event class
  drm/nouveau/fifo: expose non-stall intr in host channel event class
  drm/nouveau/fifo: expose channel killed in host channel event class
  drm/nouveau/nvkm: rip out old notify
  drm/nouveau/kms: switch to drm fbdev helpers
  drm/nouveau/nvkm: give each nvkm_event its own lockdep class
  drm/nouveau/top: parse device topology right after devinit
  drm/nouveau/intr: add shared interrupt plumbing between pci/tegra
  drm/nouveau/intr: support multiple trees, and explicit interfaces
  drm/nouveau/intr: add nvkm_subdev_intr() compatibility
  drm/nouveau/vfn: add stub subdev for dev_func
  drm/nouveau/vfn: move NV_USERMODE class from host
  drm/nouveau/vfn/tu102-: support new-style interrupt tree
  drm/nouveau/fault/tu102: switch to explicit intr handlers
  drm/nouveau/fault/ga100: initial support
  drm/nouveau/mc: implement intr handling on top of nvkm_intr
  drm/nouveau/mc: move NV_PMC_ENABLE bashing to chipset-specific code
  drm/nouveau/mc/ga100: switch to using NV_PMC_DEVICE_ENABLE
  drm/nouveau/nvkm: add locking to subdev/engine init paths
  drm/nouveau/flcn: show falcon user in debug output
  drm/nouveau/imem: allow bar2 mapping of user allocations
  drm/nouveau/fifo: add chid_nr()
  drm/nouveau/fifo: unify handling of channel classes
  drm/nouveau/fifo: pre-move some blocks of code around
  drm/nouveau/fifo: merge gk104_fifo_func into nvkm_host_func
  drm/nouveau/fifo: add chid allocator
  drm/nouveau/fifo: add runq
  drm/nouveau/fifo: add common runlist/engine topology
  drm/nouveau/fifo: expose runlist topology info on all chipsets
  drm/nouveau/fifo: expose per-runlist CHID information
  drm/nouveau/fifo: add cgrp, have all channels be part of one
  drm/nouveau/fifo: use runlist engine info to lookup engine classes
  drm/nouveau/fifo: use explicit intr interfaces
  drm/nouveau/fifo: tidy up non-stall intr handling
  drm/nouveau/fifo: tidy global PBDMA init
  drm/nouveau/fifo: program NV_PFIFO_FB_TIMEOUT on init
  drm/nouveau/fifo: move PBDMA init to runq
  drm/nouveau/fifo: move PBDMA intr to runq
  drm/nouveau/fifo: merge mmu fault handlers together
  drm/nouveau/fifo: add new channel lookup interfaces
  drm/nouveau/fifo: add new engine context tracking
  drm/nouveau/fifo: add runlist wait()
  drm/nouveau/fifo: add runlist block()/allow()
  drm/nouveau/fifo: add chan bind()/unbind()
  drm/nouveau/fifo: add chan start()/stop()
  drm/nouveau/fifo: add chan/cgrp preempt()
  drm/nouveau/fifo: kill channel on a selection of PBDMA errors
  drm/nouveau/fifo: kill channel on NV_PPBDMA_INTR_1_CTXNOTVALID
  drm/nouveau/fifo: add

Re: [PATCH] drm/nouveau/bios: Rename prom_init() and friends functions

2022-03-18 Thread Ben Skeggs
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 to _rom.  It's a reference to the
NV_PROM device.

Ben.

>
> On Fri, 2022-03-18 at 10:55 +0100, Christophe Leroy wrote:
> > Hi Paul,
> >
> > Le 05/03/2022 à 10:51, Christophe Leroy a écrit :
> > >
> > >
> > > Le 05/03/2022 à 08:38, Christophe Leroy a écrit :
> > > >
> > > >
> > > > Le 04/03/2022 à 21:24, Lyude Paul a écrit :
> > > > > This mostly looks good to me. Just one question (and one comment down
> > > > > below
> > > > > that needs addressing). Is this with ppc32? (I ask because ppc64le
> > > > > doesn't
> > > > > seem to hit this compilation error).
> > > >
> > > > That's with PPC64, see
> > > > http://kisskb.ellerman.id.au/kisskb/branch/chleroy/head/252ba609bea83234d2e35841c19ae84c67b43ec7/
> > > >
> > > >
> > > >
> > > > But that's not (yet) with the mainline tree. That's work I'm doing to
> > > > cleanup our asm/asm-protoypes.h header.
> > > >
> > > > Since commit 4efca4ed05cb ("kbuild: modversions for EXPORT_SYMBOL()
> > > > for asm") that file is dedicated to prototypes of functions defined in
> > > > assembly. Therefore I'm trying to dispatch C functions prototypes in
> > > > other headers. I wanted to move prom_init() prototype into asm/prom.h
> > > > and then I hit the problem.
> > > >
> > > > In the beginning I was thinking about just changing the name of the
> > > > function in powerpc, but as I see that M68K, MIPS and SPARC also have
> > > > a prom_init() function, I thought it would be better to change the
> > > > name in shadowrom.c to avoid any future conflict like the one I got
> > > > while reworking the headers.
> > > >
> > > >
> > > > > > @@ -57,8 +57,8 @@ prom_init(struct nvkm_bios *bios, const char
> > > > > > *name)
> > > > > >   const struct nvbios_source
> > > > > >   nvbios_rom = {
> > > > > >  .name = "PROM",
> > > > > > -   .init = prom_init,
> > > > > > -   .fini = prom_fini,
> > > > > > -   .read = prom_read,
> > > > > > +   .init = nvbios_rom_init,
> > > > > > +   .fini = nvbios_rom_fini,
> > > > > > +   .read = nvbios_rom_read,
> > > > >
> > > > > Seeing as the source name is prom, I think using the naming convention
> > > > > nvbios_prom_* would be better then nvbios_rom_*.
> > > > >
> > > >
> > > > Yes I wasn't sure about the best naming as the file name is
> > > > shadowrom.c and not shadowprom.c.
> > > >
> > > > I will send v2 using nvbios_prom_* as a name.
> > >
> > > While preparing v2 I remembered that in fact, I called the functions
> > > nvbios_rom_* because the name of the nvbios_source struct is nvbios_rom,
> > > so for me it made sense to use the name of the struct as a prefix for
> > > the functions.
> > >
> > > So I'm OK to change it to nvbios_prom_* but it looks less logical to me.
> > >
> > > Please confirm you still prefer nvbios_prom as prefix to the function
> > > names.
> > >
> >
> > Are you still expecting a v2 for this patch ?
> >
> > As the name of the structure is nvbios_rom, do you really prefer the
> > functions to be called nvbios_prom_* as you mentionned in your comment ?
> >
> > In that case, do you also expect the structure name to be changed to
> > nvbios_prom ?
> >
> > Thanks
> > Christophe
> >
>
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
>


Re: [Nouveau] [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2

2021-12-15 Thread Ben Skeggs
On Tue, 14 Dec 2021 at 19:19, Christian König
 wrote:
>
> Am 11.12.21 um 10:59 schrieb Stefan Fritsch:
> > On 09.12.21 11:23, Christian König wrote:
> >> Always waiting for the exclusive fence resulted on some performance
> >> regressions. So try to wait for the shared fences first, then the
> >> exclusive fence should always be signaled already.
> >>
> >> v2: fix incorrectly placed "(", add some comment why we do this.
> >>
> >> Signed-off-by: Christian König 
> >
> > Tested-by: Stefan Fritsch 
>
> 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.
>
> >
> > Cheers,
> > Stefan
> >
> >> ---
> >>   drivers/gpu/drm/nouveau/nouveau_fence.c | 28 +
> >>   1 file changed, 15 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
> >> b/drivers/gpu/drm/nouveau/nouveau_fence.c
> >> index 05d0b3eb3690..0ae416aa76dc 100644
> >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c
> >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
> >> @@ -353,15 +353,22 @@ nouveau_fence_sync(struct nouveau_bo *nvbo,
> >> struct nouveau_channel *chan, bool e
> >> if (ret)
> >>   return ret;
> >> -}
> >>   -fobj = dma_resv_shared_list(resv);
> >> -fence = dma_resv_excl_fence(resv);
> >> +fobj = NULL;
> >> +} else {
> >> +fobj = dma_resv_shared_list(resv);
> >> +}
> >>   -if (fence) {
> >> +/* Waiting for the exclusive fence first causes performance
> >> regressions
> >> + * under some circumstances. So manually wait for the shared
> >> ones first.
> >> + */
> >> +for (i = 0; i < (fobj ? fobj->shared_count : 0) && !ret; ++i) {
> >>   struct nouveau_channel *prev = NULL;
> >>   bool must_wait = true;
> >>   +fence = rcu_dereference_protected(fobj->shared[i],
> >> +dma_resv_held(resv));
> >> +
> >>   f = nouveau_local_fence(fence, chan->drm);
> >>   if (f) {
> >>   rcu_read_lock();
> >> @@ -373,20 +380,13 @@ nouveau_fence_sync(struct nouveau_bo *nvbo,
> >> struct nouveau_channel *chan, bool e
> >> if (must_wait)
> >>   ret = dma_fence_wait(fence, intr);
> >> -
> >> -return ret;
> >>   }
> >>   -if (!exclusive || !fobj)
> >> -return ret;
> >> -
> >> -for (i = 0; i < fobj->shared_count && !ret; ++i) {
> >> +fence = dma_resv_excl_fence(resv);
> >> +if (fence) {
> >>   struct nouveau_channel *prev = NULL;
> >>   bool must_wait = true;
> >>   -fence = rcu_dereference_protected(fobj->shared[i],
> >> -dma_resv_held(resv));
> >> -
> >>   f = nouveau_local_fence(fence, chan->drm);
> >>   if (f) {
> >>   rcu_read_lock();
> >> @@ -398,6 +398,8 @@ nouveau_fence_sync(struct nouveau_bo *nvbo,
> >> struct nouveau_channel *chan, bool e
> >> if (must_wait)
> >>   ret = dma_fence_wait(fence, intr);
> >> +
> >> +return ret;
> >>   }
> >> return ret;
>


Re: [Nouveau] [PATCH] drm/nouveau/acr: fix a couple NULL vs IS_ERR() checks

2021-11-18 Thread Ben Skeggs
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-by: Dan Carpenter 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/acr/gm200.c | 6 --
>  drivers/gpu/drm/nouveau/nvkm/subdev/acr/gp102.c | 6 --
>  2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/gm200.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/gm200.c
> index cdb1ead26d84..82b4c8e1457c 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/gm200.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/gm200.c
> @@ -207,11 +207,13 @@ int
>  gm200_acr_wpr_parse(struct nvkm_acr *acr)
>  {
> const struct wpr_header *hdr = (void *)acr->wpr_fw->data;
> +   struct nvkm_acr_lsfw *lsfw;
>
> while (hdr->falcon_id != WPR_HEADER_V0_FALCON_ID_INVALID) {
> wpr_header_dump(>subdev, hdr);
> -   if (!nvkm_acr_lsfw_add(NULL, acr, NULL, (hdr++)->falcon_id))
> -   return -ENOMEM;
> +   lsfw = nvkm_acr_lsfw_add(NULL, acr, NULL, (hdr++)->falcon_id);
> +   if (IS_ERR(lsfw))
> +   return PTR_ERR(lsfw);
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/gp102.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/gp102.c
> index fb9132a39bb1..fd97a935a380 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/gp102.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/gp102.c
> @@ -161,11 +161,13 @@ int
>  gp102_acr_wpr_parse(struct nvkm_acr *acr)
>  {
> const struct wpr_header_v1 *hdr = (void *)acr->wpr_fw->data;
> +   struct nvkm_acr_lsfw *lsfw;
>
> while (hdr->falcon_id != WPR_HEADER_V1_FALCON_ID_INVALID) {
> wpr_header_v1_dump(>subdev, hdr);
> -   if (!nvkm_acr_lsfw_add(NULL, acr, NULL, (hdr++)->falcon_id))
> -   return -ENOMEM;
> +   lsfw = nvkm_acr_lsfw_add(NULL, acr, NULL, (hdr++)->falcon_id);
> +   if (IS_ERR(lsfw))
> +   return PTR_ERR(lsfw);
> }
>
> return 0;
> --
> 2.20.1
>


Re: [Nouveau] [PATCH] MAINTAINERS: update information for nouveau

2021-11-10 Thread Ben Skeggs
On Wed, 10 Nov 2021 at 23:32, Karol Herbst  wrote:
>
> Some side notes on this. Atm we do want to use gitlab for bug tracking and
> merge requests. But due to the nature of the current linux kernel
> development, we can only do so for nouveau internal changes.
>
> Everything else still needs to be sent as emails and this is also includes
> changes to UAPI etc.
>
> Anyway, if somebody wants to submit patches via gitlab, they are free to
> do so and this should just make this more official and documented.
>
> People listed as maintainers are such that have 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 
> Cc: Lyude Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Karol Herbst 
Signed-off-by: Ben Skeggs 

> ---
>  MAINTAINERS | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8805df335326..270dc9c0a427 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5961,10 +5961,17 @@ F:  drivers/gpu/drm/panel/panel-novatek-nt36672a.c
>
>  DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS
>  M: Ben Skeggs 
> +M: Karol Herbst 
> +M: Lyude Paul 
>  L: dri-devel@lists.freedesktop.org
>  L: nouv...@lists.freedesktop.org
>  S: Supported
> -T: git git://github.com/skeggsb/linux
> +W: https://nouveau.freedesktop.org/
> +Q: https://patchwork.freedesktop.org/project/nouveau/
> +Q: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests
> +B: https://gitlab.freedesktop.org/drm/nouveau/-/issues
> +C: irc://irc.oftc.net/nouveau
> +T: git https://gitlab.freedesktop.org/drm/nouveau.git
>  F: drivers/gpu/drm/nouveau/
>  F: include/uapi/drm/nouveau_drm.h
>
> --
> 2.33.1
>


Re: [Nouveau] [PATCH] drm/nouveau: set RGB quantization range to FULL

2021-11-10 Thread Ben Skeggs
On Thu, 11 Nov 2021 at 01:58, Hans Verkuil  wrote:
>
> The nouveau driver outputs full range RGB, but the AVI InfoFrame just says
> 'Default' instead of 'Full'.
>
> Call drm_hdmi_avi_infoframe_quant_range to fill in the quantization field of
> the AVI 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 

> ---
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index d7b9f7f8c9e3..b05c01927fe6 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -852,6 +852,9 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct 
> nouveau_crtc *nv_crtc,
> ret = drm_hdmi_avi_infoframe_from_display_mode(_frame.avi,
>_connector->base, 
> mode);
> if (!ret) {
> +   drm_hdmi_avi_infoframe_quant_range(_frame.avi,
> +  _connector->base, mode,
> +  
> HDMI_QUANTIZATION_RANGE_FULL);
> /* We have an AVI InfoFrame, populate it to the display */
> args.pwr.avi_infoframe_length
> = hdmi_infoframe_pack(_frame, args.infoframes, 
> 17);


Re: [Nouveau] [PATCH] drm/nouveau: hdmigv100.c: fix corrupted HDMI Vendor InfoFrame

2021-11-10 Thread Ben Skeggs
On Thu, 11 Nov 2021 at 01:43, Hans Verkuil  wrote:
>
> gv100_hdmi_ctrl() writes vendor_infoframe.subpack0_high to 0x6f0110, and
> then overwrites it with 0. Just drop the overwrite with 0, that's clearly
> a mistake.
>
> Because of this issue the HDMI VIC is 0 instead 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/nouveau/nvkm/engine/disp/hdmigv100.c
> index 6e3c450eaace..3ff49344abc7 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigv100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigv100.c
> @@ -62,7 +62,6 @@ gv100_hdmi_ctrl(struct nvkm_ior *ior, int head, bool 
> enable, u8 max_ac_packet,
> nvkm_wr32(device, 0x6f0108 + hdmi, vendor_infoframe.header);
> nvkm_wr32(device, 0x6f010c + hdmi, 
> vendor_infoframe.subpack0_low);
> nvkm_wr32(device, 0x6f0110 + hdmi, 
> vendor_infoframe.subpack0_high);
> -   nvkm_wr32(device, 0x6f0110 + hdmi, 0x);
> nvkm_wr32(device, 0x6f0114 + hdmi, 0x);
> nvkm_wr32(device, 0x6f0118 + hdmi, 0x);
> nvkm_wr32(device, 0x6f011c + hdmi, 0x);
>


Re: [PATCH v1 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

2021-10-12 Thread Ben Skeggs
On Wed, 13 Oct 2021 at 03:58, Rafael J. Wysocki  wrote:
>
> From: Rafael J. Wysocki 
>
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, 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 Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nouveau_acpi.c |9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
> ===
> --- linux-pm.orig/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ linux-pm/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -364,7 +364,6 @@ void *
>  nouveau_acpi_edid(struct drm_device *dev, struct drm_connector *connector)
>  {
> struct acpi_device *acpidev;
> -   acpi_handle handle;
> int type, ret;
> void *edid;
>
> @@ -377,12 +376,8 @@ nouveau_acpi_edid(struct drm_device *dev
> return NULL;
> }
>
> -   handle = ACPI_HANDLE(dev->dev);
> -   if (!handle)
> -   return NULL;
> -
> -   ret = acpi_bus_get_device(handle, );
> -   if (ret)
> +   acpidev = ACPI_COMPANION(dev->dev);
> +   if (!acpidev)
> return NULL;
>
> ret = acpi_video_get_edid(acpidev, type, -1, );
>
>
>


Re: [Nouveau] [PATCH] drm/nouveau/mmu/gp100: remove unused variable

2021-10-12 Thread Ben Skeggs
On Tue, 12 Oct 2021 at 23:33, Karol Herbst  wrote:
>
> Fixes a compilation issue introduced because I forgot to test with WERROR
> enabled.
>
> Cc: Stephen Rothwell 
> Cc: DRI 
> Cc: nouv...@lists.freedesktop.org
> Fixes: 404046cf4805 ("drm/nouveau/mmu/gp100-: drop unneeded 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/vmmgp100.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
> index 2b21f43069aa..17899fc95b2d 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
> @@ -488,7 +488,7 @@ gp100_vmm_fault_cancel(struct nvkm_vmm *vmm, void *argv, 
> u32 argc)
> struct gp100_vmm_fault_cancel_v0 v0;
> } *args = argv;
> int ret = -ENOSYS;
> -   u32 inst, aper;
> +   u32 aper;
>
> if ((ret = nvif_unpack(ret, , , args->v0, 0, 0, false)))
> return ret;
> --
> 2.31.1
>


Re: [PATCH] drm/nouveau/fifo: Reinstate the correct engine bit programming

2021-10-07 Thread Ben Skeggs
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 place we can get this pushed next week so we can
> finally fix this annoying issue :) I was also seeing some minor
> graphical corruptions which would be cool if this patch fixes it as
> well.
>
> Thanks for the patch and poking us about the bug again.
>
> On Thu, Oct 7, 2021 at 11:41 PM Marek Vasut  wrote:
> >
> > Commit 64f7c698bea9 ("drm/nouveau/fifo: add engine_id hook") replaced
> > fifo/chang84.c g84_fifo_chan_engine() call with an indirect call of
> > fifo/g84.c g84_fifo_engine_id(). The G84_FIFO_ENGN_* values returned
> > from the later g84_fifo_engine_id() are incremented by 1 compared to
> > the previous g84_fifo_chan_engine() return values.
> >
> > This is fine either way for most of the code, except this one line
> > where an engine bit programmed into the hardware is derived from the
> > return value. Decrement the return value accordingly, otherwise the
> > wrong engine bit is programmed into the hardware and that leads to
> > the following failure:
> > nouveau :01:00.0: gr: 0030 [ILLEGAL_MTHD ILLEGAL_CLASS] ch 1 
> > [003fbce000 DRM] subc 3 class  mthd 085c data 0420
> >
> > On the following hardware:
> > lspci -s 01:00.0
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro FX 
> > 880M] (rev a2)
> > lspci -ns 01:00.0
> > 01:00.0 0300: 10de:0a3c (rev a2)
> >
> > Fixes: 64f7c698bea9 ("drm/nouveau/fifo: add engine_id hook")
> > Signed-off-by: Marek Vasut 
> > Cc:  # 5.12+
> > Cc: Ben Skeggs 
> > Cc: Karol Herbst 
> > Cc: Lyude Paul 
> > ---
> >  drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c 
> > b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c
> > index 353b77d9b3dc..3492c561f2cf 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c
> > @@ -82,7 +82,7 @@ g84_fifo_chan_engine_fini(struct nvkm_fifo_chan *base,
> > if (offset < 0)
> > return 0;
> >
> > -   engn = fifo->base.func->engine_id(>base, engine);
> > +   engn = fifo->base.func->engine_id(>base, engine) - 1;
> > save = nvkm_mask(device, 0x002520, 0x003f, 1 << engn);
> > nvkm_wr32(device, 0x0032fc, chan->base.inst->addr >> 12);
> > done = nvkm_msec(device, 2000,
> > --
> > 2.33.0
> >
>


[PATCH] drm/nouveau/fifo/ga102: initialise chid on return from channel creation

2021-09-21 Thread Ben Skeggs
From: Ben Skeggs 

Turns out caller isn't zero-initialised after-all.

Fixes: 6b457230bfa1 ("drm/nouveau/ga102-: support ttm buffer moves via copy 
engine")
Reported-by: Karol Herbst 
Signed-off-by: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c
index f897bef13acf..c630dbd2911a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c
@@ -179,6 +179,9 @@ ga102_chan_new(struct nvkm_device *device,
return -ENODEV;
 
chan->ctrl.chan = nvkm_rd32(device, chan->ctrl.runl + 0x004) & 
0xfff0;
+
+   args->chid = 0;
+   args->inst = 0;
args->token = nvkm_rd32(device, chan->ctrl.runl + 0x008) & 0x;
 
ret = nvkm_memory_new(device, NVKM_MEM_TARGET_INST, 0x1000, 0x1000, 
true, >mthd);
-- 
2.31.1



[PATCH v2] drm/nouveau/ga102-: support ttm buffer moves via copy engine

2021-09-16 Thread Ben Skeggs
From: Ben Skeggs 

We don't currently have any kind of real acceleration on Ampere GPUs,
but the TTM memcpy() fallback paths aren't really designed to handle
copies between different devices, such as on Optimus systems, and
result in a kernel OOPS.

A few options were investigated to try and fix this, but didn't work
out, and likely would have resulted in a very unpleasant experience
for users anyway.

This commit adds just enough support for setting up a single channel
connected to a copy engine, which the kernel can use to accelerate
the buffer copies between devices.  Userspace has no access to this
incomplete channel support, but it's suitable for TTM's needs.

A more complete implementation of host(fifo) for Ampere GPUs is in
the works, but the required changes are far too invasive that they
would be unsuitable to backport to fix this issue on current kernels.

v2: fix GPFIFO length in RAMFC (reported by Karol)

Signed-off-by: Ben Skeggs 
Cc: Lyude Paul 
Cc: Karol Herbst 
Cc:  # v5.12+
Reviewed-by: Karol Herbst 
Signed-off-by: Karol Herbst 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20210906005628.11499-1-skeg...@gmail.com
---
 drivers/gpu/drm/nouveau/include/nvif/class.h  |   2 +
 .../drm/nouveau/include/nvkm/engine/fifo.h|   1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c  |   1 +
 drivers/gpu/drm/nouveau/nouveau_chan.c|   6 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c |   4 +
 drivers/gpu/drm/nouveau/nv84_fence.c  |   2 +-
 .../gpu/drm/nouveau/nvkm/engine/device/base.c |   3 +
 .../gpu/drm/nouveau/nvkm/engine/fifo/Kbuild   |   1 +
 .../gpu/drm/nouveau/nvkm/engine/fifo/ga102.c  | 308 ++
 .../gpu/drm/nouveau/nvkm/subdev/top/ga100.c   |   7 +-
 10 files changed, 329 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c

diff --git a/drivers/gpu/drm/nouveau/include/nvif/class.h 
b/drivers/gpu/drm/nouveau/include/nvif/class.h
index c68cc957248e..a582c0cb0cb0 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/class.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/class.h
@@ -71,6 +71,7 @@
 #define PASCAL_CHANNEL_GPFIFO_A   /* cla06f.h */ 0xc06f
 #define VOLTA_CHANNEL_GPFIFO_A/* clc36f.h */ 0xc36f
 #define TURING_CHANNEL_GPFIFO_A   /* clc36f.h */ 0xc46f
+#define AMPERE_CHANNEL_GPFIFO_B   /* clc36f.h */ 0xc76f
 
 #define NV50_DISP /* cl5070.h */ 0x5070
 #define G82_DISP  /* cl5070.h */ 0x8270
@@ -200,6 +201,7 @@
 #define PASCAL_DMA_COPY_B0xc1b5
 #define VOLTA_DMA_COPY_A 0xc3b5
 #define TURING_DMA_COPY_A0xc5b5
+#define AMPERE_DMA_COPY_B0xc7b5
 
 #define FERMI_DECOMPRESS 0x90b8
 
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h 
b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
index 54fab7cc36c1..64ee82c7c1be 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
@@ -77,4 +77,5 @@ int gp100_fifo_new(struct nvkm_device *, enum 
nvkm_subdev_type, int inst, struct
 int gp10b_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
struct nvkm_fifo **);
 int gv100_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
struct nvkm_fifo **);
 int tu102_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
struct nvkm_fifo **);
+int ga102_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
struct nvkm_fifo **);
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 6d07e653f82d..c58bcdba2c7a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -844,6 +844,7 @@ nouveau_bo_move_init(struct nouveau_drm *drm)
struct ttm_resource *, struct ttm_resource *);
int (*init)(struct nouveau_channel *, u32 handle);
} _methods[] = {
+   {  "COPY", 4, 0xc7b5, nve0_bo_move_copy, nve0_bo_move_init },
{  "COPY", 4, 0xc5b5, nve0_bo_move_copy, nve0_bo_move_init },
{  "GRCE", 0, 0xc5b5, nve0_bo_move_copy, nvc0_bo_move_init },
{  "COPY", 4, 0xc3b5, nve0_bo_move_copy, nve0_bo_move_init },
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 80099ef75702..ea7769135b0d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -250,7 +250,8 @@ static int
 nouveau_channel_ind(struct nouveau_drm *drm, struct nvif_device *device,
u64 runlist, bool priv, struct nouveau_

Re: [PATCH 1/2] drm/nouveau/ga102-: support ttm buffer moves via copy engine

2021-09-08 Thread Ben Skeggs
On Thu, 9 Sept 2021 at 04:19, Daniel Vetter  wrote:
>
> On Mon, Sep 06, 2021 at 10:56:27AM +1000, Ben Skeggs wrote:
> > From: Ben Skeggs 
> >
> > We don't currently have any kind of real acceleration on Ampere GPUs,
> > but the TTM memcpy() fallback paths aren't really designed to handle
> > copies between different devices, such as on Optimus systems, and
> > result in a kernel OOPS.
>
> Is this just for moving a buffer from vram to system memory when you pin
> it for dma-buf? I'm kinda lost what you even use ttm bo moves for if
> there's no one using the gpu.
It occurs when we attempt to move the buffer into vram for scanout,
through the modeset paths.

>
> Also I guess memcpy goes boom if you can't mmap it because it's outside
> the gart? Or just that it's very slow. We're trying to use ttm memcyp as
> fallback, so want to know how this can all go wrong :-)
Neither ttm_kmap_iter_linear_io_init() nor ttm_kmap_iter_tt_init() are
able to work with the imported dma-buf object, which can obviously be
fixed.

But.  I then attempted to hack that up with a custom memcpy() for that
situation to test it, using dma_buf_vmap(), and get stuck forever
inside i915 waiting for the gem object lock.

Ben.

> -Daniel
>
> >
> > A few options were investigated to try and fix this, but didn't work
> > out, and likely would have resulted in a very unpleasant experience
> > for users anyway.
> >
> > This commit adds just enough support for setting up a single channel
> > connected to a copy engine, which the kernel can use to accelerate
> > the buffer copies between devices.  Userspace has no access to this
> > incomplete channel support, but it's suitable for TTM's needs.
> >
> > A more complete implementation of host(fifo) for Ampere GPUs is in
> > the works, but the required changes are far too invasive that they
> > would be unsuitable to backport to fix this issue on current kernels.
> >
> > Signed-off-by: Ben Skeggs 
> > Cc: Lyude Paul 
> > Cc: Karol Herbst 
> > Cc:  # v5.12+
> > ---
> >  drivers/gpu/drm/nouveau/include/nvif/class.h  |   2 +
> >  .../drm/nouveau/include/nvkm/engine/fifo.h|   1 +
> >  drivers/gpu/drm/nouveau/nouveau_bo.c  |   1 +
> >  drivers/gpu/drm/nouveau/nouveau_chan.c|   6 +-
> >  drivers/gpu/drm/nouveau/nouveau_drm.c |   4 +
> >  drivers/gpu/drm/nouveau/nv84_fence.c  |   2 +-
> >  .../gpu/drm/nouveau/nvkm/engine/device/base.c |   3 +
> >  .../gpu/drm/nouveau/nvkm/engine/fifo/Kbuild   |   1 +
> >  .../gpu/drm/nouveau/nvkm/engine/fifo/ga102.c  | 308 ++
> >  .../gpu/drm/nouveau/nvkm/subdev/top/ga100.c   |   7 +-
> >  10 files changed, 329 insertions(+), 6 deletions(-)
> >  create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c
> >
> > diff --git a/drivers/gpu/drm/nouveau/include/nvif/class.h 
> > b/drivers/gpu/drm/nouveau/include/nvif/class.h
> > index c68cc957248e..a582c0cb0cb0 100644
> > --- a/drivers/gpu/drm/nouveau/include/nvif/class.h
> > +++ b/drivers/gpu/drm/nouveau/include/nvif/class.h
> > @@ -71,6 +71,7 @@
> >  #define PASCAL_CHANNEL_GPFIFO_A   /* cla06f.h */ 
> > 0xc06f
> >  #define VOLTA_CHANNEL_GPFIFO_A/* clc36f.h */ 
> > 0xc36f
> >  #define TURING_CHANNEL_GPFIFO_A   /* clc36f.h */ 
> > 0xc46f
> > +#define AMPERE_CHANNEL_GPFIFO_B   /* clc36f.h */ 
> > 0xc76f
> >
> >  #define NV50_DISP /* cl5070.h */ 
> > 0x5070
> >  #define G82_DISP  /* cl5070.h */ 
> > 0x8270
> > @@ -200,6 +201,7 @@
> >  #define PASCAL_DMA_COPY_B
> > 0xc1b5
> >  #define VOLTA_DMA_COPY_A 
> > 0xc3b5
> >  #define TURING_DMA_COPY_A
> > 0xc5b5
> > +#define AMPERE_DMA_COPY_B
> > 0xc7b5
> >
> >  #define FERMI_DECOMPRESS 
> > 0x90b8
> >
> > diff --git a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h 
> > b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
> > index 54fab7cc36c1..64ee82c7c1be 100644
> > --- a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
> > +++ b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
> > @@ -77,4 +77,5 @@ int gp100_fifo_new(struct nvkm_device *, enum 
> > nvkm_subdev_type, int inst, struct
> >  int gp10b_fifo_new(struc

Re: [PATCH 1/2] drm/nouveau/ga102-: support ttm buffer moves via copy engine

2021-09-06 Thread Ben Skeggs
On Tue, 7 Sept 2021 at 10:28, Karol Herbst  wrote:
>
> On Tue, Sep 7, 2021 at 1:28 AM Ben Skeggs  wrote:
> >
> > On Tue, 7 Sept 2021 at 09:17, Karol Herbst  wrote:
> > >
> > > ."
> > >
> > >
> > > On Mon, Sep 6, 2021 at 2:56 AM Ben Skeggs  wrote:
> > > >
> > > > From: Ben Skeggs 
> > > >
> > > > We don't currently have any kind of real acceleration on Ampere GPUs,
> > > > but the TTM memcpy() fallback paths aren't really designed to handle
> > > > copies between different devices, such as on Optimus systems, and
> > > > result in a kernel OOPS.
> > > >
> > > > A few options were investigated to try and fix this, but didn't work
> > > > out, and likely would have resulted in a very unpleasant experience
> > > > for users anyway.
> > > >
> > > > This commit adds just enough support for setting up a single channel
> > > > connected to a copy engine, which the kernel can use to accelerate
> > > > the buffer copies between devices.  Userspace has no access to this
> > > > incomplete channel support, but it's suitable for TTM's needs.
> > > >
> > > > A more complete implementation of host(fifo) for Ampere GPUs is in
> > > > the works, but the required changes are far too invasive that they
> > > > would be unsuitable to backport to fix this issue on current kernels.
> > > >
> > > > Signed-off-by: Ben Skeggs 
> > > > Cc: Lyude Paul 
> > > > Cc: Karol Herbst 
> > > > Cc:  # v5.12+
> > > > ---
> > > >  drivers/gpu/drm/nouveau/include/nvif/class.h  |   2 +
> > > >  .../drm/nouveau/include/nvkm/engine/fifo.h|   1 +
> > > >  drivers/gpu/drm/nouveau/nouveau_bo.c  |   1 +
> > > >  drivers/gpu/drm/nouveau/nouveau_chan.c|   6 +-
> > > >  drivers/gpu/drm/nouveau/nouveau_drm.c |   4 +
> > > >  drivers/gpu/drm/nouveau/nv84_fence.c  |   2 +-
> > > >  .../gpu/drm/nouveau/nvkm/engine/device/base.c |   3 +
> > > >  .../gpu/drm/nouveau/nvkm/engine/fifo/Kbuild   |   1 +
> > > >  .../gpu/drm/nouveau/nvkm/engine/fifo/ga102.c  | 308 ++
> > > >  .../gpu/drm/nouveau/nvkm/subdev/top/ga100.c   |   7 +-
> > > >  10 files changed, 329 insertions(+), 6 deletions(-)
> > > >  create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c
> > > >
> > > > diff --git a/drivers/gpu/drm/nouveau/include/nvif/class.h 
> > > > b/drivers/gpu/drm/nouveau/include/nvif/class.h
> > > > index c68cc957248e..a582c0cb0cb0 100644
> > > > --- a/drivers/gpu/drm/nouveau/include/nvif/class.h
> > > > +++ b/drivers/gpu/drm/nouveau/include/nvif/class.h
> > > > @@ -71,6 +71,7 @@
> > > >  #define PASCAL_CHANNEL_GPFIFO_A   /* cla06f.h */ 
> > > > 0xc06f
> > > >  #define VOLTA_CHANNEL_GPFIFO_A/* clc36f.h */ 
> > > > 0xc36f
> > > >  #define TURING_CHANNEL_GPFIFO_A   /* clc36f.h */ 
> > > > 0xc46f
> > > > +#define AMPERE_CHANNEL_GPFIFO_B   /* clc36f.h */ 
> > > > 0xc76f
> > > >
> > > >  #define NV50_DISP /* cl5070.h */ 
> > > > 0x5070
> > > >  #define G82_DISP  /* cl5070.h */ 
> > > > 0x8270
> > > > @@ -200,6 +201,7 @@
> > > >  #define PASCAL_DMA_COPY_B
> > > > 0xc1b5
> > > >  #define VOLTA_DMA_COPY_A 
> > > > 0xc3b5
> > > >  #define TURING_DMA_COPY_A
> > > > 0xc5b5
> > > > +#define AMPERE_DMA_COPY_B
> > > > 0xc7b5
> > > >
> > > >  #define FERMI_DECOMPRESS 
> > > > 0x90b8
> > > >
> > > > diff --git a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h 
> > > > b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
> > > > index 54fab7cc36c1..64ee82c7c1be 100644
> > > > --- a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
> > > > +++ b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
> > > > @@ -77,4 +77,5 @@ int gp100_fifo_new(

Re: [PATCH 1/2] drm/nouveau/ga102-: support ttm buffer moves via copy engine

2021-09-06 Thread Ben Skeggs
On Tue, 7 Sept 2021 at 09:17, Karol Herbst  wrote:
>
> ."
>
>
> On Mon, Sep 6, 2021 at 2:56 AM Ben Skeggs  wrote:
> >
> > From: Ben Skeggs 
> >
> > We don't currently have any kind of real acceleration on Ampere GPUs,
> > but the TTM memcpy() fallback paths aren't really designed to handle
> > copies between different devices, such as on Optimus systems, and
> > result in a kernel OOPS.
> >
> > A few options were investigated to try and fix this, but didn't work
> > out, and likely would have resulted in a very unpleasant experience
> > for users anyway.
> >
> > This commit adds just enough support for setting up a single channel
> > connected to a copy engine, which the kernel can use to accelerate
> > the buffer copies between devices.  Userspace has no access to this
> > incomplete channel support, but it's suitable for TTM's needs.
> >
> > A more complete implementation of host(fifo) for Ampere GPUs is in
> > the works, but the required changes are far too invasive that they
> > would be unsuitable to backport to fix this issue on current kernels.
> >
> > Signed-off-by: Ben Skeggs 
> > Cc: Lyude Paul 
> > Cc: Karol Herbst 
> > Cc:  # v5.12+
> > ---
> >  drivers/gpu/drm/nouveau/include/nvif/class.h  |   2 +
> >  .../drm/nouveau/include/nvkm/engine/fifo.h|   1 +
> >  drivers/gpu/drm/nouveau/nouveau_bo.c  |   1 +
> >  drivers/gpu/drm/nouveau/nouveau_chan.c|   6 +-
> >  drivers/gpu/drm/nouveau/nouveau_drm.c |   4 +
> >  drivers/gpu/drm/nouveau/nv84_fence.c  |   2 +-
> >  .../gpu/drm/nouveau/nvkm/engine/device/base.c |   3 +
> >  .../gpu/drm/nouveau/nvkm/engine/fifo/Kbuild   |   1 +
> >  .../gpu/drm/nouveau/nvkm/engine/fifo/ga102.c  | 308 ++
> >  .../gpu/drm/nouveau/nvkm/subdev/top/ga100.c   |   7 +-
> >  10 files changed, 329 insertions(+), 6 deletions(-)
> >  create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c
> >
> > diff --git a/drivers/gpu/drm/nouveau/include/nvif/class.h 
> > b/drivers/gpu/drm/nouveau/include/nvif/class.h
> > index c68cc957248e..a582c0cb0cb0 100644
> > --- a/drivers/gpu/drm/nouveau/include/nvif/class.h
> > +++ b/drivers/gpu/drm/nouveau/include/nvif/class.h
> > @@ -71,6 +71,7 @@
> >  #define PASCAL_CHANNEL_GPFIFO_A   /* cla06f.h */ 
> > 0xc06f
> >  #define VOLTA_CHANNEL_GPFIFO_A/* clc36f.h */ 
> > 0xc36f
> >  #define TURING_CHANNEL_GPFIFO_A   /* clc36f.h */ 
> > 0xc46f
> > +#define AMPERE_CHANNEL_GPFIFO_B   /* clc36f.h */ 
> > 0xc76f
> >
> >  #define NV50_DISP /* cl5070.h */ 
> > 0x5070
> >  #define G82_DISP  /* cl5070.h */ 
> > 0x8270
> > @@ -200,6 +201,7 @@
> >  #define PASCAL_DMA_COPY_B
> > 0xc1b5
> >  #define VOLTA_DMA_COPY_A 
> > 0xc3b5
> >  #define TURING_DMA_COPY_A
> > 0xc5b5
> > +#define AMPERE_DMA_COPY_B
> > 0xc7b5
> >
> >  #define FERMI_DECOMPRESS 
> > 0x90b8
> >
> > diff --git a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h 
> > b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
> > index 54fab7cc36c1..64ee82c7c1be 100644
> > --- a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
> > +++ b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
> > @@ -77,4 +77,5 @@ int gp100_fifo_new(struct nvkm_device *, enum 
> > nvkm_subdev_type, int inst, struct
> >  int gp10b_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
> > struct nvkm_fifo **);
> >  int gv100_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
> > struct nvkm_fifo **);
> >  int tu102_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
> > struct nvkm_fifo **);
> > +int ga102_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
> > struct nvkm_fifo **);
> >  #endif
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index 4a7cebac8060..b3e4f555fa05 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -844,6 +844,7 @@ nouveau_bo_move_init(struct nouveau_drm *drm)
> > str

[PATCH 2/2] drm/nouveau/kms/tu102-: delay enabling cursor until after assign_windows

2021-09-05 Thread Ben Skeggs
From: Ben Skeggs 

Prevent NVD core channel error code 67 occuring and hanging display,
managed to reproduce on GA102 while testing suspend/resume scenarios.

Required extension of earlier commit to fix interactions with EFI.

Fixes: e78b1b545c6c ("drm/nouveau/kms/nv50: workaround EFI GOP window channel 
format differences").
Signed-off-by: Ben Skeggs 
Cc: Lyude Paul 
Cc: Karol Herbst 
Cc:  # v5.12+
---
 drivers/gpu/drm/nouveau/dispnv50/head.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index f8438a886b64..c3c57be54e1c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -52,6 +52,7 @@ nv50_head_flush_clr(struct nv50_head *head,
 void
 nv50_head_flush_set_wndw(struct nv50_head *head, struct nv50_head_atom *asyh)
 {
+   if (asyh->set.curs   ) head->func->curs_set(head, asyh);
if (asyh->set.olut   ) {
asyh->olut.offset = nv50_lut_load(>olut,
  asyh->olut.buffer,
@@ -67,7 +68,6 @@ nv50_head_flush_set(struct nv50_head *head, struct 
nv50_head_atom *asyh)
if (asyh->set.view   ) head->func->view(head, asyh);
if (asyh->set.mode   ) head->func->mode(head, asyh);
if (asyh->set.core   ) head->func->core_set(head, asyh);
-   if (asyh->set.curs   ) head->func->curs_set(head, asyh);
if (asyh->set.base   ) head->func->base(head, asyh);
if (asyh->set.ovly   ) head->func->ovly(head, asyh);
if (asyh->set.dither ) head->func->dither  (head, asyh);
-- 
2.31.1



[PATCH 1/2] drm/nouveau/ga102-: support ttm buffer moves via copy engine

2021-09-05 Thread Ben Skeggs
From: Ben Skeggs 

We don't currently have any kind of real acceleration on Ampere GPUs,
but the TTM memcpy() fallback paths aren't really designed to handle
copies between different devices, such as on Optimus systems, and
result in a kernel OOPS.

A few options were investigated to try and fix this, but didn't work
out, and likely would have resulted in a very unpleasant experience
for users anyway.

This commit adds just enough support for setting up a single channel
connected to a copy engine, which the kernel can use to accelerate
the buffer copies between devices.  Userspace has no access to this
incomplete channel support, but it's suitable for TTM's needs.

A more complete implementation of host(fifo) for Ampere GPUs is in
the works, but the required changes are far too invasive that they
would be unsuitable to backport to fix this issue on current kernels.

Signed-off-by: Ben Skeggs 
Cc: Lyude Paul 
Cc: Karol Herbst 
Cc:  # v5.12+
---
 drivers/gpu/drm/nouveau/include/nvif/class.h  |   2 +
 .../drm/nouveau/include/nvkm/engine/fifo.h|   1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c  |   1 +
 drivers/gpu/drm/nouveau/nouveau_chan.c|   6 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c |   4 +
 drivers/gpu/drm/nouveau/nv84_fence.c  |   2 +-
 .../gpu/drm/nouveau/nvkm/engine/device/base.c |   3 +
 .../gpu/drm/nouveau/nvkm/engine/fifo/Kbuild   |   1 +
 .../gpu/drm/nouveau/nvkm/engine/fifo/ga102.c  | 308 ++
 .../gpu/drm/nouveau/nvkm/subdev/top/ga100.c   |   7 +-
 10 files changed, 329 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c

diff --git a/drivers/gpu/drm/nouveau/include/nvif/class.h 
b/drivers/gpu/drm/nouveau/include/nvif/class.h
index c68cc957248e..a582c0cb0cb0 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/class.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/class.h
@@ -71,6 +71,7 @@
 #define PASCAL_CHANNEL_GPFIFO_A   /* cla06f.h */ 0xc06f
 #define VOLTA_CHANNEL_GPFIFO_A/* clc36f.h */ 0xc36f
 #define TURING_CHANNEL_GPFIFO_A   /* clc36f.h */ 0xc46f
+#define AMPERE_CHANNEL_GPFIFO_B   /* clc36f.h */ 0xc76f
 
 #define NV50_DISP /* cl5070.h */ 0x5070
 #define G82_DISP  /* cl5070.h */ 0x8270
@@ -200,6 +201,7 @@
 #define PASCAL_DMA_COPY_B0xc1b5
 #define VOLTA_DMA_COPY_A 0xc3b5
 #define TURING_DMA_COPY_A0xc5b5
+#define AMPERE_DMA_COPY_B0xc7b5
 
 #define FERMI_DECOMPRESS 0x90b8
 
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h 
b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
index 54fab7cc36c1..64ee82c7c1be 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h
@@ -77,4 +77,5 @@ int gp100_fifo_new(struct nvkm_device *, enum 
nvkm_subdev_type, int inst, struct
 int gp10b_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
struct nvkm_fifo **);
 int gv100_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
struct nvkm_fifo **);
 int tu102_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
struct nvkm_fifo **);
+int ga102_fifo_new(struct nvkm_device *, enum nvkm_subdev_type, int inst, 
struct nvkm_fifo **);
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4a7cebac8060..b3e4f555fa05 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -844,6 +844,7 @@ nouveau_bo_move_init(struct nouveau_drm *drm)
struct ttm_resource *, struct ttm_resource *);
int (*init)(struct nouveau_channel *, u32 handle);
} _methods[] = {
+   {  "COPY", 4, 0xc7b5, nve0_bo_move_copy, nve0_bo_move_init },
{  "COPY", 4, 0xc5b5, nve0_bo_move_copy, nve0_bo_move_init },
{  "GRCE", 0, 0xc5b5, nve0_bo_move_copy, nvc0_bo_move_init },
{  "COPY", 4, 0xc3b5, nve0_bo_move_copy, nve0_bo_move_init },
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 80099ef75702..ea7769135b0d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -250,7 +250,8 @@ static int
 nouveau_channel_ind(struct nouveau_drm *drm, struct nvif_device *device,
u64 runlist, bool priv, struct nouveau_channel **pchan)
 {
-   static const u16 oclasses[] = { TURING_CHANNEL_GPFIFO_A,
+   static const u16 oclasses[] = { AMPERE_CHANNEL_GPFIFO_B,
+  

Re: [PATCH] drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource

2021-08-30 Thread Ben Skeggs
On Mon, 30 Aug 2021 at 17:48, Thomas Hellström
 wrote:
>
> The code was making a copy of a struct ttm_resource. However,
> recently the struct ttm_resources were allowed to be subclassed and
> also were allowed to be malloced, hence the driver could end up assuming
> the copy we handed it was subclassed and worse, the original could have
> been freed at this point.
>
> Fix this by using the original struct ttm_resource before it is
> potentially freed in ttm_bo_move_sync_cleanup()
>
> Reported-by: Ben Skeggs 
> Reported-by: Dave Airlie 
> Cc: Christian König 
> Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based 
> iomem")
> Signed-off-by: Thomas Hellström 
That's basically identical to what I came up with locally, so:

Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/ttm/ttm_bo_util.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 5c20d0541cc3..c893c3db2623 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -139,7 +139,6 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
> struct ttm_resource *src_mem = bo->resource;
> struct ttm_resource_manager *src_man =
> ttm_manager_type(bdev, src_mem->mem_type);
> -   struct ttm_resource src_copy = *src_mem;
> union {
> struct ttm_kmap_iter_tt tt;
> struct ttm_kmap_iter_linear_io io;
> @@ -173,11 +172,10 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
> if (!(clear && ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)))
> ttm_move_memcpy(clear, dst_mem->num_pages, dst_iter, 
> src_iter);
>
> -   src_copy = *src_mem;
> +   if (!src_iter->ops->maps_tt)
> +   ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, src_mem);
> ttm_bo_move_sync_cleanup(bo, dst_mem);
>
> -   if (!src_iter->ops->maps_tt)
> -   ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, _copy);
>  out_src_iter:
> if (!dst_iter->ops->maps_tt)
> ttm_kmap_iter_linear_io_fini(&_dst_iter.io, bdev, dst_mem);
> --
> 2.31.1
>


[PULL] nouveau-fixes 5.14

2021-08-18 Thread Ben Skeggs
Hey,

Just a couple fixes for Ampere display issues, and a long-standing
race in MM paths.

Ben.

The following changes since commit 7c60610d476766e128cc4284bb6349732cbd6606:

  Linux 5.14-rc6 (2021-08-15 13:40:53 -1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.14

for you to fetch changes up to 59f216cf04d973b4316761cbf3e7cb9556715b7a:

  drm/nouveau: rip out nvkm_client.super (2021-08-18 19:00:15 +1000)


Ben Skeggs (6):
  drm/nouveau: recognise GA107
  drm/nouveau/disp: power down unused DP links during init
  drm/nouveau/kms/nv50: workaround EFI GOP window channel format differences
  drm/nouveau/fifo/nv50-: rip out dma channels
  drm/nouveau: block a bunch of classes from userspace
  drm/nouveau: rip out nvkm_client.super

 drivers/gpu/drm/nouveau/dispnv50/disp.c| 27 +++
 drivers/gpu/drm/nouveau/dispnv50/head.c| 13 --
 drivers/gpu/drm/nouveau/dispnv50/head.h|  1 +
 drivers/gpu/drm/nouveau/include/nvif/cl0080.h  |  3 +-
 drivers/gpu/drm/nouveau/include/nvif/class.h   |  2 -
 drivers/gpu/drm/nouveau/include/nvif/client.h  |  1 -
 drivers/gpu/drm/nouveau/include/nvif/driver.h  |  2 +-
 drivers/gpu/drm/nouveau/include/nvkm/core/client.h |  1 -
 drivers/gpu/drm/nouveau/include/nvkm/core/ioctl.h  |  2 +-
 drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h  |  1 -
 drivers/gpu/drm/nouveau/nouveau_abi16.c|  2 -
 drivers/gpu/drm/nouveau/nouveau_chan.c | 19 +---
 drivers/gpu/drm/nouveau/nouveau_drm.c  |  3 +-
 drivers/gpu/drm/nouveau/nouveau_mem.c  | 15 +-
 drivers/gpu/drm/nouveau/nouveau_nvif.c |  4 +-
 drivers/gpu/drm/nouveau/nouveau_svm.c  |  9 
 drivers/gpu/drm/nouveau/nouveau_usif.c | 57
+--
 drivers/gpu/drm/nouveau/nvif/client.c  |  3 +-
 drivers/gpu/drm/nouveau/nvif/object.c  |  3 +-
 drivers/gpu/drm/nouveau/nvkm/core/ioctl.c  |  4 +-
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  | 21 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/user.c  |  2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c  |  2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.h  |  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c|  9 
 drivers/gpu/drm/nouveau/nvkm/engine/dma/user.c | 15 --
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/Kbuild|  2 -
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/channv50.h|  2 -
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmag84.c  | 94
--
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv50.c | 92
-
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/g84.c |  1 -
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c |  2 -
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogv100.c |  2 -
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifotu102.c |  2 -
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv50.c|  1 -
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/umem.c |  6 +--
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/umem.h |  1 -
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/ummu.c |  2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c | 27 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c  |  6 +--
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 16 +++
 41 files changed, 144 insertions(+), 334 deletions(-)
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmag84.c
 delete mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv50.c


Re: [PATCH v8 8/8] nouveau/svm: Implement atomic SVM access

2021-05-20 Thread Ben Skeggs
On Wed, 7 Apr 2021 at 18:43, Alistair Popple  wrote:
>
> Some NVIDIA GPUs do not support direct atomic access to system memory
> via PCIe. Instead this must be emulated by granting the GPU exclusive
> access to the memory. This is achieved by replacing CPU page table
> entries with special swap entries that fault on userspace access.
>
> The driver then grants the GPU permission to update the page undergoing
> atomic access via the GPU page tables. When CPU access to the page is
> required a CPU fault is raised which calls into the device driver via
> MMU 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 values for fault access levels
> * Improved readability of fault comparison code
>
> v4:
> * Check that page table entries haven't changed before mapping on the
>   device
> ---
>  drivers/gpu/drm/nouveau/include/nvif/if000c.h |   1 +
>  drivers/gpu/drm/nouveau/nouveau_svm.c | 126 --
>  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h |   1 +
>  .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c|   6 +
>  4 files changed, 123 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h 
> b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
> index d6dd40f21eed..9c7ff56831c5 100644
> --- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
> +++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
> @@ -77,6 +77,7 @@ struct nvif_vmm_pfnmap_v0 {
>  #define NVIF_VMM_PFNMAP_V0_APER   
> 0x00f0ULL
>  #define NVIF_VMM_PFNMAP_V0_HOST   
> 0xULL
>  #define NVIF_VMM_PFNMAP_V0_VRAM   
> 0x0010ULL
> +#define NVIF_VMM_PFNMAP_V0_A 
> 0x0004ULL
>  #define NVIF_VMM_PFNMAP_V0_W  
> 0x0002ULL
>  #define NVIF_VMM_PFNMAP_V0_V  
> 0x0001ULL
>  #define NVIF_VMM_PFNMAP_V0_NONE   
> 0xULL
> diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c 
> b/drivers/gpu/drm/nouveau/nouveau_svm.c
> index a195e48c9aee..81526d65b4e2 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_svm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  struct nouveau_svm {
> struct nouveau_drm *drm;
> @@ -67,6 +68,11 @@ struct nouveau_svm {
> } buffer[1];
>  };
>
> +#define FAULT_ACCESS_READ 0
> +#define FAULT_ACCESS_WRITE 1
> +#define FAULT_ACCESS_ATOMIC 2
> +#define FAULT_ACCESS_PREFETCH 3
> +
>  #define SVM_DBG(s,f,a...) NV_DEBUG((s)->drm, "svm: "f"\n", ##a)
>  #define SVM_ERR(s,f,a...) NV_WARN((s)->drm, "svm: "f"\n", ##a)
>
> @@ -411,6 +417,24 @@ nouveau_svm_fault_cancel_fault(struct nouveau_svm *svm,
>   fault->client);
>  }
>
> +static int
> +nouveau_svm_fault_priority(u8 fault)
> +{
> +   switch (fault) {
> +   case FAULT_ACCESS_PREFETCH:
> +   return 0;
> +   case FAULT_ACCESS_READ:
> +   return 1;
> +   case FAULT_ACCESS_WRITE:
> +   return 2;
> +   case FAULT_ACCESS_ATOMIC:
> +   return 3;
> +   default:
> +   WARN_ON_ONCE(1);
> +   return -1;
> +   }
> +}
> +
>  static int
>  nouveau_svm_fault_cmp(const void *a, const void *b)
>  {
> @@ -421,9 +445,8 @@ nouveau_svm_fault_cmp(const void *a, const void *b)
> return ret;
> if ((ret = (s64)fa->addr - fb->addr))
> return ret;
> -   /*XXX: atomic? */
> -   return (fa->access == 0 || fa->access == 3) -
> -  (fb->access == 0 || fb->access == 3);
> +   return nouveau_svm_fault_priority(fa->access) -
> +   nouveau_svm_fault_priority(fb->access);
>  }
>
>  static void
> @@ -487,6 +510,10 @@ static bool nouveau_svm_range_invalidate(struct 
> mmu_interval_notifier *mni,
> struct svm_notifier *sn =
> container_of(mni, struct svm_notifier, notifier);
>
> +   if (range->event == MMU_NOTIFY_EXCLUSIVE &&
> +   range->owner == sn->svmm->vmm->cli->drm->dev)
> +   return true;
> +
> /*
>  * serializes the update to mni->invalidate_seq done by caller and
>  *

[PULL] nouveau-fixes 5.12

2021-03-24 Thread Ben Skeggs
Single regression fix.

Thanks,
Ben.

The following changes since commit d27ce83fa4baa5cb908a42e9878564cad6ea0eb3:

  Merge tag 'du-fixes-20210316' of git://linuxtv.org/pinchartl/media
into drm-fixes (2021-03-22 13:49:55 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.12

for you to fetch changes up to d3999c1f7bbbc100c167d7ad3cd79c1d10446ba2:

  drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128 (2021-03-25
10:00:04 +1000)


Lyude Paul (1):
  drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128

 drivers/gpu/drm/nouveau/dispnv50/disp.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH] drm/nouveau/kms/nv04: use vzalloc for nv04_display

2021-03-24 Thread Ben Skeggs
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. Egge 
> Signed-off-by: Ilia Mirkin 
> Cc: sta...@vger.kernel.org
Thanks!

> ---
>  drivers/gpu/drm/nouveau/dispnv04/disp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> index 7739f46470d3..99fee4d8cd31 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> @@ -205,7 +205,7 @@ nv04_display_destroy(struct drm_device *dev)
> nvif_notify_dtor(>flip);
>
> nouveau_display(dev)->priv = NULL;
> -   kfree(disp);
> +   vfree(disp);
>
> nvif_object_unmap(>client.device.object);
>  }
> @@ -223,7 +223,7 @@ nv04_display_create(struct drm_device *dev)
> struct nv04_display *disp;
> int i, ret;
>
> -   disp = kzalloc(sizeof(*disp), GFP_KERNEL);
> +   disp = vzalloc(sizeof(*disp));
> if (!disp)
> return -ENOMEM;
>
> --
> 2.26.2
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] nouveau/nvkm/subdev/devinit/mcp89.c:Unneeded variable

2021-03-24 Thread Ben Skeggs
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/gpu/drm/nouveau/nvkm/subdev/devinit/mcp89.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/mcp89.c
> index fb90d47..a9cdf24 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/mcp89.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/mcp89.c
> @@ -32,7 +32,6 @@
> struct nvkm_device *device = init->subdev.device;
> u32 r001540 = nvkm_rd32(device, 0x001540);
> u32 r00154c = nvkm_rd32(device, 0x00154c);
> -   u64 disable = 0;
>
> if (!(r001540 & 0x4000)) {
> nvkm_subdev_disable(device, NVKM_ENGINE_MSPDEC, 0);
> @@ -48,7 +47,7 @@
> if (!(r00154c & 0x0200))
> nvkm_subdev_disable(device, NVKM_ENGINE_CE, 0);
>
> -   return disable;
> +   return 0;
>  }
>
>  static const struct nvkm_devinit_func
> --
> 1.9.1
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] drm/nouveau/kms/nv50-: Correct size checks for cursors

2021-03-24 Thread Ben Skeggs
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 cursor can be larger than the size of the cursor, as long as
> the width is the same as the cursor size and there's no framebuffer offset.
>
> Note that I'm not entirely sure why this wasn't previously breaking
> kms_cursor_crc tests - they all set up cursors with the height being one
> pixel larger than the actual size of the cursor. But this seems to fix
> things, and the code before was definitely incorrect - so it's not really
> worth looking into further imho.
>
> Changes since v1:
> * Don't use crtc_w everywhere for determining cursor layout, just use fb
>   size again
> * Change check so that we only check that the w/h of the cursor plane is
>   the same, the width of the scanout surface is the same as the framebuffer
>   width, and that there's no offset being used for the cursor surface.
>
> Signed-off-by: Lyude Paul 
> Cc: Martin Peres 
> Cc: Jeremy Cline 
Thanks Lyude!

> ---
>  drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c 
> b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> index 54fbd6fe751d..00e19fd959ea 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> @@ -98,6 +98,7 @@ static int
>  curs507a_acquire(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw,
>  struct nv50_head_atom *asyh)
>  {
> +   struct nouveau_drm *drm = nouveau_drm(wndw->plane.dev);
> struct nv50_head *head = nv50_head(asyw->state.crtc);
> int ret;
>
> @@ -109,8 +110,20 @@ curs507a_acquire(struct nv50_wndw *wndw, struct 
> nv50_wndw_atom *asyw,
> if (ret || !asyh->curs.visible)
> return ret;
>
> -   if (asyw->image.w != asyw->image.h)
> +   if (asyw->state.crtc_w != asyw->state.crtc_h) {
> +   NV_ATOMIC(drm, "Plane width/height must be equal for 
> cursors\n");
> return -EINVAL;
> +   }
> +
> +   if (asyw->image.w != asyw->state.crtc_w) {
> +   NV_ATOMIC(drm, "Plane width must be equal to fb width for 
> cursors (height can be larger though)\n");
> +   return -EINVAL;
> +   }
> +
> +   if (asyw->state.src_x || asyw->state.src_y) {
> +   NV_ATOMIC(drm, "Cursor planes do not support framebuffer 
> offsets\n");
> +   return -EINVAL;
> +   }
>
> ret = head->func->curs_layout(head, asyw, asyh);
> if (ret)
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH -next] drm/nouveau/core/client: Mark nvkm_uclient_sclass with static keyword

2021-03-24 Thread Ben Skeggs
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/nvkm/core/client.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/core/client.c 
> b/drivers/gpu/drm/nouveau/nvkm/core/client.c
> index ac671202919e..0c8c55c73b12 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/core/client.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/core/client.c
> @@ -60,7 +60,7 @@ nvkm_uclient_new(const struct nvkm_oclass *oclass, void 
> *argv, u32 argc,
> return 0;
>  }
>
> -const struct nvkm_sclass
> +static const struct nvkm_sclass
>  nvkm_uclient_sclass = {
> .oclass = NVIF_CLASS_CLIENT,
> .minver = 0,
> --
> 2.17.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] nouveau-fixes 5.12

2021-03-02 Thread Ben Skeggs
Hey,

A single regression fix here that I noticed while testing a bunch of
boards for something else, not sure where this got lost!  Prevents 3D
driver from initialising on some GPUs.

Ben.

The following changes since commit f6df392dddbb9e637b785e7e3d9337a74923dc10:

  drm/nouveau/top/ga100: initial support (2021-02-11 11:50:04 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux 00.00-inst

for you to fetch changes up to 78652ff69be439f7e925067c6a61b1839e531c01:

  drm/nouveau/fifo/gk104-gp1xx: fix creation of sw class (2021-03-02
21:48:42 +1000)


Ben Skeggs (1):
  drm/nouveau/fifo/gk104-gp1xx: fix creation of sw class

 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 3 +++
 1 file changed, 3 insertions(+)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] drm/nouveau/pmu: fix timeout on GP108

2021-02-24 Thread Ben Skeggs
On Wed, 17 Feb 2021 at 13:30, Alexandre Courbot  wrote:
>
> On Wed, Feb 17, 2021 at 1:20 AM Diego Viola  wrote:
> >
> > This code times out on GP108, probably because the BIOS puts it into a
> > bad state.
> >
> > Since we reset the PMU on driver load anyway, we are at no risk from
> > missing a response from it since we are not waiting for one to begin
> > with.
>
> This looks safe to me, provided indeed that the PMU's reset is not
> called outside of initialization (which for GP108 is shouldn't be
> IIRC?).
ISTR that the PMU FW we use prior to GM200 might depend on that being there.

I've posted a proposed alternate fix here[1], as we probably shouldn't
have been touching PMU there anyway on those GPUs.

Ben.

[1] 
https://github.com/skeggsb/linux/commit/90224a17437b1f39dbecbb385567c1fce958f992

>
> >
> > Signed-off-by: Diego Viola 
> > ---
> >  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c 
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c
> > index a0fe607c9c07..5c802f2d00cb 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c
> > @@ -102,12 +102,8 @@ nvkm_pmu_reset(struct nvkm_pmu *pmu)
> > if (!pmu->func->enabled(pmu))
> > return 0;
> >
> > -   /* Inhibit interrupts, and wait for idle. */
> > +   /* Inhibit interrupts. */
> > nvkm_wr32(device, 0x10a014, 0x);
> > -   nvkm_msec(device, 2000,
> > -   if (!nvkm_rd32(device, 0x10a04c))
> > -   break;
> > -   );
> >
> > /* Reset. */
> > if (pmu->func->reset)
> > --
> > 2.30.1
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] nouveau-next 5.12

2021-02-10 Thread Ben Skeggs
Hey,

This is super late in the cycle, but after talking it over with Dave,
it's probably best to get this in sooner rather than later.  The vast
majority of the changes are simple and repetitive, but invasive in
that the constructor function signature of every sub-device module for
every chipset is touched.

The problem is that GA100 added enough new engine types and instances
that we would have begun to overflow various u64 bitfields used to
track the connections between various engines.

A less-invasive solution that was considered would have been to begin
to alias with engine types that no longer exist on newer hardware, but
that'd have only gotten us so far for so long, and introduces the
possibility of subtle and hard-to-detect bugs moving forward.

Instead, rather than addressing subdevs by a unique index, we give
each subdev a type and instance id, and replace the use of bitfields
tied to subdev index with other methods.

Notable changes:
- replace subdev index with subdev type + instance id
- engines that turn out to be fused-off (can't detect until later in
init) no longer leave dangling pointers around
- new subdev/instance additions no longer need to be made in multiple places
- ampere engine topology is now being parsed

Ben.

The following changes since commit 4c3a3292730c56591472717d8c5c0faf74f6c6bb:

  drm/amd/display: fix unused variable warning (2021-02-05 09:49:44 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux 00.00-inst

for you to fetch changes up to f6df392dddbb9e637b785e7e3d9337a74923dc10:

  drm/nouveau/top/ga100: initial support (2021-02-11 11:50:04 +1000)


Ben Skeggs (87):
  drm/nouveau/engine: use refcount_t + private mutex
  drm/nouveau/fb: protect comptags with private mutex
  drm/nouveau/fb: protect vram mm with private mutex
  drm/nouveau/instmem: protect mm/lru with private mutex
  drm/nouveau/ltc: serialise cbc operations with private mutex
  drm/nouveau/mmu: serialise mmu invalidations with private mutex
  drm/nouveau/pmu: serialise send() with private mutex
  drm/nouveau/disp: use private spinlock to control exclusive access to disp
  drm/nouveau/fifo: private mutex
  drm/nouveau/perfmon: use private spinlock to control exclusive
access to perfmon
  drm/nouveau/subdev: remove nvkm_subdev.mutex
  drm/nouveau/subdev: store subdevs in list
  drm/nouveau/subdev: store full subdev name in struct
  drm/nouveau/subdev: track type+instance separately
  drm/nouveau/device: pass instance id when looking up a subdev/engine
  drm/nouveau/nvkm: add macros for subdev layout
  drm/nouveau/acr: switch to instanced constructor
  drm/nouveau/bar: switch to instanced constructor
  drm/nouveau/bios: switch to instanced constructor
  drm/nouveau/bus: switch to instanced constructor
  drm/nouveau/clk: switch to instanced constructor
  drm/nouveau/devinit: switch to instanced constructor
  drm/nouveau/fault: switch to instanced constructor
  drm/nouveau/fb: switch to instanced constructor
  drm/nouveau/fuse: switch to instanced constructor
  drm/nouveau/gpio: switch to instanced constructor
  drm/nouveau/gsp: switch to instanced constructor
  drm/nouveau/i2c: switch to instanced constructor
  drm/nouveau/ibus: switch to instanced constructor
  drm/nouveau/iccsense: switch to instanced constructor
  drm/nouveau/instmem: switch to instanced constructor
  drm/nouveau/ltc: switch to instanced constructor
  drm/nouveau/top: store device type and instance separately
  drm/nouveau/top: expose parsed device info more directly
  drm/nouveau/mc: switch to instanced constructor
  drm/nouveau/mc: lookup subdev interrupt handlers with split type+inst
  drm/nouveau/mc: use split type+inst in device reset APIs
  drm/nouveau/mc: use split type+inst in interrupt masking API
  drm/nouveau/mc: use split type+inst when handling dev_top interrupts
  drm/nouveau/mmu: switch to instanced constructor
  drm/nouveau/mmu: index engref by subdev type
  drm/nouveau/mxm: switch to instanced constructor
  drm/nouveau/pci: switch to instanced constructor
  drm/nouveau/pmu: switch to instanced constructor
  drm/nouveau/therm: switch to instanced constructor
  drm/nouveau/therm/gk104: use split subdev type+inst in cg engine lists
  drm/nouveau/tmr: switch to instanced constructor
  drm/nouveau/top: switch to instanced constructor
  drm/nouveau/volt: switch to instanced constructor
  drm/nouveau/bsp,vp: switch to instanced constructor
  drm/nouveau/falcon: use split type+inst when looking up PRI addr
  drm/nouveau/ce: switch to instanced constructor
  drm/nouveau/ce: make use of nvkm_subdev.inst
  drm/nouveau/cipher: switch to instanced constructor
  drm/nouveau/disp: switch to instanced constructor
  drm

nouveau-next 5.12

2021-01-28 Thread Ben Skeggs
Hey Dave,

Nothing too major here, I actually thought I'd sent most of these
right before the new year, but that apparently got lost in the bustle:
- Turing MMU fault recovery fixes
- Fix mDP connectors being reported as eDP to userspace
- Fixes for audio locking, and other bit-rot from DRM changes since
atomic support was written
- Misc other minor fixes.

Ben.

The following changes since commit bc96ad6722f86a377ed2872c9a4854c90caf78ca:

  Merge tag 'v5.11-rc5' of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into
drm-next (2021-01-25 14:35:44 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.12

for you to fetch changes up to d1f5a3fc85566e9ddce9361ef180f070367e6eab:

  drm/nouveau/kms: handle mDP connectors (2021-01-29 16:49:15 +1000)


Alistair Popple (5):
  drm/nouveau/mc/tu102: Fix MMU fault interrupts on Turing
  drm/nouveau/mc/tu102: Remove Turing interrupt hack
  drm/nouveau/fifo/tu102: Move Turing specific FIFO functions
  drm/nouveau/fifo/tu102: FIFO interrupt fixes for Turing
  drm/nouveau/fifo/tu102: Turing channel preemption fix

Ben Skeggs (3):
  drm/nouveau/kms/nv50-gp1xx: wait for less EVO pushbuf space for
core updates without notify
  drm/nouveau/kms/gv100-: wait for less NVD pushbuf space for core
updates without notify
  drm/nouveau/kms/nv50-: add module option to select EVO/NVD push
buffer location

Frantisek Hrbata (1):
  drm/nouveau: bail out of nouveau_channel_new if channel init fails

Karol Herbst (1):
  drm/nouveau/kms: handle mDP connectors

Lyude Paul (9):
  drm/nouveau/kms/nv50-: Don't call HEAD_SET_CRC_CONTROL in head907d_mode()
  drm/nouveau/kms/nv50-: Log SOR/PIOR caps
  drm/nouveau/kms/nv50-: Remove (nv_encoder->crtc) checks in
->disable callbacks
  drm/nouveau/kms/nv50-: Rename encoder->atomic_(enable|disable) callbacks
  drm/nouveau/kms/nv50-: s/armh/asyh/ in nv50_msto_atomic_enable()
  drm/nouveau/kms/nv50-: Reverse args for
nv50_outp_get_(old|new)_connector()
  drm/nouveau/kms/nv50-: Lookup current encoder/crtc from atomic state
  drm/nouveau/kms/nv50-: Use nouveau_encoder->crtc in get_eld callback
  drm/nouveau/kms/nv50-: Fix locking for audio callbacks

 drivers/gpu/drm/nouveau/dispnv50/core507d.c |   2 +-
 drivers/gpu/drm/nouveau/dispnv50/corec37d.c |   2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 230
+--
 drivers/gpu/drm/nouveau/dispnv50/head907d.c |  11 +-
 drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h |   1 +
 drivers/gpu/drm/nouveau/nouveau_chan.c  |   1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c |   1 +
 drivers/gpu/drm/nouveau/nouveau_drv.h   |   1 +
 drivers/gpu/drm/nouveau/nouveau_encoder.h   |  13 +-
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c|  46 ++---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.h|  32 
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/tu102.c| 364
+++-
 drivers/gpu/drm/nouveau/nvkm/subdev/fault/tu102.c   |  21 ++-
 drivers/gpu/drm/nouveau/nvkm/subdev/mc/base.c   |   3 -
 drivers/gpu/drm/nouveau/nvkm/subdev/mc/priv.h   |   1 -
 drivers/gpu/drm/nouveau/nvkm/subdev/mc/tu102.c  | 113 +--
 16 files changed, 675 insertions(+), 167 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] nouveau-fixes 5.11

2021-01-26 Thread Ben Skeggs
Hey Dave,

Mostly a regression fixes here, a couple of which could lead to
display hanging, and have been affecting a number of users.

Ben.

The following changes since commit 8ef23b6f6a79e6fa2a169081d2d76011fffa0482:

  drm/nouveau/disp/ga10[24]: initial support (2021-01-15 10:25:24 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux 04.01-ampere-lite

for you to fetch changes up to d2be5ff9f287b8815c36e95ea34dc4b09f313c3b:

  drm/nouveau/kms/gk104-gp1xx: Fix > 64x64 cursors (2021-01-27 16:36:13 +1000)


Bastian Beranek (1):
  drm/nouveau/dispnv50: Restore pushing of all data.

Ben Skeggs (1):
  drm/nouveau/nvif: fix method count when pushing an array

Karol Herbst (1):
  drm/nouveau/svm: fail NOUVEAU_SVM_INIT ioctl on unsupported devices

Lyude Paul (3):
  drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes
  drm/nouveau/kms/nv50-: Report max cursor size to userspace
  drm/nouveau/kms/gk104-gp1xx: Fix > 64x64 cursors

 drivers/gpu/drm/nouveau/dispnv50/base507c.c |   6 ++-
 drivers/gpu/drm/nouveau/dispnv50/base827c.c |   6 ++-
 drivers/gpu/drm/nouveau/dispnv50/disp.c |   8 
 drivers/gpu/drm/nouveau/dispnv50/head917d.c |  28 ++-
 drivers/gpu/drm/nouveau/dispnv50/wndw.c |  17 +--
 drivers/gpu/drm/nouveau/include/nvhw/class/cl917d.h |   4 ++
 drivers/gpu/drm/nouveau/include/nvif/push.h | 216
++--
 drivers/gpu/drm/nouveau/nouveau_svm.c   |   4 ++
 8 files changed, 174 insertions(+), 115 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] nouveau: ampere modesetting

2021-01-14 Thread Ben Skeggs
Hey Dave,

This series of patches to add modesetting support for Ampere has been
pulled out of a larger, more invasive series.  As there's currently no
firmware available for us to use, the rest of it isn't important right
now, and it'd be nice to have something non-invasive to provide what
support we currently can (and is possible to backport to earlier
kernels).

No other chipset should be impacted by these patches, as the changes
are largely confined to adding Ampere versions of the code handling
each IP block.

I'd like to extend thanks to NVIDIA for providing hardware, and for
their assistance with confirming/clarifying some of the changes.

Ben.

The following changes since commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e:

  drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
(2021-01-15 10:25:17 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux 04.01-ampere-lite

for you to fetch changes up to 8ef23b6f6a79e6fa2a169081d2d76011fffa0482:

  drm/nouveau/disp/ga10[24]: initial support (2021-01-15 10:25:24 +1000)


Ben Skeggs (15):
  drm/nouveau/core: recognise GA10[024]
  drm/nouveau/pci/ga10[024]: initial support
  drm/nouveau/bios/ga10[024]: initial support
  drm/nouveau/devinit/ga10[024]: initial support
  drm/nouveau/mc/ga10[024]: initial support
  drm/nouveau/privring/ga10[024]: initial support
  drm/nouveau/imem/ga10[024]: initial support
  drm/nouveau/fb/ga10[024]: initial support
  drm/nouveau/timer/ga10[024]: initial support
  drm/nouveau/mmu/ga10[024]: initial support
  drm/nouveau/bar/ga10[024]: initial support
  drm/nouveau/gpio/ga10[024]: initial support
  drm/nouveau/i2c/ga10[024]: initial support
  drm/nouveau/dmaobj/ga10[24]: initial support
  drm/nouveau/disp/ga10[24]: initial support

 drivers/gpu/drm/nouveau/dispnv50/Kbuild|   1 +
 drivers/gpu/drm/nouveau/dispnv50/core.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/curs.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wimm.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wndw.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wndw.h|   8 +++
 drivers/gpu/drm/nouveau/dispnv50/wndwc57e.c|  10 ++--
 drivers/gpu/drm/nouveau/dispnv50/wndwc67e.c| 106
+++
 drivers/gpu/drm/nouveau/include/nvif/cl0080.h  |   1 +
 drivers/gpu/drm/nouveau/include/nvif/class.h   |   5 ++
 drivers/gpu/drm/nouveau/include/nvkm/core/device.h |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/engine/disp.h |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/devinit.h  |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h   |   2 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/gpio.h |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/mc.h   |   1 +
 drivers/gpu/drm/nouveau/nouveau_backlight.c|   1 +
 drivers/gpu/drm/nouveau/nvif/disp.c|   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  75
++--
 drivers/gpu/drm/nouveau/nvkm/engine/device/user.c  |   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild|   3 ++
 drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c  |  33 ++---
 drivers/gpu/drm/nouveau/nvkm/engine/disp/ga102.c   |  46 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h |   4 ++
 drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.h|   2 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/rootga102.c   |  52
+++
 drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.h|   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/sorga102.c| 140

 drivers/gpu/drm/nouveau/nvkm/engine/disp/sortu102.c|   2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/tu102.c   |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowramin.c |   3 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/Kbuild |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/ga100.c|  76

 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/priv.h |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c|   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild  |   3 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga100.c |  40 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga102.c |  40 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gv100.c |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h  |   2 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h   |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramga102.c  |  40 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/gpio/Kbuild|   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/gpio/ga102.c   | 118

[PULL] nouveau-fixes 5.11

2021-01-14 Thread Ben Skeggs
Hey Dave,

As requested, here's a tree with the non-Ampere-specific fixes split
out, as most of them are potentially relevant to already-supported
GPUs.

I'll send another pull request with bare-bones GA102/GA104 support shortly.

Ben.

The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:

  Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)

are available in the Git repository at:

  git://github.com/skeggsb/linux 04.00-ampere-lite-fixes

for you to fetch changes up to caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e:

  drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0
(2021-01-15 10:25:17 +1000)


Ben Skeggs (7):
  drm/nouveau/bios: fix issue shadowing expansion ROMs
  drm/nouveau/privring: ack interrupts the same way as RM
  drm/nouveau/i2c/gk110: split out from i2c/gk104
  drm/nouveau/i2c/gk110-: disable hw-initiated dpcd reads
  drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields
  drm/nouveau/mmu: fix vram heap sizing
  drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0

 drivers/gpu/drm/nouveau/dispnv50/disp.c|  4 ++--
 drivers/gpu/drm/nouveau/dispnv50/disp.h|  2 +-
 drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c|  2 +-
 drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h  |  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  | 12 +--
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c  |  2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild |  1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h  |  7 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c   | 10 +++---
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 17 ++--
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gk110.c| 45
++
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gm200.c|  7 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/pad.h  |  2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/priv.h |  4 
 drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c   | 10 +++---
 drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gk104.c   | 10 +++---
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c |  6 +++---
 17 files changed, 112 insertions(+), 30 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/gk110.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH] drm/nouveau: bail out of nouveau_channel_new if channel init fails

2020-11-15 Thread Ben Skeggs
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
> > > ioctl. This was reported by trinity[1] fuzzer.
> > >
> > > [   71.073906] nouveau :01:00.0: crashme[1329]: channel failed to 
> > > initialise, -17
> > > [   71.081730] BUG: kernel NULL pointer dereference, address: 
> > > 00a0
> > > [   71.088928] #PF: supervisor read access in kernel mode
> > > [   71.094059] #PF: error_code(0x) - not-present page
> > > [   71.099189] PGD 119590067 P4D 119590067 PUD 1054f5067 PMD 0
> > > [   71.104842] Oops:  [#1] SMP NOPTI
> > > [   71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2
> > > [   71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014
> > > [   71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380 
> > > [nouveau]
> > > [   71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45 
> > > 31 c0 4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43 
> > > 10 <8b> 90 a0 00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41
> > > [   71.147074] RSP: 0018:b4a1809cfd38 EFLAGS: 00010246
> > > [   71.152526] RAX:  RBX: 98cedbaa1d20 RCX: 
> > > 03bf
> > > [   71.159651] RDX: 03be RSI:  RDI: 
> > > 00030160
> > > [   71.166774] RBP: 98cee776de00 R08: dc0144198a08 R09: 
> > > 98ceeefd4000
> > > [   71.173901] R10: 98cee7e81780 R11: 0001 R12: 
> > > b4a1809cfe08
> > > [   71.181214] R13: 98cee776d000 R14: 98cec519e000 R15: 
> > > 98cee776def0
> > > [   71.188339] FS:  7fd926250500() GS:98ceeac8() 
> > > knlGS:
> > > [   71.196418] CS:  0010 DS:  ES:  CR0: 80050033
> > > [   71.202155] CR2: 00a0 CR3: 000106622000 CR4: 
> > > 000406e0
> > > [   71.209297] Call Trace:
> > > [   71.211777]  ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
> > > [   71.218053]  drm_ioctl_kernel+0xac/0xf0 [drm]
> > > [   71.222421]  drm_ioctl+0x211/0x3c0 [drm]
> > > [   71.226379]  ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
> > > [   71.232500]  nouveau_drm_ioctl+0x57/0xb0 [nouveau]
> > > [   71.237285]  ksys_ioctl+0x86/0xc0
> > > [   71.240595]  __x64_sys_ioctl+0x16/0x20
> > > [   71.244340]  do_syscall_64+0x4c/0x90
> > > [   71.248110]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > [   71.253162] RIP: 0033:0x7fd925d4b88b
> > > [   71.256731] Code: Bad RIP value.
> > > [   71.259955] RSP: 002b:7ffc743592d8 EFLAGS: 0206 ORIG_RAX: 
> > > 0010
> > > [   71.267514] RAX: ffda RBX:  RCX: 
> > > 7fd925d4b88b
> > > [   71.274637] RDX: 00601080 RSI: c0586442 RDI: 
> > > 0003
> > > [   71.281986] RBP: 7ffc74359340 R08: 7fd926016ce0 R09: 
> > > 7fd926016ce0
> > > [   71.289111] R10: 0003 R11: 0206 R12: 
> > > 00400620
> > > [   71.296235] R13: 7ffc74359420 R14:  R15: 
> > > 
> > > [   71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek 
> > > snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg 
> > > snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp 
> > > snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco 
> > > pcspkr crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev 
> > > i2c_piix4 fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c 
> > > sd_mod t10_pi sg nouveau video mxm_wmi i2c_algo_bit drm_kms_helper 
> > > syscopyarea sysfillrect sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib 
> > > ata_generic ahci drm e1000 crc32c_intel libahci serio_raw tg3 libata 
> > > firewire_ohci firewire_core wmi crc_itu_t dm_mirror dm_region_hash dm_log 
> > > dm_mod
> > > [   71.365269] CR2: 00a0
> > >
> > > simplified reproducer
> > > -8<
> > > /*
> > >  * gcc -o crashme crashme.c
> > >  * ./crashme /dev/dri/renderD128
> > >  */
> > >
> > > struct drm_nouveau_channel_alloc {
> > >   uint32_t fb_ctxdma_handle;
> > >   uint32_t tt_ctxdma_handle;
> > >
> > >   int  channel;
> > >   uint32_t pushbuf_domains;
> > >
> > >   /* Notifier memory */
> > >   uint32_t notifier_handle;
> > >
> > >   /* DRM-enforced subchannel assignments */
> > >   struct {
> > >   uint32_t handle;
> > >   uint32_t grclass;
> > >   } subchan[8];
> > >   uint32_t nr_subchan;
> > > };
> > >
> > > static struct drm_nouveau_channel_alloc channel;
> > >
> > > int main(int argc, char *argv[]) {
> > >   int fd;
> > >   int rv;
> > >
> > >   

Re: [Nouveau] [PATCH 1/8] drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere

2020-11-13 Thread Ben Skeggs
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 to use atomic_enable/atomic_disable(), so let's go and
> actually do that.
>
> Signed-off-by: Lyude Paul 
> Cc: Kirill A. Shutemov 
> Fixes: 09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors 
> properly")
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 29 -
>  1 file changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index b111fe24a06b..36d6b6093d16 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -455,7 +455,7 @@ nv50_outp_get_old_connector(struct nouveau_encoder *outp,
>   * DAC
>   
> */
>  static void
> -nv50_dac_disable(struct drm_encoder *encoder)
> +nv50_dac_disable(struct drm_encoder *encoder, struct drm_atomic_state *state)
>  {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nv50_core *core = nv50_disp(encoder->dev)->core;
> @@ -467,7 +467,7 @@ nv50_dac_disable(struct drm_encoder *encoder)
>  }
>
>  static void
> -nv50_dac_enable(struct drm_encoder *encoder)
> +nv50_dac_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
>  {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
> @@ -525,8 +525,8 @@ nv50_dac_detect(struct drm_encoder *encoder, struct 
> drm_connector *connector)
>  static const struct drm_encoder_helper_funcs
>  nv50_dac_help = {
> .atomic_check = nv50_outp_atomic_check,
> -   .enable = nv50_dac_enable,
> -   .disable = nv50_dac_disable,
> +   .atomic_enable = nv50_dac_enable,
> +   .atomic_disable = nv50_dac_disable,
> .detect = nv50_dac_detect
>  };
>
> @@ -1055,7 +1055,7 @@ nv50_dp_bpc_to_depth(unsigned int bpc)
>  }
>
>  static void
> -nv50_msto_enable(struct drm_encoder *encoder)
> +nv50_msto_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
>  {
> struct nv50_head *head = nv50_head(encoder->crtc);
> struct nv50_head_atom *armh = nv50_head_atom(head->base.base.state);
> @@ -1101,7 +1101,7 @@ nv50_msto_enable(struct drm_encoder *encoder)
>  }
>
>  static void
> -nv50_msto_disable(struct drm_encoder *encoder)
> +nv50_msto_disable(struct drm_encoder *encoder, struct drm_atomic_state 
> *state)
>  {
> struct nv50_msto *msto = nv50_msto(encoder);
> struct nv50_mstc *mstc = msto->mstc;
> @@ -1118,8 +1118,8 @@ nv50_msto_disable(struct drm_encoder *encoder)
>
>  static const struct drm_encoder_helper_funcs
>  nv50_msto_help = {
> -   .disable = nv50_msto_disable,
> -   .enable = nv50_msto_enable,
> +   .atomic_disable = nv50_msto_disable,
> +   .atomic_enable = nv50_msto_enable,
> .atomic_check = nv50_msto_atomic_check,
>  };
>
> @@ -1645,8 +1645,7 @@ nv50_sor_disable(struct drm_encoder *encoder,
>  }
>
>  static void
> -nv50_sor_enable(struct drm_encoder *encoder,
> -   struct drm_atomic_state *state)
> +nv50_sor_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
>  {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
> @@ -1873,7 +1872,7 @@ nv50_pior_atomic_check(struct drm_encoder *encoder,
>  }
>
>  static void
> -nv50_pior_disable(struct drm_encoder *encoder)
> +nv50_pior_disable(struct drm_encoder *encoder, struct drm_atomic_state 
> *state)
>  {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nv50_core *core = nv50_disp(encoder->dev)->core;
> @@ -1885,7 +1884,7 @@ nv50_pior_disable(struct drm_encoder *encoder)
>  }
>
>  static void
> -nv50_pior_enable(struct drm_encoder *encoder)
> +nv50_pior_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
>  {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
> @@ -1921,14 +1920,14 @@ nv50_pior_enable(struct drm_encoder *encoder)
> }
>
> core->func->pior->ctrl(core, nv_encoder->or, ctrl, asyh);
> -   nv_encoder->crtc = encoder->crtc;
> +   nv_encoder->crtc = _crtc->base;
>  }
>
>  static const struct drm_encoder_helper_funcs
>  nv50_pior_help = {
> .atomic_check = nv50_pior_atomic_check,
> -   .enable = nv50_pior_enable,
> -   .disable = nv50_pior_disable,
> +   .atomic_enable = nv50_pior_enable,
> +   .atomic_disable = nv50_pior_disable,
>  };
>
>  static void
> --
> 2.28.0
>
> 

[PULL] nouveau-next 5.11

2020-11-13 Thread Ben Skeggs
Just a single fix at the moment.  An alternate version of a regression
fix in 5.10, against additional changes from drm-next.

Ben.

The following changes since commit 512bce50a41c528fa15c4c014293e7bebf018658:

  Merge v5.10-rc3 into drm-next (2020-11-10 14:36:36 +0100)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.11

for you to fetch changes up to be323a4cef022aa9685b08d5a94ddc841ccf617a:

  drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50
(2020-11-14 14:35:57 +1000)


Ben Skeggs (1):
  drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50

 drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] nouveau-fixes 5.10

2020-11-13 Thread Ben Skeggs
The following changes since commit f8394f232b1eab649ce2df5c5f15b0e528c92091:

  Linux 5.10-rc3 (2020-11-08 16:10:16 -0800)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.10

for you to fetch changes up to 5c6fb4b28b165887c42c66731c90eaca818b04c6:

  drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere
(2020-11-14 14:19:18 +1000)


Alexander Kapshuk (1):
  drm/nouveau/kms: Fix NULL pointer dereference in
nouveau_connector_detect_depth

Ben Skeggs (1):
  drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50

Lyude Paul (1):
  drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere

 drivers/gpu/drm/nouveau/dispnv50/disp.c | 29 ++---
 drivers/gpu/drm/nouveau/nouveau_bo.c|  3 +--
 drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +-
 3 files changed, 24 insertions(+), 22 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] nouveau-fixes 5.10

2020-11-11 Thread Ben Skeggs
The following changes since commit 512bce50a41c528fa15c4c014293e7bebf018658:

  Merge v5.10-rc3 into drm-next (2020-11-10 14:36:36 +0100)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.10

for you to fetch changes up to f67e5ecab785631cf7f776533432ba5aba06615a:

  drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50
(2020-11-12 14:09:45 +1000)


Alexander Kapshuk (1):
  drm/nouveau/kms: Fix NULL pointer dereference in
nouveau_connector_detect_depth

Ben Skeggs (1):
  drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50

 drivers/gpu/drm/nouveau/nouveau_bo.c|  3 +--
 drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +-
 2 files changed, 10 insertions(+), 7 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type

2020-11-11 Thread Ben Skeggs
> >>>  [   18.778890]  __kasan_kmalloc.constprop.0+0xbf/0xd0
> >>>  [   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/0x210 [ttm]
> >>>  [   18.816853]  ttm_bo_global_init+0x4a/0x160 [ttm]
> >>>  [   18.823420]  ttm_bo_device_init+0x39/0x220 [ttm]
> >>>  [   18.830046]  nouveau_ttm_init+0x2c3/0x830 [nouveau]
> >>>  [   18.836929]  nouveau_drm_device_init+0x1b4/0x3f0 [nouveau]
> >>>  <...>
> >>>  [   19.105336]
> >>>
> >===
> >>> ===
> >>>
> >>> Fix this error, by not using type_vram as an index if it's negative.
> >>> Assume default values instead.
> >>>
> >>> The error was seen on Nvidia G72 hardware.
> >>>
> >>> Signed-off-by: Thomas Zimmermann 
> >>> Fixes: 1cf65c45183a ("drm/ttm: add caching state to ttm_bus_placement")
> >>> Cc: Christian König 
> >>> Cc: Michael J. Ruhl 
> >>> Cc: Maarten Lankhorst 
> >>> Cc: Maxime Ripard 
> >>> Cc: Thomas Zimmermann 
> >>> Cc: David Airlie 
> >>> Cc: Daniel Vetter 
> >>> Cc: Ben Skeggs 
> >>> Cc: Dave Airlie 
> >>> Cc: Gerd Hoffmann 
> >>> Cc: Alex Deucher 
> >>> Cc: "Christian König" 
> >>> Cc: VMware Graphics 
> >>> Cc: Roland Scheidegger 
> >>> Cc: Huang Rui 
> >>> Cc: Felix Kuehling 
> >>> Cc: Hawking Zhang 
> >>> Cc: Jason Gunthorpe 
> >>> Cc: Likun Gao 
> >>> Cc: dri-devel@lists.freedesktop.org
> >>> Cc: nouv...@lists.freedesktop.org
> >>> Cc: virtualizat...@lists.linux-foundation.org
> >>> Cc: spice-de...@lists.freedesktop.org
> >>> Cc: amd-...@lists.freedesktop.org
> >>> ---
> >>> drivers/gpu/drm/nouveau/nouveau_bo.c | 5 -
> >>> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> index 8133377d865d..fe15299d417e 100644
> >>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> @@ -1142,9 +1142,12 @@ nouveau_ttm_io_mem_reserve(struct
> >>> ttm_bo_device *bdev, struct ttm_resource *reg)
> >>> struct nvkm_device *device = nvxx_device(>client.device);
> >>> struct nouveau_mem *mem = nouveau_mem(reg);
> >>> struct nvif_mmu *mmu = >client.mmu;
> >>> -   const u8 type = mmu->type[drm->ttm.type_vram].type;
> >>> +   u8 type = 0;
> >>> int ret;
> >>>
> >>> +   if (drm->ttm.type_vram >= 0)
> >>> +   type = mmu->type[drm->ttm.type_vram].type;
> >>> +
> >>> mutex_lock(>ttm.io_reserve_mutex);
> >>> retry:
> >>> switch (reg->mem_type) {
> >>> --
> >>> 2.29.2
> >>
> >
> >--
> >Thomas Zimmermann
> >Graphics Driver Developer
> >SUSE Software Solutions Germany GmbH
> >Maxfeldstr. 5, 90409 Nürnberg, Germany
> >(HRB 36809, AG Nürnberg)
> >Geschäftsführer: Felix Imendörffer
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] nouveau-fixes 5.10

2020-10-29 Thread Ben Skeggs
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:

  Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.10

for you to fetch changes up to d7787cc04e0a1f2043264d1550465081096bd065:

  drm/nouveau/kms/nv50-: Fix clock checking algorithm in
nv50_dp_mode_valid() (2020-10-30 09:34:13 +1000)


Karol Herbst (2):
  drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"
  drm/nouveau/device: fix changing endianess code to work on older GPUs

Lyude Paul (3):
  drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
  drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid()
  drm/nouveau/kms/nv50-: Fix clock checking algorithm in
nv50_dp_mode_valid()

Ralph Campbell (1):
  drm/nouveau/nouveau: fix the start/end range for migration

 drivers/gpu/drm/nouveau/dispnv50/core.h |  2 ++
 drivers/gpu/drm/nouveau/dispnv50/core507d.c | 41
+++--
 drivers/gpu/drm/nouveau/dispnv50/core907d.c | 36
+++-
 drivers/gpu/drm/nouveau/dispnv50/core917d.c |  2 +-
 drivers/gpu/drm/nouveau/include/nvhw/class/cl507d.h |  5 -
 drivers/gpu/drm/nouveau/include/nvhw/class/cl907d.h |  4 
 drivers/gpu/drm/nouveau/nouveau_connector.c | 36
++--
 drivers/gpu/drm/nouveau/nouveau_dp.c| 31
+++
 drivers/gpu/drm/nouveau/nouveau_gem.c   |  3 ++-
 drivers/gpu/drm/nouveau/nouveau_svm.c   | 14 +++---
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c   | 39
++-
 11 files changed, 145 insertions(+), 68 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH] drm/nouveau: Drop mutex_lock_nested for atomic

2020-09-30 Thread Ben Skeggs
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:
> > > >
> > > > Ben, did you have a chance to look at this?
> > >
> > > Ping
> > > -Daniel
> > >
> > > > On Mon, Aug 3, 2020 at 1:22 PM Maarten Lankhorst
> > > >  wrote:
> > > > >
> > > > > Op 02-08-2020 om 20:18 schreef Daniel Vetter:
> > > > > > Purely conjecture, but I think the original locking inversion with 
> > > > > > the
> > > > > > legacy page flip code between flipping and ttm's bo move function
> > > > > > shoudn't exist anymore 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
> > > > > > Author: Ben Skeggs 
> > > > > > Date:   Mon Jul 8 14:15:51 2013 +1000
> > > > > >
> > > > > > drm/nouveau: fix locking issues in page flipping paths
> > > > > >
> > > > > > due to
> > > > > >
> > > > > > commit b580c9e2b7ba5030a795aa2fb73b796523d65a78
> > > > > > Author: Maarten Lankhorst 
> > > > > > Date:   Thu Jun 27 13:48:18 2013 +0200
> > > > > >
> > > > > > drm/nouveau: make flipping lockdep safe
> > > > > >
> > > > > > Signed-off-by: Daniel Vetter 
> > > > > > Cc: Maarten Lankhorst 
> > > > > > Cc: Ben Skeggs 
> > > > > > Cc: Dave Airlie 
> > > > > > Cc: nouv...@lists.freedesktop.org
> > > > > > ---
> > > > > > I might be totally wrong, so this definitely needs testing :-)
> > > > > >
> > > > > > Cheers, Daniel
> > > > > > ---
> > > > > >  drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +-
> > > > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > > > > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > > index 7806278dce57..a7b2a9bb0ffe 100644
> > > > > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > > @@ -776,7 +776,11 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object 
> > > > > > *bo, int evict, bool intr,
> > > > > >   return ret;
> > > > > >   }
> > > > > >
> > > > > > - mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
> > > > > > + if (drm_drv_uses_atomic_modeset(drm->dev))
> > > > > > + mutex_lock(>mutex);
> > > > > > + else
> > > > > > + mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
> > > > > > +
> > > > > >   ret = nouveau_fence_sync(nouveau_bo(bo), chan, true, intr);
> > > > > >   if (ret == 0) {
> > > > > >   ret = drm->ttm.move(chan, bo, >mem, new_reg);
> > > > >
> > > > > Well if you're certain it works now. :)
> > > > >
> > > > > Reviewed-by: Maarten Lankhorst 
> > Acked-by: Ben Skeggs 
>
> Can you pull this in through your tree and maybe give it a spin just to
> make sure? I don't really have nouveau hardware here.
Yeah, I can do that easily enough.

Ben.

>
> Also it's entirely stand-alone, I was simply reviewing all the
> mutex_lock_nested we have in drm, and this one stuck out as probably not
> necessary anymore, at least with atomic.
>
> I guess I can also just stuff it into drm-misc-next and if it blows up,
> figure out what to do then :-)
> -Daniel
>
> >
> > > > >
> > > >
> > > >
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > http://blog.ffwll.ch
> > >
> > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> > > ___
> > > Nouveau mailing list
> > > nouv...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/nouveau
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 18/45] drm/nouveau: handle move notify inside move callback.

2020-09-29 Thread Ben Skeggs
On Thu, 24 Sep 2020 at 15:20, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Don't use explicit move notify for moves just do it in the driver side.
>
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 62 
>  1 file changed, 44 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 1e6c2561d692..144b82db16ac 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -970,38 +970,42 @@ nouveau_bo_move_flips(struct ttm_buffer_object *bo, 
> bool evict,
>  }
>
>  static void
> -nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, bool evict,
> -struct ttm_resource *new_reg)
> +nouveau_bo_vma_map_update(struct nouveau_bo *nvbo,
> + uint32_t mem_type,
> + struct nouveau_mem *mem)
>  {
> -   struct nouveau_mem *mem = new_reg ? nouveau_mem(new_reg) : NULL;
> -   struct nouveau_bo *nvbo = nouveau_bo(bo);
> struct nouveau_vma *vma;
>
> -   /* ttm can now (stupidly) pass the driver bos it didn't create... */
> -   if (bo->destroy != nouveau_bo_del_ttm)
> -   return;
> -
> -   nouveau_bo_del_io_reserve_lru(bo);
> -
> -   if (mem && new_reg->mem_type != TTM_PL_SYSTEM &&
> +   if (mem && mem_type != TTM_PL_SYSTEM &&
> mem->mem.page == nvbo->page) {
> list_for_each_entry(vma, >vma_list, head) {
> nouveau_vma_map(vma, mem);
> }
> } else {
> list_for_each_entry(vma, >vma_list, head) {
> -   WARN_ON(ttm_bo_wait(bo, false, false));
> +   WARN_ON(ttm_bo_wait(>bo, false, false));
I can look at this more closely myself a bit down the track, as I need
to do a lot in this area in the near future anyway, but it'd be nice
to pass the failure back here where possible to do so.  The new
invalidate_notify() hook still can't fail, but the other uses can and
it'd be nice to do the right thing where it's possible.

Ben.

> nouveau_vma_unmap(vma);
> }
> }
> +}
>
> -   if (new_reg) {
> -   if (new_reg->mm_node)
> -   nvbo->offset = (new_reg->start << PAGE_SHIFT);
> -   else
> -   nvbo->offset = 0;
> -   }
> +static void
> +nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, bool evict,
> +struct ttm_resource *new_reg)
> +{
> +   struct nouveau_bo *nvbo = nouveau_bo(bo);
> +
> +   /* ttm can now (stupidly) pass the driver bos it didn't create... */
> +   if (bo->destroy != nouveau_bo_del_ttm)
> +   return;
> +
> +   /* handle new_reg path in move */
> +   if (new_reg)
> +   return;
> +
> +   nouveau_bo_del_io_reserve_lru(bo);
>
> +   nouveau_bo_vma_map_update(nvbo, 0, NULL);
>  }
>
>  static int
> @@ -1038,6 +1042,20 @@ nouveau_bo_vm_cleanup(struct ttm_buffer_object *bo,
> *old_tile = new_tile;
>  }
>
> +
> +static void
> +nouveau_bo_update_mem(struct nouveau_bo *nvbo,
> + struct ttm_resource *new_reg)
> +{
> +   nouveau_bo_vma_map_update(nvbo, new_reg->mem_type, 
> nouveau_mem(new_reg));
> +   if (new_reg) {
> +   if (new_reg->mm_node)
> +   nvbo->offset = (new_reg->start << PAGE_SHIFT);
> +   else
> +   nvbo->offset = 0;
> +   }
> +}
> +
>  static int
>  nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
> struct ttm_operation_ctx *ctx,
> @@ -1053,6 +1071,9 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool 
> evict,
> if (ret)
> return ret;
>
> +   nouveau_bo_del_io_reserve_lru(bo);
> +   nouveau_bo_update_mem(nvbo, new_reg);
> +
> if (nvbo->bo.pin_count)
> NV_WARN(drm, "Moving pinned object %p!\n", nvbo);
>
> @@ -1108,6 +1129,11 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool 
> evict,
> nouveau_bo_vm_cleanup(bo, new_tile, >tile);
> }
>
> +   if (ret) {
> +   nouveau_bo_del_io_reserve_lru(bo);
> +   nouveau_bo_update_mem(nvbo, >mem);
> +   }
> +
> return ret;
>  }
>
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 00/45] TTM move refactoring

2020-09-29 Thread Ben Skeggs
On Thu, 24 Sep 2020 at 15:19, Dave Airlie  wrote:
>
> This refactors how TTM moves get called between core and drivers.
>
> 1) puts the driver in charge of all moves, and enforces
> drivers have a move callback.
> 2) moves move_notify actions around moves to the driver side
> 3) moves binding/unbinding completely into move and driver side
> 4) add a new invalidate callback to replace the last use of move_notify
> 5) add some helpers to cleanup the resulting move code
>
> There's a bit of internal churn to try and make each patch logical, so
> don't get too caught up in each patches changes unless the end result
> is a problem.
I've looked over the nouveau-specific patches, and the ttm ones
(mostly ignoring the changes to other drivers beyond a quick glance
over).  For all but 37/45 and the patches that depend on it:

Reviewed-by: Ben Skeggs 

I'll add some more specific comments to one of the patches, but it's
also fine as-is.

Ben.

>
> Dave.
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH] drm/nouveau: Drop mutex_lock_nested for atomic

2020-09-29 Thread Ben Skeggs
On Wed, 30 Sep 2020 at 00:52, Daniel Vetter  wrote:
>
> On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter  wrote:
> >
> > Ben, did you have a chance to look at this?
>
> Ping
> -Daniel
>
> > On Mon, Aug 3, 2020 at 1:22 PM Maarten Lankhorst
> >  wrote:
> > >
> > > Op 02-08-2020 om 20:18 schreef Daniel Vetter:
> > > > Purely conjecture, but I think the original locking inversion with the
> > > > legacy page flip code between flipping and ttm's bo move function
> > > > shoudn't exist anymore 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
> > > > Author: Ben Skeggs 
> > > > Date:   Mon Jul 8 14:15:51 2013 +1000
> > > >
> > > > drm/nouveau: fix locking issues in page flipping paths
> > > >
> > > > due to
> > > >
> > > > commit b580c9e2b7ba5030a795aa2fb73b796523d65a78
> > > > Author: Maarten Lankhorst 
> > > > Date:   Thu Jun 27 13:48:18 2013 +0200
> > > >
> > > > drm/nouveau: make flipping lockdep safe
> > > >
> > > > Signed-off-by: Daniel Vetter 
> > > > Cc: Maarten Lankhorst 
> > > > Cc: Ben Skeggs 
> > > > Cc: Dave Airlie 
> > > > Cc: nouv...@lists.freedesktop.org
> > > > ---
> > > > I might be totally wrong, so this definitely needs testing :-)
> > > >
> > > > Cheers, Daniel
> > > > ---
> > > >  drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > index 7806278dce57..a7b2a9bb0ffe 100644
> > > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > @@ -776,7 +776,11 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, 
> > > > int evict, bool intr,
> > > >   return ret;
> > > >   }
> > > >
> > > > - mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
> > > > + if (drm_drv_uses_atomic_modeset(drm->dev))
> > > > + mutex_lock(>mutex);
> > > > + else
> > > > + mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
> > > > +
> > > >   ret = nouveau_fence_sync(nouveau_bo(bo), chan, true, intr);
> > > >   if (ret == 0) {
> > > >   ret = drm->ttm.move(chan, bo, >mem, new_reg);
> > >
> > > Well if you're certain it works now. :)
> > >
> > > Reviewed-by: Maarten Lankhorst 
Acked-by: Ben Skeggs 

> > >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: Why is nouveau using a separate swap storage?

2020-09-17 Thread Ben Skeggs
On Thu, 17 Sep 2020 at 20:06, Christian König
 wrote:
>
> Hi guys,
>
> just another TTM feature which is only used by nouveau.
>
> We have this bo->bo.persistent_swap_storage pointer which is only set by
> nouveau to the GEM filp and used when a BO is swapped to a shmem file.
>
> As far as I can see this doesn't make any sense at all? What is the
> background here.
No specific reason I can remember, likely cargo-cult from very very
early versions of TTM/GEM stuff.

Ben.

>
> Thanks,
> Christian.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH] drm/nouveau: Add fine-grain temperature reporting

2020-09-09 Thread Ben Skeggs
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:
> > > >
> > > > 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_temp_get().
> > > >
> > > > Rather than altering nvkm_therm_temp_get() to report finer-grain
> > > > temperatures, which would be inconvenient for other users of the
> > > > function, a second interface has been added to line up with hwmon's
> > > > native unit of temperature.
> > > Hey Jeremy,
> > >
> > > Sorry this slipped past me until now.  I'm OK with adding support for
> > > millidegree temperature reporting, but don't think we need to keep
> > > both interfaces around and would rather see the existing code
> > > converted to return millidegrees (even on GPUs that don't support it)
> > > instead of degrees.
> > >
> > > Thanks!
> > > Ben.
> > >
> >
> > just a note as I was trying something like that in the past: we have a
> > lot of code which fetches the temperature and there are a lot of
> > places where we would then do a divide by 1000, so having a wrapper
> > function at least makes sense. If we want to keep the func pointers?
> > well.. I guess the increased CPU overhead wouldn't be as bad if all
> > sub classes do this static * 1000 as well either. I just think we
> > should have both interfaces in subdev/therm.h so we can just keep most
> > of the current code as is.
> >
>
> Indeed. My initial plan was to change the meaning of temp_get() and
> adjust all the users, but there's around a dozen of them and based on my
> understanding of the users none of them cared much about such accuracy.
>
> However, I do find having one way to do things appealing, so if there's
> a strong preference for it, I'm happy to produce a somewhat more
> invasive patch where all users expect millidegrees.
Yeah, I do have a strong preference for not having to keep multiple
interfaces around unnecessarily.  It'd be somewhat different if we had
external interactions, but this is all stuff within the module and we
should be able to make these kinds of changes without too much pain.

Ben.

>
> - Jeremy
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH] drm/nouveau: Add fine-grain temperature reporting

2020-09-08 Thread Ben Skeggs
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_temp_get().
>
> Rather than altering nvkm_therm_temp_get() to report finer-grain
> temperatures, which would be inconvenient for other users of the
> function, a second interface has been added to line up with hwmon's
> native unit of temperature.
Hey Jeremy,

Sorry this slipped past me until now.  I'm OK with adding support for
millidegree temperature reporting, but don't think we need to keep
both interfaces around and would rather see the existing code
converted to return millidegrees (even on GPUs that don't support it)
instead of degrees.

Thanks!
Ben.

>
> Signed-off-by: Jeremy Cline 
> ---
>  .../drm/nouveau/include/nvkm/subdev/therm.h   | 18 +
>  drivers/gpu/drm/nouveau/nouveau_hwmon.c   |  4 +--
>  .../gpu/drm/nouveau/nvkm/subdev/therm/base.c  | 16 
>  .../gpu/drm/nouveau/nvkm/subdev/therm/gp100.c | 25 +--
>  .../gpu/drm/nouveau/nvkm/subdev/therm/priv.h  |  1 +
>  5 files changed, 60 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h 
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> index 62c34f98c930..7b9928dd001c 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> @@ -100,6 +100,24 @@ struct nvkm_therm {
>  };
>
>  int nvkm_therm_temp_get(struct nvkm_therm *);
> +
> +/**
> + * nvkm_therm_temp_millidegree_get() - get the temperature in millidegrees
> + * @therm: The thermal device to read from.
> + *
> + * This interface reports temperatures in units of millidegree Celsius to
> + * align with the hwmon API. Some cards may only be capable of reporting in
> + * units of Celsius, and those that report finer grain temperatures may not 
> be
> + * capable of millidegree Celsius accuracy,
> + *
> + * For cases where millidegree temperature is too fine-grain, the
> + * nvkm_therm_temp_get() interface reports temperatures in one degree Celsius
> + * increments.
> + *
> + * Return: The temperature in millidegrees Celsius, or -ENODEV if temperature
> + * reporting is not supported.
> + */
> +int nvkm_therm_temp_millidegree_get(struct nvkm_therm *therm);
>  int nvkm_therm_fan_sense(struct nvkm_therm *);
>  int nvkm_therm_cstate(struct nvkm_therm *, int, int);
>  void nvkm_therm_clkgate_init(struct nvkm_therm *,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
> b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> index 1c3104d20571..e96355f93ce5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> @@ -428,8 +428,8 @@ nouveau_temp_read(struct device *dev, u32 attr, int 
> channel, long *val)
> case hwmon_temp_input:
> if (drm_dev->switch_power_state != DRM_SWITCH_POWER_ON)
> return -EINVAL;
> -   ret = nvkm_therm_temp_get(therm);
> -   *val = ret < 0 ? ret : (ret * 1000);
> +   ret = nvkm_therm_temp_millidegree_get(therm);
> +   *val = ret;
> break;
> case hwmon_temp_max:
> *val = therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK)
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> index 4a4d1e224126..e655b32c78b8 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> @@ -34,6 +34,22 @@ nvkm_therm_temp_get(struct nvkm_therm *therm)
> return -ENODEV;
>  }
>
> +int
> +nvkm_therm_temp_millidegree_get(struct nvkm_therm *therm)
> +{
> +   int ret = -ENODEV;
> +
> +   if (therm->func->temp_millidegree_get)
> +   return therm->func->temp_millidegree_get(therm);
> +
> +   if (therm->func->temp_get) {
> +   ret = therm->func->temp_get(therm);
> +   if (ret > 0)
> +   ret *= 1000;
> +   }
> +   return ret;
> +}
> +
>  static int
>  nvkm_therm_update_trip(struct nvkm_therm *therm)
>  {
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
> index 9f0dea3f61dc..4c3c2895a3cb 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gp100.c
> @@ -24,7 +24,7 @@
>  #include "priv.h"
>
>  static int
> -gp100_temp_get(struct nvkm_therm *therm)
> +gp100_temp_get_raw(struct nvkm_therm *therm)
>  {
> struct nvkm_device *device = therm->subdev.device;
> struct nvkm_subdev *subdev = >subdev;
> @@ -37,14 +37,35 @@ gp100_temp_get(struct nvkm_therm *therm)
>
> /* device valid */
> if (tsensor & 

Re: [Nouveau] [PATCH v5 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

2020-09-07 Thread Ben Skeggs
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 P72:
>
> nouveau :01:00.0: disp: chid 0 mthd 008c data  508c 102b
>
> This is magic nvidia speak for "You need to have the DMA notifier offset
> programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
> this by doing that, and also perform an update afterwards to prevent
> racing with the GPU when reading capabilities.
>
> v2:
> * Don't just program the DMA notifier offset, make sure to actually
>   perform an update
> v3:
> * Don't call UPDATE()
> * Actually read the correct notifier fields, as apparently the
>   CAPABILITIES_DONE field lives in a different location than the main
>   NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different
>   CAPABILITIES_DONE field then pre-907d cards.
> v4:
> * Don't forget to check the return value of core507d_read_caps()
> v5:
> * Get rid of NV50_DISP_CAPS_NTFY[14], use NV50_DISP_CORE_NTFY
> * Disable notifier after calling GetCapabilities()
>
> Signed-off-by: Lyude Paul 
> Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP 
> interlacing support")
> Cc:  # v5.8+
Thanks Lyude, looks good, and merged!

Ben.

> ---
>  drivers/gpu/drm/nouveau/dispnv50/core.h   |  2 +
>  drivers/gpu/drm/nouveau/dispnv50/core507d.c   | 41 ++-
>  drivers/gpu/drm/nouveau/dispnv50/core907d.c   | 36 +++-
>  drivers/gpu/drm/nouveau/dispnv50/core917d.c   |  2 +-
>  .../drm/nouveau/include/nvhw/class/cl507d.h   |  5 ++-
>  .../drm/nouveau/include/nvhw/class/cl907d.h   |  4 ++
>  6 files changed, 85 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/core.h 
> b/drivers/gpu/drm/nouveau/dispnv50/core.h
> index 498622c0c670d..f75088186fba3 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/core.h
> +++ b/drivers/gpu/drm/nouveau/dispnv50/core.h
> @@ -44,6 +44,7 @@ int core507d_new_(const struct nv50_core_func *, struct 
> nouveau_drm *, s32,
>   struct nv50_core **);
>  int core507d_init(struct nv50_core *);
>  void core507d_ntfy_init(struct nouveau_bo *, u32);
> +int core507d_read_caps(struct nv50_disp *disp);
>  int core507d_caps_init(struct nouveau_drm *, struct nv50_disp *);
>  int core507d_ntfy_wait_done(struct nouveau_bo *, u32, struct nvif_device *);
>  int core507d_update(struct nv50_core *, u32 *, bool);
> @@ -55,6 +56,7 @@ extern const struct nv50_outp_func pior507d;
>  int core827d_new(struct nouveau_drm *, s32, struct nv50_core **);
>
>  int core907d_new(struct nouveau_drm *, s32, struct nv50_core **);
> +int core907d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp);
>  extern const struct nv50_outp_func dac907d;
>  extern const struct nv50_outp_func sor907d;
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c 
> b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> index 248edf69e1683..e6f16a7750f07 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> @@ -78,18 +78,55 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
>  }
>
>  int
> -core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> +core507d_read_caps(struct nv50_disp *disp)
>  {
> struct nvif_push *push = disp->core->chan.push;
> int ret;
>
> -   if ((ret = PUSH_WAIT(push, 2)))
> +   ret = PUSH_WAIT(push, 6);
> +   if (ret)
> return ret;
>
> +   PUSH_MTHD(push, NV507D, SET_NOTIFIER_CONTROL,
> + NVDEF(NV507D, SET_NOTIFIER_CONTROL, MODE, WRITE) |
> + NVVAL(NV507D, SET_NOTIFIER_CONTROL, OFFSET, 
> NV50_DISP_CORE_NTFY >> 2) |
> + NVDEF(NV507D, SET_NOTIFIER_CONTROL, NOTIFY, ENABLE));
> +
> PUSH_MTHD(push, NV507D, GET_CAPABILITIES, 0x);
> +
> +   PUSH_MTHD(push, NV507D, SET_NOTIFIER_CONTROL,
> + NVDEF(NV507D, SET_NOTIFIER_CONTROL, NOTIFY, DISABLE));
> +
> return PUSH_KICK(push);
>  }
>
> +int
> +core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> +{
> +   struct nv50_core *core = disp->core;
> +   struct nouveau_bo *bo = disp->sync;
> +   s64 time;
> +   int ret;
> +
> +   NVBO_WR32(bo, NV50_DISP_CORE_NTFY, NV_DISP_CORE_NOTIFIER_1, 
> CAPABILITIES_1,
> +NVDEF(NV_DISP_CORE_NOTIFIER_1, 
> CAPABILITIES_1, DONE, FALSE));
> +
> +   ret = core507d_read_caps(disp);
> +   if (ret < 0)
> +   return ret;
> +
> +   time = nvif_msec(core->chan.base.device, 2000ULL,
> +if (NVBO_TD32(bo, NV50_DISP_CORE_NTFY,
> +  NV_DISP_CORE_NOTIFIER_1, 
> CAPABILITIES_1, DONE, ==, TRUE))
> +break;
> +   

Re: [PATCH 00/13] ttm tt refactor repost of part 1

2020-09-07 Thread Ben Skeggs
On Tue, 8 Sep 2020 at 06:46, Dave Airlie  wrote:
>
> Most of these have r-b or acks already, patch 1 I may have
> posted before but found in my tree, so reposting it, and patch
> 5 for radeon I think were what needed re-review.
R-b for ttm and nouveau changes, A-b for the other drivers.

Ben.

>
> I'd like to land these, and I'll revisit the remainder of this
> series.
>
> Dave.
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] nouveau-fixes 5.9

2020-09-02 Thread Ben Skeggs
Hey Dave,

A couple of minor fixes to the display changes that went in for 5.9.
The most important of which is a workaround for a HW bug that was
exposed by better push buffer space management, leading to
random(ish...) display engine hangs.

Ben.

The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:

  Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.9

for you to fetch changes up to ca386aa7155a5467fa7b2b8376f4da8f8e59be4d:

  drm/nouveau/kms/nv50-gp1xx: add WAR for EVO push buffer HW bug
(2020-09-03 15:32:24 +1000)


Ben Skeggs (3):
  drm/nouveau/kms/nv50-: add some whitespace before debug message
  drm/nouveau/kms/nv50-gp1xx: disable notifies again after core update
  drm/nouveau/kms/nv50-gp1xx: add WAR for EVO push buffer HW bug

Lyude Paul (1):
  drm/nouveau/kms/gv100-: Include correct push header in crcc37d.c

 drivers/gpu/drm/nouveau/dispnv50/core507d.c | 5 -
 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c  | 2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
 drivers/gpu/drm/nouveau/include/nvif/push507c.h | 2 +-
 4 files changed, 12 insertions(+), 3 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH v4] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

2020-09-02 Thread Ben Skeggs
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 P72:
>
> nouveau :01:00.0: disp: chid 0 mthd 008c data  508c 102b
>
> This is magic nvidia speak for "You need to have the DMA notifier offset
> programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
> this by doing that, and also perform an update afterwards to prevent
> racing with the GPU when reading capabilities.
>
> v2:
> * Don't just program the DMA notifier offset, make sure to actually
>   perform an update
> v3:
> * Don't call UPDATE()
> * Actually read the correct notifier fields, as apparently the
>   CAPABILITIES_DONE field lives in a different location than the main
>   NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different
>   CAPABILITIES_DONE field then pre-907d cards.
> v4:
> * Don't forget to check the return value of core507d_read_caps()
>
> Signed-off-by: Lyude Paul 
> Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP 
> interlacing support")
> Cc:  # v5.8+
> ---
>  drivers/gpu/drm/nouveau/dispnv50/core.h   |  2 +
>  drivers/gpu/drm/nouveau/dispnv50/core507d.c   | 37 ++-
>  drivers/gpu/drm/nouveau/dispnv50/core907d.c   | 36 +-
>  drivers/gpu/drm/nouveau/dispnv50/core917d.c   |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.h   |  2 +
>  .../drm/nouveau/include/nvhw/class/cl507d.h   |  5 ++-
>  .../drm/nouveau/include/nvhw/class/cl907d.h   |  4 ++
>  7 files changed, 83 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/core.h 
> b/drivers/gpu/drm/nouveau/dispnv50/core.h
> index 498622c0c670d..b789139e5fff6 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/core.h
> +++ b/drivers/gpu/drm/nouveau/dispnv50/core.h
> @@ -44,6 +44,7 @@ int core507d_new_(const struct nv50_core_func *, struct 
> nouveau_drm *, s32,
>   struct nv50_core **);
>  int core507d_init(struct nv50_core *);
>  void core507d_ntfy_init(struct nouveau_bo *, u32);
> +int core507d_read_caps(struct nv50_disp *disp, u32 offset);
>  int core507d_caps_init(struct nouveau_drm *, struct nv50_disp *);
>  int core507d_ntfy_wait_done(struct nouveau_bo *, u32, struct nvif_device *);
>  int core507d_update(struct nv50_core *, u32 *, bool);
> @@ -55,6 +56,7 @@ extern const struct nv50_outp_func pior507d;
>  int core827d_new(struct nouveau_drm *, s32, struct nv50_core **);
>
>  int core907d_new(struct nouveau_drm *, s32, struct nv50_core **);
> +int core907d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp);
>  extern const struct nv50_outp_func dac907d;
>  extern const struct nv50_outp_func sor907d;
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c 
> b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> index ad1f09a143aa4..d0f2b80a32103 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> @@ -75,18 +75,51 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
>  }
>
>  int
> -core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> +core507d_read_caps(struct nv50_disp *disp, u32 offset)
>  {
> struct nvif_push *push = disp->core->chan.push;
> int ret;
>
> -   if ((ret = PUSH_WAIT(push, 2)))
> +   ret = PUSH_WAIT(push, 4);
> +   if (ret)
> return ret;
>
> +   PUSH_MTHD(push, NV507D, SET_NOTIFIER_CONTROL,
> + NVDEF(NV507D, SET_NOTIFIER_CONTROL, MODE, WRITE) |
> + NVVAL(NV507D, SET_NOTIFIER_CONTROL, OFFSET, offset >> 2) |
> + NVDEF(NV507D, SET_NOTIFIER_CONTROL, NOTIFY, ENABLE));
> PUSH_MTHD(push, NV507D, GET_CAPABILITIES, 0x);
Can you send a SET_NOTIFIER_CONTROL_NOTIFY_DISABLE after
GET_CAPABILITIES() too please :)

> +
> return PUSH_KICK(push);
>  }
>
> +int
> +core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> +{
> +   struct nv50_core *core = disp->core;
> +   struct nouveau_bo *bo = disp->sync;
> +   s64 time;
> +   int ret;
> +
> +   NVBO_WR32(bo, NV50_DISP_CAPS_NTFY1, NV_DISP_CORE_NOTIFIER_1, 
> CAPABILITIES_1,
> + NVDEF(NV_DISP_CORE_NOTIFIER_1, 
> CAPABILITIES_1, DONE, FALSE));
You don't need these NV50_DISP_CAPS_NTFYx thingies.  These offsets are
already encoded in NVIDIA's headers
(NV_DISP_CORE_NOTIFIER_1_CAPABILITIES_1 is an offset), you're adding
an additional offset by doing this.  Just use NV50_DISP_CORE_NTFY in
all these places, and let NVIDIA's headers do the rest.

The additional offset in these macros are meant for when there's
multiple structures packed into a single nouveau_bo at different
offsets.

It doesn't actually matter here, because it gets divided away.  But
for core907d, you're actually 

Re: [PATCH 1/3] drm/ttm: make sure that we always zero init mem.bus v2

2020-09-02 Thread Ben Skeggs
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:

Reviewed-by: Ben Skeggs 

>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index e3931e515906..772c640a6046 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -650,6 +650,9 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
> evict_mem.mm_node = NULL;
> evict_mem.bus.io_reserved_vm = false;
> evict_mem.bus.io_reserved_count = 0;
> +   evict_mem.bus.base = 0;
> +   evict_mem.bus.offset = 0;
> +   evict_mem.bus.addr = NULL;
>
> ret = ttm_bo_mem_space(bo, , _mem, ctx);
> if (ret) {
> @@ -1084,6 +1087,9 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object 
> *bo,
> mem.page_alignment = bo->mem.page_alignment;
> mem.bus.io_reserved_vm = false;
> mem.bus.io_reserved_count = 0;
> +   mem.bus.base = 0;
> +   mem.bus.offset = 0;
> +   mem.bus.addr = NULL;
> mem.mm_node = NULL;
>
> /*
> @@ -1243,6 +1249,9 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
> bo->mem.page_alignment = page_alignment;
> bo->mem.bus.io_reserved_vm = false;
> bo->mem.bus.io_reserved_count = 0;
> +   bo->mem.bus.base = 0;
> +   bo->mem.bus.offset = 0;
> +   bo->mem.bus.addr = NULL;
> bo->moving = NULL;
> bo->mem.placement = (TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED);
> bo->acc_size = acc_size;
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: nouveau PUSHBUFFER_ERR on 5.9.0-rc2-next-20200824

2020-08-30 Thread Ben Skeggs
On Tue, 25 Aug 2020 at 17:21, Alexander Kapshuk
 wrote:
>
> Since upgrading to linux-next based on 5.9.0-rc1 and 5.9.0-rc2 I have
> had my mouse pointer disappear soon after logging in, and I have
> observed the system freezing temporarily when clicking on objects and
> when typing text.
> I have also found records of push buffer errors in dmesg output:
> [ 6625.450394] nouveau :01:00.0: disp: ERROR 1 [PUSHBUFFER_ERR] 02
> [] chid 0 mthd  data 0400
Hey,

Yeah, I'm aware of this.  Lyude and I have both seen it, but it's been
very painful to track down to what's actually causing it so far.  It
likely is the commit you mentioned that's at fault, and I'm still
working to find a proper solution before I revert it.

Ben.

>
> I tried setting CONFIG_NOUVEAU_DEBUG=5 (tracing) to try and collect
> further debug info, but nothing caught the eye.
>
> The error message in question comes from nv50_disp_intr_error in
> drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c:613,645.
> And nv50_disp_intr_error is called from nv50_disp_intr in the
> following while block:
> drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c:647,658
> void
> nv50_disp_intr(struct nv50_disp *disp)
> {
> struct nvkm_device *device = disp->base.engine.subdev.device;
> u32 intr0 = nvkm_rd32(device, 0x610020);
> u32 intr1 = nvkm_rd32(device, 0x610024);
>
> 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 commits?
> commit 0a96099691c8cd1ac0744ef30b6846869dc2b566
> Author: Ben Skeggs 
> Date:   Tue Jul 21 11:34:07 2020 +1000
>
> drm/nouveau/kms/nv50-: implement proper push buffer control logic
>
> We had a, what was supposed to be temporary, hack in the KMS code where 
> we'd
> completely drain an EVO/NVD channel's push buffer when wrapping to the 
> start
> again, instead of treating it as a ring buffer.
>
> Let's fix that, finally.
>
> Signed-off-by: Ben Skeggs 
>
> Here are my GPU details:
> 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce
> 210] (rev a1)
> Subsystem: Micro-Star International Co., Ltd. [MSI] Device 8a93
> Kernel driver in use: nouveau
>
> The last linux-next kernel I built where the problem reported does not
> manifest itself is 5.8.0-rc6-next-20200720.
>
> I would appreciate being given any pointers on how to further debug this.
> Or is git bisect the only way to proceed with this?
>
> Thanks.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

2020-08-30 Thread Ben Skeggs
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 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 P72:
> > >
> > > nouveau :01:00.0: disp: chid 0 mthd 008c data  508c 
> > > 102b
> > >
> > > This is magic nvidia speak for "You need to have the DMA notifier offset
> > > programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
> > > this by doing that, and also perform an update afterwards to prevent
> > > racing with the GPU when reading capabilities.
> > >
> > > Changes since v1:
> > > * Don't just program the DMA notifier offset, make sure to actually
> > >   perform an update
> > I'm not sure there's a need to send an Update() method here, I believe
> > GetCapabilities() is an action method on its own right?
> >
>
> I'm not entirely sure about this part tbh. I do know that we need to call
> GetCapabilities() _after_ the DMA notifier offset is programmed. But, my
> assumption was that if GetCapabilities() requires a DMA notifier offset to 
> store
> its results in, we'd probably want to fire an update or something to make sure
> that we're not reading before it finishes writing capabilities?
We definitely want to *wait* on GetCapabilities() finishing, I believe
it should also update the notifier the same (or similar) way Update()
does.  But I don't think we want to send an Update() here, it'll
actually trigger a modeset (which, on earlier HW, will tear down the
boot mode.  Not sure about current HW, it might preserve state), and
we may not want that to happen there.

Ben.

>
> > Ben.
> >
> > > Signed-off-by: Lyude Paul 
> > > Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for 
> > > DP
> > > interlacing support")
> > > Cc:  # v5.8+
> > > ---
> > >  drivers/gpu/drm/nouveau/dispnv50/core507d.c | 25 -
> > >  1 file changed, 19 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > > b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > > index e341f572c2696..5e86feec3b720 100644
> > > --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > > +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > > @@ -65,13 +65,26 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
> > >  int
> > >  core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> > >  {
> > > -   u32 *push = evo_wait(>core->chan, 2);
> > > +   struct nv50_core *core = disp->core;
> > > +   u32 interlock[NV50_DISP_INTERLOCK__SIZE] = {0};
> > > +   u32 *push;
> > >
> > > -   if (push) {
> > > -   evo_mthd(push, 0x008c, 1);
> > > -   evo_data(push, 0x0);
> > > -   evo_kick(push, >core->chan);
> > > -   }
> > > +   core->func->ntfy_init(disp->sync, NV50_DISP_CORE_NTFY);
> > > +
> > > +   push = evo_wait(>chan, 4);
> > > +   if (!push)
> > > +   return 0;
> > > +
> > > +   evo_mthd(push, 0x0084, 1);
> > > +   evo_data(push, 0x8000 | NV50_DISP_CORE_NTFY);
> > > +   evo_mthd(push, 0x008c, 1);
> > > +   evo_data(push, 0x0);
> > > +   evo_kick(push, >chan);
> > > +
> > > +   core->func->update(core, interlock, false);
> > > +   if (core->func->ntfy_wait_done(disp->sync, NV50_DISP_CORE_NTFY,
> > > +  core->chan.base.device))
> > > +   NV_ERROR(drm, "core notifier timeout\n");
> > >
> > > return 0;
> > >  }
> > > --
> > > 2.26.2
> > >
> > > ___
> > > Nouveau mailing list
> > > nouv...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/nouveau
> --
> Sincerely,
>   Lyude Paul (she/her)
>   Software Engineer at Red Hat
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

2020-08-24 Thread Ben Skeggs
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 P72:
>
> nouveau :01:00.0: disp: chid 0 mthd 008c data  508c 102b
>
> This is magic nvidia speak for "You need to have the DMA notifier offset
> programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
> this by doing that, and also perform an update afterwards to prevent
> racing with the GPU when reading capabilities.
>
> Changes since v1:
> * Don't just program the DMA notifier offset, make sure to actually
>   perform an update
I'm not sure there's a need to send an Update() method here, I believe
GetCapabilities() is an action method on its own right?

Ben.

>
> Signed-off-by: Lyude Paul 
> Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP 
> interlacing support")
> Cc:  # v5.8+
> ---
>  drivers/gpu/drm/nouveau/dispnv50/core507d.c | 25 -
>  1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c 
> b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> index e341f572c2696..5e86feec3b720 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> @@ -65,13 +65,26 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
>  int
>  core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
>  {
> -   u32 *push = evo_wait(>core->chan, 2);
> +   struct nv50_core *core = disp->core;
> +   u32 interlock[NV50_DISP_INTERLOCK__SIZE] = {0};
> +   u32 *push;
>
> -   if (push) {
> -   evo_mthd(push, 0x008c, 1);
> -   evo_data(push, 0x0);
> -   evo_kick(push, >core->chan);
> -   }
> +   core->func->ntfy_init(disp->sync, NV50_DISP_CORE_NTFY);
> +
> +   push = evo_wait(>chan, 4);
> +   if (!push)
> +   return 0;
> +
> +   evo_mthd(push, 0x0084, 1);
> +   evo_data(push, 0x8000 | NV50_DISP_CORE_NTFY);
> +   evo_mthd(push, 0x008c, 1);
> +   evo_data(push, 0x0);
> +   evo_kick(push, >chan);
> +
> +   core->func->update(core, interlock, false);
> +   if (core->func->ntfy_wait_done(disp->sync, NV50_DISP_CORE_NTFY,
> +  core->chan.base.device))
> +   NV_ERROR(drm, "core notifier timeout\n");
>
> return 0;
>  }
> --
> 2.26.2
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [RFC 20/20] drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()

2020-08-11 Thread Ben Skeggs
On Wed, 12 Aug 2020 at 06:07, Lyude Paul  wrote:
>
> Now that we've extracted i915's code for reading both the normal DPCD
> caps and extended DPCD caps into a shared helper, let's start using this
> in nouveau to enable us to start checking extended DPCD caps for free.
>
> 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
> index f41fa513023fd..a4e07d116972f 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -55,15 +55,13 @@ nouveau_dp_probe_dpcd(struct nouveau_connector 
> *nv_connector,
> int ret;
> u8 *dpcd = outp->dp.dpcd;
>
> -   ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
> -   if (ret == DP_RECEIVER_CAP_SIZE && dpcd[DP_DPCD_REV]) {
> -   ret = drm_dp_read_desc(aux, >dp.desc,
> -  drm_dp_is_branch(dpcd));
> -   if (ret < 0)
> -   goto out;
> -   } else {
> +   ret = drm_dp_read_dpcd_caps(aux, dpcd);
> +   if (ret < 0)
> +   goto out;
> +
> +   ret = drm_dp_read_desc(aux, >dp.desc, drm_dp_is_branch(dpcd));
> +   if (ret < 0)
> goto out;
> -   }
>
> if (nouveau_mst) {
> mstm = outp->dp.mstm;
> --
> 2.26.2
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC 17/20] drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT

2020-08-11 Thread Ben Skeggs
On Wed, 12 Aug 2020 at 06:06, Lyude Paul  wrote:
>
> This is another bit that we never implemented for nouveau: dongle
> detection. When a "dongle", e.g. an active display adaptor, is hooked up
> to the system and causes an HPD to be fired, we don't actually know
> whether or not there's anything plugged into the dongle without checking
> the sink count. As a result, plugging in a dongle without anything
> plugged into it currently results in a bogus EDID retrieval error in the 
> kernel log.
>
> Additionally, most dongles won't send another long HPD signal if the
> user suddenly plugs something in, they'll only send a short HPD IRQ with
> the expectation that the source will check the sink count and reprobe
> the connector if it's changed - something we don't actually do. As a
> result, nothing will 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-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nouveau_dp.c  | 54 ---
>  drivers/gpu/drm/nouveau/nouveau_encoder.h |  2 +
>  2 files changed, 51 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index f6950a62138ca..f41fa513023fd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -36,12 +36,22 @@ MODULE_PARM_DESC(mst, "Enable DisplayPort multi-stream 
> (default: enabled)");
>  static int nouveau_mst = 1;
>  module_param_named(mst, nouveau_mst, int, 0400);
>
> +static bool
> +nouveau_dp_has_sink_count(struct drm_connector *connector,
> + struct nouveau_encoder *outp)
> +{
> +   return drm_dp_has_sink_count(connector, outp->dp.dpcd,
> +>dp.desc);
> +}
> +
>  static enum drm_connector_status
>  nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
>   struct nouveau_encoder *outp)
>  {
> +   struct drm_connector *connector = _connector->base;
> struct drm_dp_aux *aux = _connector->aux;
> struct nv50_mstm *mstm = NULL;
> +   enum drm_connector_status status = connector_status_disconnected;
> int ret;
> u8 *dpcd = outp->dp.dpcd;
>
> @@ -50,9 +60,9 @@ nouveau_dp_probe_dpcd(struct nouveau_connector 
> *nv_connector,
> ret = drm_dp_read_desc(aux, >dp.desc,
>drm_dp_is_branch(dpcd));
> if (ret < 0)
> -   return connector_status_disconnected;
> +   goto out;
> } else {
> -   return connector_status_disconnected;
> +   goto out;
> }
>
> if (nouveau_mst) {
> @@ -61,12 +71,33 @@ nouveau_dp_probe_dpcd(struct nouveau_connector 
> *nv_connector,
> mstm->can_mst = drm_dp_has_mst(aux, dpcd);
> }
>
> +   if (nouveau_dp_has_sink_count(connector, outp)) {
> +   ret = drm_dp_get_sink_count(aux);
> +   if (ret < 0)
> +   goto out;
> +
> +   outp->dp.sink_count = ret;
> +
> +   /*
> +* Dongle connected, but no display. Don't bother reading
> +* downstream port info
> +*/
> +   if (!outp->dp.sink_count)
> +   return connector_status_disconnected;
> +   }
> +
> ret = drm_dp_downstream_read_info(aux, dpcd,
>   outp->dp.downstream_ports);
> if (ret < 0)
> -   return connector_status_disconnected;
> +   goto out;
>
> -   return connector_status_connected;
> +   status = connector_status_connected;
> +out:
> +   if (status != connector_status_connected) {
> +   /* Clear any cached info */
> +   outp->dp.sink_count = 0;
> +   }
> +   return status;
>  }
>
>  int
> @@ -161,6 +192,8 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
> struct drm_connector *connector = _connector->base;
> struct nouveau_encoder *outp = find_encoder(connector, DCB_OUTPUT_DP);
> struct nv50_mstm *mstm;
> +   int ret;
> +   bool send_hpd = false;
>
> if (!outp)
> return;
> @@ -172,12 +205,23 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
>
> if (mstm && mstm->

Re: [RFC 10/20] drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST caps

2020-08-11 Thread Ben Skeggs
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_dp.c 
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index d701f09aea645..bb85d81c25244 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -44,7 +44,6 @@ nouveau_dp_probe_dpcd(struct nouveau_connector 
> *nv_connector,
> struct nv50_mstm *mstm = NULL;
> int ret;
> u8 *dpcd = outp->dp.dpcd;
> -   u8 tmp;
>
> ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
> if (ret == DP_RECEIVER_CAP_SIZE && dpcd[DP_DPCD_REV]) {
> @@ -56,19 +55,10 @@ nouveau_dp_probe_dpcd(struct nouveau_connector 
> *nv_connector,
> return connector_status_disconnected;
> }
>
> -   if (nouveau_mst)
> +   if (nouveau_mst) {
> mstm = outp->dp.mstm;
> -
> -   if (mstm) {
> -   if (dpcd[DP_DPCD_REV] >= DP_DPCD_REV_12) {
> -   ret = drm_dp_dpcd_readb(aux, DP_MSTM_CAP, );
> -   if (ret < 0)
> -   return connector_status_disconnected;
> -
> -   mstm->can_mst = !!(tmp & DP_MST_CAP);
> -   } else {
> -   mstm->can_mst = false;
> -   }
> +   if (mstm)
> +   mstm->can_mst = drm_dp_has_mst(aux, dpcd);
> }
>
> return connector_status_connected;
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC 01/20] drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()

2020-08-11 Thread Ben Skeggs
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/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 8a0f7994e1aeb..ee778ddc95fae 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -76,10 +76,10 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
> nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK;
>
> NV_DEBUG(drm, "display: %dx%d dpcd 0x%02x\n",
> -nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]);
> +nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]);
> NV_DEBUG(drm, "encoder: %dx%d\n",
> -nv_encoder->dcb->dpconf.link_nr,
> -nv_encoder->dcb->dpconf.link_bw);
> +nv_encoder->dcb->dpconf.link_nr,
> +nv_encoder->dcb->dpconf.link_bw);
>
> if (nv_encoder->dcb->dpconf.link_nr < nv_encoder->dp.link_nr)
> nv_encoder->dp.link_nr = nv_encoder->dcb->dpconf.link_nr;
> @@ -87,7 +87,7 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
> nv_encoder->dp.link_bw = nv_encoder->dcb->dpconf.link_bw;
>
> NV_DEBUG(drm, "maximum: %dx%d\n",
> -nv_encoder->dp.link_nr, nv_encoder->dp.link_bw);
> +nv_encoder->dp.link_nr, nv_encoder->dp.link_bw);
>
> nouveau_dp_probe_oui(dev, aux, dpcd);
>
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [git pull] drm next for 5.9-rc1

2020-08-10 Thread Ben Skeggs
On Tue, 11 Aug 2020 at 04:46, Dave Airlie  wrote:
>
> On Mon, 10 Aug 2020 at 22:23, Christoph Hellwig  wrote:
> >
> > On Thu, Aug 06, 2020 at 11:07:02AM +1000, Dave Airlie wrote:
> > > nouveau:
> > > - add CRC support
> > > - start using NVIDIA published class header files
> >
> > Where does Nvdia provide them?  I looked into the commits and the
> > Nouveau mailing list archives and could not find anything.
>
> https://github.com/NVIDIA/open-gpu-doc
>
> Is I believe the canonical upstream source for them.
> >
> > Note that various new files with a MIT boilerplate instead of
> > an SPDX tag.
>
> Ben might just have imported them directly, so SPDX tags might need to
> be sent upstream and see if they accept them.
Yeah, I decided to play it safe and keep NVIDIA's headers as-provided,
just trimmed down to the parts we're using.

Ben.

>
> Dave.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 59/59] drm/ttm: rename ttm_mem_reg to ttm_resource.

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:41, Christian König  wrote:
>
> Am 04.08.20 um 04:56 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > This name better reflects what the object does. I didn't rename
> > all the pointers it seemed too messy.
> >
> > Signed-off-by: Dave Airlie 
>
> Acked-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c   |  6 +--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  4 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h|  2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   | 46 +--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h   | 10 ++--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c  | 12 ++---
> >   drivers/gpu/drm/drm_gem_vram_helper.c |  6 +--
> >   drivers/gpu/drm/nouveau/nouveau_bo.c  | 28 +--
> >   drivers/gpu/drm/nouveau/nouveau_bo.h  | 14 +++---
> >   drivers/gpu/drm/nouveau/nouveau_bo0039.c  |  4 +-
> >   drivers/gpu/drm/nouveau/nouveau_bo5039.c  |  2 +-
> >   drivers/gpu/drm/nouveau/nouveau_bo74c1.c  |  2 +-
> >   drivers/gpu/drm/nouveau/nouveau_bo85b5.c  |  2 +-
> >   drivers/gpu/drm/nouveau/nouveau_bo9039.c  |  2 +-
> >   drivers/gpu/drm/nouveau/nouveau_bo90b5.c  |  2 +-
> >   drivers/gpu/drm/nouveau/nouveau_boa0b5.c  |  2 +-
> >   drivers/gpu/drm/nouveau/nouveau_drv.h |  2 +-
> >   drivers/gpu/drm/nouveau/nouveau_mem.c |  8 ++--
> >   drivers/gpu/drm/nouveau/nouveau_mem.h | 10 ++--
> >   drivers/gpu/drm/nouveau/nouveau_sgdma.c   |  4 +-
> >   drivers/gpu/drm/nouveau/nouveau_ttm.c |  8 ++--
> >   drivers/gpu/drm/nouveau/nv17_fence.c  |  2 +-
> >   drivers/gpu/drm/nouveau/nv50_fence.c  |  2 +-
> >   drivers/gpu/drm/qxl/qxl_drv.h |  2 +-
> >   drivers/gpu/drm/qxl/qxl_ttm.c | 14 +++---
> >   drivers/gpu/drm/radeon/radeon.h   |  2 +-
> >   drivers/gpu/drm/radeon/radeon_object.c|  2 +-
> >   drivers/gpu/drm/radeon/radeon_object.h|  2 +-
> >   drivers/gpu/drm/radeon/radeon_ttm.c   | 28 +--
> >   drivers/gpu/drm/radeon/radeon_vm.c|  2 +-
> >   drivers/gpu/drm/ttm/ttm_agp_backend.c |  2 +-
> >   drivers/gpu/drm/ttm/ttm_bo.c  | 26 +--
> >   drivers/gpu/drm/ttm/ttm_bo_util.c | 46 +--
> >   drivers/gpu/drm/ttm/ttm_range_manager.c   |  4 +-
> >   drivers/gpu/drm/ttm/ttm_tt.c  |  2 +-
> >   drivers/gpu/drm/vmwgfx/vmwgfx_bo.c|  4 +-
> >   drivers/gpu/drm/vmwgfx/vmwgfx_drv.h   |  4 +-
> >   drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  4 +-
> >   drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  2 +-
> >   drivers/gpu/drm/vmwgfx/vmwgfx_thp.c   |  6 +--
> >   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c|  8 ++--
> >   include/drm/ttm/ttm_bo_api.h  | 10 ++--
> >   include/drm/ttm/ttm_bo_driver.h   | 42 -
> >   include/drm/ttm/ttm_tt.h  | 10 ++--
> >   45 files changed, 202 insertions(+), 202 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> > index 8b600b804f34..fb1415488579 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> > @@ -171,7 +171,7 @@ void amdgpu_gtt_mgr_fini(struct amdgpu_device *adev)
> >*
> >* Check if a mem object has already address space allocated.
> >*/
> > -bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_mem_reg *mem)
> > +bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_resource *mem)
> >   {
> >   return mem->mm_node != NULL;
> >   }
> > @@ -189,7 +189,7 @@ bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_mem_reg 
> > *mem)
> >   static int amdgpu_gtt_mgr_new(struct ttm_resource_manager *man,
> > struct ttm_buffer_object *tbo,
> > const struct ttm_place *place,
> > -   struct ttm_mem_reg *mem)
> > +   struct ttm_resource *mem)
> >   {
> >   struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
> >   struct amdgpu_gtt_node *node;
> > @@ -250,7 +250,7 @@ static int amdgpu_gtt_mgr_new(struct 
> > ttm_resource_manager *man,
> >* Free the allocated GTT again.
> >*/
> >   static vo

Re: [PATCH 58/59] drm/ttm: rename ttm_mem_type_manager -> ttm_resource_manager.

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:41, Christian König  wrote:
>
> Am 04.08.20 um 04:56 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > This name makes a lot more sense, since these are about managing
> > driver resources rather than just memory ranges.
> >
> > Signed-off-by: Dave Airlie 
>
> Acked-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c|  2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|  2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c   | 36 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  4 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  4 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h   |  8 +--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c  | 36 +-
> >   drivers/gpu/drm/drm_gem_vram_helper.c |  4 +-
> >   drivers/gpu/drm/nouveau/nouveau_ttm.c | 46 ++---
> >   drivers/gpu/drm/nouveau/nouveau_ttm.h |  6 +-
> >   drivers/gpu/drm/qxl/qxl_ttm.c |  4 +-
> >   drivers/gpu/drm/radeon/radeon_gem.c   |  2 +-
> >   drivers/gpu/drm/radeon/radeon_ttm.c   |  4 +-
> >   drivers/gpu/drm/ttm/ttm_bo.c  | 66 +--
> >   drivers/gpu/drm/ttm/ttm_bo_util.c | 26 
> >   drivers/gpu/drm/ttm/ttm_bo_vm.c   |  2 +-
> >   drivers/gpu/drm/ttm/ttm_range_manager.c   | 28 
> >   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   | 20 +++---
> >   drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 26 
> >   drivers/gpu/drm/vmwgfx/vmwgfx_thp.c   | 26 
> >   include/drm/ttm/ttm_bo_api.h  |  6 +-
> >   include/drm/ttm/ttm_bo_driver.h   | 60 -
> >   23 files changed, 210 insertions(+), 210 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> > index e24f421e5553..478f67498a17 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> > @@ -517,7 +517,7 @@ int amdgpu_amdkfd_get_dmabuf_info(struct kgd_dev *kgd, 
> > int dma_buf_fd,
> >   uint64_t amdgpu_amdkfd_get_vram_usage(struct kgd_dev *kgd)
> >   {
> >   struct amdgpu_device *adev = (struct amdgpu_device *)kgd;
> > - struct ttm_mem_type_manager *vram_man = 
> > ttm_manager_type(>mman.bdev, TTM_PL_VRAM);
> > + struct ttm_resource_manager *vram_man = 
> > ttm_manager_type(>mman.bdev, TTM_PL_VRAM);
> >
> >   return amdgpu_vram_mgr_usage(vram_man);
> >   }
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index 9829640e1769..ecd051976bce 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > @@ -299,7 +299,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct 
> > amdgpu_device *adev,
> >   {
> >   s64 time_us, increment_us;
> >   u64 free_vram, total_vram, used_vram;
> > - struct ttm_mem_type_manager *vram_man = 
> > ttm_manager_type(>mman.bdev, TTM_PL_VRAM);
> > + struct ttm_resource_manager *vram_man = 
> > ttm_manager_type(>mman.bdev, TTM_PL_VRAM);
> >   /* Allow a maximum of 200 accumulated ms. This is basically per-IB
> >* throttling.
> >*
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> > index 71461d652fcc..8b600b804f34 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> > @@ -25,13 +25,13 @@
> >   #include "amdgpu.h"
> >
> >   struct amdgpu_gtt_mgr {
> > - struct ttm_mem_type_manager manager;
> > + struct ttm_resource_manager manager;
> >   struct drm_mm mm;
> >   spinlock_t lock;
> >   atomic64_t available;
> >   };
> >
> > -static inline struct amdgpu_gtt_mgr *to_gtt_mgr(struct 
> > ttm_mem_type_manager *man)
> > +static inline struct amdgpu_gtt_mgr *to_gtt_mgr(struct 
> > ttm_resource_manager *man)
> >   {
> >   return container_of(man, struct amdgpu_gtt_mgr, manager);
> >   }
> > @@ -54,7 +54,7 @@ static ssize_t amdgpu_mem_info_gtt_total_show(struct 
> > device *dev,
> >   {
> >   struct drm_device *ddev = dev_get_drvdata(dev);
> >   struct amdgpu_de

Re: [PATCH 57/59] drm/ttm: rename bo manager to range manager.

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:40, Christian König  wrote:
>
> Am 04.08.20 um 04:56 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > The generic manager is called the range manager now, rename
> > the file and some internals.
> >
> > Signed-off-by: Dave Airlie 
>
> Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/ttm/Makefile  |  2 +-
> >   .../{ttm_bo_manager.c => ttm_range_manager.c} | 26 +--
> >   2 files changed, 14 insertions(+), 14 deletions(-)
> >   rename drivers/gpu/drm/ttm/{ttm_bo_manager.c => ttm_range_manager.c} (88%)
> >
> > diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
> > index caea2a099496..e54326e6cea4 100644
> > --- a/drivers/gpu/drm/ttm/Makefile
> > +++ b/drivers/gpu/drm/ttm/Makefile
> > @@ -4,7 +4,7 @@
> >
> >   ttm-y := ttm_memory.o ttm_tt.o ttm_bo.o \
> >   ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
> > - ttm_execbuf_util.o ttm_page_alloc.o ttm_bo_manager.o
> > + ttm_execbuf_util.o ttm_page_alloc.o ttm_range_manager.o
> >   ttm-$(CONFIG_AGP) += ttm_agp_backend.o
> >   ttm-$(CONFIG_DRM_TTM_DMA_PAGE_POOL) += ttm_page_alloc_dma.o
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c 
> > b/drivers/gpu/drm/ttm/ttm_range_manager.c
> > similarity index 88%
> > rename from drivers/gpu/drm/ttm/ttm_bo_manager.c
> > rename to drivers/gpu/drm/ttm/ttm_range_manager.c
> > index 6679dc11934f..52d9a0ed7165 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> > +++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
> > @@ -54,10 +54,10 @@ static inline struct ttm_range_manager 
> > *to_range_manager(struct ttm_mem_type_man
> >   return container_of(man, struct ttm_range_manager, manager);
> >   }
> >
> > -static int ttm_bo_man_get_node(struct ttm_mem_type_manager *man,
> > -struct ttm_buffer_object *bo,
> > -const struct ttm_place *place,
> > -struct ttm_mem_reg *mem)
> > +static int ttm_range_man_get_node(struct ttm_mem_type_manager *man,
> > +   struct ttm_buffer_object *bo,
> > +   const struct ttm_place *place,
> > +   struct ttm_mem_reg *mem)
> >   {
> >   struct ttm_range_manager *rman = to_range_manager(man);
> >   struct drm_mm *mm = >mm;
> > @@ -95,8 +95,8 @@ static int ttm_bo_man_get_node(struct 
> > ttm_mem_type_manager *man,
> >   return ret;
> >   }
> >
> > -static void ttm_bo_man_put_node(struct ttm_mem_type_manager *man,
> > - struct ttm_mem_reg *mem)
> > +static void ttm_range_man_put_node(struct ttm_mem_type_manager *man,
> > +struct ttm_mem_reg *mem)
> >   {
> >   struct ttm_range_manager *rman = to_range_manager(man);
> >
> > @@ -110,7 +110,7 @@ static void ttm_bo_man_put_node(struct 
> > ttm_mem_type_manager *man,
> >   }
> >   }
> >
> > -static const struct ttm_mem_type_manager_func ttm_bo_manager_func;
> > +static const struct ttm_mem_type_manager_func ttm_range_manager_func;
> >
> >   int ttm_range_man_init(struct ttm_bo_device *bdev,
> >  unsigned type,
> > @@ -131,7 +131,7 @@ int ttm_range_man_init(struct ttm_bo_device *bdev,
> >   man->default_caching = default_caching;
> >   man->use_tt = use_tt;
> >
> > - man->func = _bo_manager_func;
> > + man->func = _range_manager_func;
> >
> >   ttm_mem_type_manager_init(man, p_size);
> >
> > @@ -170,7 +170,7 @@ int ttm_range_man_fini(struct ttm_bo_device *bdev,
> >   }
> >   EXPORT_SYMBOL(ttm_range_man_fini);
> >
> > -static void ttm_bo_man_debug(struct ttm_mem_type_manager *man,
> > +static void ttm_range_man_debug(struct ttm_mem_type_manager *man,
> >struct drm_printer *printer)
> >   {
> >   struct ttm_range_manager *rman = to_range_manager(man);
> > @@ -180,8 +180,8 @@ static void ttm_bo_man_debug(struct 
> > ttm_mem_type_manager *man,
> >   spin_unlock(>lock);
> >   }
> >
> > -static const struct ttm_mem_type_manager_func ttm_bo_manager_func = {
> > - .get_node = ttm_bo_man_get_node,
> > - .put_node = ttm_bo_man_put_node,
> > - .debug = ttm_bo_man_debug
> > +static const struct ttm_mem_type_manager_func ttm_range_manager_func = {
> > + .get_node = ttm_range_man_get_node,
> > + .put_node = ttm_range_man_put_node,
> > + .debug = ttm_range_man_debug
> >   };
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 56/59] drm/ttm: add a wrapper for checking if manager is in use

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:38, Christian König  wrote:
>
> Am 04.08.20 um 04:56 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > This converts vmwgfx over to using an interface to set the
> > in use and check the in use flag.
> >
> > Signed-off-by: Dave Airlie 
>
> Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/nouveau/nouveau_ttm.c |  1 -
> >   drivers/gpu/drm/ttm/ttm_bo.c  |  2 +-
> >   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   | 14 +++---
> >   include/drm/ttm/ttm_bo_driver.h   | 14 ++
> >   4 files changed, 22 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> > b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> > index 22185a8dcfa1..38a0e4bd16f7 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> > @@ -240,7 +240,6 @@ nouveau_ttm_init_gtt(struct nouveau_drm *drm)
> >   ttm_mem_type_manager_init(man, size_pages);
> >   ttm_set_driver_manager(>ttm.bdev, TTM_PL_TT, man);
> >   ttm_mem_type_manager_set_used(man, true);
> > -
> >   return 0;
> >   }
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index cda33b4af681..7d10abae9a60 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -1002,7 +1002,7 @@ static int ttm_bo_mem_placement(struct 
> > ttm_buffer_object *bo,
> >   return ret;
> >
> >   man = ttm_manager_type(bdev, mem_type);
> > - if (!man || !man->use_type)
> > + if (!man || !ttm_mem_type_manager_used(man))
> >   return -EBUSY;
> >
> >   if (!ttm_bo_mt_compatible(man, mem_type, place, _flags))
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > index 7168403fb4f8..b2f1e7a3b048 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > @@ -630,7 +630,7 @@ static int vmw_vram_manager_init(struct vmw_private 
> > *dev_priv)
> >TTM_PL_FLAG_CACHED, TTM_PL_FLAG_CACHED,
> >false, dev_priv->vram_size >> PAGE_SHIFT);
> >   #endif
> > - ttm_manager_type(_priv->bdev, TTM_PL_VRAM)->use_type = false;
> > + ttm_mem_type_manager_set_used(ttm_manager_type(_priv->bdev, 
> > TTM_PL_VRAM), false);
> >   return ret;
> >   }
> >
> > @@ -1192,9 +1192,9 @@ static void __vmw_svga_enable(struct vmw_private 
> > *dev_priv)
> >   struct ttm_mem_type_manager *man = ttm_manager_type(_priv->bdev, 
> > TTM_PL_VRAM);
> >
> >   spin_lock(_priv->svga_lock);
> > - if (!man->use_type) {
> > + if (!ttm_mem_type_manager_used(man)) {
> >   vmw_write(dev_priv, SVGA_REG_ENABLE, SVGA_REG_ENABLE);
> > - man->use_type = true;
> > + ttm_mem_type_manager_set_used(man, true);
> >   }
> >   spin_unlock(_priv->svga_lock);
> >   }
> > @@ -1223,8 +1223,8 @@ static void __vmw_svga_disable(struct vmw_private 
> > *dev_priv)
> >   struct ttm_mem_type_manager *man = ttm_manager_type(_priv->bdev, 
> > TTM_PL_VRAM);
> >
> >   spin_lock(_priv->svga_lock);
> > - if (man->use_type) {
> > - man->use_type = false;
> > + if (ttm_mem_type_manager_used(man)) {
> > + ttm_mem_type_manager_set_used(man, false);
> >   vmw_write(dev_priv, SVGA_REG_ENABLE,
> > SVGA_REG_ENABLE_HIDE |
> > SVGA_REG_ENABLE_ENABLE);
> > @@ -1257,8 +1257,8 @@ void vmw_svga_disable(struct vmw_private *dev_priv)
> >   vmw_kms_lost_device(dev_priv->dev);
> >   ttm_write_lock(_priv->reservation_sem, false);
> >   spin_lock(_priv->svga_lock);
> > - if (man->use_type) {
> > - man->use_type = false;
> > + if (ttm_mem_type_manager_used(man)) {
> > + ttm_mem_type_manager_set_used(man, false);
> >   spin_unlock(_priv->svga_lock);
> >   if (ttm_bo_evict_mm(_priv->bdev, TTM_PL_VRAM))
> >   DRM_ERROR("Failed evicting VRAM buffers.\n");
> > diff --git a/include/drm/ttm/ttm_bo_driver.h 
> > b/include/drm/ttm/ttm_bo_driver.h
> > index 300934289e64..f231fe34e744 100644
> > --- a/include/drm/ttm/ttm_bo_driver.h
> > +++ b/include/drm/

Re: [PATCH 55/59] drm/ttm: drop type manager has_type

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:38, Christian König  wrote:
>
> Am 04.08.20 um 04:56 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > under driver control, this flag isn't needed anymore,
> > remove the API that used to access it, and consoldiate
> > with the used api.
> >
> > Signed-off-by: Dave Airlie 
>
> Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c   |  2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c  |  2 +-
> >   drivers/gpu/drm/nouveau/nouveau_ttm.c |  4 ++--
> >   drivers/gpu/drm/ttm/ttm_bo.c  |  8 +++-
> >   drivers/gpu/drm/ttm/ttm_bo_manager.c  |  2 +-
> >   drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  2 +-
> >   drivers/gpu/drm/vmwgfx/vmwgfx_thp.c   |  2 +-
> >   include/drm/ttm/ttm_bo_driver.h   | 17 -
> >   8 files changed, 10 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> > index 9fc3d876ed38..71461d652fcc 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> > @@ -146,7 +146,7 @@ void amdgpu_gtt_mgr_fini(struct amdgpu_device *adev)
> >   struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
> >   int ret;
> >
> > - ttm_mem_type_manager_disable(man);
> > + ttm_mem_type_manager_set_used(man, false);
> >
> >   ret = ttm_mem_type_manager_force_list_clean(>mman.bdev, man);
> >   if (ret)
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > index 684698cdf772..8cc44c3d2fdd 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > @@ -223,7 +223,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device *adev)
> >   struct amdgpu_vram_mgr *mgr = to_vram_mgr(man);
> >   int ret;
> >
> > - ttm_mem_type_manager_disable(man);
> > + ttm_mem_type_manager_set_used(man, false);
> >
> >   ret = ttm_mem_type_manager_force_list_clean(>mman.bdev, man);
> >   if (ret)
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> > b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> > index d408e1485cce..22185a8dcfa1 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> > @@ -194,7 +194,7 @@ nouveau_ttm_fini_vram(struct nouveau_drm *drm)
> >   struct ttm_mem_type_manager *man = ttm_manager_type(>ttm.bdev, 
> > TTM_PL_VRAM);
> >
> >   if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
> > - ttm_mem_type_manager_disable(man);
> > + ttm_mem_type_manager_set_used(man, false);
> >   ttm_mem_type_manager_force_list_clean(>ttm.bdev, man);
> >   ttm_mem_type_manager_cleanup(man);
> >   ttm_set_driver_manager(>ttm.bdev, TTM_PL_VRAM, NULL);
> > @@ -253,7 +253,7 @@ nouveau_ttm_fini_gtt(struct nouveau_drm *drm)
> >   drm->agp.bridge)
> >   ttm_range_man_fini(>ttm.bdev, TTM_PL_TT);
> >   else {
> > - ttm_mem_type_manager_disable(man);
> > + ttm_mem_type_manager_set_used(man, false);
> >   ttm_mem_type_manager_force_list_clean(>ttm.bdev, man);
> >   ttm_mem_type_manager_cleanup(man);
> >   ttm_set_driver_manager(>ttm.bdev, TTM_PL_TT, NULL);
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index 12abe46bfbc1..cda33b4af681 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -80,7 +80,6 @@ static inline int ttm_mem_type_from_place(const struct 
> > ttm_place *place,
> >   void ttm_mem_type_manager_debug(struct ttm_mem_type_manager *man,
> >   struct drm_printer *p)
> >   {
> > - drm_printf(p, "has_type: %d\n", man->has_type);
> >   drm_printf(p, "use_type: %d\n", man->use_type);
> >   drm_printf(p, "use_tt: %d\n", man->use_tt);
> >   drm_printf(p, "size: %llu\n", man->size);
> > @@ -1003,7 +1002,7 @@ static int ttm_bo_mem_placement(struct 
> > ttm_buffer_object *bo,
> >   return ret;
> >
> >   man = ttm_manager_type(bdev, mem_type);
> > - if (!man->has_type || !man->use_type)
&

Re: [PATCH 53/59] drm/ttm: drop man->bdev link.

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:58, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> This link isn't needed anymore, drop it from the init interface.
>
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c   | 2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c  | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_ttm.c | 6 ++
>  drivers/gpu/drm/ttm/ttm_bo.c  | 6 ++
>  drivers/gpu/drm/ttm/ttm_bo_manager.c  | 2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_thp.c   | 2 +-
>  include/drm/ttm/ttm_bo_api.h  | 6 ++
>  include/drm/ttm/ttm_bo_driver.h   | 2 --
>  9 files changed, 11 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> index b664c5cb13ce..9fc3d876ed38 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> @@ -108,7 +108,7 @@ int amdgpu_gtt_mgr_init(struct amdgpu_device *adev, 
> uint64_t gtt_size)
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
>
> -   ttm_mem_type_manager_init(>mman.bdev, man, gtt_size >> 
> PAGE_SHIFT);
> +   ttm_mem_type_manager_init(man, gtt_size >> PAGE_SHIFT);
>
> start = AMDGPU_GTT_MAX_TRANSFER_SIZE * 
> AMDGPU_GTT_NUM_TRANSFER_WINDOWS;
> size = (adev->gmc.gart_size >> PAGE_SHIFT) - start;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index bbc528c0ed3e..684698cdf772 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -190,7 +190,7 @@ int amdgpu_vram_mgr_init(struct amdgpu_device *adev)
> man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
>
> -   ttm_mem_type_manager_init(>mman.bdev, man, 
> adev->gmc.real_vram_size >> PAGE_SHIFT);
> +   ttm_mem_type_manager_init(man, adev->gmc.real_vram_size >> 
> PAGE_SHIFT);
>
> man->func = _vram_mgr_func;
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index 58d9bd708e95..d408e1485cce 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -175,7 +175,7 @@ nouveau_ttm_init_vram(struct nouveau_drm *drm)
> man->func = _vram_manager;
> man->use_io_reserve_lru = true;
>
> -   ttm_mem_type_manager_init(>ttm.bdev, man,
> +   ttm_mem_type_manager_init(man,
>   drm->gem.vram_available >> 
> PAGE_SHIFT);
> ttm_set_driver_manager(>ttm.bdev, TTM_PL_VRAM, man);
> ttm_mem_type_manager_set_used(man, true);
> @@ -237,9 +237,7 @@ nouveau_ttm_init_gtt(struct nouveau_drm *drm)
> man->available_caching = available_caching;
> man->default_caching = default_caching;
> man->use_tt = true;
> -   ttm_mem_type_manager_init(>ttm.bdev, man,
> - size_pages);
> -
> +   ttm_mem_type_manager_init(man, size_pages);
> ttm_set_driver_manager(>ttm.bdev, TTM_PL_TT, man);
> ttm_mem_type_manager_set_used(man, true);
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 3a3a4dfb0fff..78b72443a9ef 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1471,8 +1471,7 @@ int ttm_bo_evict_mm(struct ttm_bo_device *bdev, 
> unsigned mem_type)
>  }
>  EXPORT_SYMBOL(ttm_bo_evict_mm);
>
> -void ttm_mem_type_manager_init(struct ttm_bo_device *bdev,
> -  struct ttm_mem_type_manager *man,
> +void ttm_mem_type_manager_init(struct ttm_mem_type_manager *man,
>unsigned long p_size)
>  {
> unsigned i;
> @@ -1482,7 +1481,6 @@ void ttm_mem_type_manager_init(struct ttm_bo_device 
> *bdev,
> mutex_init(>io_reserve_mutex);
> spin_lock_init(>move_lock);
> INIT_LIST_HEAD(>io_reserve_lru);
> -   man->bdev = bdev;
> man->size = p_size;
>
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
> @@ -1595,7 +1593,7 @@ static void ttm_bo_init_sysman(struct ttm_bo_device 
> *bdev)
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
>
> -   t

Re: [PATCH 54/59] drm/ttm: drop list of memory managers from device. (v2)

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:37, Christian König  wrote:
>
> Am 04.08.20 um 04:56 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > The driver now controls these, the core just controls the system
> > memory one.
> >
> > v2: init sysman explicitly and assign it as a driver manager
> > to simplify the lookup sequence.
> >
> > Signed-off-by: Dave Airlie 
>
> Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo.c| 6 +++---
> >   include/drm/ttm/ttm_bo_driver.h | 6 ++
> >   2 files changed, 5 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index 78b72443a9ef..12abe46bfbc1 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -1558,6 +1558,7 @@ int ttm_bo_device_release(struct ttm_bo_device *bdev)
> >
> >   man = ttm_manager_type(bdev, TTM_PL_SYSTEM);
> >   ttm_mem_type_manager_disable(man);
> > + ttm_set_driver_manager(bdev, TTM_PL_SYSTEM, NULL);
> >
> >   mutex_lock(_global_mutex);
> >   list_del(>device_list);
> > @@ -1583,7 +1584,7 @@ EXPORT_SYMBOL(ttm_bo_device_release);
> >
> >   static void ttm_bo_init_sysman(struct ttm_bo_device *bdev)
> >   {
> > - struct ttm_mem_type_manager *man = ttm_manager_type(bdev, 
> > TTM_PL_SYSTEM);
> > + struct ttm_mem_type_manager *man = >sysman;
> >
> >   /*
> >* Initialize the system memory buffer type.
> > @@ -1594,6 +1595,7 @@ static void ttm_bo_init_sysman(struct ttm_bo_device 
> > *bdev)
> >   man->default_caching = TTM_PL_FLAG_CACHED;
> >
> >   ttm_mem_type_manager_init(man, 0);
> > + ttm_set_driver_manager(bdev, TTM_PL_SYSTEM, man);
> >   ttm_mem_type_manager_set_used(man, true);
> >   }
> >
> > @@ -1615,8 +1617,6 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
> >
> >   bdev->driver = driver;
> >
> > - memset(bdev->man_priv, 0, sizeof(bdev->man_priv));
> > -
> >   ttm_bo_init_sysman(bdev);
> >
> >   bdev->vma_manager = vma_manager;
> > diff --git a/include/drm/ttm/ttm_bo_driver.h 
> > b/include/drm/ttm/ttm_bo_driver.h
> > index bfd19400372f..d5646d7cac60 100644
> > --- a/include/drm/ttm/ttm_bo_driver.h
> > +++ b/include/drm/ttm/ttm_bo_driver.h
> > @@ -414,7 +414,7 @@ struct ttm_bo_device {
> >   /*
> >* access via ttm_manager_type.
> >*/
> > - struct ttm_mem_type_manager man_priv[TTM_NUM_MEM_TYPES];
> > + struct ttm_mem_type_manager sysman;
> >   struct ttm_mem_type_manager *man_drv[TTM_NUM_MEM_TYPES];
> >   /*
> >* Protected by internal locks.
> > @@ -446,9 +446,7 @@ struct ttm_bo_device {
> >   static inline struct ttm_mem_type_manager *ttm_manager_type(struct 
> > ttm_bo_device *bdev,
> >   int mem_type)
> >   {
> > - if (bdev->man_drv[mem_type])
> > - return bdev->man_drv[mem_type];
> > - return >man_priv[mem_type];
> > + return bdev->man_drv[mem_type];
> >   }
> >
> >   static inline void ttm_set_driver_manager(struct ttm_bo_device *bdev,
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 51/59] drm/ttm: drop priv pointer in memory manager

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:58, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> This isn't needed anymore by any drivers.
>
> Reviewed-by: Christian König 
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  include/drm/ttm/ttm_bo_driver.h | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 789c1eb26859..b477c1ad5c3e 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -123,7 +123,6 @@ struct ttm_mem_type_manager_func {
>   * @default_caching: The default caching policy used for a buffer object
>   * placed in this memory type if the user doesn't provide one.
>   * @func: structure pointer implementing the range manager. See above
> - * @priv: Driver private closure for @func.
>   * @io_reserve_mutex: Mutex optionally protecting shared io_reserve 
> structures
>   * @use_io_reserve_lru: Use an lru list to try to unreserve io_mem_regions
>   * reserved by the TTM vm system.
> @@ -152,7 +151,6 @@ struct ttm_mem_type_manager {
> uint32_t available_caching;
> uint32_t default_caching;
> const struct ttm_mem_type_manager_func *func;
> -   void *priv;
> struct mutex io_reserve_mutex;
> bool use_io_reserve_lru;
> spinlock_t move_lock;
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 50/59] drm/nouveau/ttm: move to driver allocated manager

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:58, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nouveau_ttm.c | 45 +++
>  1 file changed, 32 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index 1c636723823c..58d9bd708e95 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -157,12 +157,12 @@ static int
>  nouveau_ttm_init_vram(struct nouveau_drm *drm)
>  {
> struct nvif_mmu *mmu = >client.mmu;
> -
> if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
> -   struct ttm_mem_type_manager *man = 
> ttm_manager_type(>ttm.bdev, TTM_PL_VRAM);
> -
> /* Some BARs do not support being ioremapped WC */
> const u8 type = mmu->type[drm->ttm.type_vram].type;
> +   struct ttm_mem_type_manager *man = kzalloc(sizeof(struct 
> ttm_mem_type_manager), GFP_KERNEL);
> +   if (!man)
> +   return -ENOMEM;
>
> man->available_caching = TTM_PL_FLAG_UNCACHED | 
> TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> @@ -174,8 +174,10 @@ nouveau_ttm_init_vram(struct nouveau_drm *drm)
>
> man->func = _vram_manager;
> man->use_io_reserve_lru = true;
> +
> ttm_mem_type_manager_init(>ttm.bdev, man,
>   drm->gem.vram_available >> 
> PAGE_SHIFT);
> +   ttm_set_driver_manager(>ttm.bdev, TTM_PL_VRAM, man);
> ttm_mem_type_manager_set_used(man, true);
> return 0;
> } else {
> @@ -195,6 +197,8 @@ nouveau_ttm_fini_vram(struct nouveau_drm *drm)
> ttm_mem_type_manager_disable(man);
> ttm_mem_type_manager_force_list_clean(>ttm.bdev, man);
> ttm_mem_type_manager_cleanup(man);
> +   ttm_set_driver_manager(>ttm.bdev, TTM_PL_VRAM, NULL);
> +   kfree(man);
> } else
> ttm_range_man_fini(>ttm.bdev, TTM_PL_VRAM);
>  }
> @@ -202,30 +206,43 @@ nouveau_ttm_fini_vram(struct nouveau_drm *drm)
>  static int
>  nouveau_ttm_init_gtt(struct nouveau_drm *drm)
>  {
> -   struct ttm_mem_type_manager *man = ttm_manager_type(>ttm.bdev, 
> TTM_PL_TT);
> +   struct ttm_mem_type_manager *man;
> unsigned long size_pages = drm->gem.gart_available >> PAGE_SHIFT;
> -   man->use_tt = true;
> +   unsigned available_caching, default_caching;
> +   const struct ttm_mem_type_manager_func *func = NULL;
> if (drm->agp.bridge) {
> -   man->available_caching = TTM_PL_FLAG_UNCACHED |
> +   available_caching = TTM_PL_FLAG_UNCACHED |
> TTM_PL_FLAG_WC;
> -   man->default_caching = TTM_PL_FLAG_WC;
> +   default_caching = TTM_PL_FLAG_WC;
> } else {
> -   man->available_caching = TTM_PL_MASK_CACHING;
> -   man->default_caching = TTM_PL_FLAG_CACHED;
> +   available_caching = TTM_PL_MASK_CACHING;
> +   default_caching = TTM_PL_FLAG_CACHED;
> }
>
> if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA)
> -   man->func = _gart_manager;
> +   func = _gart_manager;
> else if (!drm->agp.bridge)
> -   man->func = _gart_manager;
> +   func = _gart_manager;
> else
> return ttm_range_man_init(>ttm.bdev, TTM_PL_TT,
> - TTM_PL_FLAG_UNCACHED | 
> TTM_PL_FLAG_WC,
> - TTM_PL_FLAG_WC, true,
> + available_caching, default_caching,
> + true,
>   size_pages);
> +
> +   man = kzalloc(sizeof(struct ttm_mem_type_manager), GFP_KERNEL);
> +   if (!man)
> +   return -ENOMEM;
> +
> +   man->func = func;
> +   man->available_caching = available_caching;
> +   man->default_caching = default_caching;
> +   man->use_tt = true;
> ttm_mem_type_manager_init(>ttm.bdev, man,
>   size_pages);
> +
> +   ttm_set_driver_manager(>ttm.bdev, TTM_PL_TT, man);
> ttm_mem_type_manager_set_used(man, true);
> +
> return 0;
>  }
>
> @@ -241,6 

Re: [PATCH 47/59] drm/ttm: move range manager to subclassed driver allocation

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:58, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Reviewed-by: Christian König 
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/ttm/ttm_bo_manager.c | 31 +---
>  1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c 
> b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> index d83cb967a107..01d41c6f2f7b 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> @@ -44,16 +44,22 @@
>   */
>
>  struct ttm_range_manager {
> +   struct ttm_mem_type_manager manager;
> struct drm_mm mm;
> spinlock_t lock;
>  };
>
> +static inline struct ttm_range_manager *to_range_manager(struct 
> ttm_mem_type_manager *man)
> +{
> +   return container_of(man, struct ttm_range_manager, manager);
> +}
> +
>  static int ttm_bo_man_get_node(struct ttm_mem_type_manager *man,
>struct ttm_buffer_object *bo,
>const struct ttm_place *place,
>struct ttm_mem_reg *mem)
>  {
> -   struct ttm_range_manager *rman = (struct ttm_range_manager *) 
> man->priv;
> +   struct ttm_range_manager *rman = to_range_manager(man);
> struct drm_mm *mm = >mm;
> struct drm_mm_node *node;
> enum drm_mm_insert_mode mode;
> @@ -92,7 +98,7 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager 
> *man,
>  static void ttm_bo_man_put_node(struct ttm_mem_type_manager *man,
> struct ttm_mem_reg *mem)
>  {
> -   struct ttm_range_manager *rman = (struct ttm_range_manager *) 
> man->priv;
> +   struct ttm_range_manager *rman = to_range_manager(man);
>
> if (mem->mm_node) {
> spin_lock(>lock);
> @@ -113,25 +119,26 @@ int ttm_range_man_init(struct ttm_bo_device *bdev,
>bool use_tt,
>unsigned long p_size)
>  {
> -   struct ttm_mem_type_manager *man = ttm_manager_type(bdev, type);
> +   struct ttm_mem_type_manager *man;
> struct ttm_range_manager *rman;
>
> -   man->available_caching = available_caching;
> -   man->default_caching = default_caching;
> -   man->use_tt = use_tt;
> -
> rman = kzalloc(sizeof(*rman), GFP_KERNEL);
> if (!rman)
> return -ENOMEM;
>
> +   man = >manager;
> +   man->available_caching = available_caching;
> +   man->default_caching = default_caching;
> +   man->use_tt = use_tt;
> +
> man->func = _bo_manager_func;
>
> ttm_mem_type_manager_init(bdev, man, p_size);
>
> drm_mm_init(>mm, 0, p_size);
> spin_lock_init(>lock);
> -   man->priv = rman;
>
> +   ttm_set_driver_manager(bdev, type, >manager);
> ttm_mem_type_manager_set_used(man, true);
> return 0;
>  }
> @@ -141,7 +148,7 @@ int ttm_range_man_fini(struct ttm_bo_device *bdev,
>unsigned type)
>  {
> struct ttm_mem_type_manager *man = ttm_manager_type(bdev, type);
> -   struct ttm_range_manager *rman = (struct ttm_range_manager *) 
> man->priv;
> +   struct ttm_range_manager *rman = to_range_manager(man);
> struct drm_mm *mm = >mm;
> int ret;
>
> @@ -155,10 +162,10 @@ int ttm_range_man_fini(struct ttm_bo_device *bdev,
> drm_mm_clean(mm);
> drm_mm_takedown(mm);
> spin_unlock(>lock);
> -   kfree(rman);
> -   man->priv = NULL;
>
> ttm_mem_type_manager_cleanup(man);
> +   ttm_set_driver_manager(bdev, type, NULL);
> +   kfree(rman);
> return 0;
>  }
>  EXPORT_SYMBOL(ttm_range_man_fini);
> @@ -166,7 +173,7 @@ EXPORT_SYMBOL(ttm_range_man_fini);
>  static void ttm_bo_man_debug(struct ttm_mem_type_manager *man,
>  struct drm_printer *printer)
>  {
> -   struct ttm_range_manager *rman = (struct ttm_range_manager *) 
> man->priv;
> +   struct ttm_range_manager *rman = to_range_manager(man);
>
> spin_lock(>lock);
> drm_mm_print(>mm, printer);
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 46/59] drm/ttm: make ttm_range_man_init/takedown take type + args

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:35, Christian König  wrote:
>
> Am 04.08.20 um 04:56 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > This makes it easier to move these to a driver allocated system
> >
> > Signed-off-by: Dave Airlie 
>
> Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 15 +---
> >   drivers/gpu/drm/drm_gem_vram_helper.c   | 10 
> >   drivers/gpu/drm/nouveau/nouveau_ttm.c   | 22 +++---
> >   drivers/gpu/drm/qxl/qxl_ttm.c   | 13 ---
> >   drivers/gpu/drm/radeon/radeon_ttm.c | 31 -
> >   drivers/gpu/drm/ttm/ttm_bo_manager.c| 19 +++
> >   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 13 ---
> >   include/drm/ttm/ttm_bo_driver.h | 12 +++---
> >   8 files changed, 70 insertions(+), 65 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > index 1bd860877f1e..b190d50dc9bb 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > @@ -67,12 +67,9 @@ static int amdgpu_ttm_init_on_chip(struct amdgpu_device 
> > *adev,
> >   unsigned int type,
> >   uint64_t size)
> >   {
> > - struct ttm_mem_type_manager *man = ttm_manager_type(>mman.bdev, 
> > type);
> > -
> > - man->available_caching = TTM_PL_FLAG_UNCACHED;
> > - man->default_caching = TTM_PL_FLAG_UNCACHED;
> > -
> > - return ttm_range_man_init(>mman.bdev, man, size >> PAGE_SHIFT);
> > + return ttm_range_man_init(>mman.bdev, type,
> > +   TTM_PL_FLAG_UNCACHED, TTM_PL_FLAG_UNCACHED,
> > +   false, size >> PAGE_SHIFT);
> >   }
> >
> >   /**
> > @@ -2014,9 +2011,9 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
> >
> >   amdgpu_vram_mgr_fini(adev);
> >   amdgpu_gtt_mgr_fini(adev);
> > - ttm_range_man_fini(>mman.bdev, 
> > ttm_manager_type(>mman.bdev, AMDGPU_PL_GDS));
> > - ttm_range_man_fini(>mman.bdev, 
> > ttm_manager_type(>mman.bdev, AMDGPU_PL_GWS));
> > - ttm_range_man_fini(>mman.bdev, 
> > ttm_manager_type(>mman.bdev, AMDGPU_PL_OA));
> > + ttm_range_man_fini(>mman.bdev, AMDGPU_PL_GDS);
> > + ttm_range_man_fini(>mman.bdev, AMDGPU_PL_GWS);
> > + ttm_range_man_fini(>mman.bdev, AMDGPU_PL_OA);
> >   ttm_bo_device_release(>mman.bdev);
> >   adev->mman.initialized = false;
> >   DRM_INFO("amdgpu: ttm finalized\n");
> > diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
> > b/drivers/gpu/drm/drm_gem_vram_helper.c
> > index a01768adb96d..2187787f397e 100644
> > --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> > @@ -1103,7 +1103,6 @@ EXPORT_SYMBOL(drm_vram_mm_debugfs_init);
> >   static int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device 
> > *dev,
> >   uint64_t vram_base, size_t vram_size)
> >   {
> > - struct ttm_mem_type_manager *man = ttm_manager_type(>bdev, 
> > TTM_PL_VRAM);
> >   int ret;
> >
> >   vmm->vram_base = vram_base;
> > @@ -1116,9 +1115,10 @@ static int drm_vram_mm_init(struct drm_vram_mm *vmm, 
> > struct drm_device *dev,
> >   if (ret)
> >   return ret;
> >
> > - man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> > - man->default_caching = TTM_PL_FLAG_WC;
> > - ret = ttm_range_man_init(>bdev, man, vram_size >> PAGE_SHIFT);
> > + ret = ttm_range_man_init(>bdev, TTM_PL_VRAM,
> > +  TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC,
> > +  TTM_PL_FLAG_WC, false,
> > +  vram_size >> PAGE_SHIFT);
> >   if (ret)
> >   return ret;
> >
> > @@ -1127,7 +1127,7 @@ static int drm_vram_mm_init(struct drm_vram_mm *vmm, 
> > struct drm_device *dev,
> >
> >   static void drm_vram_mm_cleanup(struct drm_vram_mm *vmm)
> >   {
> > - ttm_range_man_fini(>bdev, ttm_manager_type(>bdev, 
> > TTM_PL_VRAM));
> > + ttm_range_man_fini(>bdev, TTM_PL_VRAM);
> >   ttm_bo_device_release(>bdev);
> >   }
> >
> > diff --git a/drivers/gpu/drm/nouve

Re: [PATCH 44/59] drm/ttm: allow drivers to provide their own manager subclasses

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:30, Christian König  wrote:
>
> Am 04.08.20 um 04:56 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > This will get removed eventually and all drivers will use this.
> >
> > Signed-off-by: Dave Airlie 
>
> Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   include/drm/ttm/ttm_bo_driver.h | 11 ++-
> >   1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/drm/ttm/ttm_bo_driver.h 
> > b/include/drm/ttm/ttm_bo_driver.h
> > index 03b253d14e6a..6940d85a531a 100644
> > --- a/include/drm/ttm/ttm_bo_driver.h
> > +++ b/include/drm/ttm/ttm_bo_driver.h
> > @@ -419,7 +419,7 @@ struct ttm_bo_device {
> >* access via ttm_manager_type.
> >*/
> >   struct ttm_mem_type_manager man_priv[TTM_NUM_MEM_TYPES];
> > -
> > + struct ttm_mem_type_manager *man_drv[TTM_NUM_MEM_TYPES];
> >   /*
> >* Protected by internal locks.
> >*/
> > @@ -450,9 +450,18 @@ struct ttm_bo_device {
> >   static inline struct ttm_mem_type_manager *ttm_manager_type(struct 
> > ttm_bo_device *bdev,
> >   int mem_type)
> >   {
> > + if (bdev->man_drv[mem_type])
> > + return bdev->man_drv[mem_type];
> >   return >man_priv[mem_type];
> >   }
> >
> > +static inline void ttm_set_driver_manager(struct ttm_bo_device *bdev,
> > +   int type,
> > +   struct ttm_mem_type_manager 
> > *manager)
> > +{
> > + bdev->man_drv[type] = manager;
> > +}
> > +
> >   /**
> >* struct ttm_lru_bulk_move_pos
> >*
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 43/59] drm/ttm: rename manager variable to make sure wrapper is used.

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:30, Christian König  wrote:
>
> Am 04.08.20 um 04:56 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > Other users of this should notice this change and switch to wrapper.
> >
> > Signed-off-by: Dave Airlie 
>
> Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
> >   include/drm/ttm/ttm_bo_driver.h | 7 +--
> >   2 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index 8777c323e7de..3a3a4dfb0fff 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -1617,7 +1617,7 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
> >
> >   bdev->driver = driver;
> >
> > - memset(bdev->man, 0, sizeof(bdev->man));
> > + memset(bdev->man_priv, 0, sizeof(bdev->man_priv));
> >
> >   ttm_bo_init_sysman(bdev);
> >
> > diff --git a/include/drm/ttm/ttm_bo_driver.h 
> > b/include/drm/ttm/ttm_bo_driver.h
> > index e80deee3ae99..03b253d14e6a 100644
> > --- a/include/drm/ttm/ttm_bo_driver.h
> > +++ b/include/drm/ttm/ttm_bo_driver.h
> > @@ -415,7 +415,10 @@ struct ttm_bo_device {
> >*/
> >   struct list_head device_list;
> >   struct ttm_bo_driver *driver;
> > - struct ttm_mem_type_manager man[TTM_NUM_MEM_TYPES];
> > + /*
> > +  * access via ttm_manager_type.
> > +  */
> > + struct ttm_mem_type_manager man_priv[TTM_NUM_MEM_TYPES];
> >
> >   /*
> >* Protected by internal locks.
> > @@ -447,7 +450,7 @@ struct ttm_bo_device {
> >   static inline struct ttm_mem_type_manager *ttm_manager_type(struct 
> > ttm_bo_device *bdev,
> >   int mem_type)
> >   {
> > - return >man[mem_type];
> > + return >man_priv[mem_type];
> >   }
> >
> >   /**
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 36/59] drm/ttm: add wrapper to get manager from bdev.

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:25, Christian König  wrote:
>
> Am 04.08.20 um 04:56 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > This will allow different abstractions later.
> >
> > Signed-off-by: Dave Airlie 
>
> Acked-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo.c  | 34 +++
> >   drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +-
> >   drivers/gpu/drm/ttm/ttm_bo_vm.c   |  2 +-
> >   include/drm/ttm/ttm_bo_driver.h   |  6 ++
> >   4 files changed, 34 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index ebecb796dd49..8777c323e7de 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -108,7 +108,7 @@ static void ttm_bo_mem_space_debug(struct 
> > ttm_buffer_object *bo,
> >   return;
> >   drm_printf(, "  placement[%d]=0x%08X (%d)\n",
> >  i, placement->placement[i].flags, mem_type);
> > - man = >bdev->man[mem_type];
> > + man = ttm_manager_type(bo->bdev, mem_type);
> >   ttm_mem_type_manager_debug(man, );
> >   }
> >   }
> > @@ -157,7 +157,7 @@ static void ttm_bo_add_mem_to_lru(struct 
> > ttm_buffer_object *bo,
> >   if (mem->placement & TTM_PL_FLAG_NO_EVICT)
> >   return;
> >
> > - man = >man[mem->mem_type];
> > + man = ttm_manager_type(bdev, mem->mem_type);
> >   list_add_tail(>lru, >lru[bo->priority]);
> >
> >   if (man->use_tt && bo->ttm &&
> > @@ -232,7 +232,7 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move 
> > *bulk)
> >   dma_resv_assert_held(pos->first->base.resv);
> >   dma_resv_assert_held(pos->last->base.resv);
> >
> > - man = >first->bdev->man[TTM_PL_TT];
> > + man = ttm_manager_type(pos->first->bdev, TTM_PL_TT);
> >   list_bulk_move_tail(>lru[i], >first->lru,
> >   >last->lru);
> >   }
> > @@ -247,7 +247,7 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move 
> > *bulk)
> >   dma_resv_assert_held(pos->first->base.resv);
> >   dma_resv_assert_held(pos->last->base.resv);
> >
> > - man = >first->bdev->man[TTM_PL_VRAM];
> > + man = ttm_manager_type(pos->first->bdev, TTM_PL_VRAM);
> >   list_bulk_move_tail(>lru[i], >first->lru,
> >   >last->lru);
> >   }
> > @@ -273,8 +273,8 @@ static int ttm_bo_handle_move_mem(struct 
> > ttm_buffer_object *bo,
> > struct ttm_operation_ctx *ctx)
> >   {
> >   struct ttm_bo_device *bdev = bo->bdev;
> > - struct ttm_mem_type_manager *old_man = >man[bo->mem.mem_type];
> > - struct ttm_mem_type_manager *new_man = >man[mem->mem_type];
> > + struct ttm_mem_type_manager *old_man = ttm_manager_type(bdev, 
> > bo->mem.mem_type);
> > + struct ttm_mem_type_manager *new_man = ttm_manager_type(bdev, 
> > mem->mem_type);
> >   int ret;
> >
> >   ret = ttm_mem_io_lock(old_man, true);
> > @@ -340,7 +340,7 @@ static int ttm_bo_handle_move_mem(struct 
> > ttm_buffer_object *bo,
> >   return 0;
> >
> >   out_err:
> > - new_man = >man[bo->mem.mem_type];
> > + new_man = ttm_manager_type(bdev, bo->mem.mem_type);
> >   if (!new_man->use_tt) {
> >   ttm_tt_destroy(bo->ttm);
> >   bo->ttm = NULL;
> > @@ -552,7 +552,7 @@ static void ttm_bo_release(struct kref *kref)
> >   struct ttm_buffer_object *bo =
> >   container_of(kref, struct ttm_buffer_object, kref);
> >   struct ttm_bo_device *bdev = bo->bdev;
> > - struct ttm_mem_type_manager *man = >man[bo->mem.mem_type];
> > + struct ttm_mem_type_manager *man = ttm_manager_type(bdev, 
> > bo->mem.mem_type);
> >   size_t acc_size = bo->acc_size;
> >   int ret;
> >
> > @@ -844,7 +844,7 @@ static int ttm_bo_mem_get(struct ttm_buffer_object *bo,
> > const struct ttm_place *place,
> > struct ttm_mem_reg *mem)
> >   {
> > - struct ttm_mem_type_mana

Re: [PATCH 39/59] drm/nouveau/ttm: use wrapper to access memory managers

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:58, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nouveau_ttm.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index bb310719e3f5..cc6cf04553dd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -156,7 +156,7 @@ nouveau_ttm_init_host(struct nouveau_drm *drm, u8 kind)
>  static int
>  nouveau_ttm_init_vram(struct nouveau_drm *drm)
>  {
> -   struct ttm_mem_type_manager *man = >ttm.bdev.man[TTM_PL_VRAM];
> +   struct ttm_mem_type_manager *man = ttm_manager_type(>ttm.bdev, 
> TTM_PL_VRAM);
> struct nvif_mmu *mmu = >client.mmu;
>
> man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> @@ -186,7 +186,7 @@ nouveau_ttm_init_vram(struct nouveau_drm *drm)
>  static void
>  nouveau_ttm_fini_vram(struct nouveau_drm *drm)
>  {
> -   struct ttm_mem_type_manager *man = >ttm.bdev.man[TTM_PL_VRAM];
> +   struct ttm_mem_type_manager *man = ttm_manager_type(>ttm.bdev, 
> TTM_PL_VRAM);
>
> if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
> ttm_mem_type_manager_disable(man);
> @@ -199,7 +199,7 @@ nouveau_ttm_fini_vram(struct nouveau_drm *drm)
>  static int
>  nouveau_ttm_init_gtt(struct nouveau_drm *drm)
>  {
> -   struct ttm_mem_type_manager *man = >ttm.bdev.man[TTM_PL_TT];
> +   struct ttm_mem_type_manager *man = ttm_manager_type(>ttm.bdev, 
> TTM_PL_TT);
> unsigned long size_pages = drm->gem.gart_available >> PAGE_SHIFT;
> man->use_tt = true;
> if (drm->agp.bridge) {
> @@ -228,7 +228,7 @@ nouveau_ttm_init_gtt(struct nouveau_drm *drm)
>  static void
>  nouveau_ttm_fini_gtt(struct nouveau_drm *drm)
>  {
> -   struct ttm_mem_type_manager *man = >ttm.bdev.man[TTM_PL_TT];
> +   struct ttm_mem_type_manager *man = ttm_manager_type(>ttm.bdev, 
> TTM_PL_TT);
>
> if (drm->client.device.info.family < NV_DEVICE_INFO_V0_TESLA &&
> drm->agp.bridge)
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 35/59] drm/ttm: make TTM responsible for cleaning system only.

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:58, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Drivers should all be cleaning up their memory managers
> themselves now, so let the core just clean the system one up.
>
> Remove the legacy cleaning interface.
>
> Reviewed-by: Christian König 
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c| 54 +++--
>  include/drm/ttm/ttm_bo_api.h| 28 -
>  include/drm/ttm/ttm_bo_driver.h | 10 --
>  3 files changed, 4 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index a45038c74de6..ebecb796dd49 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1452,42 +1452,6 @@ int ttm_mem_type_manager_force_list_clean(struct 
> ttm_bo_device *bdev,
>  }
>  EXPORT_SYMBOL(ttm_mem_type_manager_force_list_clean);
>
> -int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned mem_type)
> -{
> -   struct ttm_mem_type_manager *man;
> -   int ret = -EINVAL;
> -
> -   if (mem_type >= TTM_NUM_MEM_TYPES) {
> -   pr_err("Illegal memory type %d\n", mem_type);
> -   return ret;
> -   }
> -   man = >man[mem_type];
> -
> -   if (!man->has_type) {
> -   pr_err("Trying to take down uninitialized memory manager type 
> %u\n",
> -  mem_type);
> -   return ret;
> -   }
> -
> -   ttm_mem_type_manager_disable(man);
> -
> -   ret = 0;
> -   if (mem_type > 0) {
> -   ret = ttm_mem_type_manager_force_list_clean(bdev, man);
> -   if (ret) {
> -   pr_err("Cleanup eviction failed\n");
> -   return ret;
> -   }
> -
> -   if (man->func->takedown)
> -   ret = (*man->func->takedown)(man);
> -   }
> -
> -   ttm_mem_type_manager_cleanup(man);
> -
> -   return ret;
> -}
> -EXPORT_SYMBOL(ttm_bo_clean_mm);
>
>  int ttm_bo_evict_mm(struct ttm_bo_device *bdev, unsigned mem_type)
>  {
> @@ -1591,21 +1555,11 @@ int ttm_bo_device_release(struct ttm_bo_device *bdev)
>  {
> struct ttm_bo_global *glob = _bo_glob;
> int ret = 0;
> -   unsigned i = TTM_NUM_MEM_TYPES;
> +   unsigned i;
> struct ttm_mem_type_manager *man;
>
> -   while (i--) {
> -   man = >man[i];
> -   if (man->has_type) {
> -   man->use_type = false;
> -   if ((i != TTM_PL_SYSTEM) && ttm_bo_clean_mm(bdev, i)) 
> {
> -   ret = -EBUSY;
> -   pr_err("DRM memory manager type %d is not 
> clean\n",
> -  i);
> -   }
> -   man->has_type = false;
> -   }
> -   }
> +   man = >man[TTM_PL_SYSTEM];
> +   ttm_mem_type_manager_disable(man);
>
> mutex_lock(_global_mutex);
> list_del(>device_list);
> @@ -1618,7 +1572,7 @@ int ttm_bo_device_release(struct ttm_bo_device *bdev)
>
> spin_lock(>lru_lock);
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
> -   if (list_empty(>man[0].lru[0]))
> +   if (list_empty(>lru[0]))
> pr_debug("Swap list %d was clean\n", i);
> spin_unlock(>lru_lock);
>
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 2c84622faa44..9c55eafd0e7d 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -546,34 +546,6 @@ void ttm_mem_type_manager_init(struct ttm_bo_device 
> *bdev,
>struct ttm_mem_type_manager *man,
>unsigned long p_size);
>
> -/**
> - * ttm_bo_clean_mm
> - *
> - * @bdev: Pointer to a ttm_bo_device struct.
> - * @mem_type: The memory type.
> - *
> - * Take down a manager for a given memory type after first walking
> - * the LRU list to evict any buffers left alive.
> - *
> - * Normally, this function is part of lastclose() or unload(), and at that
> - * point there shouldn't be any buffers left created by user-space, since
> - * there should've been removed by the file descriptor release() method.
> - * However, before this function is run, make sure to signal all sync 
> objects,
> - * and verify that the delayed delete queue is empty. The driver must also
> - * make sure that there are no NO_EVICT 

Re: [PATCH 34/59] drm/ttm: remove range manager legacy takedown path

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:58, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Now all drivers have been converted, drop the non-driver path.
>
> Reviewed-by: Christian König 
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/ttm/ttm_bo_manager.c | 28 +---
>  1 file changed, 9 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c 
> b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> index 96da22be672b..86bf5e71e959 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> @@ -129,26 +129,11 @@ int ttm_range_man_init(struct ttm_bo_device *bdev,
>  }
>  EXPORT_SYMBOL(ttm_range_man_init);
>
> -static int ttm_bo_man_takedown_private(struct ttm_mem_type_manager *man)
> -{
> -   struct ttm_range_manager *rman = (struct ttm_range_manager *) 
> man->priv;
> -   struct drm_mm *mm = >mm;
> -
> -   spin_lock(>lock);
> -   if (drm_mm_clean(mm)) {
> -   drm_mm_takedown(mm);
> -   spin_unlock(>lock);
> -   kfree(rman);
> -   man->priv = NULL;
> -   return 0;
> -   }
> -   spin_unlock(>lock);
> -   return -EBUSY;
> -}
> -
>  int ttm_range_man_fini(struct ttm_bo_device *bdev,
>struct ttm_mem_type_manager *man)
>  {
> +   struct ttm_range_manager *rman = (struct ttm_range_manager *) 
> man->priv;
> +   struct drm_mm *mm = >mm;
> int ret;
>
> ttm_mem_type_manager_disable(man);
> @@ -157,7 +142,13 @@ int ttm_range_man_fini(struct ttm_bo_device *bdev,
> if (ret)
> return ret;
>
> -   ttm_bo_man_takedown_private(man);
> +   spin_lock(>lock);
> +   drm_mm_clean(mm);
> +   drm_mm_takedown(mm);
> +   spin_unlock(>lock);
> +   kfree(rman);
> +   man->priv = NULL;
> +
> ttm_mem_type_manager_cleanup(man);
> return 0;
>  }
> @@ -174,7 +165,6 @@ static void ttm_bo_man_debug(struct ttm_mem_type_manager 
> *man,
>  }
>
>  static const struct ttm_mem_type_manager_func ttm_bo_manager_func = {
> -   .takedown = ttm_bo_man_takedown_private,
> .get_node = ttm_bo_man_get_node,
> .put_node = ttm_bo_man_put_node,
> .debug = ttm_bo_man_debug
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 30/59] drm/nouveau: use new cleanup paths

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:58, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nouveau_ttm.c | 41 ---
>  1 file changed, 30 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index cfcbecd332ef..bb310719e3f5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -31,12 +31,6 @@
>
>  #include 
>
> -static int
> -nouveau_manager_fini(struct ttm_mem_type_manager *man)
> -{
> -   return 0;
> -}
> -
>  static void
>  nouveau_manager_del(struct ttm_mem_type_manager *man, struct ttm_mem_reg 
> *reg)
>  {
> @@ -70,7 +64,6 @@ nouveau_vram_manager_new(struct ttm_mem_type_manager *man,
>  }
>
>  const struct ttm_mem_type_manager_func nouveau_vram_manager = {
> -   .takedown = nouveau_manager_fini,
> .get_node = nouveau_vram_manager_new,
> .put_node = nouveau_manager_del,
>  };
> @@ -94,7 +87,6 @@ nouveau_gart_manager_new(struct ttm_mem_type_manager *man,
>  }
>
>  const struct ttm_mem_type_manager_func nouveau_gart_manager = {
> -   .takedown = nouveau_manager_fini,
> .get_node = nouveau_gart_manager_new,
> .put_node = nouveau_manager_del,
>  };
> @@ -127,7 +119,6 @@ nv04_gart_manager_new(struct ttm_mem_type_manager *man,
>  }
>
>  const struct ttm_mem_type_manager_func nv04_gart_manager = {
> -   .takedown = nouveau_manager_fini,
> .get_node = nv04_gart_manager_new,
> .put_node = nouveau_manager_del,
>  };
> @@ -192,6 +183,19 @@ nouveau_ttm_init_vram(struct nouveau_drm *drm)
> }
>  }
>
> +static void
> +nouveau_ttm_fini_vram(struct nouveau_drm *drm)
> +{
> +   struct ttm_mem_type_manager *man = >ttm.bdev.man[TTM_PL_VRAM];
> +
> +   if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
> +   ttm_mem_type_manager_disable(man);
> +   ttm_mem_type_manager_force_list_clean(>ttm.bdev, man);
> +   ttm_mem_type_manager_cleanup(man);
> +   } else
> +   ttm_range_man_fini(>ttm.bdev, man);
> +}
> +
>  static int
>  nouveau_ttm_init_gtt(struct nouveau_drm *drm)
>  {
> @@ -221,6 +225,21 @@ nouveau_ttm_init_gtt(struct nouveau_drm *drm)
> return 0;
>  }
>
> +static void
> +nouveau_ttm_fini_gtt(struct nouveau_drm *drm)
> +{
> +   struct ttm_mem_type_manager *man = >ttm.bdev.man[TTM_PL_TT];
> +
> +   if (drm->client.device.info.family < NV_DEVICE_INFO_V0_TESLA &&
> +   drm->agp.bridge)
> +   ttm_range_man_fini(>ttm.bdev, man);
> +   else {
> +   ttm_mem_type_manager_disable(man);
> +   ttm_mem_type_manager_force_list_clean(>ttm.bdev, man);
> +   ttm_mem_type_manager_cleanup(man);
> +   }
> +}
> +
>  int
>  nouveau_ttm_init(struct nouveau_drm *drm)
>  {
> @@ -310,8 +329,8 @@ nouveau_ttm_fini(struct nouveau_drm *drm)
>  {
> struct nvkm_device *device = nvxx_device(>client.device);
>
> -   ttm_bo_clean_mm(>ttm.bdev, TTM_PL_VRAM);
> -   ttm_bo_clean_mm(>ttm.bdev, TTM_PL_TT);
> +   nouveau_ttm_fini_vram(drm);
> +   nouveau_ttm_fini_gtt(drm);
>
> ttm_bo_device_release(>ttm.bdev);
>
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 26/59] drm/ttm: start allowing drivers to use new takedown path (v2)

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:20, Christian König  wrote:
>
> Am 04.08.20 um 04:55 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > Allow the takedown path callback to be optional as well.
> >
> > v2: use fini for range manager
> > Signed-off-by: Dave Airlie 
>
> Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo.c | 12 +++-
> >   drivers/gpu/drm/ttm/ttm_bo_manager.c | 21 +++--
> >   include/drm/ttm/ttm_bo_driver.h  | 24 
> >   3 files changed, 50 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index 127a0b62bf98..a45038c74de6 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -1407,8 +1407,8 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
> >   }
> >   EXPORT_SYMBOL(ttm_bo_create);
> >
> > -static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
> > -struct ttm_mem_type_manager *man)
> > +int ttm_mem_type_manager_force_list_clean(struct ttm_bo_device *bdev,
> > +   struct ttm_mem_type_manager *man)
> >   {
> >   struct ttm_operation_ctx ctx = {
> >   .interruptible = false,
> > @@ -1450,6 +1450,7 @@ static int ttm_bo_force_list_clean(struct 
> > ttm_bo_device *bdev,
> >
> >   return 0;
> >   }
> > +EXPORT_SYMBOL(ttm_mem_type_manager_force_list_clean);
> >
> >   int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned mem_type)
> >   {
> > @@ -1472,13 +1473,14 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, 
> > unsigned mem_type)
> >
> >   ret = 0;
> >   if (mem_type > 0) {
> > - ret = ttm_bo_force_list_clean(bdev, man);
> > + ret = ttm_mem_type_manager_force_list_clean(bdev, man);
> >   if (ret) {
> >   pr_err("Cleanup eviction failed\n");
> >   return ret;
> >   }
> >
> > - ret = (*man->func->takedown)(man);
> > + if (man->func->takedown)
> > + ret = (*man->func->takedown)(man);
> >   }
> >
> >   ttm_mem_type_manager_cleanup(man);
> > @@ -1501,7 +1503,7 @@ int ttm_bo_evict_mm(struct ttm_bo_device *bdev, 
> > unsigned mem_type)
> >   return 0;
> >   }
> >
> > - return ttm_bo_force_list_clean(bdev, man);
> > + return ttm_mem_type_manager_force_list_clean(bdev, man);
> >   }
> >   EXPORT_SYMBOL(ttm_bo_evict_mm);
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c 
> > b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> > index b56c6961b278..96da22be672b 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> > @@ -129,7 +129,7 @@ int ttm_range_man_init(struct ttm_bo_device *bdev,
> >   }
> >   EXPORT_SYMBOL(ttm_range_man_init);
> >
> > -static int ttm_bo_man_takedown(struct ttm_mem_type_manager *man)
> > +static int ttm_bo_man_takedown_private(struct ttm_mem_type_manager *man)
> >   {
> >   struct ttm_range_manager *rman = (struct ttm_range_manager *) 
> > man->priv;
> >   struct drm_mm *mm = >mm;
> > @@ -146,6 +146,23 @@ static int ttm_bo_man_takedown(struct 
> > ttm_mem_type_manager *man)
> >   return -EBUSY;
> >   }
> >
> > +int ttm_range_man_fini(struct ttm_bo_device *bdev,
> > +struct ttm_mem_type_manager *man)
> > +{
> > + int ret;
> > +
> > + ttm_mem_type_manager_disable(man);
> > +
> > + ret = ttm_mem_type_manager_force_list_clean(bdev, man);
> > + if (ret)
> > + return ret;
> > +
> > + ttm_bo_man_takedown_private(man);
> > + ttm_mem_type_manager_cleanup(man);
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(ttm_range_man_fini);
> > +
> >   static void ttm_bo_man_debug(struct ttm_mem_type_manager *man,
> >struct drm_printer *printer)
> >   {
> > @@ -157,7 +174,7 @@ static void ttm_bo_man_debug(struct 
> > ttm_mem_type_manager *man,
> >   }
> >
> >   static const struct ttm_mem_type_manager_func ttm_bo_manager_func = {
> > - .takedown = ttm_bo_man_takedown,
> > + .takedown = ttm_bo_man_takedown_private,
> >   .get_node = ttm_bo_man_get_node,
> >   .put_no

Re: [PATCH 25/59] drm/ttm: make some inline helper functions for cleanup paths. (v2)

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 21:18, Christian König  wrote:
>
> Am 04.08.20 um 04:55 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > The disable path is just temporary for now, it will be dropped once has_type
> > is gone in a later patch.
> >
> > v2: add docs.
> > rename to ttm_mem_type_manager namespace
> >
> > Signed-off-by: Dave Airlie 
>
> Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo.c|  6 ++
> >   include/drm/ttm/ttm_bo_driver.h | 26 ++
> >   2 files changed, 28 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index af1b1c3f6ed2..127a0b62bf98 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -1468,8 +1468,7 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, 
> > unsigned mem_type)
> >   return ret;
> >   }
> >
> > - man->use_type = false;
> > - man->has_type = false;
> > + ttm_mem_type_manager_disable(man);
> >
> >   ret = 0;
> >   if (mem_type > 0) {
> > @@ -1482,8 +1481,7 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, 
> > unsigned mem_type)
> >   ret = (*man->func->takedown)(man);
> >   }
> >
> > - dma_fence_put(man->move);
> > - man->move = NULL;
> > + ttm_mem_type_manager_cleanup(man);
> >
> >   return ret;
> >   }
> > diff --git a/include/drm/ttm/ttm_bo_driver.h 
> > b/include/drm/ttm/ttm_bo_driver.h
> > index 548c27294c64..41bfa514c29d 100644
> > --- a/include/drm/ttm/ttm_bo_driver.h
> > +++ b/include/drm/ttm/ttm_bo_driver.h
> > @@ -680,6 +680,32 @@ static inline void 
> > ttm_mem_type_manager_set_used(struct ttm_mem_type_manager *ma
> >   man->use_type = used;
> >   }
> >
> > +/**
> > + * ttm_mem_type_manager_disable.
> > + *
> > + * @man: A memory manager object.
> > + *
> > + * Indicate the manager is not to be used and deregistered. (temporary 
> > during rework).
> > + */
> > +static inline void ttm_mem_type_manager_disable(struct 
> > ttm_mem_type_manager *man)
> > +{
> > + man->has_type = false;
> > + man->use_type = false;
> > +}
> > +
> > +/**
> > + * ttm_mem_type_manager_cleanup
> > + *
> > + * @man: A memory manager object.
> > + *
> > + * Cleanup the move fences from the memory manager object.
> > + */
> > +static inline void ttm_mem_type_manager_cleanup(struct 
> > ttm_mem_type_manager *man)
> > +{
> > + dma_fence_put(man->move);
> > + man->move = NULL;
> > +}
> > +
> >   /*
> >* ttm_bo_util.c
> >*/
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 24/59] drm/ttm: pass man around instead of mem_type in some places

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:57, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> This makes it easier to cleanup things
>
> Reviewed-by: Christian König 
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index da88ea6cb814..af1b1c3f6ed2 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -769,13 +769,12 @@ static int ttm_mem_evict_wait_busy(struct 
> ttm_buffer_object *busy_bo,
>  }
>
>  static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> -  uint32_t mem_type,
> +  struct ttm_mem_type_manager *man,
>const struct ttm_place *place,
>struct ttm_operation_ctx *ctx,
>struct ww_acquire_ctx *ticket)
>  {
> struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
> -   struct ttm_mem_type_manager *man = >man[mem_type];
> bool locked = false;
> unsigned i;
> int ret;
> @@ -924,7 +923,7 @@ static int ttm_bo_mem_force_space(struct 
> ttm_buffer_object *bo,
> break;
> if (unlikely(ret != -ENOSPC))
> return ret;
> -   ret = ttm_mem_evict_first(bdev, mem->mem_type, place, ctx,
> +   ret = ttm_mem_evict_first(bdev, man, place, ctx,
>   ticket);
> if (unlikely(ret != 0))
> return ret;
> @@ -1409,14 +1408,13 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
>  EXPORT_SYMBOL(ttm_bo_create);
>
>  static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
> -  unsigned mem_type)
> +  struct ttm_mem_type_manager *man)
>  {
> struct ttm_operation_ctx ctx = {
> .interruptible = false,
> .no_wait_gpu = false,
> .flags = TTM_OPT_FLAG_FORCE_ALLOC
> };
> -   struct ttm_mem_type_manager *man = >man[mem_type];
> struct ttm_bo_global *glob = _bo_glob;
> struct dma_fence *fence;
> int ret;
> @@ -1430,7 +1428,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
> *bdev,
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> while (!list_empty(>lru[i])) {
> spin_unlock(>lru_lock);
> -   ret = ttm_mem_evict_first(bdev, mem_type, NULL, ,
> +   ret = ttm_mem_evict_first(bdev, man, NULL, ,
>   NULL);
> if (ret)
> return ret;
> @@ -1475,7 +1473,7 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, 
> unsigned mem_type)
>
> ret = 0;
> if (mem_type > 0) {
> -   ret = ttm_bo_force_list_clean(bdev, mem_type);
> +   ret = ttm_bo_force_list_clean(bdev, man);
> if (ret) {
> pr_err("Cleanup eviction failed\n");
> return ret;
> @@ -1505,7 +1503,7 @@ int ttm_bo_evict_mm(struct ttm_bo_device *bdev, 
> unsigned mem_type)
> return 0;
> }
>
> -   return ttm_bo_force_list_clean(bdev, mem_type);
> +   return ttm_bo_force_list_clean(bdev, man);
>  }
>  EXPORT_SYMBOL(ttm_bo_evict_mm);
>
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 23/59] drm/ttm: purge old manager init path.

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:57, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Reviewed-by: Christian König 
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 19 --
>  drivers/gpu/drm/ttm/ttm_bo_manager.c | 29 ++--
>  include/drm/ttm/ttm_bo_api.h | 18 -
>  include/drm/ttm/ttm_bo_driver.h  | 15 --
>  4 files changed, 10 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index c56cbc6c0ba8..da88ea6cb814 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1529,25 +1529,6 @@ void ttm_mem_type_manager_init(struct ttm_bo_device 
> *bdev,
>  }
>  EXPORT_SYMBOL(ttm_mem_type_manager_init);
>
> -int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned type,
> -   unsigned long p_size)
> -{
> -   int ret;
> -   struct ttm_mem_type_manager *man;
> -
> -   BUG_ON(type >= TTM_NUM_MEM_TYPES);
> -   ttm_mem_type_manager_init(bdev, >man[type], p_size);
> -
> -   if (type != TTM_PL_SYSTEM) {
> -   ret = (*man->func->init)(man, p_size);
> -   if (ret)
> -   return ret;
> -   }
> -   ttm_mem_type_manager_set_used(man, true);
> -   return 0;
> -}
> -EXPORT_SYMBOL(ttm_bo_init_mm);
> -
>  static void ttm_bo_global_kobj_release(struct kobject *kobj)
>  {
> struct ttm_bo_global *glob =
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c 
> b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> index eb86c8694f47..b56c6961b278 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> @@ -104,11 +104,18 @@ static void ttm_bo_man_put_node(struct 
> ttm_mem_type_manager *man,
> }
>  }
>
> -static int ttm_bo_man_init_private(struct ttm_mem_type_manager *man,
> -  unsigned long p_size)
> +static const struct ttm_mem_type_manager_func ttm_bo_manager_func;
> +
> +int ttm_range_man_init(struct ttm_bo_device *bdev,
> +  struct ttm_mem_type_manager *man,
> +  unsigned long p_size)
>  {
> struct ttm_range_manager *rman;
>
> +   man->func = _bo_manager_func;
> +
> +   ttm_mem_type_manager_init(bdev, man, p_size);
> +
> rman = kzalloc(sizeof(*rman), GFP_KERNEL);
> if (!rman)
> return -ENOMEM;
> @@ -116,21 +123,7 @@ static int ttm_bo_man_init_private(struct 
> ttm_mem_type_manager *man,
> drm_mm_init(>mm, 0, p_size);
> spin_lock_init(>lock);
> man->priv = rman;
> -   return 0;
> -}
>
> -int ttm_range_man_init(struct ttm_bo_device *bdev,
> -  struct ttm_mem_type_manager *man,
> -  unsigned long p_size)
> -{
> -   int ret;
> -
> -   man->func = _bo_manager_func;
> -
> -   ttm_mem_type_manager_init(bdev, man, p_size);
> -   ret = ttm_bo_man_init_private(man, p_size);
> -   if (ret)
> -   return ret;
> ttm_mem_type_manager_set_used(man, true);
> return 0;
>  }
> @@ -163,11 +156,9 @@ static void ttm_bo_man_debug(struct ttm_mem_type_manager 
> *man,
> spin_unlock(>lock);
>  }
>
> -const struct ttm_mem_type_manager_func ttm_bo_manager_func = {
> -   .init = ttm_bo_man_init_private,
> +static const struct ttm_mem_type_manager_func ttm_bo_manager_func = {
> .takedown = ttm_bo_man_takedown,
> .get_node = ttm_bo_man_get_node,
> .put_node = ttm_bo_man_put_node,
> .debug = ttm_bo_man_debug
>  };
> -EXPORT_SYMBOL(ttm_bo_manager_func);
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 89053e761a69..2c84622faa44 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -546,24 +546,6 @@ void ttm_mem_type_manager_init(struct ttm_bo_device 
> *bdev,
>struct ttm_mem_type_manager *man,
>unsigned long p_size);
>
> -/**
> - * ttm_bo_init_mm
> - *
> - * @bdev: Pointer to a ttm_bo_device struct.
> - * @mem_type: The memory type.
> - * @p_size: size managed area in pages.
> - *
> - * Initialize a manager for a given memory type.
> - * Note: if part of driver firstopen, it must be protected from a
> - * potentially racing lastclose.
> - * Returns:
> - * -EINVAL: invalid size or memory type.
> - * -ENOMEM: Not enough memory.
> - * May also return driver-specified errors.
> - */
> -int ttm_bo_i

Re: [PATCH 22/59] drm/ttm: convert system manager init to new code.

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:57, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Remove the exit path, since this can't fail now.
>
> Reviewed-by: Christian König 
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 30 +-
>  1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 300bcc10696a..c56cbc6c0ba8 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1650,6 +1650,22 @@ int ttm_bo_device_release(struct ttm_bo_device *bdev)
>  }
>  EXPORT_SYMBOL(ttm_bo_device_release);
>
> +static void ttm_bo_init_sysman(struct ttm_bo_device *bdev)
> +{
> +   struct ttm_mem_type_manager *man = >man[TTM_PL_SYSTEM];
> +
> +   /*
> +* Initialize the system memory buffer type.
> +* Other types need to be driver / IOCTL initialized.
> +*/
> +   man->use_tt = true;
> +   man->available_caching = TTM_PL_MASK_CACHING;
> +   man->default_caching = TTM_PL_FLAG_CACHED;
> +
> +   ttm_mem_type_manager_init(bdev, man, 0);
> +   ttm_mem_type_manager_set_used(man, true);
> +}
> +
>  int ttm_bo_device_init(struct ttm_bo_device *bdev,
>struct ttm_bo_driver *driver,
>struct address_space *mapping,
> @@ -1670,16 +1686,7 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
>
> memset(bdev->man, 0, sizeof(bdev->man));
>
> -   /*
> -* Initialize the system memory buffer type.
> -* Other types need to be driver / IOCTL initialized.
> -*/
> -   bdev->man[TTM_PL_SYSTEM].use_tt = true;
> -   bdev->man[TTM_PL_SYSTEM].available_caching = TTM_PL_MASK_CACHING;
> -   bdev->man[TTM_PL_SYSTEM].default_caching = TTM_PL_FLAG_CACHED;
> -   ret = ttm_bo_init_mm(bdev, TTM_PL_SYSTEM, 0);
> -   if (unlikely(ret != 0))
> -   goto out_no_sys;
> +   ttm_bo_init_sysman(bdev);
>
> bdev->vma_manager = vma_manager;
> INIT_DELAYED_WORK(>wq, ttm_bo_delayed_workqueue);
> @@ -1691,9 +1698,6 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
> mutex_unlock(_global_mutex);
>
> return 0;
> -out_no_sys:
> -   ttm_bo_global_release();
> -   return ret;
>  }
>  EXPORT_SYMBOL(ttm_bo_device_init);
>
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 19/59] drm/nouveau: use new memory manager init paths

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:57, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nouveau_ttm.c | 43 ---
>  1 file changed, 19 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index 6de762a0c229..cfcbecd332ef 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -31,12 +31,6 @@
>
>  #include 
>
> -static int
> -nouveau_manager_init(struct ttm_mem_type_manager *man, unsigned long psize)
> -{
> -   return 0;
> -}
> -
>  static int
>  nouveau_manager_fini(struct ttm_mem_type_manager *man)
>  {
> @@ -76,7 +70,6 @@ nouveau_vram_manager_new(struct ttm_mem_type_manager *man,
>  }
>
>  const struct ttm_mem_type_manager_func nouveau_vram_manager = {
> -   .init = nouveau_manager_init,
> .takedown = nouveau_manager_fini,
> .get_node = nouveau_vram_manager_new,
> .put_node = nouveau_manager_del,
> @@ -101,7 +94,6 @@ nouveau_gart_manager_new(struct ttm_mem_type_manager *man,
>  }
>
>  const struct ttm_mem_type_manager_func nouveau_gart_manager = {
> -   .init = nouveau_manager_init,
> .takedown = nouveau_manager_fini,
> .get_node = nouveau_gart_manager_new,
> .put_node = nouveau_manager_del,
> @@ -135,7 +127,6 @@ nv04_gart_manager_new(struct ttm_mem_type_manager *man,
>  }
>
>  const struct ttm_mem_type_manager_func nv04_gart_manager = {
> -   .init = nouveau_manager_init,
> .takedown = nouveau_manager_fini,
> .get_node = nv04_gart_manager_new,
> .put_node = nouveau_manager_del,
> @@ -191,27 +182,21 @@ nouveau_ttm_init_vram(struct nouveau_drm *drm)
>
> man->func = _vram_manager;
> man->use_io_reserve_lru = true;
> +   ttm_mem_type_manager_init(>ttm.bdev, man,
> + drm->gem.vram_available >> 
> PAGE_SHIFT);
> +   ttm_mem_type_manager_set_used(man, true);
> +   return 0;
> } else {
> -   man->func = _bo_manager_func;
> +   return ttm_range_man_init(>ttm.bdev, man,
> + drm->gem.vram_available >> 
> PAGE_SHIFT);
> }
> -
> -   return ttm_bo_init_mm(>ttm.bdev, TTM_PL_VRAM,
> - drm->gem.vram_available >> PAGE_SHIFT);
>  }
>
>  static int
>  nouveau_ttm_init_gtt(struct nouveau_drm *drm)
>  {
> struct ttm_mem_type_manager *man = >ttm.bdev.man[TTM_PL_TT];
> -
> -   if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA)
> -   man->func = _gart_manager;
> -   else
> -   if (!drm->agp.bridge)
> -   man->func = _gart_manager;
> -   else
> -   man->func = _bo_manager_func;
> -
> +   unsigned long size_pages = drm->gem.gart_available >> PAGE_SHIFT;
> man->use_tt = true;
> if (drm->agp.bridge) {
> man->available_caching = TTM_PL_FLAG_UNCACHED |
> @@ -222,8 +207,18 @@ nouveau_ttm_init_gtt(struct nouveau_drm *drm)
> man->default_caching = TTM_PL_FLAG_CACHED;
> }
>
> -   return ttm_bo_init_mm(>ttm.bdev, TTM_PL_TT,
> - drm->gem.gart_available >> PAGE_SHIFT);
> +   if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA)
> +   man->func = _gart_manager;
> +   else if (!drm->agp.bridge)
> +   man->func = _gart_manager;
> +   else
> +   return ttm_range_man_init(>ttm.bdev, man,
> + size_pages);
> +
> +   ttm_mem_type_manager_init(>ttm.bdev, man,
> + size_pages);
> +   ttm_mem_type_manager_set_used(man, true);
> +   return 0;
>  }
>
>  int
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 09/59] drm/nouveau/ttm: don't fill in blank ttm debug callback

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 12:57, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> Acked-by: Christian König 
> Signed-off-by: Dave Airlie 
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nouveau_ttm.c | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index b0012021ae12..6de762a0c229 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -49,12 +49,6 @@ nouveau_manager_del(struct ttm_mem_type_manager *man, 
> struct ttm_mem_reg *reg)
> nouveau_mem_del(reg);
>  }
>
> -static void
> -nouveau_manager_debug(struct ttm_mem_type_manager *man,
> - struct drm_printer *printer)
> -{
> -}
> -
>  static int
>  nouveau_vram_manager_new(struct ttm_mem_type_manager *man,
>  struct ttm_buffer_object *bo,
> @@ -86,7 +80,6 @@ const struct ttm_mem_type_manager_func nouveau_vram_manager 
> = {
> .takedown = nouveau_manager_fini,
> .get_node = nouveau_vram_manager_new,
> .put_node = nouveau_manager_del,
> -   .debug = nouveau_manager_debug,
>  };
>
>  static int
> @@ -112,7 +105,6 @@ const struct ttm_mem_type_manager_func 
> nouveau_gart_manager = {
> .takedown = nouveau_manager_fini,
> .get_node = nouveau_gart_manager_new,
> .put_node = nouveau_manager_del,
> -   .debug = nouveau_manager_debug
>  };
>
>  static int
> @@ -147,7 +139,6 @@ const struct ttm_mem_type_manager_func nv04_gart_manager 
> = {
> .takedown = nouveau_manager_fini,
> .get_node = nv04_gart_manager_new,
> .put_node = nouveau_manager_del,
> -   .debug = nouveau_manager_debug
>  };
>
>  int
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 08/59] drm/ttm: export memory type debug entrypoint.

2020-08-04 Thread Ben Skeggs
On Tue, 4 Aug 2020 at 20:35, Christian König  wrote:
>
> Am 04.08.20 um 04:55 schrieb Dave Airlie:
> > From: Dave Airlie 
> >
> > As suggested on review, just export the memory type debug for
> > drivers to use, while also making the debug callback optional
> > (don't need to test for system as it won't init it).
> >
> > rename it to be more consistent with object name for now.
> > (we may rename all the objects later.)
> >
> > Signed-off-by: Dave Airlie 
>
> Reviewed-by: Christian König 
Reviewed-by: Ben Skeggs 

>
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo.c| 13 +++--
> >   include/drm/ttm/ttm_bo_driver.h |  8 
> >   2 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index 2b49037231eb..2ac70ec1f37d 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -77,26 +77,26 @@ static inline int ttm_mem_type_from_place(const struct 
> > ttm_place *place,
> >   return 0;
> >   }
> >
> > -static void ttm_mem_type_debug(struct ttm_bo_device *bdev, struct 
> > drm_printer *p,
> > -int mem_type)
> > +void ttm_mem_type_manager_debug(struct ttm_mem_type_manager *man,
> > + struct drm_printer *p)
> >   {
> > - struct ttm_mem_type_manager *man = >man[mem_type];
> > -
> >   drm_printf(p, "has_type: %d\n", man->has_type);
> >   drm_printf(p, "use_type: %d\n", man->use_type);
> >   drm_printf(p, "use_tt: %d\n", man->use_tt);
> >   drm_printf(p, "size: %llu\n", man->size);
> >   drm_printf(p, "available_caching: 0x%08X\n", 
> > man->available_caching);
> >   drm_printf(p, "default_caching: 0x%08X\n", man->default_caching);
> > - if (mem_type != TTM_PL_SYSTEM)
> > + if (man->func && man->func->debug)
> >   (*man->func->debug)(man, p);
> >   }
> > +EXPORT_SYMBOL(ttm_mem_type_manager_debug);
> >
> >   static void ttm_bo_mem_space_debug(struct ttm_buffer_object *bo,
> >   struct ttm_placement *placement)
> >   {
> >   struct drm_printer p = drm_debug_printer(TTM_PFX);
> >   int i, ret, mem_type;
> > + struct ttm_mem_type_manager *man;
> >
> >   drm_printf(, "No space for %p (%lu pages, %luK, %luM)\n",
> >  bo, bo->mem.num_pages, bo->mem.size >> 10,
> > @@ -108,7 +108,8 @@ static void ttm_bo_mem_space_debug(struct 
> > ttm_buffer_object *bo,
> >   return;
> >   drm_printf(, "  placement[%d]=0x%08X (%d)\n",
> >  i, placement->placement[i].flags, mem_type);
> > - ttm_mem_type_debug(bo->bdev, , mem_type);
> > + man = >bdev->man[mem_type];
> > + ttm_mem_type_manager_debug(man, );
> >   }
> >   }
> >
> > diff --git a/include/drm/ttm/ttm_bo_driver.h 
> > b/include/drm/ttm/ttm_bo_driver.h
> > index 7958e411269a..73f5d9c766cc 100644
> > --- a/include/drm/ttm/ttm_bo_driver.h
> > +++ b/include/drm/ttm/ttm_bo_driver.h
> > @@ -795,4 +795,12 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
> > tmp);
> >
> >   extern const struct ttm_mem_type_manager_func ttm_bo_manager_func;
> >
> > +/**
> > + * ttm_mem_type_manager_debug
> > + *
> > + * @man: manager type to dump.
> > + * @p: printer to use for debug.
> > + */
> > +void ttm_mem_type_manager_debug(struct ttm_mem_type_manager *man,
> > + struct drm_printer *p);
> >   #endif
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   3   4   5   6   7   >