Re: [Nouveau] [PATCH 1/5] PCI: Recognize Thunderbolt devices

2017-02-24 Thread Lukas Wunner 
On Fri, Feb 24, 2017 at 04:17:24PM -0600, Bjorn Helgaas wrote:
> On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -358,6 +358,7 @@ struct pci_dev {
> > unsigned intis_virtfn:1;
> > unsigned intreset_fn:1;
> > unsigned intis_hotplug_bridge:1;
> > +   unsigned intis_thunderbolt:1; /* Thunderbolt controller */
> 
> I'm not really keen on having this in the PCI core because the core
> doesn't need this or even know what it means.
> 
> pci_find_next_ext_capability() is available to drivers, and if
> Thunderbolt-connectedness is useful information to apple-gmux or GPU
> drivers, it's fine with me if you want to use it there.  I just don't
> see the benefit to having it in the core.

The above contradicts your statement 3 days earlier:

"Assuming we need it, having it in struct pci_dev is fine.
 There's no point in looking up the VSEC capability more than once."
(http://www.spinics.net/lists/linux-pci/msg58532.html)

Please explain.

Thanks,

Lukas
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 99922] [NVE4] [regression, bisected] 4.10 (atomic): X shows black screen with cursor after monitors turn off

2017-02-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=99922

--- Comment #6 from Ben Skeggs  ---
(In reply to kevin from comment #5)
> Created attachment 129896 [details]
> Normal Xorg logs on Linux 4.10 with xf86-video-modesetting
> 
> Interestingly, the bug does not appear with the generic modesetting driver!
> I've attached the Xorg log, but it seems normal.

Yeah, the nouveau 2D driver doesn't handle page flips failing correctly for
some reason (this can happen under atomic when DPMS is set to a power-saving
mode).

I wasn't able to reproduce this with the nouveau DDX running in its (default)
DRI2 mode, only DRI3, so I hadn't prioritized looking into it.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 99954] New: Errors when using VirtualBox with 3D acceleration: gr: ILLEGAL_CLASS ch 6 [007f7f8000 VirtualBox[5063]] subc 0 class c000 mthd 2390 data 00000000

2017-02-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=99954

Bug ID: 99954
   Summary: Errors when using VirtualBox with 3D acceleration: gr:
ILLEGAL_CLASS ch 6 [007f7f8000 VirtualBox[5063]] subc
0 class c000 mthd 2390 data 
   Product: xorg
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: mpiecho...@nvidia.com
QA Contact: xorg-t...@lists.x.org

On W530 with iGPU disabled I see the errors in dmesg log when I try to run
VirtualBox with 3D acceleration:

[ 8781.350709] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350729] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350749] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350769] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350789] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350808] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350828] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350848] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350868] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350888] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350907] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2390 data 
[ 8781.350927] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2380 data 0800
[ 8781.350947] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2384 data 
[ 8781.350967] nouveau :01:00.0: gr: ILLEGAL_CLASS ch 6 [007f7f8000
VirtualBox[5063]] subc 0 class c000 mthd 2388 data 00380800

VirtualBox itself has hang.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 99502] W530 hangs when iGPU is disabled and EFI started in dock

2017-02-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=99502

--- Comment #1 from mpiecho...@nvidia.com  ---
I cannot reproduce problem when the internal LCD is primary display instead of
external one.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 3/5] drm/nouveau: Don't register Thunderbolt eGPU with vga_switcheroo

2017-02-24 Thread Bjorn Helgaas 
On Fri, Feb 24, 2017 at 1:19 PM, Lukas Wunner  wrote:
> An external Thunderbolt GPU can neither drive the laptop's panel nor be
> powered off by the platform, so there's no point in registering it with
> vga_switcheroo.

> In fact, when the external GPU is runtime suspended,
> vga_switcheroo will cut power to the internal discrete GPU, resulting in
> a lockup.

Why does suspending the external GPU cause vga_switcheroo to cut power
to the internal GPU?  No doubt this would be obvious to a GPU person,
which I definitely am not.

> Cc: Ben Skeggs 
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/gpu/drm/nouveau/nouveau_vga.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
> b/drivers/gpu/drm/nouveau/nouveau_vga.c
> index eef22c6b9665..c2a7fd606c2e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_vga.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
> @@ -95,6 +95,10 @@ nouveau_vga_init(struct nouveau_drm *drm)
>
> vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode);
>
> +   /* don't register Thunderbolt eGPU with vga_switcheroo */
> +   if (pci_is_thunderbolt_attached(dev->pdev))
> +   return;

I guess there's no way to move this inside
vga_switcheroo_register_client() instead of putting the test in all
the drivers?

