Commit graph

932,869 commits

Author SHA1 Message Date
Kirill A. Shutemov
16877a5570 x86/mm: Fix guard hole handling
There is a guard hole at the beginning of the kernel address space, also
used by hypervisors. It occupies 16 PGD entries.

This reserved range is not defined explicitely, it is calculated relative
to other entities: direct mapping and user space ranges.

The calculation got broken by recent changes of the kernel memory layout:
LDT remap range is now mapped before direct mapping and makes the
calculation invalid.

The breakage leads to crash on Xen dom0 boot[1].

Define the reserved range explicitely. It's part of kernel ABI (hypervisors
expect it to be stable) and must not depend on changes in the rest of
kernel memory layout.

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html

Fixes: d52888aa27 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging")
Reported-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Cc: bp@alien8.de
Cc: hpa@zytor.com
Cc: dave.hansen@linux.intel.com
Cc: luto@kernel.org
Cc: peterz@infradead.org
Cc: boris.ostrovsky@oracle.com
Cc: bhe@redhat.com
Cc: linux-mm@kvack.org
Cc: xen-devel@lists.xenproject.org
Link: https://lkml.kernel.org/r/20181130202328.65359-2-kirill.shutemov@linux.intel.com
2018-12-11 11:19:24 +01:00
Rafael J. Wysocki
2c3b0463bb Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq
Pull devfreq framework changes for v4.21 from MyungJoo Ham:

"This includes the suspend-frequency support for devfreq, which is
 similar with suspend_freq in cpufreq."

* 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq:
  PM / devfreq: add devfreq_suspend/resume() functions
  PM / devfreq: add support for suspend/resume of a devfreq device
  PM / devfreq: refactor set_target frequency function
2018-12-11 10:58:17 +01:00
Nikolay Borisov
ac9498d686 fanotify: Use inode_is_open_for_write
Use the aptly named function rather than opencoding i_writecount check.
No functional changes.

Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Jan Kara <jack@suse.cz>
2018-12-11 10:55:45 +01:00
Jani Nikula
cb6f4c2c34 Merge tag 'gvt-next-2018-12-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes
gvt-next-2018-12-07

- Fix -next regression on shadow ctx's ppgtt destroy (Xiong)
- Update force-to-nonpriv register list (Yan)
- three typo fixes

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207043659.GI12743@zhen-hp.sh.intel.com
2018-12-11 11:48:44 +02:00
Lu Baolu
6d68b88e09 iommu/vt-d: Remove deferred invalidation
Deferred invalidation is an ECS specific feature. It will not be
supported when IOMMU works in scalable mode. As we deprecated the
ECS support, remove deferred invalidation and cleanup the code.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Liu Yi L <yi.l.liu@intel.com>
Cc: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:46:00 +01:00
Lu Baolu
1c4f88b7f1 iommu/vt-d: Shared virtual address in scalable mode
This patch enables the current SVA (Shared Virtual Address)
implementation to work in the scalable mode.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:46:00 +01:00
Lu Baolu
437f35e1cd iommu/vt-d: Add first level page table interface
This adds an interface to setup the PASID entries for first
level page table translation.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:45:59 +01:00
Lu Baolu
7373a8cc38 iommu/vt-d: Setup context and enable RID2PASID support
This patch enables the translation for requests without PASID in
the scalable mode by setting up the root and context entries.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:45:59 +01:00
Lu Baolu
ca6e322d60 iommu/vt-d: Pass pasid table to context mapping
So that the pasid related info, such as the pasid table and the
maximum of pasid could be used during setting up scalable mode
context.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Liu Yi L <yi.l.liu@intel.com>
Cc: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:45:59 +01:00
Lu Baolu
ef848b7e5a iommu/vt-d: Setup pasid entry for RID2PASID support
when the scalable mode is enabled, there is no second level
page translation pointer in the context entry any more (for
DMA request without PASID). Instead, a new RID2PASID field
is introduced in the context entry. Software can choose any
PASID value to set RID2PASID and then setup the translation
in the corresponding PASID entry. Upon receiving a DMA request
without PASID, hardware will firstly look at this RID2PASID
field and then treat this request as a request with a pasid
value specified in RID2PASID field.

