Add support for the A5XX family of Adreno GPUs.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Disable the interrupt during the init sequence to avoid having
interrupts fired for errors and other things that we are not
ready to handle while initializing.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The adreno code inherited a silly workaround from downstream
from the bad old days before decent clock control. grp_clk[0]
(named 'src_clk') doesn't actually exist - it was used as a proxy
for whatever the core clock actually was (usually 'core_clk').

All targets should be able to correctly request 'core_clk' and
get the right thing back so zap the anachronism and directly
use grp_clk[0] to control the clock rate.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Add helper functions for TYPE4 and TYPE7 ME opcodes that replace
TYPE0 and TYPE3 starting with the A5XX targets.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Add a new generic function to write a "64" bit value. This isn't
actually a 64 bit operation, it just writes the upper and lower
32 bit of a 64 bit value to a specified LO and HI register.  If
a particular target doesn't support one of the registers it can
mark that register as SKIP and writes/reads from that register
will be quietly dropped.

This can be immediately put in place for the ringbuffer base and
the RPTR address.  Both writes are converted to use
adreno_gpu_write64() with their respective high and low registers
and the high register appropriately marked as SKIP for both 32 bit
targets (a3xx and a4xx). When a5xx comes it will define valid target
registers for the 'hi' option and everything else will just work.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Add some new functions to manipulate GPU registers.  gpu_read64 and
gpu_write64 can read/write a 64 bit value to two 32 bit registers.
For 4XX and older these are normally perfcounter registers, but
future targets will use 64 bit addressing so there will be many
more spots where a 64 bit read and write are needed.

gpu_rmw() does a read/modify/write on a 32 bit register given a mask
and bits to OR in.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

When the GPU hardware init function fails (like say, ME_INIT timed
out) return error instead of blindly continuing on. This gives us
a small chance of saving the system before it goes boom.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

There are very few register accesses in the common code. Cut down
the list of common registers to just those that are used.  This
saves const space and saves us the effort of maintaining registers
for A3XX and A4XX that don't exist or are unused.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Pull in a5xx registers.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Scratch registers move, annoyingly enough, in a5xx.  Move to
per-generation aNxx_recover() fxn.
Signed-off-by: NRob Clark <robdclark@gmail.com>

For backwards compat, the rd format puts the high 32b after the size
field in the GPUADDR packet.
Signed-off-by: NRob Clark <robdclark@gmail.com>

For a5xx the gpu is 64b so we need to change iova to 64b everywhere.  On
the display side, iova is still 32b so it can ignore the upper bits.
(Although all the armv8 devices have an iommu that can map 64b pa to 32b
iova.)
Signed-off-by: NRob Clark <robdclark@gmail.com>

Previous value really only made sense on armv7 without LPAE.  Everything
that supports more than 4g of memory also has iommu's that can map
anything.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob 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: NRob Clark <robdclark@gmail.com>

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

Signed-off-by: NRob 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: NRob 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: NRob 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: NRob Clark <robdclark@gmail.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>

This will give the kms backends a slot to stash their own hw specific
global state.
Signed-off-by: NRob 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: NRob Clark <robdclark@gmail.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>

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

Signed-off-by: NRob 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: NRob 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: NRob 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: NRob 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: NRob 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: NRob 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: NRob Clark <robdclark@gmail.com>

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

Signed-off-by: NRob 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: NRob Clark <robdclark@gmail.com>
Acked-by: NEmil 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: NRob 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: NRob 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: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NRussell 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: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NBrian Starkey <brian.starkey@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>