History log of /linux-master/drivers/gpu/drm/nouveau/nouveau_encoder.h
Revision Date Author Comments
# 63371650 19-Sep-2023 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: add dp train method

- passes DPCD information from DRM to NVKM
- removes NVKM's own sink caps handling
- link still trained from supervisor, more patches to come

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Danilo Krummrich <me@dakr.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-33-lyude@redhat.com


# 75703380 19-Sep-2023 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/nv50-: fixup sink D3 before tearing down link

- fixes bug preventing this on SST
- implement for MST

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Danilo Krummrich <me@dakr.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-32-lyude@redhat.com


# bfb03a07 19-Sep-2023 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: add dp rates method

- moves building of link rates table from NVKM to DRM
- preparing to move link training out of supervisor

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Danilo Krummrich <me@dakr.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-29-lyude@redhat.com


# bd7a61bc 19-Sep-2023 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: add dp aux xfer method

- preparation for GSP-RM

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Danilo Krummrich <me@dakr.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-28-lyude@redhat.com


# 8ed09421 19-Sep-2023 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: move hdmi disable out of release()

- release() is being moved post-modeset, preserve hdmi behaviour for now

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Danilo Krummrich <me@dakr.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-21-lyude@redhat.com


# 42db5692 19-Sep-2023 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/nv50-: remove nv_encoder.audio.connector

- use nv_encoder.conn instead, outp->conn never changes

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Danilo Krummrich <me@dakr.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-17-lyude@redhat.com


# e32de3da 19-Sep-2023 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/nv50-: pull some common init out of OR-specific code

- cleanup before additional changes

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Danilo Krummrich <me@dakr.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919220442.202488-16-lyude@redhat.com


# 949ab38a 28-Jun-2023 Karol Herbst <kherbst@redhat.com>

drm/nouveau/disp: drop unused argument in nv50_dp_mode_valid

Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230628212248.3798605-2-kherbst@redhat.com


# 773eb04d 01-Jun-2022 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: expose conn event class

This removes some now-unnecessary nesting of workqueues.

v2:
- use ?: (lyude)

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>


# 8bb30c88 01-Jun-2022 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: add method to trigger DP link retrain

This moves control of link retraining in response to HPD IRQ to the
KMS driver's HPD IRQ handler.

NVKM still handles checking link status for the moment, this can be
moved to the KMS driver when it takes explicit control of link rate
selection.

v2:
- skip source config on retrain (fixes some retrain failures)

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>


# ea6143a8 01-Jun-2022 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: move and extend the role of outp acquire/release methods

There are various pieces of information we pass to NVKM about the next
modeset, which are generally used while handling supervisor interrupts.

We had to start passing in some information about audio requirements a
while back to allocate an appropriate SOR in ACQUIRE, so we may as well
move all this type of information here for other protocols too.

Certain methods will be blocked on non-acquired outputs now, preventing
NULL pointer derefs from KMS driver bugs.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>


# 1b255f1c 01-Jun-2022 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: add output class

Will be used to more cleanly implement existing method interfaces that
take some confusing (IEDTkey, inherited from VBIOS, which RM no longer
uses on Ampere) match values to determine which display path to operate
on.

Methods will be protected from racing with supervisor, and from being
called where they shouldn't be (ie. without an OR assigned).

v2:
- use ?: (lyude)
v3:
- fix return code if noacquire() method fails

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>


# da68386d 21-Apr-2022 Thomas Zimmermann <tzimmermann@suse.de>

drm: Rename dp/ to display/

Rename dp/ to display/ to account for additional display-related
helpers, such as HDMI. Update all related include statements. No
functional changes.

Various drivers, such as i915 and amdgpu, use similar naming scheme
by putting code for video-output standards into a local display/
directory. The new directory's name is aligned with this convention.

v2:
* update commit message (Javier)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-3-tzimmermann@suse.de


# 5b529e8d 13-Jan-2022 Thomas Zimmermann <tzimmermann@suse.de>

drm/dp: Move public DisplayPort headers into dp/

Move all public DisplayPort headers into dp/ and update users. No
functional changes.

v3:
* rebased onto latest drm-tip

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20220114114535.29157-5-tzimmermann@suse.de