> +
> if (nouveau_runtime_pm == 1)
> runtime = true;
> if ((nouveau_runtime_pm == -1) && (nouveau_is_optimus() || 
> nouveau_is_v1_dsm()))
> @@ -111,6 +115,11 @@ nouveau_vga_fini(struct nouveau_drm *drm)
> struct drm_device *dev = drm->dev;
> bool runtime = false;
>
> +   vga_client_register(dev->pdev, NULL, NULL, NULL);
> +
> +   if (pci_is_thunderbolt_attached(dev->pdev))
> +   return;
> +
> if (nouveau_runtime_pm == 1)
> runtime = true;
> if ((nouveau_runtime_pm == -1) && (nouveau_is_optimus() || 
> nouveau_is_v1_dsm()))
> @@ -119,7 +128,6 @@ nouveau_vga_fini(struct nouveau_drm *drm)
> vga_switcheroo_unregister_client(dev->pdev);
> if (runtime && nouveau_is_v1_dsm() && !nouveau_is_optimus())
> vga_switcheroo_fini_domain_pm_ops(drm->dev->dev);
> -   vga_client_register(dev->pdev, NULL, NULL, NULL);

The amd & radeon patches look like this:

-   vga_switcheroo_unregister_client(rdev->pdev);
+   if (!pci_is_thunderbolt_attached(adev->pdev))
+   vga_switcheroo_unregister_client(adev->pdev);

This nouveau patch looks suspiciously different.  But again, I'm not a
GPU guy so all I can really say is "hmm, I wonder why it's different?"

>  }
>
>
> --
> 2.11.0
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 3/5] drm/nouveau: Don't register Thunderbolt eGPU with vga_switcheroo

2017-02-24 Thread Lukas Wunner 
An external Thunderbolt GPU can neither drive the laptop's panel nor be
powered off by the platform, so there's no point in registering it with
vga_switcheroo.  In fact, when the external GPU is runtime suspended,
vga_switcheroo will cut power to the internal discrete GPU, resulting in
a lockup.

Cc: Ben Skeggs 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/nouveau/nouveau_vga.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index eef22c6b9665..c2a7fd606c2e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -95,6 +95,10 @@ nouveau_vga_init(struct nouveau_drm *drm)
 
vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode);
 
+   /* don't register Thunderbolt eGPU with vga_switcheroo */
+   if (pci_is_thunderbolt_attached(dev->pdev))
+   return;
+
if (nouveau_runtime_pm == 1)
runtime = true;
if ((nouveau_runtime_pm == -1) && (nouveau_is_optimus() || 
nouveau_is_v1_dsm()))
@@ -111,6 +115,11 @@ nouveau_vga_fini(struct nouveau_drm *drm)
struct drm_device *dev = drm->dev;
bool runtime = false;
 
+   vga_client_register(dev->pdev, NULL, NULL, NULL);
+
+   if (pci_is_thunderbolt_attached(dev->pdev))
+   return;
+
if (nouveau_runtime_pm == 1)
runtime = true;
if ((nouveau_runtime_pm == -1) && (nouveau_is_optimus() || 
nouveau_is_v1_dsm()))
@@ -119,7 +128,6 @@ nouveau_vga_fini(struct nouveau_drm *drm)
vga_switcheroo_unregister_client(dev->pdev);
if (runtime && nouveau_is_v1_dsm() && !nouveau_is_optimus())
vga_switcheroo_fini_domain_pm_ops(drm->dev->dev);
-   vga_client_register(dev->pdev, NULL, NULL, NULL);
 }
 
 
-- 
2.11.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/5] PCI: Recognize Thunderbolt devices

2017-02-24 Thread Lukas Wunner 
Detect on probe whether a PCI device is part of a Thunderbolt controller.

Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234
on such devices.  Detect presence of this VSEC and cache it in a newly
added is_thunderbolt bit in struct pci_dev.  Add a helper to check
whether a given PCI device is situated on a Thunderbolt daisy chain.

The necessity arises from the following:

* To power off Thunderbolt controllers on Macs even if their BIOS is
  older than 2015, their PCIe ports need to be whitelisted for runtime
  PM.  For this we need a way to recognize them.

* Dual GPU MacBook Pros introduced 2011+ can no longer switch external
  DisplayPort ports between GPUs.  (They're no longer just used for DP
  but have become combined DP/Thunderbolt ports.)  The driver to switch
  the ports, drivers/platform/x86/apple-gmux.c, needs to detect presence
  of a Thunderbolt controller and, if found, keep external ports
  permanently switched to the discrete GPU.

