In add_components_mdp, we parse the endpoints in MDP output ports
using the helper for_each_endpoint_of_node(). Our function calls
of_node_put() on the endpoint node before we iterate over the
next one. This is already done by the helper, and results in
trying to decrement the refcount twice.

Remove the extra of_node_put calls. This fixes warnings seen when
we try to insert the driver as a module on IFC6410.
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

The mode_config->max_{width,height} is for the maximum size of a fb, not
the max scanout limits (of the layer-mixer).  It is legal, and in fact
common, to create a larger fb, only only scan-out a smaller part of it.
For example multi-monitor configurations for x11, or android wallpaper
layer (which is created larger than the screen resolution for fast
scrolling by just changing the src x/y coordinates).
Signed-off-by: Rob Clark <robdclark@gmail.com>

If the dumpstate modparam is enabled, for debugging error irq's, also
dump SMP state.
Signed-off-by: Rob Clark <robdclark@gmail.com>

Signed-off-by: Rob Clark <robdclark@gmail.com>

Previously, SMP block allocation was not checked in the plane's
atomic_check() fxn, so we could fail allocation SMP block allocation at
atomic_update() time.  Re-work the block allocation to request blocks
during atomic_check(), but not update the hw until committing the atomic
update.

Since SMP blocks allocated at atomic_check() time, we need to manage the
SMP state as part of mdp5_state (global atomic state).  This actually
ends up significantly simplifying the SMP management, as the SMP module
does not need to manage the intermediate state between assigning new
blocks before setting flush bits and releasing old blocks after vblank.
(The SMP registers and SMP allocation is not double-buffered, so newly
allocated blocks need to be updated in kms->prepare_commit() released
blocks in kms->complete_commit().)
Signed-off-by: Rob Clark <robdclark@gmail.com>

(re)assign the hw pipes to planes based on required caps, and to handle
situations where we could not modify an in-use plane (ie. SMP block
reallocation).

This means all planes advertise the superset of formats and properties.
Userspace must (as always) use atomic TEST_ONLY step for atomic updates,
as not all planes may be available for use on every frame.

The mapping of hwpipe to plane is stored in mdp5_state, so that state
updates are atomically committed in the same way that plane/etc state
updates are managed.  This is needed because the mdp5_plane_state keeps
a pointer to the hwpipe, and we don't want global state to become out
of sync with the plane state if an atomic update fails, we hit deadlock/
backoff scenario, etc.  The use of state_lock keeps multiple parallel
updates which both re-assign hwpipes properly serialized.
Signed-off-by: Rob Clark <robdclark@gmail.com>

Add basic state duplication/apply mechanism.  Following commits will
move actual global hw state into this.

The state_lock allows multiple concurrent updates to proceed as long as
they don't both try to alter global state.  The ww_mutex mechanism will
trigger backoff in case of deadlock between multiple threads trying to
update state.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>

This will give the kms backends a slot to stash their own hw specific
global state.
Signed-off-by: Rob Clark <robdclark@gmail.com>

Split out the hardware pipe specifics from mdp5_plane.  To start, the hw
pipes are statically assigned to planes, but next step is to assign the
hw pipes during plane->atomic_check() based on requested caps (scaling,
YUV, etc).  And then hw pipe re-assignment if required if required SMP
blocks changes.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>

It wasn't really doing the right thing if, for example, position or
height changed.
Signed-off-by: Rob Clark <robdclark@gmail.com>

Signed-off-by: Rob Clark <robdclark@gmail.com>

Just use plane->name now that it is a thing.  In a following patch, once
we dynamically assign hw pipes to planes, it won't make sense to name
planes the way we do, so this also partly reduces churn in following
patch.
Signed-off-by: Rob Clark <robdclark@gmail.com>

We can do this all from mdp5_plane_complete_commit(), so simplify things
a bit and drop mdp5_plane_complete_flip().
Signed-off-by: Rob Clark <robdclark@gmail.com>