Though software is allowed to use any PASID for the RID2PASID,
we will always use the PASID 0 as a sort of design decision.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:45:58 +01:00
Lu Baolu
6f7db75e1c iommu/vt-d: Add second level page table interface
This adds the interfaces to setup or tear down the structures
for second level page table translations. This includes types
of second level only translation and pass through.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:45:58 +01:00
Lu Baolu
3b33d4ab32 iommu/vt-d: Reserve a domain id for FL and PT modes
Vt-d spec rev3.0 (section 6.2.3.1) requires that each pasid
entry for first-level or pass-through translation should be
programmed with a domain id different from those used for
second-level or nested translation. It is recommended that
software could use a same domain id for all first-only and
pass-through translations.

This reserves a domain id for first-level and pass-through
translations.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Liu Yi L <yi.l.liu@intel.com>
Cc: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:45:58 +01:00
Lu Baolu
5d308fc1ec iommu/vt-d: Add 256-bit invalidation descriptor support
Intel vt-d spec rev3.0 requires software to use 256-bit
descriptors in invalidation queue. As the spec reads in
section 6.5.2:

Remapping hardware supporting Scalable Mode Translations
(ECAP_REG.SMTS=1) allow software to additionally program
the width of the descriptors (128-bits or 256-bits) that
will be written into the Queue. Software should setup the
Invalidation Queue for 256-bit descriptors before progra-
mming remapping hardware for scalable-mode translation as
128-bit descriptors are treated as invalid descriptors
(see Table 21 in Section 6.5.2.10) in scalable-mode.

This patch adds 256-bit invalidation descriptor support
if the hardware presents scalable mode capability.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:45:58 +01:00
Lu Baolu
4f2ed183cf iommu/vt-d: Move page table helpers into header
So that they could also be used in other source files.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Liu Yi L <yi.l.liu@intel.com>
Cc: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:45:57 +01:00
Lu Baolu
0bbeb01a4f iommu/vt-d: Manage scalalble mode PASID tables
In scalable mode, pasid structure is a two level table with
a pasid directory table and a pasid table. Any pasid entry
can be identified by a pasid value in below way.

   1
   9                       6 5      0
    .-----------------------.-------.
    |              PASID    |       |
    '-----------------------'-------'    .-------------.
             |                    |      |             |
             |                    |      |             |
             |                    |      |             |
             |     .-----------.  |      .-------------.
             |     |           |  |----->| PASID Entry |
             |     |           |  |      '-------------'
             |     |           |  |Plus  |             |
             |     .-----------.  |      |             |
             |---->| DIR Entry |-------->|             |
             |     '-----------'         '-------------'
.---------.  |Plus |           |
| Context |  |     |           |
|  Entry  |------->|           |
'---------'        '-----------'

This changes the pasid table APIs to support scalable mode
PASID directory and PASID table. It also adds a helper to
get the PASID table entry according to the pasid value.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:45:57 +01:00
Lu Baolu
765b6a98c1 iommu/vt-d: Enumerate the scalable mode capability
The Intel vt-d spec rev3.0 introduces a new translation
mode called scalable mode, which enables PASID-granular
translations for first level, second level, nested and
pass-through modes. At the same time, the previous
Extended Context (ECS) mode is deprecated (no production
ever implements ECS).

This patch adds enumeration for Scalable Mode and removes
the deprecated ECS enumeration. It provides a boot time
option to disable scalable mode even hardware claims to
support it.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:45:57 +01:00
Ganapatrao Kulkarni
c4b17afb0a iommu/dma: Use NUMA aware memory allocations in __iommu_dma_alloc_pages()
Change function __iommu_dma_alloc_pages() to allocate pages for DMA from
respective device NUMA node. The ternary operator which would be for
alloc_pages_node() is tidied along with this.

