drm/nv50/kms: use sclass() instead of trial-and-error

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

drm/nv50/kms: remove a couple of cursor-related stub functions

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

drm/nouveau: fix pin refcnt leak in failure path

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

drm/nouveau: synchronize BOs when required

On architectures for which access to GPU memory is non-coherent,
caches need to be flushed and invalidated explicitly when BO control
changes between CPU and GPU.

This patch adds buffer synchronization functions which invokes the
correct API (PCI or DMA) to ensure synchronization is effective.

Based on the TTM DMA cache helper patches by Lucas Stach.

Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: allocate GPFIFOs and fences coherently

Specify TTM_PL_FLAG_UNCACHED when allocating GPFIFOs and fences to
allow them to be safely accessed by the kernel without being synced
on non-coherent architectures.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: implement explicitly coherent BOs

Allow nouveau_bo_new() to recognize the TTM_PL_FLAG_UNCACHED flag, which
means that we want the allocated BO to be perfectly coherent between the
CPU and GPU. This is useful on non-coherent architectures for which we
do not want to manually sync some rarely-accessed buffers: typically,
fences and pushbuffers.

A TTM BO allocated with the TTM_PL_FLAG_UNCACHED on a non-coherent
architecture will be populated using the DMA API, and accesses to it
performed using the coherent mapping performed by dma_alloc_coherent().

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: introduce nv_device_is_cpu_coherent()

Add a function allowing us to know whether a device is CPU-coherent,
i.e. accesses performed by the CPU on GPU-mapped buffers will
be immediately visible on the GPU side and vice-versa.

For now, a device is considered to be coherent if it uses the PCI bus on
a non-ARM architecture.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: warn when moving a pinned object

Pinned BOs are supposed to remain in their current location until
unpinned. Display a warning for the supposedly-erroneous case where we
are trying to move such objects.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: clear notify intr status when enabling, to prevent races

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

drm/nv50-/disp: rename class members to match nvidia channel names

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

drm/nouveau/core: remove some dead code that got forgotten

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

drm/nouveau/pwr/fuc: Fix thinko in nouveau_memx_wait()

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

drm/nva3/clock: Allow user reclocking

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

drm/nouveau/fb/ramnva3: Reclocking script for GDDR3

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

drm/nouveau/fb/ramnva3: Reclocking script for DDR2

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

drm/nouveau/fb/ramnva3: Reclocking script for DDR3

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

drm/nouveau/fb/ramnva3: Ressurect timing calculation code

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

drm/nouveau/fb/ramnva3: Link training for DDR3

V2: fix whitespace errors in memx.fuc

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

drm/nouveau/fb/gddr3: Generate MR values

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

drm/nouveau/bios/ramcfg: 10_02_40 -> DLLoff

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

drm/nouveau: move the (far too many...) different s/r paths to the same place

No code changes.

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

drm/gk104-/fifo: handle copy engine class errors

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

drm/nouveau/bios: stop after NV+NPDS+ISBN image

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

drm/nouveau/bios: add some more signatures as seen on my gtx660

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

drm/nouveau: add support for gm204

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

drm/nouveau/device: recognise GM204

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

drm/gm204/disp: some magic that fixes bringup of uninitialised outputs

Probably missing something here, doesn't make a lot of sense to write
or+link data into a register whose offset is calculated by the same
or+link info..

This is the all I've witnessed the binary driver and vbios doing so
far, so it'll do.

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

drm/gm204/disp: initial support

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

drm/gf110-/disp: magic that might help some tmds issues

The binary driver has been doing this since GF119, and we've somehow
gotten away with it.  But, TMDS that hasn't been initialised already
by the x86 vbios code is distorted without it on GM204.

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

drm/nouveau/bios: support for opcodes 0x47/0x48

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

drm/nouveau/bios: add support for udisp 2.2

Not entirely sure why this got bumped at all yet.

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