Plane's (pipes) can be assigned dynamically with atomic, so it doesn't
make much sense to name the pipe after it's primary plane.
Signed-off-by: Rob Clark <robdclark@gmail.com>

These are really plane-id's, not crtc-id's.  Only connection to CRTCs is
that they are used as primary-planes.

Current name is just legacy from when we only supported RGB/primary
planes.  Lets pick a better name now.
Signed-off-by: Rob Clark <robdclark@gmail.com>

We can have various combinations of 64b and 32b address space, ie. 64b
CPU but 32b display and gpu, or 64b CPU and GPU but 32b display.  So
best to decouple the device iova's from mmap offset.
Signed-off-by: Rob Clark <robdclark@gmail.com>

If fb dimensions are larger than what can be scanned out, but the src
dimensions are not, the hw can still handle this.  So clip.
Signed-off-by: Rob Clark <robdclark@gmail.com>

Signed-off-by: Rob Clark <robdclark@gmail.com>

Signed-off-by: Rob Clark <robdclark@gmail.com>

The same file in libdrm is, as is the tradition with the rest of libdrm,
etc, using an MIT license.  To avoid complications in the future with
sync'ing the uapi header to libdrm, lets fix the license mismatch now
before there are any non-trivial commits from someone other than myself.

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Gabriel Laskar <gabriel@lse.epita.fr>
Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>

Looks like cut/paste error from the other device cfgs (which do support
scaling on RGBn pipes).
Signed-off-by: Rob Clark <robdclark@gmail.com>

If the bottom-most layer is not fullscreen, we need to use the BASE
mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT).  The
blend_setup() code pretty much handled this already, we just had to
figure this out in _atomic_check() and assign the stages appropriately.

Also fix the case where there are zero enabled planes, where we also
need to enable BORDER_OUT.
Signed-off-by: Rob Clark <robdclark@gmail.com>

These updates:
* improve the robustness of the driver wrt races
* improve the compliance for sending infoframes and audio
* re-organise the function order in the driver to group like functions
  together.  (This unfortunately causes a conflict with the change in
  drm-misc, but it should be trivial to solve, although it looks more
  scarey than it really is - sfr has already sent two reports about
  this, one earlier today.)
* simplify tda998x_audio_get_eld and DPMS handling
* power down sections of the chip that we never use
* add some initial preparation for supporting the CEC driver

* 'drm-tda998x-devel' of git://git.armlinux.org.uk/~rmk/linux-arm:
  drm/i2c: tda998x: fix spelling mistake
  drm/i2c: tda998x: allow sharing of the CEC device accesses
  drm/i2c: tda998x: allow interrupt to be shared
  drm/i2c: tda998x: power down pre-filter and color conversion
  drm/i2c: tda998x: switch to boolean is_on
  drm/i2c: tda998x: remove complexity from tda998x_audio_get_eld()
  drm/i2c: tda998x: group audio functions together
  drm/i2c: tda998x: separate connector initialisation
  drm/i2c: tda998x: group connector functions and funcs together
  drm/i2c: tda998x: move and rename tda998x_encoder_set_config()
  drm/i2c: tda998x: correct function name in comments
  drm/i2c: tda998x: only enable audio if supported by sink
  drm/i2c: tda998x: only configure infoframes and audio if supported
  drm/i2c: tda998x: avoid race when programming audio
  drm/i2c: tda998x: avoid racy access to mode clock
  drm/i2c: tda998x: avoid race in tda998x_encoder_mode_set()
  drm/i2c: tda998x: move audio mutex initialisation

Building on top of the MALI change previously merged, these changes:
* add tracing support for overlay updates
* refactor some of the plane support code
* de-midlayer the driver
* cleanups from other folk reviewing the code

* 'drm-armada-devel' of git://git.armlinux.org.uk/~rmk/linux-arm:
  drm/armada: fix NULL pointer comparison warning
  drm/armada: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/armada: remove some dead code
  drm/armada: mark symbols static where possible
  drm/armada: de-midlayer armada
  drm/armada: use common helper for plane base address
  drm/armada: move setting primary plane position to armada_drm_primary_set()
  drm/armada: split out primary plane update
  drm/armada: move plane state to struct armada_plane
  drm/armada: clean up armada_drm_plane_work_run()
  drm/armada: add tracing support