* If an external Thunderbolt GPU is connected to a dual GPU laptop (Mac
  or not), that GPU is currently registered with vga_switcheroo even
  though it can neither drive the laptop's panel nor be powered off by
  the platform.  To vga_switcheroo it will appear as if two discrete
  GPUs are present.  As a result, when the external GPU is runtime
  suspended, vga_switcheroo will cut power to the internal discrete GPU
  which may not be runtime suspended at all at this moment.  The
  solution is to not register external GPUs with vga_switcheroo, which
  necessitates a way to recognize if they're on a Thunderbolt daisy
  chain.

Cc: Andreas Noever 
Cc: Michael Jamet 
Cc: Tomas Winkler 
Cc: Amir Levy 
Signed-off-by: Lukas Wunner 
---
 drivers/pci/pci.h   |  2 ++
 drivers/pci/probe.c | 21 +
 include/linux/pci.h | 23 +++
 3 files changed, 46 insertions(+)

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index cb17db242f30..45c2b8144911 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -3,6 +3,8 @@
 
 #define PCI_FIND_CAP_TTL   48
 
+#define PCI_VSEC_ID_INTEL_TBT  0x1234  /* Thunderbolt */
+
 extern const unsigned char pcie_link_speed[];
 
 bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 204960e70333..7963ecc6d85f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1208,6 +1208,24 @@ void set_pcie_hotplug_bridge(struct pci_dev *pdev)
pdev->is_hotplug_bridge = 1;
 }
 
+static void set_pcie_thunderbolt(struct pci_dev *dev)
+{
+   int vsec = 0;
+   u32 header;
+
+   while ((vsec = pci_find_next_ext_capability(dev, vsec,
+   PCI_EXT_CAP_ID_VNDR))) {
+   pci_read_config_dword(dev, vsec + PCI_VNDR_HEADER, );
+
+   /* Is the device part of a Thunderbolt controller? */
+   if (dev->vendor == PCI_VENDOR_ID_INTEL &&
+   PCI_VNDR_HEADER_ID(header) == PCI_VSEC_ID_INTEL_TBT) {
+   dev->is_thunderbolt = 1;
+   return;
+   }
+   }
+}
+
 /**
  * pci_ext_cfg_is_aliased - is ext config space just an alias of std config?
  * @dev: PCI device
@@ -1360,6 +1378,9 @@ int pci_setup_device(struct pci_dev *dev)
/* need to have dev->class ready */
dev->cfg_size = pci_cfg_space_size(dev);
 
+   /* need to have dev->cfg_size ready */
+   set_pcie_thunderbolt(dev);
+
/* "Unknown power state" */
dev->current_state = PCI_UNKNOWN;
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e2d1a124216a..36dfcfd946f4 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -358,6 +358,7 @@ struct pci_dev {
unsigned intis_virtfn:1;
unsigned intreset_fn:1;
unsigned intis_hotplug_bridge:1;
+   unsigned intis_thunderbolt:1; /* Thunderbolt controller */
unsigned int__aer_firmware_first_valid:1;
unsigned int__aer_firmware_first:1;
unsigned intbroken_intx_masking:1;
@@ -2171,6 +2172,28 @@ static inline bool pci_ari_enabled(struct pci_bus *bus)
return bus->self && bus->self->ari_enabled;
 }
 
