Ben Skeggs [Tue, 14 Jan 2020 20:34:22 +0000 (06:34 +1000)]
drm/nouveau/flcn/msgq: move handling of init message to subdevs
When the PMU/SEC2 LS FWs have booted, they'll send a message to the host
with various information, including the configuration of message/command
queues that are available.
Move the handling for this to the relevant subdevs.
Ben Skeggs [Tue, 14 Jan 2020 20:34:22 +0000 (06:34 +1000)]
drm/nouveau/flcn/qmgr: allow arbtrary priv + return code for callbacks
Code to interface with LS firmwares is being moved to the subdevs where it
belongs, rather than living in the common falcon code.
Arbitrary private data passed to callbacks is to allow for something other
than struct nvkm_msgqueue to be passed into the callback (like the pointer
to the subdev itself, for example), and the return code will be used where
we'd like to detect failure from synchronous messages.
Ben Skeggs [Tue, 14 Jan 2020 20:34:21 +0000 (06:34 +1000)]
drm/nouveau/flcn: move fetching of configuration until first use
We want to be able to register falcons with ACR during the constructor for
the subdev it belongs to, however, we may not have access to the falcon's
registers prior to DEVINIT.
Delay touching registers until the first time the falcon is acquired.
This may temporarily break secboot on non-production boards due to not
being able to determine whether the falcon is in debug or production mode,
the new ACR subdev will not have this issue, and it's not a use-case that's
terribly important for bisectability.
YueHaibing [Fri, 10 Jan 2020 07:28:37 +0000 (15:28 +0800)]
drm/nouveau/drm/ttm: Remove set but not used variable 'mem'
drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new:
drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_gart_manager_new:
drivers/gpu/drm/nouveau/nouveau_ttm.c:106:22: warning: variable mem set but not used [-Wunused-but-set-variable]
They are not used any more, so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
YueHaibing [Fri, 10 Jan 2020 06:32:01 +0000 (14:32 +0800)]
drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler
Like other cases, it should use rcu protected 'chan' rather
than 'fence->channel' in nouveau_fence_wait_uevent_handler.
Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Thu, 9 Jan 2020 01:46:15 +0000 (11:46 +1000)]
drm/nouveau/gr/gk20a,gm200-: add terminators to method lists read from fw
Method init is typically ordered by class in the FW image as ThreeD,
TwoD, Compute.
Due to a bug in parsing the FW into our internal format, we've been
accidentally sending Twod + Compute methods to the ThreeD class, as
well as Compute methods to the TwoD class - oops.
Dan Carpenter [Wed, 8 Jan 2020 05:46:01 +0000 (08:46 +0300)]
drm/nouveau/secboot/gm20b: initialize pointer in gm20b_secboot_new()
We accidentally set "psb" which is a no-op instead of "*psb" so it
generates a static checker warning. We should probably set it before
the first error return so that it's always initialized.
Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add secure boot support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
James Jones [Tue, 17 Dec 2019 00:58:05 +0000 (16:58 -0800)]
drm/nouveau/mmu: Add correct turing page kinds
Turing introduced a new simplified page kind
scheme, reducing the number of possible page
kinds from 256 to 16. It also is the first
NVIDIA GPU in which the highest possible page
kind value is not reserved as an "invalid" page
kind.
To address this, the invalid page kind is made
an explicit property of the MMU HAL, and a new
table of page kinds is added to the tu102 MMU
HAL.
One hardware change not addressed here is that
0x00 is technically no longer a supported page
kind, and pitch surfaces are instead intended to
share the block-linear generic page kind 0x06.
However, because that will be a rather invasive
change to nouveau and 0x00 still works fine in
practice on Turing hardware, addressing this new
behavior is deferred.
Signed-off-by: James Jones <jajones@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
James Jones [Tue, 17 Dec 2019 00:56:12 +0000 (16:56 -0800)]
drm/nouveau: Fix ttm move init with multiple GPUs
The pointer used to walk the table of move ops
and pick the right one for the current GPU was
declared static, meaning its state was carried
over between invocations of the function, and also
made the function non-rentrant and thread-unsafe.
Since the table is ordered such that newer GPU
methods are listed first, the result of this was
that initializing newer GPUs after older GPUs
would result in no suitable ttm move acceleration
operations being found, and ttm would fall back
to CPU blits on the older GPUs.
This change declares the walking pointer
separately from the table and makes it non-static
to fix the logic.
Signed-off-by: James Jones <jajones@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Wambui Karuga [Tue, 31 Dec 2019 20:57:34 +0000 (23:57 +0300)]
drm/nouveau: use NULL for pointer assignment.
Replace the use of 0 in the pointer assignment with NULL to address the
following sparse warning:
drivers/gpu/drm/nouveau/nouveau_hwmon.c:744:29: warning: Using plain integer as NULL pointer
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Thierry Reding [Mon, 9 Dec 2019 12:00:05 +0000 (13:00 +0100)]
drm/nouveau/ce/gp10b: Use correct copy engine
gp10b uses the new engine enumeration mechanism introduced in the Pascal
architecture. As a result, the copy engine, which used to be at index 2
for prior Tegra GPU instantiations, has now moved to index 0. Fix up the
index and also use the gp100 variant of the copy engine class because on
gp10b the PASCAL_DMA_COPY_B class is not supported.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There are extra registers that need to be programmed to make the level 2
cache work on GP10B, such as the stream ID register that is used when an
SMMU is used to translate memory addresses.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Thierry Reding [Mon, 9 Dec 2019 12:00:03 +0000 (13:00 +0100)]
drm/nouveau/secboot/gm20b,gp10b: Read WPR configuration from GPU registers
The GPUs found on Tegra SoCs have registers that can be used to read the
WPR configuration. Use these registers instead of reaching into the
memory controller's register space to read the same information.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Thierry Reding [Mon, 9 Dec 2019 12:00:01 +0000 (13:00 +0100)]
drm/nouveau/tegra: Avoid pulsing reset twice
When the GPU powergate is controlled by a generic power domain provider,
the reset will automatically be asserted and deasserted as part of the
power-ungating procedure.
On some Jetson TX2 boards, doing an additional assert and deassert of
the GPU outside of the power-ungate procedure can cause the GPU to go
into a bad state where the memory interface can no longer access system
memory.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Thierry Reding [Mon, 9 Dec 2019 12:00:00 +0000 (13:00 +0100)]
drm/nouveau: Do not try to disable PCI device on Tegra
When Nouveau is instantiated on top of a platform device, the dev->pdev
field will be NULL and calling pci_disable_device() will crash. Move the
PCI disabling code to the PCI specific driver removal code.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Thierry Reding [Mon, 9 Dec 2019 11:59:59 +0000 (12:59 +0100)]
drm/nouveau/fault: Add support for GP10B
There is no BAR2 on GP10B and there is no need to map through BAR2
because all memory is shared between the GPU and the CPU. Add a custom
implementation of the fault sub-device that uses nvkm_memory_addr()
instead of nvkm_memory_bar2() to return the address of a pinned fault
buffer.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Colin Ian King [Fri, 29 Nov 2019 16:28:28 +0000 (16:28 +0000)]
drm/nouveau/nouveau: fix incorrect sizeof on args.src an args.dst
The sizeof is currently on args.src and args.dst and should be on
*args.src and *args.dst. Fortunately these sizes just so happen
to be the same size so it worked, however, this should be fixed
and it also cleans up static analysis warnings
Addresses-Coverity: ("sizeof not portable") Fixes: f268307ec7c7 ("nouveau: simplify nouveau_dmem_migrate_vma") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Lyude Paul [Fri, 13 Sep 2019 22:03:53 +0000 (18:03 -0400)]
drm/nouveau/kms/nv50-: Report possible_crtcs incorrectly on mstos, for now
This commit is seperate from the previous one to make it easier to
revert in the future. Basically, while working on making MSTOs per-head
as opposed to per-head-per-connector I discovered these lovely issues:
Note as well that Intel already has a temporary workaround for this in
their kernel driver. So, unfortunately we need to follow suit to avoid
causing a regression in userspace. Once these issues get fixed, this
commit should be reverted.
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Lyude Paul [Fri, 13 Sep 2019 22:03:52 +0000 (18:03 -0400)]
drm/nouveau/kms/nv50-: Use less encoders by making mstos per-head
Currently, for every single MST capable DRM connector we create a set of
fake encoders, one for each possible head. Unfortunately this ends up
being a huge waste of encoders. While this currently isn't causing us
any problems, it's extremely close to doing so.
The ThinkPad P71 is a good example of this. Originally when trying to
figure out why nouveau was failing to load on this laptop, I discovered
it was because nouveau was creating too many encoders. This ended up
being because we were mistakenly creating MST encoders for the eDP port,
however we are still extremely close to hitting the encoder limit on
this machine as it exposes 1 eDP port and 5 DP ports, resulting in 31
encoders.
So while this fix didn't end up being necessary to fix the P71, we still
need to implement this so that we avoid hitting the encoder limit for
valid display configurations in the event that some machine with more
connectors then this becomes available. Plus, we don't want to let good
code go to waste :)
So, use less encoders by only creating one MSTO per head. Then, attach
each new MSTC to each MSTO which corresponds to a head that it's parent
DP port is capable of using. This brings the number of encoders we
register on the ThinkPad P71 from 31, down to just 15. Yay!
Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When drm_connector_helper_funcs->atomic_best_encoder is defined,
->best_encoder is ignored by the atomic modesetting helpers. That being
said, this hook is completely broken anyway - it always returns the
first msto for a given mstc, despite the fact it might already be in
use.
So, just get rid of it. We'll need this in a moment anyway, when we make
mstos per-head as opposed to per-connector.
Changes since v1:
* Fix typo in documentation - imirkin
Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Dave Airlie [Mon, 13 Jan 2020 01:53:01 +0000 (11:53 +1000)]
Merge tag 'drm-misc-next-2020-01-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v5.6:
UAPI Changes:
Cross-subsystem Changes:
- Convert simple panel bindings to a template.
Core Changes:
- Revert drm-bridge-state changes, it causes a dependency error
between drm and drm_kms_helper.
- Fix when disabling crc's.
- Assorted Kconfig fixes.
Driver Changes:
- Add ddc symlinks to more drivers.
- Fix chained bridge handling in exynos and vc4.
- More clock rate fixes in sun4i.
- Add support for AUO B116XAK01, GiantPlus GPM940B0, Sony ACX424AKP,
BOE NV140FHM-N49, Satoz SAT050AT40H12R2 and Sharp LS020B1DD01D panels.
- Assorted small bugfixes.
drm: add dp helper to initialize remote aux channel.
[why]
We need to minimally initialize the remote aux channel, e.g. the
crc work struct of remote aux to dump the sink's DPRX CRCs in MST
setup.
[how]
Add helper that only initializes the crc work struct of the remote
aux, hooke crc work queue to 'drm_dp_aux_crc_work'. Then call this
helper in DP MST port initialization.
This, plus David Francis' patch [1], fix the issue of MST remote
aux DPCD CRCs read.
Cc: Leo Li <sunpeng.li@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: David (Dingchen) Zhang <dingchen.zhang@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mikita Lipski [Tue, 12 Nov 2019 14:14:15 +0000 (09:14 -0500)]
drm/amd/display: Trigger modesets on MST DSC connectors
Whenever a connector on an MST network is attached, detached, or
undergoes a modeset, the DSC configs for each stream on that
topology will be recalculated. This can change their required
bandwidth, requiring a full reprogramming, as though a modeset
was performed, even if that stream did not change timing.
Therefore, whenever a crtc has drm_atomic_crtc_needs_modeset,
for each crtc that shares a MST topology with that stream and
supports DSC, add that crtc (and all affected connectors and
planes) to the atomic state and set mode_changed on its state
v2: Do this check only on Navi and before adding connectors
and planes on modesetting crtcs
v3: Call the drm_dp_mst_add_affected_dsc_crtcs() to update
all affected CRTCs
Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: David Francis <David.Francis@amd.com> Signed-off-by: Mikita Lipski <mikita.lipski@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>