DRM core already checks in drm_atomic_plane_check() if the
pixelformat is valid. Hence we can collapse the default case
of the switch statement with the XRGB8888 case.

No functional change.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

DRM core already checks in drm_atomic_plane_check() if the
pixelformat is valid. Hence we can drop the default case of
the switch statement and collapse most of the code.

Also rename the two booleans to reflect what true/false
actually means, and to avoid mixing CrCb/NV21 descriptions.

No functional change.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The video processor supports a tiled version of the NV12 format,
known as NV12MT in V4L2 terms. The support was removed in commit
083500ba due to not being a real
pixel format, but rather NV12 with a special memory layout.

With the introduction of FB modifiers, we can now properly support
this format again.

Tested with a hacked up modetest from libdrm's test suite on
an ODROID-X2 (Exynos4412).
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The current comment sounds like the division op is done to
compensate for some hardware erratum. But the chroma plane
having half the height of the luma plane is just the way
NV12/NV21 is defined, so clarify this behaviour.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Since panel's mode of work is propagated properly from panel to DECON,
there is no need to use redundant private device tree property.
The only issue with such approach is that check for required interrupts
should be postponed until panel communicate its requirements, ie to
mode validation phase - mode_valid callback.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>

crtc::mode_valid callback is required to implement proper pipeline
validation for command/video modes. Since Exynos uses private
framework such callback should be added to it.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

To allow runtime validation of mode of work irq request
code should be split into two separate phases:
- irq reqesting,
- irq checking.
Following patches will move 2nd phase to mode validation phase.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

MIC driver should use info from CRTC to check mode of work instead of
illegally peeking into nodes of other devices.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

mipi_dsi framework provides information about panel's mode of work.
This info should be propagated upstream to configure all elements of
the pipeline. As CRTC is the common denominator of the pipeline we can
put such info into its structures.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Description of drm_helper_hpd_irq_event clearly states that drivers
supporting hotplug events per connector should use different helper -
drm_kms_helper_hotplug_event. To achieve it following changes have
been performed:
- moved down all DSI ops - they require exynos_dsi_disable function
to be defined earlier,
- simplified exynos_dsi_detect - there is no real detection, it just
returns if panel is attached,
- DSI attach/detach callbacks attaches/detaches DRM panel and sets
connector status and other context fields accordingly, all this is
performed under mutex, as these callbacks are asynchronous.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

All encoders share the same code to set encoders possible_crtcs field.
The patch creates helper to abstract out this code.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Linux core provide helpers for polling with timeout, lets use them.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The null check on the array msto is incorrect since msto is never
null. The null check should be instead on msto[i] since this is
being dereferenced in the call to drm_mode_connector_attach_encoder.

Thanks to Emil Velikov for pointing out the mistake in my original
fix and for suggesting the correct fix.

Detected by CoverityScan, CID#1375915 ("Array compared against 0")

Fixes: f479c0ba ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It appears that MSI does not work on either G5 PPC nor on a E5500-based
platform, where other hardware is reported to work fine with MSI.

Both tests were conducted with NV4x hardware, so perhaps other (or even
this) hardware can be made to work. It's still possible to force-enable
with config=NvMSI=1 on load.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These are particularly annoying on Optimus systems where these paths can
be called regularly.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

drm_crtc_init exposes the XRGB8888 and ARGB8888 formats. In actuality,
ARGB8888's 32-bit depth messes up some formulas that weren't meant for
it, and the alpha is fairly meaningless for the primary plane.

The modesetting logic appears to be fully prepared for RGB565 as well as
XRGB1555 however, as tested with modetest.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We were previously setting the pitch based on a perfectly packed buffer.
This does not necessarily happen. Either modetest started generating
such buffers recently, or earlier testing only happened with well-picked
overlay sizes.

While we're at it, beef up and refactor the error state detection.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Pre-nv50 YUV overlays have stringent requirements for working with the
internal machinery. Instead of rejecting these at update_plane time, we
should instead prevent the framebuffers from being created in the first
place.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: NTobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These are used for accesses to sparse mappings, and we want reads of
such mappings to return 0.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Useful for testing, and for the userspace build where we can't kick
a framebuffer driver off the device.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Forked from GP107 implementation. Secboot/gr left out as we don't have
signed blobs from NVIDIA in linux-firmware.

