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

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

Under certain circumstances the trapped address will contain subc 7,
which GK104 GR doesn't have anymore.

Notice this case to avoid causing additional priv ring faults.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

No idea if "3" is a constant or derived from something else, but the
value is unchanged in the limited traces of gm107/gm204 I have here.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

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

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

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

Make static a few functions and structures that should be.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

A "return 0" found its way in the middle of the error path of
nouveau_platform_probe(), remove it as it will make the kernel crash if
we try to unload the module afterwards.

While we are at it, also remove the IOMMU domain if it has been created,
as we should.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

nvkm_mm_fini() was not called when exiting the driver, resulting in a
memory leak. Fix this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

On some of these chipsets, reading NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK
can trigger a PRI fault and return an error code instead of a TPC mask,
unless PGOB has been disabled first.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Before we moved gk110's implementation of this to pmu, the functions were
identical.  This commit just switches GK208 to use the new (more complete)
implementation of the power-up sequence.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Turns out the PTHERM part of this dance is bracketed by the same PMU
fiddling that occurs on GK104/6, let's assume it's also PGOB.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

So we can actually use the full 512 byte code space
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

If a memory allocation fails when using the DMA allocator,
gk20a_instobj_dtor_dma() will be called on the failed instmem object.
At this time, node->handle might not be NULL despite the call to
dma_alloc_attrs() having failed. node->cpuaddr is the right member to
check for such a failure, so use it instead.
Reported-by: Vince Hsu <vinceh@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

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

User-space use mappable BOs notably for fences, and expects that a
value update by the GPU will be immediatly visible through the
user-space mapping.

ARM has a property that may prevent this from happening though: memory
can be mapped multiple times only if the different mappings share the
same caching properties. However all the lowmem memory is already
identity-mapped into the kernel with cache enabled, so when user-space
requests an uncached mapping, we actually get an "undefined caching
policy" one and this has strange side-effects described on Freedesktop
bug 86690.

To prevent this from happening, allow user-space to explicitly specify
which objects should be coherent, and create such objects with the
TTM_PL_FLAG_UNCACHED flag. This will make TTM allocate memory using the
DMA API, which will fix the identify mapping and allow us to safely map
the objects to user-space uncached.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Let GK20A's instmem take advantage of the IOMMU if it is present. Having
an IOMMU means that instmem is no longer allocated using the DMA API,
but instead obtained through page_alloc and made contiguous to the GPU
by IOMMU mappings.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Tegra SoCs have an IOMMU that can be used to present non-contiguous
physical memory as contiguous to the GPU and maximize the use of large
pages in the GPU MMU, leading to performance gains. This patch adds
support for probing such a IOMMU if present and make its properties
available in the nouveau_platform_gpu structure so subsystems can take
advantage of it.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

instmem for GK20A is allocated using dma_alloc_coherent(), which
provides us with a coherent CPU mapping that we never use because
instmem objects are accessed through PRAMIN. Switch to
dma_alloc_attrs() which gives us the option to dismiss that CPU mapping
and free up some CPU virtual space.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Now that Nouveau can operate even when there is no RAM device, remove
the dummy one used by GK20A.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

GK20A does not have dedicated RAM, thus having a RAM device for it does
not make sense. Move the contiguous physical memory allocation to
instmem.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Having a RAM device does not make sense for chips like GK20A which have
no dedicated video memory. The dummy RAM device that we used so far
works as a temporary band-aid, but in the longer term it is desirable
for the driver to be able to work without any kind of VRAM.

This patch adds a few conditionals in places where a RAM device was
assumed to be present and allows some more objects to be allocated from
the TT domain, allowing Nouveau to handle GPUs for which
pfb->ram == NULL.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Notify interrupt is only used for cyclestats. We can just clear it and
avoid an "unknown stat" error that gets printed to dmesg otherwise.
Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Other methods in this file suggest this is the correct way to retrieve
the engine pointer.
Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

We use -1 to mean "not read from hw yet"
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This if statement is correct but it wasn't indented, so it looked like
some code was missing.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Spotted by coccinelle:
drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c:50:5-8: WARNING: end returns can be simpified
Signed-off-by: Martin Peres <martin.peres@free.fr>
Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

imx-drm changes to use media bus formats and LDB drm_panel support

- Add media bus formats needed by imx-drm
- Switch to use media bus formats to describe the pixel format
  on the internal parallel bus between display interface and
  encoders
- Some preparations for TV Output via TVEv2 on i.MX5
- Add drm_panel support to the i.MX LVDS driver, allow to
  determine the bus pixel format from the panel descriptor.