The motivation for this change is to have a policy for page allocation
consistent with direct DMA mapping, which attempts to allocate pages local
to the device, as mentioned in [1].

In addition, for certain workloads it has been observed a marginal
performance improvement. The patch caused an observation of 0.9% average
throughput improvement for running tcrypt with HiSilicon crypto engine.

We also include a modification to use kvzalloc() for kzalloc()/vzalloc()
combination.

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1692998.html

Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
[JPG: Added kvzalloc(), drop pages ** being device local, remove ternary operator, update message]
Signed-off-by: John Garry <john.garry@huawei.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2018-12-11 10:29:39 +01:00
YueHaibing
8e41cae64b ieee802154: ca8210: fix possible u8 overflow in ca8210_rx_done
gcc warning this:

drivers/net/ieee802154/ca8210.c:730:10: warning:
 comparison is always false due to limited range of data type [-Wtype-limits]

'len' is u8 type, we get it from buf[1] adding 2, which can overflow.
This patch change the type of 'len' to unsigned int to avoid this,also fix
the gcc warning.

Fixes: ded845a781 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
2018-12-11 09:33:11 +01:00
Arnd Bergmann
1e73359a24 ALSA: hda/ca0132 - make pci_iounmap() call conditional
When building without CONFIG_PCI, we can (depending on the architecture)
get a link failure:

ERROR: "pci_iounmap" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!

Adding a compile-time check for PCI gets it to work correctly on
32-bit ARM.