+/**
+ * pci_is_thunderbolt_attached - whether device is on a Thunderbolt daisy chain
+ * @pdev: PCI device to check
+ *
+ * Walk upwards from @pdev and check for each encountered bridge if it's
+ * part of a Thunderbolt controller.  Reaching the host bridge means @pdev
+ * is soldered to the mainboard.
+ */
+static inline bool pci_is_thunderbolt_attached(struct pci_dev *pdev)
+{
+   struct pci_dev *parent = pdev;
+
+   if (pdev->is_thunderbolt)
+   return true;
+
+   while ((parent = pci_upstream_bridge(parent)))
+   if (parent->is_thunderbolt)
+   return true;
+
+   return false;

[Nouveau] [PATCH 0/5] Thunderbolt GPU fixes

2017-02-24 Thread Lukas Wunner 
Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo:

Patch [1/5] ("Recognize Thunderbolt devices") has already been subjected
to a fair amount of scrutiny over at linux-pci@, I've submitted it 5 times
total since May 2016.  With luck it may be in ack-able shape now.

Patch [2/5] amends apple-gmux to handle combined DP/Thunderbolt ports
properly on newer MacBook Pros.

Patches [3/5] to [5/5] avoid registering external Thunderbolt GPUs with
vga_switcheroo:  Dave Airlie designed vga_switcheroo to register GPUs
unconditionally.  So if a desktop box has multiple GPUs, vga_switcheroo
will see more than one discrete GPU but that's not a problem because on
desktop boxes no handler is registered and thus vga_switcheroo_enable()
is never called.  Hybrid graphics laptops on the other hand do register
a handler, but are assumed to never register more than one discrete GPU.
However once a Thunderbolt eGPU is attached to a hybrid graphics laptop,
that assumption is no longer true and things go south when vga_switcheroo
runtime suspends the external discrete GPU and then calls the handler to
cut power to the internal discrete GPU.  The driver for the internal GPU
will sit there puzzled and typically cause a lockup.

This series is just a first step towards proper handling of eGPUs, another
will be support for surprise removal:  DRM drivers need to cease MMIO and
PCI config space access once a device is gone to avoid delaying device
teardown or accessing a newly attached replacement device.  Also, MMIO
reads to removed devices return "all ones", which results in an infinite
loop e.g. in nouveau's nvkm_nsec().

The question is how to recognize device removal.  One common method is to
read the vendor register with pci_device_is_present(), but this reports
a false positive if the device is present but in D3cold.  A better method
is to let the PCIe hotplug driver recognize and cache device removal.
Keith Busch has developed patches which do exactly that, they're now at
v6 and fully reviewed by Christoph Hellwig but alas were not included in
the 4.11 PCI pull for some reason:
http://www.spinics.net/lists/linux-pci/msg58123.html

I've pushed the present series to GitHub in case anyone prefers reviewing
it in a GUI:
https://github.com/l1k/linux/commits/thunderbolt_gpu_v1

Thanks,

Lukas


Lukas Wunner (5):
  PCI: Recognize Thunderbolt devices
  apple-gmux: Don't switch external DP port on 2011+ MacBook Pros
  drm/nouveau: Don't register Thunderbolt eGPU with vga_switcheroo
  drm/radeon: Don't register Thunderbolt eGPU with vga_switcheroo
  drm/amdgpu: Don't register Thunderbolt eGPU with vga_switcheroo

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  7 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|  3 ++-
 drivers/gpu/drm/nouveau/nouveau_vga.c  | 10 +-
 drivers/gpu/drm/radeon/radeon_device.c |  7 +--
 drivers/gpu/drm/radeon/radeon_kms.c|  3 ++-
 drivers/pci/pci.h  |  2 ++
 drivers/pci/probe.c| 21 
 drivers/platform/x86/apple-gmux.c  | 31 +-
 include/linux/pci.h| 23 ++
 9 files changed, 99 insertions(+), 8 deletions(-)

-- 
2.11.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 99922] [NVE4] [regression, bisected] 4.10 (atomic): X shows black screen with cursor after monitors turn off

2017-02-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=99922

kevin@potatofrom.space changed:

   What|Removed |Added

 Attachment #129896|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 99922] [NVE4] [regression, bisected] 4.10 (atomic): X shows black screen with cursor after monitors turn off

2017-02-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=99922

--- Comment #5 from kevin@potatofrom.space ---
Created attachment 129896
  --> https://bugs.freedesktop.org/attachment.cgi?id=129896=edit
Normal Xorg logs on Linux 4.10 with xf86-video-modesetting

Interestingly, the bug does not appear with the generic modesetting driver!
I've attached the Xorg log, but it seems normal.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: gk20a: Turn instmem lock into mutex

2017-02-24 Thread Ben Skeggs 
On 02/24/2017 05:25 PM, Alexandre Courbot wrote:
> On 02/24/2017 01:20 AM, Thierry Reding wrote:
>> * PGP Signed by an unknown key
>>
>> On Mon, Jan 30, 2017 at 09:03:07PM +0100, Thierry Reding wrote:
>>> From: Thierry Reding 
>>>
>>> The gk20a implementation of instance memory uses vmap()/vunmap() to map
>>> memory regions into the kernel's virtual address space. These functions
>>> may sleep, so protecting them by a spin lock is not safe. This triggers
>>> a warning if the DEBUG_ATOMIC_SLEEP Kconfig option is enabled. Fix this
>>> by using a mutex instead.
>>>
>>> Signed-off-by: Thierry Reding 
>>> ---
>>>  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 19
>>> ---
>>>  1 file changed, 8 insertions(+), 11 deletions(-)
>>
>> Alex, could you take a look at this?
> 
> Sorry! Yes, using a mutex here should be safe since vmap() can sleep
> anyway. And I don't think this code can ever be reached in atomic
> context (Ben can confirm that last point). Tested this patch and it
> seems to work like a charm.
That should be true on this chipset.  Though, if we ever need to touch
the grctx or something in response to an interrupt (iirc nvgpu does
this, maybe?), this could change.  Granted, we probably should switch to
threaded interrupts at some point anyway.