* tag 'imx-drm-next-2015-03-31' of git://git.pengutronix.de/git/pza/linux:
  drm/imx: imx-ldb: allow to determine bus format from the connected panel
  drm/imx: imx-ldb: reset display clock input when disabling LVDS
  drm/imx: imx-ldb: add drm_panel support
  drm/imx: consolidate bus format variable names
  drm/imx: switch to use media bus formats
  Add RGB666_1X24_CPADHI media bus format
  Add YUV8_1X24 media bus format
  Add BGR888_1X24 and GBR888_1X24 media bus formats
  Add LVDS RGB media bus formats
  Add RGB444_1X12 and RGB565_1X16 media bus formats
  drm/imx: ipuv3-crtc: Allow to divide DI clock from TVEv2
  drm/imx: Add support for interlaced scanout

drm: Use of-graph helpers to loop over endpoints

Convert all drm callers that use of_graph_get_next_endpoint to loop over
of-graph endpoints to the newly introduced for_each_endpoint_of_node
helper macro.

* tag 'of-graph-drm-2015-04-08' of git://git.pengutronix.de/git/pza/linux:
  drm/rockchip: use for_each_endpoint_of_node macro, drop endpoint reference on break
  drm/rcar-du: use for_each_endpoint_of_node macro
  drm/imx: use for_each_endpoint_of_node macro in imx_drm_encoder_get_mux_id
  drm: use for_each_endpoint_of_node macro in drm_of_find_possible_crtcs
  of: Explicitly include linux/types.h in of_graph.h
  dt-bindings: brcm: rationalize Broadcom documentation naming
  of/unittest: replace 'selftest' with 'unittest'
  Documentation: rename of_selftest.txt to of_unittest.txt
  Documentation: update the of_selftest.txt
  dt: OF_UNITTEST make dependency broken
  MAINTAINERS: Pantelis Antoniou device tree overlay maintainer
  of: Add of_graph_get_port_by_id function
  of: Add for_each_endpoint_of_node helper macro
  of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint

Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next

   This pull request contains just cleanup for atomic pageflip/modeset
   support, and some fixeups.

   We wanted to merge atomic pageflip/modeset feature support, new drivers
   - MIC and DECON for exynos5433 SoC - and relevant patches this time.
   However, I'd found that these features are not only safe enough
   but also aren't tested yet. So for them, I'd like to have enough times
   for the reviews.

* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: Fix FIMD buffer size calculation
  drm/exynos: Enable DP clock to fix display on Exynos5250 and other
  drm/exynos: fimd: check whether exynos_drm_crtc_create succeed or not
  drm/exynos: dsi: remove the empty mode_valid callback
  drm/exynos: add ratio calculation
  drm/exynos: use src_x and src_y instead of fb_x and fb_y
  drm/exynos: mixer: add 2x scaling to mixer_graph_buffer
  drm/exynos: remove superfluous error messages
  drm/exynos: fix typos in hdmi and mixer
  drm/exynos/ipp: Validate buffer enqueue requests
  drm/exynos: track vblank events on a per crtc basis
  drm/exynos: remove leftover functions declarations
  drm/exynos: remove exynos_plane_destroy()
  drm/exynos: make zpos property immutable
  drm/exynos: preset zpos value for overlay planes
  drm/exynos: remove struct *_win_data abstraction on planes
  drm/exynos: remove unused exynos_crtc->win_enable() callback
  drm/exynos: fimd: fix alpha setting for XR24 pixel format

Commit adacb228 ("drm: Exynos: Respect framebuffer pitch for
FIMD/Mixer") fixed the buffer size calculation by using the FB
pitch value but later commit 26b9c2813ede1 ("drm/exynos: remove
struct *_win_data abstraction on planes") added a regression so
fix the buffer size calculation again.

Tested on Chromebook Snow / Peach Pit.

Fixes: 26b9c2813ede1 ("drm/exynos: remove struct *_win_data abstraction on planes")
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

After adding display power domain for Exynos5250 in commit
2d2c9a8d ("ARM: dts: add display power domain for exynos5250") the
display on Chromebook Snow and others stopped working after boot.

The reason for this suggested Andrzej Hajda: the DP clock was disabled.
This clock is required by Display Port and is enabled by bootloader.
However when FIMD driver probing was deferred, the display power domain
was turned off. This effectively reset the value of DP clock enable
register.

When exynos-dp is later probed, the clock is not enabled and display is
not properly configured:

exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
exynos-dp 145b0000.dp-controller: unable to config video

Fixes: 2d2c9a8d ("ARM: dts: add display power domain for exynos5250")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reported-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

>From the commit "drm/exynos: fix the execution order in FIMD
initialization" (598285bfdce46d7c47632a2ba4b980f60be4a677), the error
checking code is removed improperly. This patch fix the regression.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

Because the helper function which calls this callback checks whether
it is registered or not. It is not necessary if it does nothing.
So it would be better to remove the function for clarity.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>