hibmc drm driver for hisilicon.

* tag 'drm-hisilicon-next-2016-11-17' of http://github.com/zourongrong/linux:
  MAINTAINERS: Update HISILICON DRM entries
  drm/hisilicon/hibmc: Add support for vblank interrupt
  drm/hisilicon/hibmc: Add support for VDAC
  drm/hisilicon/hibmc: Add support for display engine
  drm/hisilicon/hibmc: Add support for frame buffer
  drm/hisilicon/hibmc: Add video memory management
  drm/hisilicon/hibmc: Add hisilicon hibmc drm master driver

Trivial fix to spelling mistake "configutation" to "configuration"
in dev_err message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

cec_read() is non-atomic in the presence of other I2C bus transactions
to the same device.  This presents a problem when we add support for
the TDA9950 CEC engine part - both drivers can be trying to access the
device.

Avoid the inherent problems by switching to i2c_transfer() instead,
which allows us to perform more than one bus transaction atomically.

As this means we will be using I2C transactions rather than SMBUS, we
have to check that the host supports I2C functionality.
Tested-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Some TDA998x contain several different I2C devices - there is the HDMI
encoder, and there is a TDA9950 CEC engine.  These two share the same
interrupt signal.

In order to allow a driver for the CEC engine to work, we need to be
able to share the interrupt with the CEC driver, so convert the handler
and registration to allow this to happen.
Tested-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Disabling the pre-filter block of the TDA998x saves 40mW and the colour
conversion block saves 15mW.  As we always disable these two blocks, we
can power these sections of the chip down to save 55mW of unnecessary
power consumption.
Tested-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Rather than storing the DPMS mode (which will always be on or off) use a
boolean to store this instead.
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

tda998x_audio_get_eld() is needlessly complex - the connector associated
with the encoder is always our own priv->connector.  Remove this
complexity, but ensure that there are no races when copying out the ELD.
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Group the TDA998x audio functions together rather than split between
two different locations in the file, keeping like code together.
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Separate out the connector initialisation from the rest of the drivers
initialisation.
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Group the TDA998x connector functions and funcs structures together
before the encoder support, rather than scattered amongst the rest of
the file.  This keeps like code together.
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

The naming of tda998x_encoder_set_config() is a left-over from when
TDA998x was a slave encoder.  Since this is part of the initialisation,
drop the _encoder from the name, and move it near tda998x_bind().
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Correct two references to tda998x_connector_get_modes() which were
incorrectly referring to tda998x_encoder_get_modes().
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Check for audio support by the attached sink by consulting the EDID
prior to enabling audio over the TMDS link.  We must consult the EDID
after calling drm_helper_probe_single_connector_modes(), as this can
use an override EDID, or load a replacement EDID.
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

The CEA 861B specification indicates the situations when we are able to
send each infoframe based on the version of the EDID's CEA extension.
Update the tda998x driver to follow the CEA specification wrt sending
of infoframes.

Since we only support the generation of AVI version 2, this limits us
to CEA extension version 3, so we treat CEA extension version 2 as
CEA 861 (no infoframes, no audio.)
Tested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Avoid a race between programming audio and an in-progress mode set.
A mode set is complex, and disables the ability to send infoframes
to the sink, and is disruptive to audio - we have to mute the audio
FIFO while doing a mode set.

If an attempt is made to start up the audio side, we will undo the
audio FIFO mute before the mode set has completed.

Move the lock so that we prevent audio interfering with an in-progress
mode set.
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Avoid a racy access to the mode clock by storing the current mode clock
during a mode set under the audio mutex.  This allows us to access it
from the audio path in a safe way.
Tested-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Jon Medhurst <tixy@linaro.org>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>