# 6eca310e 14-May-2021 Lyude Paul <lyude@redhat.com>

drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau

This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of), so this should work for any laptop panels which support the VESA
backlight control interface.

Note that we don't yet provide the panel backlight frequency to the DRM DP
backlight helpers. This should be fine for the time being, since it's not
required to get basic backlight controls working.

For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: greg.depoire@gmail.com
Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-10-lyude@redhat.com


# 9125e242 13-Nov-2020 Lyude Paul <lyude@redhat.com>

drm/nouveau/kms/nv50-: Fix locking for audio callbacks

Noticed that I wasn't paying close enough attention the last time I looked
at our audio callbacks, as I completely missed the fact that we were
figuring out which audio-enabled connector goes to each encoder by checking
it's state, but without grabbing any of the appropriate modesetting locks
to do so.

That being said however: trying to grab modesetting locks in our audio
callbacks would be very painful due to the potential for locking inversion
between HDA and DRM. So, let's instead just copy what i915 does again - add
our own audio lock to protect audio related state, and store each audio
enabled connector in each nouveau_encoder struct so that we don't need to
check any atomic states.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# cd5609f7 13-Nov-2020 Lyude Paul <lyude@redhat.com>

drm/nouveau/kms/nv50-: Reverse args for nv50_outp_get_(old|new)_connector()

Just to be more consistent with the order of args that DRM helpers like
drm_atomic_get_new_crtc_state() use.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# a4efad35 26-Aug-2020 Lyude Paul <lyude@redhat.com>

drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT

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 <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-18-lyude@redhat.com


# 409d3813 26-Aug-2020 Lyude Paul <lyude@redhat.com>

drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation

This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.

Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, since we wouldn't be able to do anything without
DPCD access anyway.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-15-lyude@redhat.com


# a0922278 26-Aug-2020 Lyude Paul <lyude@redhat.com>

drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling

First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.

Back when I originally wrote this, I did this piggy-backing with the
intention that I'd eventually be teaching our MST helpers how to recover
when an MST device has stopped responding, which in turn would require
the MST helpers having a way of disabling MST independently of the
driver. Note that this was before I reworked locking in the MST helpers,
so at the time we were sticking random things under &mgr->lock - which
grabbing this lock was meant to protect against.

This never came to fruition because doing such a reset safely turned out
to be a lot more painful and impossible then it sounds, and also just
risks us working around issues with our MST handlers that should be
properly fixed instead. Even if it did though, simply calling
drm_dp_mst_topology_mgr_set_mst() from the MST helpers (with the
exception of when we're tearing down our MST managers, that's always OK)
wouldn't have been a bad idea, since drivers like nouveau and i915 need
to do their own book keeping immediately after disabling MST.
So-implementing that would likely require adding a hook for
helper-triggered MST disables anyway.

So, fast forward to now - we want to start adding support for all of the
miscellaneous bits of the DP protocol (for both SST and MST) we're
missing before moving on to supporting more complicated features like
supporting different BPP values on MST, DSC, etc. Since many of these
features only exist on SST and make use of DP HPD IRQs, we want to be
able to atomically check whether we're servicing an MST IRQ or SST IRQ
in nouveau_connector_hotplug(). Currently we literally don't do this at
all, and just handle any kind of possible DP IRQ we could get including
ESIs - even if MST isn't actually enabled.

This would be very complicated and difficult to fix if we need to hold
&mgr->lock while handling SST IRQs to ensure that the MST topology
state doesn't change under us. What we really want here is to do our own
tracking of whether MST is enabled or not, similar to drivers like i915,
and define our own locking order to decomplicate things and avoid
hitting locking issues in the future.

So, let's do this by refactoring our MST probing/enabling code to use
our own MST bookkeeping, along with adding a lock for protecting DP
state that needs to be checked outside of our connector probing
functions. While we're at it, we also remove a bunch of unneeded steps
we perform when probing/enabling MST:

* Enabling bits in MSTM_CTRL before calling drm_dp_mst_topology_mgr_set_mst().
I don't think these ever actually did anything, since the nvif methods
for enabling MST don't actually do anything DPCD related and merely
indicate to nvkm that we've turned on MST.
* Checking the MSTM_CTRL bit is intact when checking the state of an
enabled MST topology in nv50_mstm_detect(). I just added this to be safe
originally, but now that we try reading the DPCD when probing DP
connectors it shouldn't be needed as that will abort our hotplug probing
if the device was removed well before we start checking for MST..
* All of the duplicate DPCD version checks.

This leaves us with much nicer looking code, a much more sensible
locking scheme, and an easy way of checking whether MST is enabled or
not for handling DP HPD IRQs.

v2:
* Get rid of accidental newlines
v4:
* Fix uninitialized usage of mstm in nv50_mstm_detect() - thanks kernel
bot!

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-9-lyude@redhat.com


# 09838c4e 26-Aug-2020 Lyude Paul <lyude@redhat.com>

drm/nouveau/kms: Search for encoders' connectors properly

While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.

Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and
nv50_outp_get_new_connector().

v2:
* Don't line-wrap for_each_(old|new)_connector_in_state in
nv50_outp_get_(old|new)_connector() - sravn
v3:
* Fix potential uninitialized usage of nv_connector (needs to be
initialized to NULL at the start). Thanks kernel test robot!
v4:
* Actually fix uninitialized nv_connector usage in
nv50_audio_component_get_eld(). The previous fix wouldn't have worked
since we would have started out with nv_connector == NULL, but
wouldn't clear it after a single drm_for_each_encoder() iteration.
Thanks again Kernel bot!

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-7-lyude@redhat.com


# 6ba11932 26-Aug-2020 Lyude Paul <lyude@redhat.com>

drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()

Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-3-lyude@redhat.com


# 0ad679d1 29-May-2020 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/gt215-: fix race with audio driver runpm

The audio driver can call into nouveau right while we're in the middle
of re-fetching the EDID, and decide it no longer needs to be awake.

Stop depending on EDID in the audio component get_eld() callback, and
instead cache whether audio support is present from the prior modeset.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# d6a9efec 11-May-2020 Lyude Paul <lyude@redhat.com>

drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST

Currently, the nv50_mstc_mode_valid() function is happy to take any and
all modes, even the ones we can't actually support sometimes like
interlaced modes.

Luckily, the only difference between the mode validation that needs to
be performed for MST vs. SST is that eventually we'll need to check the
minimum PBN against the MSTB's full PBN capabilities (remember-we don't
care about the current bw state here). Otherwise, all of the other code
can be shared.

So, we move all of the common mode validation in
nouveau_connector_mode_valid() into a separate helper,
nv50_dp_mode_valid(), and use that from both nv50_mstc_mode_valid() and
nouveau_connector_mode_valid(). Note that we allow for returning the
calculated clock that nv50_dp_mode_valid() came up with, since we'll
eventually want to use that for PBN calculation in
nv50_mstc_mode_valid().

Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 4a2cb418 11-May-2020 Lyude Paul <lyude@redhat.com>

drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support

Right now, we make the mistake of allowing interlacing on all
connectors. Nvidia hardware does not always support interlacing with DP
though, so we need to make sure that we don't allow interlaced modes to
be set in such situations as otherwise we'll end up accidentally hanging
the display HW.

This fixes some hangs with Turing, which would be caused by attempting
to set an interlaced mode on hardware that doesn't support it. This
patch likely fixes other hardware hanging in the same way as well.

Note that we say we probe PIOR caps, but they don't actually have any
interlacing caps. So, the get_caps() function for PIORs just sets
interlacing support to true.

Changes since v1:
* Actually probe caps correctly this time, both on EVO and NVDisplay.
Changes since v2:
* Fix probing for < GF119
* Use vfunc table, in prep for adding more caps in the future.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 2ca7fb5c 08-May-2018 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/nv50: handle SetControlOutputResource from head

Removes duplicated code from OR-specific functions.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 6c22ea37 19-May-2017 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: introduce acquire/release display path methods

These exist to give NVKM information on the set of display paths that
the DD needs to be active at any given time.

Previously, the supervisor attempted to determine this solely from OR
state, but there's a few configurations where this information on its
own isn't enough to determine the specific display paths in question:

- ANX9805, where the PIOR protocol for both DP and TMDS is TMDS.
- On a device using DCB Switched Outputs.
- On GM20x and newer, with a crossbar between the SOR and macro links.