drm/nouveau/bios: add support for dp 4.1

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

drm/nouveau/i2c: add support for DCB_I2C_PMGR port type

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

drm/nouveau/bios: add support for ccb 4.1

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

drm/nouveau/bios: add support for dcb 4.1

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

drm/gm204/i2c: add aux channel driver

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

drm/gm204/i2c: add pad driver

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

drm/nouveau/i2c: segregate aux channel adapter indices from bit-banged i2c

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

drm/nouveau/bios: store aux addr independently of i2c

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

drm/nv50-/i2c: kill some unused struct members

Left-over from before a rework a while back.

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

drm/nouveau/bios: log if auxch accesses fail, also return 0x00 from rd when it does

Logging at trace level, rather than as en error, as it seems conceivable
that failure could be normal under certain circumstances (new bios,
older sink that doesn't support a particular DPCD address)

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

drm/gm204/devinit: initial implementation

Starting from GM204, certain registers are no longer accessible by the host
(or unsigned PMU firmware).

This commit implements devinit on PMU, using a signed microcode image, and
devinit data, from the VBIOS.

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

drm/nouveau/devinit: allow impl to select its own cold-boot method

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

drm/nouveau/bios: add parsing of pmu image tables

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

drm/nouveau/bios: recognise nv-specific rom/pcir signatures

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

drm/nouveau/bios: use NPDE to locate images beyond those defined by PCIR

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

drm/nouveau/bios: add NPDE parsing

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

drm/nouveau/bios: fetch images beyond the first one in the rom

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

drm/nouveau/bios: use size/type from pci data structure

The field at +0x2 is technically processor specific, though I don't know
that it's ever mattered in practice (yet).

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

drm/nouveau/bios: add pci data structure parsing

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

drm/nouveau/bios: split out shadow methods

We're about to need to be able to fetch additional chunks of data beyond
the primary bios image, which makes fetching a lot more complicated.

This splits out the verious shadowing routines to be nothing more than
very dumb "fetch this much data from this offset" routines, and leaves
the logic of what and how much to fetch in common code.

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

drm/nouveau/bios: fix thinko when parsing extdev table

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

drm/nouveau: a, somehow, missed hunk of "fix regression on agp boards"

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

soc/tegra: fuse: export tegra_sku_info

Some Tegra drivers might be compiled as kernel modules, and they need the
fuse information for initialization. One example is the GK20A Nouveau
driver. It needs the GPU speedo value to calculate frequency-voltage
table. So export the tegra_sku_info.

Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

ARM: shmobile: marzen: Remove DU platform device

Platform data support has been removed from the DU driver, drop DU
support from the legacy Marzen board file. The multiplatform DT-based
Marzen support should be used instead.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Dave Airlie <airlied@redhat.com>

ARM: shmobile: lager: Remove DU platform device

Platform data support has been removed from the DU driver, drop DU
support from the legacy Lager board file. The multiplatform DT-based
Lager support should be used instead.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm/du/adv7511' of git://linuxtv.org/pinchartl/fbdev into drm-next

The branch is based on a merge of drm-next and Simon's tags/renesas-dt-du-for-
v3.19 available at
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git, the latter
having been pulled in the ARM SoC tree for v3.19.

Compared to v1, I've rebased my branch on a later drm-next, added Julia's
error return code fix, and documented the "drm: Decouple EDID parsing from I2C
adapter" patch properly.

v1:
Here's a pull request that adds HDMI support to the R-Car DU driver, including
a new slave encoder driver for the adv7511.

* 'drm/du/adv7511' of git://linuxtv.org/pinchartl/fbdev:
  drm: Add adv7511 encoder driver
  video: Add ADV751[13] DT bindings documentation
  drm: Decouple EDID parsing from I2C adapter
  drm: rcar-du: Add HDMI encoder and connector support
  drm: rcar-du: Replace drm_encoder with drm_slave_encoder
  drm: rcar-du: Replace direct DRM encoder access with cast macro
  drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init()
  drm: rcar-du: Remove platform data support
  drm: rcar-du: fix error return code
  ARM: shmobile: koelsch: Enable DU device in DT
  ARM: shmobile: koelsch-reference: Remove DU platform device
  ARM: shmobile: lager: Enable DU device in DT
  ARM: shmobile: lager-reference: Remove DU platform device
  ARM: shmobile: marzen: Enable DU device in DT
  ARM: shmobile: dts: Add common file for AA104XD12 panel
  ARM: shmobile: r8a7791: Add DU node to device tree
  ARM: shmobile: r8a7790: Add DU node to device tree
  ARM: shmobile: r8a7779: Add DU node to device tree
  ARM: shmobile: Remove FSF address from copyright headers

Merge branch 'amdkfd-next-3.19' of git://people.freedesktop.org/~gabbayo/linux into drm-next

- Fixes for sparse warnings
- Memory leak fixes
- Fix for deadlock between amdkfd and iommu

* 'amdkfd-next-3.19' of git://people.freedesktop.org/~gabbayo/linux:
  amdkfd: delete some dead code
  amdkfd: Fix memory leak of mqds on dqm fini
  amdkfd: fix an error handling bug in pqm_create_queue()
  amdkfd: fix some error handling in ioctl
  amdkfd: Remove DRM_AMDGPU dependency from Kconfig
  amdkfd: explicitely include io.h in kfd_doorbell.c
  amdkfd: Clear ctx cb before suspend
  amdkfd: Instead of using get function, use container_of
  amdkfd: use schedule() in sync_with_hw
  amdkfd: Fix memory leak on process deregistration
  amdkfd: add __iomem attribute to doorbell_ptr
  amdkfd: fence_wait_timeout() can be static
  amdkfd: is_occupied() can be static
  amdkfd: Fix sparse warnings in kfd_flat_memory.c
  amdkfd: pqm_get_kernel_queue() can be static
  amdkfd: test_kq() can be static
  amdkfd: Fix sparse warnings in kfd_topology.c
  amdkfd: Fix sparse warnings in kfd_chardev.c

drm: Add adv7511 encoder driver

This patch adds a driver for the Analog Devices adv7511. The adv7511 is
a standalone HDMI transmitter chip. It features a HDMI output interface
on one end and video and audio input interfaces on the other.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

video: Add ADV751[13] DT bindings documentation

The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They're described in DT using the
OF graph bindings and a list of custom properties pertaining to the
input video bus configuration.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: Decouple EDID parsing from I2C adapter

The drm_get_edid() function performs direct I2C accesses to read EDID
blocks, assuming that the monitor DDC interface is directly connected to
the I2C bus. It can't thus be used with HDMI encoders that control the
DDC bus and expose EDID blocks through a different interface.

Refactor drm_do_get_edid() to take a block read callback function
instead of an I2C adapter, and export it for direct use by drivers.

As in the general case the DDC bus is accessible by the kernel at the
I2C level, drivers must make all reasonable efforts to expose it as an
I2C adapter and use drm_get_edid() instead of abusing this function.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: rcar-du: Add HDMI encoder and connector support

SoCs that integrate the DU have no internal HDMI encoder, support
external encoders only.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: rcar-du: Replace drm_encoder with drm_slave_encoder

DRM slave encoders require their associated struct drm_encoder instance
to be embedded in a struct drm_slave_encoder. This makes processing
encoders regardless of their types needlessly and painfully complex in
drivers that use a mix of slave encoders and custom encoders. Such a
driver will need to either create drm_slave_encoder instances that fake
their embedded encoder instance, or to turn all drm_encoder instances
into drm_slave_encoder instances.

Between the two evils, one must choose the lesser. Use drm_slave_encoder
everywhere.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: rcar-du: Replace direct DRM encoder access with cast macro

Add a new macro to downcast an rcar_du_encoder pointer to a drm_encoder
pointer and use it. This prepares for the replacement of the
rcar_drm_encoder encoder field with a drm_slave_encoder.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init()

The encoder DT node will be needed to register an external HDMI encoder.
Pass it to the rcar_du_encoder_init() function to prepare for HDMI
support.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: rcar-du: Remove platform data support

All platforms now instantiate the DU through DT, platform data support
isn't needed anymore.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm: rcar-du: fix error return code

Propagate the error code on failure.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

drm/udl: properly check for error pointers

The drm_prime_pages_to_sg() function never returns NULL pointers, only
error pointers and valid pointers.

Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/udl: handle page mapping in dmabuf export.

Fixes dmabuf export failure with -E_NOMEM when the page is not mapped.

Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

MAINTAINERS: add maintainer for i.MX DRM driver

Add myself as the maintainer of the i.MX DRM driver.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: imx: Move imx-drm driver out of staging

The imx-drm driver was put into staging mostly for the following reasons,
all of which have been addressed or superseded:
 - convert the irq driver to use linear irq domains
 - work out the device tree bindings, this lead to the common of_graph
   bindings being used
 - factor out common helper functions, this mostly resulted in the
   component framework and drm of_graph helpers.

Before adding new fixes, and certainly before adding new features,
move it into its proper place below drivers/gpu/drm.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'tags/renesas-dt-du-for-v3.19' into drm/next/adv7511-base

Renesas ARM Based SoC DT DU Updates for v3.19

* Enable DU using DT on marzen/r8a7779, lager/r8a7790 and koelsch/r8a7791

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

  Add Exynos4415 SoC support, some fixups and cleanups.

   Summary:
   - Resolve kernel lockup issue incurred by probe request in probe context.
     . For this, it moves all register codes of sub drivers into init function
       and adds component binding support for vidi driver.
   - Add Exynos4415 SoC support.
   - Make each manager and display object to be embedded
     in each driver context.
   - Fix and clean up FIMD and MIPI-DSI drivers.
   - Clean up unnecesary or wrong descriptions.
   - And trivial cleanups.

* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (58 commits)
  drm/exynos: avoid leak if exynos_dpi_probe() fails
  drm/exynos: Fix exynos_dpi_remove() parameter
  drm/exynos: vidi: add component support
  drm/exynos: fix exynos_drm_component_del
  drm/exynos/ipp: fix error return code
  drm/exynos: clean up machine compatible string check
  drm/exynos: move Exynos platform drivers registration to init
  Revert "drm/exynos: fix null pointer dereference issue"
  drm/exynos/dpi: stop using display->ctx pointer
  drm/exynos/dpi: embed display into private context
  drm/exynos/dp: stop using display->ctx pointer
  drm/exynos/dp: embed display into private context
  drm/exynos/vidi: stop using display->ctx pointer
  drm/exynos/vidi: embed display into private context
  drm/exynos/hdmi: stop using display->ctx pointer
  drm/exynos/hdmi: embed display into private context
  drm/exynos/fimd: stop using manager->ctx pointer
  drm/exynos/fimd: embed manager into private context
  drm/exynos/vidi: stop using manager->ctx pointer
  drm/exynos/vidi: embed manager into private context
  ...

amdkfd: delete some dead code

This is dead code.  We don't need to unbind here, we can just return
directly.

Reviewed-by: Oded Gabbay <oded.gabbay@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Fix memory leak of mqds on dqm fini

The mqds array members are not freed when dqm is uninitialized.

Reviewed-by: Ben Goz <Ben.Goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next

Now that we have the bits needed for mdp5 atomic, here is the followup
pull request I mentioned.  Main highlights are:

1) mdp5 multiple crtc and public plane support (no more hard-coded mixer setup!)
2) mdp5 atomic conversion
3) couple atomic helper fixes for issues found during mdp5 atomic
debug (reviewed by danvet.. but he didn't plane to send an
atomic-fixes pull request so I agreed to tack them on to mine)

* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
  drm/atomic: shutdown *current* encoder
  drm/atomic: check mode_changed *after* atomic_check
  drm/msm/mdp4: fix mixer setup for multi-crtc + planes
  drm/msm/mdp5: dpms(OFF) cleanups
  drm/msm/mdp5: atomic
  drm/msm: atomic fixes
  drm/msm/mdp5: remove global mdp5_ctl_mgr
  drm/msm/mdp5: don't use void * for opaque types
  drm/msm: add multiple CRTC and overlay support
  drm/msm/mdp5: set rate before enabling clk
  drm/msm/mdp5: introduce mdp5_cfg module
  drm/msm/mdp5: make SMP module dynamically configurable
  drm/msm/hdmi: remove useless kref
  drm/msm/mdp5: get the core clock rate from MDP5 config
  drm/msm/mdp5: use irqdomains

amdkfd: fix an error handling bug in pqm_create_queue()

The call to kernel_queue_uninit(NULL) will trigger a BUG(), and also the
error code is incorrect.

Fixes: 45102048f77e ('amdkfd: Add process queue manager module')
Reviewed-by: Oded Gabbay <oded.gabbay@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: fix some error handling in ioctl

There is a typo here so the errors from kfd_bind_process_to_device()
are not detected.

Reviewed-by: Oded Gabbay <oded.gabbay@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

