Reported-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The Apple GMUX is the one managing the backlight, so there is no need for
Nouveau to register its own backlight interface.

v2: Do not split information message on two lines as it prevents from grepping
    it, as pointed out by Lukas Wunner

v3: Add a missing end-of-line character to the printed message
Signed-off-by: NPierre Moreau <pierre.morrow@free.fr>
Reviewed-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Currently, every backlight interface created by Nouveau uses the same name,
nv_backlight. This leads to a sysfs warning as it tries to create an already
existing folder. This patch adds a incremented number to the name, but keeps
the initial name as nv_backlight, to avoid possibly breaking userspace; the
second interface will be named nv_backlight1, and so on.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86539

v2:
* Switch to using ida for generating unique IDs, as suggested by Ilia Mirkin;
* Allocate backlight name on the stack, as suggested by Ilia Mirkin;
* Move `nouveau_get_backlight_name()` to avoid forward declaration, as
  suggested by Ilia Mirkin;
* Fix reference to bug report formatting, as reported by Nick Tenney.

v3:
* Define a macro for the size of the backlight name, to avoid defining
  it multiple times;
* Use snprintf in place of sprintf.

v4:
* Do not create similarly named interfaces when reaching the maximum
  amount of unique names, but fail instead, as pointed out by Lukas Wunner
Signed-off-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

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

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

TTM was changed a while back to allow for pipelining of buffer moves, and
part of this was the removal of waiting for a BO to idle before calling
move(), placing the responsibility on the driver to do this if required.

That's all well and good, except, we make use of move_notify() to handle
mapping/unmapping from the GPU VMM as move() isn't called on all paths.

This commit adds a wait before unmapping from a VMM in move_notify(), to
prevent GPU page faults where a buffer is still being accessed.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org [v4.8+]

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

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

This has been on the TODO list for a while now, recovering from things
such as attempting to execute a push buffer or touch a semaphore in an
unmapped memory area.

The only thing required on the HW side here is that the offending
channel is removed from the runlist, and *not* a full reset of PFIFO.

This used to be a bit messier to handle before the rework to make use
of engine topology info, but is apparently now trivial.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We thought that no userspace is using them, but oops libdrm is using
them to figure out whether a driver supports modesetting. Check out
drmCheckModesettingSupported but maybe don't because it's horrible and
totally runs counter to where we want to go with libdrm device
handling. The function looks in the device hierarchy for whether
controlD* exist using the following format string:

/sys/bus/pci/devices/%04x:%02x:%02x.%d/drm/controlD%d

The "/drm" subdirectory is the glue directory from the sysfs class
stuff, and the only way to get at it seems to through
kdev->kobj.parent (when kdev is represents e.g. the card0 chardev
instance in sysfs). Git grep says we're not the only ones touching
that, so I hope it's ok we dig into such internals - I couldn't find a
proper interface for getting at the glue directory.

Quick git grep shows that at least -amdgpu, -ati are using this.
-modesetting do not, and on -intel it's only about the 4th fallback
path for device lookup, which is why this didn't blow up earlier.

Oh well, we need to keep it working, and the simplest way is to add a
symlink at the right place in sysfs from controlD* to card*.

v2:
- Fix error path handling by adding if (!minor) return checks (David)
- Fix the controlD* numbers to match what's been there (David)
- Add a comment what exactly userspace minimally needs.
- Correct the analysis for -intel (Chris).

Fixes: 8a357d10 ("drm: Nerf DRM_CONTROL nodes")
Cc: Dave Airlie <airlied@gmail.com>
Reported-and-tested-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NEmil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161209135656.14881-1-daniel.vetter@ffwll.ch

vc4 already has a proper load sequence, but the unload one needed some
fixups: First unregister, and last drop the final ref.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Some generic TV connector properties are exposed in drm_mode_config, but
they are currently handled independently in each DRM encoder driver.

Extend the drm_connector_state to store TV related states, and modify the
drm_atomic_connector_{set,get}_property() helpers to fill the connector
state accordingly.

Each driver is then responsible for checking and applying the new config
in its ->atomic_mode_{check,set}() operations.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

PV_CONTROL_CLK_SELECT_VEC is actually 2 and not 0. Fix the definition and
rework the vc4_set_crtc_possible_masks() to cover the full range of the
PV_CONTROL_CLK_SELECT field.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Looks like this was missed when dce_v6_0.c was added.

Fixes: e2cdf640 ("drm/amdgpu: add display controller implementation for si v10")
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We don't require a resticted pinning in these cases, so just
use plain pin.
Reviewed-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For CZ, some function pointers like display_configuration_changed
are not set. So when HW manager tries to configure display, we
end up with messages like