As it currently stands, it should be fine.

Ben.

> 
> Reviewed-by: Alexandre Courbot 
> Tested-by: Alexandre Courbot 
> 
>>
>> Thanks,
>> Thierry
>>
>>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
>>> b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
>>> index a6a7fa0d7679..7f5244d57d2f 100644
>>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
>>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
>>> @@ -94,7 +94,7 @@ struct gk20a_instmem {
>>>  struct nvkm_instmem base;
>>>
>>>  /* protects vaddr_* and gk20a_instobj::vaddr* */
>>> -spinlock_t lock;
>>> +struct mutex lock;
>>>
>>>  /* CPU mappings LRU */
>>>  unsigned int vaddr_use;
>>> @@ -184,11 +184,10 @@ gk20a_instobj_acquire_iommu(struct nvkm_memory
>>> *memory)
>>>  struct gk20a_instmem *imem = node->base.imem;
>>>  struct nvkm_ltc *ltc = imem->base.subdev.device->ltc;
>>>  const u64 size = nvkm_memory_size(memory);
>>> -unsigned long flags;
>>>
>>>  nvkm_ltc_flush(ltc);
>>>
>>> -spin_lock_irqsave(>lock, flags);
>>> +mutex_lock(>lock);
>>>
>>>  if (node->base.vaddr) {
>>>  if (!node->use_cpt) {
>>> @@ -216,7 +215,7 @@ gk20a_instobj_acquire_iommu(struct nvkm_memory
>>> *memory)
>>>
>>>  out:
>>>  node->use_cpt++;
>>> -spin_unlock_irqrestore(>lock, flags);
>>> +mutex_unlock(>lock);
>>>
>>>  return node->base.vaddr;
>>>  }
>>> @@ -239,9 +238,8 @@ gk20a_instobj_release_iommu(struct nvkm_memory
>>> *memory)
>>>  struct gk20a_instobj_iommu *node = gk20a_instobj_iommu(memory);
>>>  struct gk20a_instmem *imem = node->base.imem;
>>>  struct nvkm_ltc *ltc = imem->base.subdev.device->ltc;
>>> -unsigned long flags;
>>>
>>> -spin_lock_irqsave(>lock, flags);
>>> +mutex_lock(>lock);
>>>
>>>  /* we should at least have one user to release... */
>>>  if (WARN_ON(node->use_cpt == 0))
>>> @@ -252,7 +250,7 @@ gk20a_instobj_release_iommu(struct nvkm_memory
>>> *memory)
>>>  list_add_tail(>vaddr_node, >vaddr_lru);
>>>
>>>  out:
>>> -spin_unlock_irqrestore(>lock, flags);
>>> +mutex_unlock(>lock);
>>>
>>>  wmb();
>>>  nvkm_ltc_invalidate(ltc);
>>> @@ -306,19 +304,18 @@ gk20a_instobj_dtor_iommu(struct nvkm_memory
>>> *memory)
>>>  struct gk20a_instmem *imem = node->base.imem;
>>>  struct device *dev = imem->base.subdev.device->dev;
>>>  struct nvkm_mm_node *r;
>>> -unsigned long flags;
>>>  int i;
>>>
>>>  if (unlikely(list_empty(>base.mem.regions)))
>>>  goto out;
>>>
>>> -spin_lock_irqsave(>lock, flags);
>>> +mutex_lock(>lock);
>>>
>>>  /* vaddr has already been recycled */
>>>  if (node->base.vaddr)
>>>  gk20a_instobj_iommu_recycle_vaddr(node);
>>>
>>> -spin_unlock_irqrestore(>lock, flags);
>>> +mutex_unlock(>lock);
>>>
>>>  r = list_first_entry(>base.mem.regions, struct nvkm_mm_node,
>>>   rl_entry);
>>> @@ -580,7 +577,7 @@ gk20a_instmem_new(struct nvkm_device *device, int
>>> index,
>>>  if (!(imem = kzalloc(sizeof(*imem), GFP_KERNEL)))
>>>  return -ENOMEM;
>>>  nvkm_instmem_ctor(_instmem, device, index, >base);
>>> -spin_lock_init(>lock);
>>> +mutex_init(>lock);
>>>  *pimem = >base;
>>>
>>>  /* do not allow more than 1MB of CPU-mapped instmem */
>>> -- 
>>> 2.11.0
>>>
>>
>> * Unknown Key
>> * 0x7F3EB3A1
>>
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau



signature.asc
Description: OpenPGP digital signature