drm/exynos: avoid leak if exynos_dpi_probe() fails

The component must be deleted if the probe fails.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: Fix exynos_dpi_remove() parameter

exynos_dpi_remove() should receive a exynos_drm_display but when
DRM_EXYNOS_DPI was disabled it was receiving a struct device resulting in
ia compiler warning.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: vidi: add component support

This patch adds component support for vidi driver.

vidi driver is a kms driver so it doesn't need to be registered
to exynos_drm_subdrv_list. For this, it changes for the component
framework to be used for vidi driver.

This patch fixes below error also,

# echo 1 > /sys/devices/platform/exynos-drm-vidi/connection
[   55.618529] ------------[ cut here ]------------
[   55.621960] WARNING: CPU: 0 PID: 1397 at drivers/gpu/drm/drm_irq.c:1203 exynos_drm_crtc_dpms+0x88/0x17c()
[   55.631268] Modules linked in:
[   55.634278] CPU: 0 PID: 1397 Comm: sh Not tainted 3.18.0-rc2-146253-g31449d7 #1154
[   55.641885] [<c0014400>] (unwind_backtrace) from [<c0011570>] (show_stack+0x10/0x14)
[   55.649597] [<c0011570>] (show_stack) from [<c04764f4>] (dump_stack+0x84/0xc4)
[   55.656802] [<c04764f4>] (dump_stack) from [<c00218b8>] (warn_slowpath_common+0x6c/0x88)
[   55.664866] [<c00218b8>] (warn_slowpath_common) from [<c0021970>] (warn_slowpath_null+0x1c/0x24)
[   55.673632] [<c0021970>] (warn_slowpath_null) from [<c027a780>] (exynos_drm_crtc_dpms+0x88/0x17c)
[   55.682482] [<c027a780>] (exynos_drm_crtc_dpms) from [<c027a910>] (exynos_drm_crtc_commit+0x14/0x44)
[   55.691622] [<c027a910>] (exynos_drm_crtc_commit) from [<c025521c>] (drm_crtc_helper_set_mode+0x3d0/0x51c)
[   55.701233] [<c025521c>] (drm_crtc_helper_set_mode) from [<c0255d68>] (drm_crtc_helper_set_config+0x87c/0x9dc)
[   55.711230] [<c0255d68>] (drm_crtc_helper_set_config) from [<c026afa8>] (drm_mode_set_config_internal+0x58/0xd4)
[   55.721380] [<c026afa8>] (drm_mode_set_config_internal) from [<c025c208>] (restore_fbdev_mode+0xcc/0xec)
[   55.730834] [<c025c208>] (restore_fbdev_mode) from [<c025c244>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x30)
[   55.741424] [<c025c244>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c025e0a8>] (drm_fb_helper_set_par+0x1c/0x60)
[   55.752271] [<c025e0a8>] (drm_fb_helper_set_par) from [<c025e174>] (drm_fb_helper_hotplug_event+0x88/0xc4)
[   55.761906] [<c025e174>] (drm_fb_helper_hotplug_event) from [<c02571c4>] (drm_helper_hpd_irq_event+0xc8/0x134)
[   55.771898] [<c02571c4>] (drm_helper_hpd_irq_event) from [<c028e27c>] (vidi_store_connection+0x90/0xc8)
[   55.781268] [<c028e27c>] (vidi_store_connection) from [<c0125f80>] (kernfs_fop_write+0xc0/0x180)
[   55.790045] [<c0125f80>] (kernfs_fop_write) from [<c00cdf60>] (vfs_write+0xa0/0x1ac)
[   55.797757] [<c00cdf60>] (vfs_write) from [<c00ce468>] (SyS_write+0x44/0x9c)
[   55.804790] [<c00ce468>] (SyS_write) from [<c000e6a0>] (ret_fast_syscall+0x0/0x30)
[   55.812328] ---[ end trace 3c0fe4386702d4dd ]---