After this commit, the DD tells NVKM *exactly* which display path it's
attempting a modeset on.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# f479c0ba 04-Nov-2016 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# d665c7e9 04-Nov-2016 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/nv50: allow encoder update to be called from other modules

MST encoders will make use of this to share code with SOR>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# f20c665c 04-Nov-2016 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/nv50: clean-up encoder functions

Just a shuffle of blocks into an order consistent with the rest of the
code, renaming hdmi/audio funtions for atomic, and removal of unused
code.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 52aa30f2 04-Nov-2016 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms/nv50: switch mst sink back into sst mode

Sometimes we load with a sink already in MST mode. If, however, we can't
or don't want to use MST, we need to be able to switch it back to SST.

This commit instantiates a stub topology manager for any output path that
we believe (the detection of this could use some improvement) has support
for MST, and adds the connector detect() logic for detecting sink support
and switching between modes.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 16c3719c 14-Dec-2015 Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Constify drm_encoder_slave_funcs

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-11-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 129b7820 04-Dec-2015 Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Move encoder->save/restore into nouveau

Nouveau is the only user, and atomic drivers should do state
save/restoring differently. So move it into noveau.

Saves me typing some kerneldoc, too ;-)

v2: Move misplaced hunk into earlier nouveau patch.

Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449245647-1315-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>


# 2aa5eac5 19-Aug-2015 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/i2c: transition pad/ports away from being based on nvkm_object

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# be83cd4e 13-Jan-2015 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: finalise nvkm namespace switch (no binary change)

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver. This is being
done in order to make it very clear as to what part of the driver a
given symbol belongs to, and as a minor step towards splitting the
DRM driver out to be able to stand on its own (for virt).

Because there's already a large amount of churn here anyway, this is
as good a time as any to also switch to NVIDIA's device and chipset
naming to ease collaboration with them.

A comparison of objdump disassemblies proves no code changes.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 8777c5c1 06-Jun-2014 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dp: probe dpcd to determine connectedness

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# e84a35a8 04-Jun-2014 Ben Skeggs <bskeggs@redhat.com>

drm/nv50-: prepare for attaching a SOR to multiple heads

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 1a646342 20-Mar-2013 Ben Skeggs <bskeggs@redhat.com>

drm/nv04/disp: hide all the cruft away in its own little hole

It'd be pretty awesome if someone would care enough to port this all
properly to a class interface, perhaps submitting a command stream to
the core via a sw object on PFIFO (emulating how EVO works basically,
and also what nvidia have done forever..)..

But, this seems unlikely given how old this hardware is now, so, lets
just hide it away.

There's a heap of other bits and pieces laying around that are still
tangled. I'll (re)move them in pieces.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 5ed50209 11-Feb-2013 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: store i2c port pointer directly in nouveau_encoder

This is about to become somewhat more complicated to determine in a
number of cases, so store the "common" case (DDC/AUX) directly inside
the encoder structure.

Pre-nv50 code not touched except to fill the pointer, don't care.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# e225f446 20-Nov-2012 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: rename nvd0_display to nv50_display to reflect reality since merge

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 8f2abc25 15-Nov-2012 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dp: remove last bits of VBIOS parsing from DRM code

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 6c8e4633 15-Nov-2012 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dp: move core link training calls to common code

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 51a3d342 25-Jul-2012 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/backlight: remove dependence on nouveau_drv.h

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 017e6e29 17-Jul-2012 Ben Skeggs <bskeggs@redhat.com>

drm/nv04/disp: kick all private state out to own header

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# cb75d97e 10-Jul-2012 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: implement devinit subdev, and new init table parser

v2:
- make sure not to execute display scripts unless resuming

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 4196faa8 09-Jul-2012 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/i2c: port to subdev interfaces

v2/v3: Ben Skeggs <bskeggs@redhat.com>
- fix typo in default bus selection
- fix accidental loss of destructor

v4: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
- fix typo causing incorrect default i2c port settings when no BMP data

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 760285e7 02-Oct-2012 David Howells <dhowells@redhat.com>

UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/

Convert #include "..." to #include <path/...> in drivers/gpu/.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>