"[ powerplay ] this function not implement!"

in the logs. This message is informational, but lacks details
on which function is not implemented and why.

Rather than using KERN_INFO to print the message everytime the
system boots, we rather use pr_debug so that it is only printed
when debug prints are enabled at runtime.
Reviewed-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NArindam Nath <arindam.nath@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NTom St Denis <tom.stdenis@amd.com>
Acked-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NTom St Denis <tom.stdenis@amd.com>
Acked-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Implemented for SGPRs for GFX v8 initially.

(v2) cleanup minor whitespace and remove sanity check and
     addressing is in dwords not bytes
Signed-off-by: NTom St Denis <tom.stdenis@amd.com>
Acked-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Allows userspace components to fetch information
from the vbios image.

v2: agd: fix warning
Reviewed-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian Koenig <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It's necessary if we want to export vbios image out.
Reviewed-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian Koenig <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

tpd12s015 driver is missing error value handling for gpio
initialization, causing 0 to be returned as an error if gpiod_get_*
fails. This may cause deferred probing to fail.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We set the possible_crtc for all planes to "(1 << priv->num_crtcs) - 1",
which is fine as the HW planes can be used fro all crtcs. However, when
we're doing that, we are still incrementing 'num_crtcs', and we'll end
up with bad possible_crtcs, preventing the use of the primary planes.

This patch passes a possible_crtcs mask to plane init function so that
we get correct possible_crtc.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

drm_universal_plane_init() and drm_plane_init() take "unsigned long
possible_crtcs" parameter, but then stuff it into uint32_t. Change the
parameter to uint32_t.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Currently the reference for the dmabuf->obj is incremented for the
dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace
interface), but is released in drm_gem_dmabuf_release() (the lowlevel
handler). Improve the symmetry of the dmabuf->obj ownership by acquiring
the reference in drm_gem_dmabuf_export(). This makes it easier to use
the prime functions directly.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Update kerneldoc.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161207214527.22533-1-chris@chris-wilson.co.uk

vgem (and our igt tests using vgem) need this. I suspect etnaviv will
fare similarly.

v2. Make it build. Oops.

Fixes: d5264ed3 ("drm: Return -ENOTSUPP when called for KMS cap with a non-KMS driver")
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161207144939.22756-1-daniel.vetter@ffwll.ch

Select DRM_PANEL, since the MXSFB driver depends on it. Otherwise,
we get the following error when compiling:

drivers/built-in.o: In function `mxsfb_probe':
core.c:(.text+0x9ce9c): undefined reference to `drm_panel_attach'
core.c:(.text+0x9cff0): undefined reference to `drm_panel_detach'
drivers/built-in.o: In function `mxsfb_panel_connector_destroy':
core.c:(.text+0x9d614): undefined reference to `drm_panel_detach'
drivers/built-in.o: In function `mxsfb_create_output':
core.c:(.text+0x9d68c): undefined reference to `of_drm_find_panel'
make: *** [Makefile:962: vmlinux] Error 1
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Reported-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Instead of dealing with crtc details inside drm_atomic.c we should
just export a function that creates a new crtc fence for us and
use that.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1481046437-18778-1-git-send-email-gustavo@padovan.org

We will ignored PSR setting if panel not support it. So, in this case,
we should return from analogix_dp_enable/disable_psr() without any
error code. Let's retrun 0 instead of -EINVAL when panel not support PSR
in analogix_dp_enable/disable_psr().
Signed-off-by: Nzain wang <wzz@rock-chips.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1481072253-8917-1-git-send-email-wzz@rock-chips.com

Signed-off-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NKen Wang <Qingqing.Wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

New variant.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

New variant.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

New variant.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

New variant.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

If doesn't enable dpm, the powerplay will not allocate memory for
hw management. So, hw_init_power_state_table function will reference
NULL pointer when resetting.
Signed-off-by: NXiangliang Yu <Xiangliang.Yu@amd.com>
Reviewed-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

For SR-IOV client, driver shouldn't touch the GFX hw during HW
fini, otherwise, gfx will fail to start after rebooting guest os.
Signed-off-by: Nshaoyunl <Shaoyun.Liu@amd.com>
Signed-off-by: NXiangliang Yu <Xiangliang.Yu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NMonk Liu <Monk.Liu@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Put the initial part close to memory allocate, it will make code
more clear.
Signed-off-by: NXiangliang Yu <Xiangliang.Yu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>