This issue occurs when modeset to vidi is tried in case that drm_vblank_init
is called prior to crtc creation of vidi driver. In this case, crtc number
of vidi is invalid so any requests with the crtc number will fail.
This patch guarantees drm_vblank_init to be called after all kms drivers
are ready by using component framework.

Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: fix exynos_drm_component_del

This patch resolves the issue that component object isn't removed
correctly.

A given component object couldn't be placed to head of drm_component_list
so all component objects added to the drm_component_list should be checked
to remove the given component object.

Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/ipp: fix error return code

Propagate the returned error code on failure.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: clean up machine compatible string check

Use 'for' statemant instead of hard-coded 'if' statement.

Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: move Exynos platform drivers registration to init

Registering the Exynos DRM subdevices platform drivers in the probe
function is causing an infinite loop. Fix this by moving it to the
exynos_drm_init() function to register the drivers on module init.

Registering drivers in the probe functions causes a deadlock in the parent
device lock. See Grant Likely explanation on the topic:

"I think the problem is that exynos_drm_init() is registering a normal
(non-OF) platform device, so the parent will be /sys/devices/platform.
It immediately gets bound against exynos_drm_platform_driver which
calls the exynos drm_platform_probe() hook. The driver core obtains
device_lock() on the device *and on the device parent*.

Inside the probe hook, additional platform_drivers get registered.
Each time one does, it tries to bind against every platform device in
the system, which includes the ones created by OF. When it attempts to
bind, it obtains device_lock() on the device *and on the device
parent*.