# f14d9a4d 10-Mar-2012 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dp: make dp dpms function common, call from sor code instead

GF119 will use this too.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 8663bc7c 08-Mar-2012 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dp: move all nv50/sor-specific code out of nouveau_dp.c

Off-chip encoders (which we don't support yet anyway), and newer chipsets
(such as NVD9...), will need their own code for this.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 52e0d0ec 03-Aug-2011 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dp: enable down-spread if vbios and sink support it

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 27a45987 03-Aug-2011 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dp: restructure link training code

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# a002fece 03-Aug-2011 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dp: pass in required datarate to link training

Not used currently, but it will be used in preference to pre-determined
lane/bandwidth numbers at a later point.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 10b461e4 02-Aug-2011 Ben Skeggs <bskeggs@redhat.com>

drm/nv50/backlight: take the sor into account when bashing regs

I'm sure that out there somewhere, someone will need this. We currently
haven't seen an example of LVDS being on a non-0 SOR so far though.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 46959b77 30-Jun-2011 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/dp: remove reliance on vbios for native displayport

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# fe224bb7 26-Sep-2010 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: enable enhanced framing only if DP display supports it

Reported-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 4a9f822f 20-Jul-2010 Francisco Jerez <currojerez@riseup.net>

drm/nv17-nv4x: Attempt to init some external TMDS transmitters.

sil164 and friends are the most common, usually they just need to be
poked once because a fixed configuration is enough for any modes and
clocks, so they worked without this patch if the BIOS had done a good
job on POST. Display couldn't survive a suspend/resume cycle though.
Unfortunately, BIOS scripts are useless here.

Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# ec7fc4a1 30-Jun-2010 Ben Skeggs <bskeggs@redhat.com>

drm/nv50: supply encoder disable() hook for SOR outputs

Allows us to remove a driver hack that used to be necessary to disable
encoders in certain situations before setting up a mode. The DRM has
better knowledge of when this is needed than the driver does.

This fixes a number of display switching issues.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 8f1a6086 27-Jun-2010 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: tidy connector/encoder creation a little

Create connectors before encoders to avoid having to do another loop across
encoder list whenever we create a new connector. This allows us to pass
the connector to the encoder creation functions, and avoid using a
create_resources() callback since we can now call it directly.

This can also potentially modify the connector ordering on nv50. On cards
where the DCB connector and encoder tables are in the same order, things
will be unchanged. However, there's some cards where the ordering between
the tables differ, and in one case, leads us to naming the connectors
"wrongly".

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# afa3b4c3 22-Apr-2010 Ben Skeggs <bskeggs@redhat.com>

drm/nv50: fix suspend/resume with DP outputs

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 6f335a7a 28-Mar-2010 Ben Skeggs <bskeggs@redhat.com>

drm/nv50: preserve an unknown SOR_MODECTRL value for DP encoders

This value interacts with some registers we don't currently know how to
program properly ourselves. The default of 5 that we were using matches
what the VBIOS on early DP cards do, but later ones use 6, which would
cause nouveau to program an incorrect mode on these chips.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>


# 6ee73861 11-Dec-2009 Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: Add DRM driver for NVIDIA GPUs

This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA.

This driver is a KMS-based driver and requires a compatible nouveau
userspace libdrm and nouveau X.org driver.

This driver requires firmware files not available in this kernel tree,
interested parties can find them via the nouveau project git archive.

This driver is reverse engineered, and is in no way supported by nVidia.

Support for nearly the complete range of nvidia hw from nv04->g80 (nv50)
is available, and the kms driver should support driving nearly all
output types (displayport is under development still) along with supporting
suspend/resume.

This work is all from the upstream nouveau project found at
nouveau.freedesktop.org.

The original authors list from nouveau git tree is:
Anssi Hannula <anssi.hannula@iki.fi>
Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez <currojerez@riseup.net>
Maarten Maathuis <madman2003@gmail.com>
Marcin Kościelnicki <koriakin@0x04.net>
Matthew Garrett <mjg@redhat.com>
Matt Parnell <mparnell@gmail.com>
Patrice Mandin <patmandin@gmail.com>
Pekka Paalanen <pq@iki.fi>
Xavier Chantry <shiningxc@gmail.com>
along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>