Fixes: d99501b857 ("ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11 09:15:39 +01:00
Takashi Iwai
46594d3345 ALSA: hda/hdmi: Always set display_power_control for Intel HSW+ codecs
We've excluded the display_power_control flag for Intel HSW and BDW
codecs as the HD-audio controllers of the corresponding platforms take
care of the display power as well.  But the recent refactoring
separates the controller and the codec power accounting, so it's fine
to call the display PM even for HSW/BDW codecs.  This is less
confusing since we can avoid this well-hidden condition.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11 08:18:46 +01:00
Takashi Iwai
77a49672aa ASoC: hdac_hdmi: Add missing display power-off at driver removal
The display power is in unbalance at removing the driver since it
misses the snd_hdac_display_power(OFF) call.

Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11 08:18:37 +01:00
Takashi Iwai
4f799e7340 ALSA: hda: Make snd_hdac_display_power() void function
After the recent refactoring, snd_hdac_display_power() doesn't return
any error, hence it can be defined to return void.
This makes many error checks redundant and allows us to reduce them
gracefully.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11 08:18:25 +01:00
Takashi Iwai
457f3c86d3 ALSA: hda/intel: Properly free the display power at error path
When an error occurs in azx_probe_continue(), we should release the
display power.  However, the current code ignores it and releases the
display power only for HSW/BDW cases.  Fix it.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11 08:15:45 +01:00
Takashi Iwai
e454ff8e89 ALSA: hda/intel: Drop superfluous AZX_DCAPS_I915_POWERWELL checks
snd_hdac_display_power() can be called even for a HDA controller
without DRM binding.  The same is true for other helpers,
snd_hdac_i915_set_bclk() and snd_hdac_set_codec_wakeup().
So all superfluous AZX_DCAPS_I915_POWERWELL  checks in hda_intel.c can
be dropped, and the definition of AZX_DCAPS_I915_POWERWELL itself can
be removed as well.  This simplifies the code a lot.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11 08:12:52 +01:00
Takashi Iwai
029d92c289 ALSA: hda: Refactor display power management
The current HD-audio code manages the DRM audio power via too complex
redirections, and this seems even still unbalanced in a corner case as
Intel DRM CI has been intermittently reporting.  This patch is a big
surgery for addressing the complexity and the possible unbalance.

Basically the patch changes the display PM in the following ways:

- Both HD-audio controller and codec drivers call a single helper,
  snd_hdac_display_power().  (Formerly, the display power control from
  a codec was done indirectly via link_power bus ops.)

- snd_hdac_display_power() receives the codec address index.  For
  turning on/off from the controller, pass HDA_CODEC_IDX_CONTROLLER.

- snd_hdac_display_power() doesn't manage refcounts any longer, but
  keeps the power status in bitmap.  If any of controller or codecs is
  turned on, the function updates the DRM power state via get_power()
  or put_power().

Also this refactor allows us more cleanup:

- The link_power bus ops is dropped, so there is no longer indirect
  management, as mentioned in the above.

- hdac_device link_power_control flag is moved to hda_codec
  display_power_control flag, as it's only for HDA legacy.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106525
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-12-11 08:06:55 +01:00
Ben Skeggs
8ff01abccc drm/nouveau/ce/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:01 +10:00
Ben Skeggs
1b2a5aff35 drm/nouveau/fifo/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:01 +10:00
Ben Skeggs
7f7bc32e23 drm/nouveau/disp/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:01 +10:00
Ben Skeggs
1a38496cdd drm/nouveau/dma/tu106: initial support
Appears to be compatible with GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:00 +10:00
Ben Skeggs
bb1e3ff701 drm/nouveau/therm/tu106: initial support
Appears to be compatible with GP100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:00 +10:00
Ben Skeggs
25a46a4a95 drm/nouveau/pmu/tu106: initial support
Appears to be compatible with GP102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:00 +10:00
Ben Skeggs
f5459f34f5 drm/nouveau/fault/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:38:00 +10:00
Ben Skeggs
340e96a7c3 drm/nouveau/bar/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:59 +10:00
Ben Skeggs
70ec09080d drm/nouveau/mmu/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:59 +10:00
Ben Skeggs
13f91e8e5a drm/nouveau/ltc/tu106: initial support
Appears to be compatible with GP102.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:59 +10:00
Ben Skeggs
cfcfb6d0a3 drm/nouveau/fb/tu106: initial support
Appears to be compatible with GV100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:59 +10:00
Ben Skeggs
75794c4124 drm/nouveau/imem/tu106: initial support
Appears to be compatible with NV50.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:59 +10:00
Ben Skeggs
2fedee302d drm/nouveau/tmr/tu106: initial support
Appears to be compatible with GK20A.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:58 +10:00
Ben Skeggs
25e6a89076 drm/nouveau/bus/tu106: initial support
Appears to be compatible with GF100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:58 +10:00
Ben Skeggs
476740843b drm/nouveau/mc/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:58 +10:00
Ben Skeggs
6a9207ecf5 drm/nouveau/fuse/tu106: initial support
Appears to be compatible with GM107.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:58 +10:00
Ben Skeggs
52c887539d drm/nouveau/i2c/tu106: initial support
Appears to be compatible with GM200.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:57 +10:00
Ben Skeggs
1b0a475482 drm/nouveau/gpio/tu106: initial support
Appears to be compatible with GK104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:57 +10:00
Ben Skeggs
8d12c4846d drm/nouveau/ibus/tu106: initial support
Appears to be compatible with GM200.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:57 +10:00
Ben Skeggs
73010b8e2b drm/nouveau/top/tu106: initial support
Appears to be compatible with GK104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:57 +10:00
Ben Skeggs
9d7693fe07 drm/nouveau/devinit/tu106: initial support
Appears to be compatible with TU104.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:56 +10:00
Ben Skeggs
b0216803e3 drm/nouveau/bios/tu106: initial support
No real surprised here so far.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:56 +10:00
Ben Skeggs
a39cb42a75 drm/nouveau/pci/tu106: initial support
Appears to be compatible with GP100.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:56 +10:00
Ben Skeggs
2cc0d7c0f7 drm/nouveau/core: recognise TU106
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:56 +10:00
Ben Skeggs
2d583ade74 drm/nouveau/core: increase maximum number of nvdec instances to 3
RTX2070 appears to have 3 copies of the engine.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11 15:37:55 +10:00