Before the change to move of-generated platform devices into
/sys/devices/platform, the devices had different parents. Now both
devices have /sys/devices/platform as the parent, so yes they are
going to deadlock.

The real problem is registering drivers from within a probe hook. That
is completely wrong for the above deadlock reason. __driver_attach()
will deadlock. Those registrations must be pulled out of .probe().

Registering devices in .probe() is okay because __device_attach()
doesn't try to obtain device_lock() on the parent."

 INFO: task swapper/0:1 blocked for more than 120 seconds.
       Not tainted 3.18.0-rc3-next-20141105 #794
 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 swapper/0       D c052534c     0     1      0 0x00000000
 [<c052534c>] (__schedule) from [<c0525b34>] (schedule_preempt_disabled+0x14/0x20)
 [<c0525b34>] (schedule_preempt_disabled) from [<c0526d44>] (mutex_lock_nested+0x1c4/0x464

 [<c0526d44>] (mutex_lock_nested) from [<c02be908>] (__driver_attach+0x48/0x98)
 [<c02be908>] (__driver_attach) from [<c02bcc00>] (bus_for_each_dev+0x54/0x88)
 [<c02bcc00>] (bus_for_each_dev) from [<c02bdce0>] (bus_add_driver+0xe4/0x200)
 [<c02bdce0>] (bus_add_driver) from [<c02bef94>] (driver_register+0x78/0xf4)
 [<c02bef94>] (driver_register) from [<c029e99c>] (exynos_drm_platform_probe+0x34/0x234)
 [<c029e99c>] (exynos_drm_platform_probe) from [<c02bfcf0>] (platform_drv_probe+0x48/0xa4)
 [<c02bfcf0>] (platform_drv_probe) from [<c02be680>] (driver_probe_device+0x13c/0x37c)
 [<c02be680>] (driver_probe_device) from [<c02be954>] (__driver_attach+0x94/0x98)
 [<c02be954>] (__driver_attach) from [<c02bcc00>] (bus_for_each_dev+0x54/0x88)
 [<c02bcc00>] (bus_for_each_dev) from [<c02bdce0>] (bus_add_driver+0xe4/0x200)
 [<c02bdce0>] (bus_add_driver) from [<c02bef94>] (driver_register+0x78/0xf4)
 [<c02bef94>] (driver_register) from [<c029e938>] (exynos_drm_init+0x70/0xa0)
 [<c029e938>] (exynos_drm_init) from [<c00089b0>] (do_one_initcall+0xac/0x1f0)
 [<c00089b0>] (do_one_initcall) from [<c074bd90>] (kernel_init_freeable+0x10c/0x1d8)
 [<c074bd90>] (kernel_init_freeable) from [<c051eabc>] (kernel_init+0x8/0xec)
 [<c051eabc>] (kernel_init) from [<c000f268>] (ret_from_fork+0x14/0x2c)
 3 locks held by swapper/0/1:
  #0:  (&dev->mutex){......}, at: [<c02be908>] __driver_attach+0x48/0x98
  #1:  (&dev->mutex){......}, at: [<c02be918>] __driver_attach+0x58/0x98
  #2:  (&dev->mutex){......}, at: [<c02be908>] __driver_attach+0x48/0x98

Changelog v2:
- call platform_driver_register after all kms and non kms drivers are
  registered
- rebased it to exynos-drm-next

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

Revert "drm/exynos: fix null pointer dereference issue"

This reverts commit cea24824ab432f8acabb254d6805e9aa756de6af.

Moving subdriver probe to exynos_drm_platform_probe() was making
exynos_drm_device_subdrv_probe() fail because the platform data wasn't set
yet. It only gets set in exynos_drm_load.

We need to find a smarter way to fix this issue.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/dpi: stop using display->ctx pointer

The patch replaces accesses to display->ctx pointer by container_of
construct. The field is removed as well as dpi was the last user of it.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/dpi: embed display into private context

exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dpi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple dpi devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/dp: stop using display->ctx pointer

The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/dp: embed display into private context

exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dp
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple dp devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/vidi: stop using display->ctx pointer

The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/vidi: embed display into private context

exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to vidi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple vidi devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/hdmi: stop using display->ctx pointer

The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/hdmi: embed display into private context

exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to hdmi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple hdmi devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/fimd: stop using manager->ctx pointer

The patch replaces accesses to manager->ctx pointer by container_of
construct. As fimd was the last user of ctx the patch removes
this field as well.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/fimd: embed manager into private context

exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple FIMD devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/vidi: stop using manager->ctx pointer

The patch replaces accesses to manager->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/vidi: embed manager into private context

exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to vidi private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple mixer devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/mixer: stop using manager->ctx pointer

The patch replaces accesses to manager->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/mixer: embed manager into private context

exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple mixer devices in the system.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>