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>

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>

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

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>

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

Not entirely sure why this got bumped at all yet.

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>

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

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

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

Left-over from before a rework a while back.

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

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>

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>

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>

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>

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

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>

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

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

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>

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>

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>

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...

- 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

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>

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>

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>

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

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