(Ben): Was unable to mmiotrace the binary driver for unknown reasons,
       so not able to 100% confirm that no other changes from GP107
       are needed.  Quick testing shows it seems to work well enough
       for display.  Due to NVIDIA dragging their heels on getting
       signed firmware to us, this is the best we can do for now.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101601Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Most of these errors seem to be WFD related. Official documentation
says dcb type 8 is reserved. It's probably used for WFD. Silence
the warning in either case.

Connector type 70 is stated to be a virtual connector for WiFi
display. Since we know this, don't warn that we don't.

Signed-off by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This warning seems to pop up mainly in laptop cards. Silence it as
it is expected behavior.

Signed-off by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GT215, GF100-GP100, and GP10x are all different.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The NV_PMC_ENABLE bit for PMU did not appear until GF100, and some other
unknown register needs to be poked instead.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

An upcoming commit will replace direct NV_PMC register bashing from PMU
with a call to the proper function.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We assume that each board has 4 heads for GF119+. However this is not
necessarily true - in the case of a GP108 board, the register indicated
that there were only 2.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101601Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This allows temperature readouts on maxwell2 GPUs.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Array thresolds should be named thresholds, rename it. Also make it static
static const char * const
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fixes a false positive from might_sleep(). The reservation object is freshly
initialized, so nobody else can hold the mutex but the function is
called from atomic context.

v2: Correctly invert the check as well.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

mmVGT_INDEX_TYPE has no default value, need to make sure
it's initialized when gfx is initialized.
Signed-off-by: NKen Wang <Ken.Wang@amd.com>
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The commit 213e08ad
	("drm/i915/bxt: add bxt dsi gpio element support")
enables GPIO support for Broxton based platforms.

While using that API we might get into troubles in the future, because
we can't rely on label name in the driver since vendor firmware might
provide any GPIO pin there, e.g. "reset", and even mark it in _DSD (in
which case the request will fail).

To avoid inconsistency and potential issues we have two options:
a) generate GPIO ACPI mapping table and supply it via
   acpi_dev_add_driver_gpios(), or
b) just pass NULL as connection ID.

The b) approach is much simpler and would work since the driver relies
on GPIO indices only. Moreover, the _CRS fallback mechanism, when
requesting GPIO, has been made stricter, and supplying non-NULL
connection ID when neither _DSD, nor GPIO ACPI mapping is present, is
making request fail.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101921
Fixes: f10e4bf6 ("gpio: acpi: Even more tighten up ACPI GPIO lookups")
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: NMika Kahola <mika.kahola@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817105541.63914-1-andriy.shevchenko@linux.intel.com

In a synchronous setup, we may retire the last request before we
complete allocating the next request. As the last request is retired, we
queue a timer to mark the device as idle, and promptly have to execute
ad cancel that timer once we complete allocating the request and need to
keep the device awake. If we rearrange the mark_busy() to occur before
we retire the previous request, we can skip this ping-pong.

v2: Joonas pointed out that unreserve_seqno() was now doing more than
doing seqno handling and should be renamed to reflect its wider purpose.
That also highlighted the new asymmetry with reserve_seqno(), so fixup
that and rename both to [un]reserve_engine().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817144719.10968-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

The word out was dropped from the sentence across the line break, put it
back.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-6-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

This was the competing idea long ago, but it was only with the rewrite
of the idr as an radixtree and using the radixtree directly ourselves,
along with the realisation that we can store the vma directly in the
radixtree and only need a list for the reverse mapping, that made the
patch performant enough to displace using a hashtable. Though the vma ht
is fast and doesn't require any extra allocation (as we can embed the node
inside the vma), it does require a thread for resizing and serialization
and will have the occasional slow lookup. That is hairy enough to
investigate alternatives and favour them if equivalent in peak performance.
One advantage of allocating an indirection entry is that we can support a
single shared bo between many clients, something that was done on a
first-come first-serve basis for shared GGTT vma previously. To offset
the extra allocations, we create yet another kmem_cache for them.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-5-chris@chris-wilson.co.uk

Since the introduction of being able to perform a lockless lookup of an
object (i915_gem_object_get_rcu() in fbbd37b3 ("drm/i915: Move object
release to a freelist + worker") we no longer need to split the
object/vma lookup into 3 phases and so combine them into a much simpler
single loop.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-4-chris@chris-wilson.co.uk