Disable the HPD interrupt when acking it, to avoid spurious
interrupt.
Signed-off-by: NJilai Wang <jilaiw@codeaurora.org>

HPD regulators need to be enabled before clocks, otherwise clock
driver will report warning.
Signed-off-by: NJilai Wang <jilaiw@codeaurora.org>

If crtc <-> encoder linkage changes, we could end up with the CRTC
listening for the wrong error or vsync irqs.  Generally this problem
would correct itself relatively quickly, since we update the global
irqmask after dispatching irqs, but to be sure let the CRTC trigger
update_irq().
Signed-off-by: NRob Clark <robdclark@gmail.com>

We can't have multiple updates pending on a given CRTC, and we don't
want a sync update to race w/ an async update that preceeded it.  So
keep track of which CRTCs have updates in flight, and block later
updates that would conflict.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Useful since this way we can pass around just the state objects and
will get ther real object, too.

Specifically this allows us to again simplify the parameters for
set_crtc_for_plane.

v2: msm already has it's own specific plane_reset hook, don't forget
that one!

v3: Fixup kerneldoc, reported by 0-day builder.

Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com> (v2)
Tested-by: Rob Clark <robdclark@gmail.com> (v2)
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This essentially reverts

commit 934ce1c2
Author: Rob Clark <robdclark@gmail.com>
Date:   Wed Nov 19 16:41:33 2014 -0500

    drm/atomic: check mode_changed *after* atomic_check

Depending upon the driver both orders (or maybe even interleaving) is
required:
- If ->atomic_check updates ->mode_changed then helper_check_modeset
  must be run afters.
- If ->atomic_check depends upon accurate adjusted dotclock values for
  e.g. watermarks, then helper_check_modeset must be run first.

The failure mode in the first case is usually a totally angry hw
because the pixel format switching doesn't happen. The failure mode in
the later case is usually nothing, since in most cases the old
adjusted mode from the previous modeset wont be too far off to be a
problem. So just underruns and perhaps even just suboptimal (from a
power consumption) watermarks.

Furthermore in the transitional helpers we only call ->atomic_check
after the new modeset state has been fully set up (and hence
computed).

Given that asymmetry in expected failure modes I think it's safer to
go back to the older order. So do that and give msm a special check
function to compensate.

Also update kerneldoc to explain this a bit.

v2: Actually add the missing hunk Rob spotted.

v3: Move msm_atomic_check into msm_atomic.c, requested by Rob.

Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Tested-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

The release_firmware() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The functions framebuffer_release() and vunmap() perform also input
parameter validation. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The ->load_lut() callback is optional, therefore a dummy implementation
is not needed.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In most situations it will be useful to have the old state passed to the
->atomic_update() callback. For example if a plane is being disabled the
new state's .crtc field will be NULL, but some drivers may rely on this
field to program the CRTCs registers.

v2: rename variable to old_plane_state and remove redundant comment as
suggested by Daniel Vetter, remove an Exynos hunk that doesn't apply to
drm-next and add a hunk for pending MSM mdp5 changes
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On mdp4 there is a single global LAYERMIXER_IN_CFG register.  The
previous logic to share that between multiple crtcs didn't actually
handle plane-disable very well.  Easier just to look at all of the
crtcs each time.
Signed-off-by: NRob Clark <robdclark@gmail.com>

When disabling the interface (INTF), the change doesn't latch until next
vblank, so we need to wait for vblank.

Also, to be pedantic, in the crtc, set all the mixer stages to unused.
It shouldn't really matter, since at this point we have already disabled
the INTF and waited for necessary vblank.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Convert mdp5 over to atomic helpers.  Extend/wrap drm_plane_state to
track plane zpos and to keep track of the needed when applying the
atomic update.  In mdp5's plane->atomic_check() we also need to check
for updates which require SMP reallocation, in order to trigger full
modeset.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Fixes for a couple little issues found in testing.
Signed-off-by: NRob Clark <robdclark@gmail.com>

A bit cleaner.. and won't resulting in an attempt to kfree() a static
global in unload path.
Signed-off-by: NRob Clark <robdclark@gmail.com>

For example, use 'struct mdp5_smp *' everywhere instead of 'void *', but
only declare it as 'struct mdp5_smp;' in common headers, so the struct
body is still private.  The accomplishes the desired modularity while
still letting the compiler provide some type checking for us.
Signed-off-by: NRob Clark <robdclark@gmail.com>

MDP5 currently support one single CRTC with its private pipe.
This change allows the configuration of multiple CRTCs with
the possibility to attach several public planes to these CRTCs.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Set a "safe" rate at first, in order to read out the hw revision.  And
then after set the optimal value.
Signed-off-by: NRob Clark <robdclark@gmail.com>

The hardware configuration modification from a version to another
is quite consequent. Introducing a configuration module
(mdp5_cfg) may make things more clear and easier to access when a
new hardware version comes up.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The Shared Memory Pool (SMP) has its own limitation, features and
state. Some examples are:
 - the number of Memory Macro Block (MMB) and their size
 - the number of lines that can be fetched
 - the state of MMB currently allocated
 - the computation of number of blocks required per plane
 - client IDs ...

In order to avoid private data to be overwritten by other modules,
let's make these private to the SMP module.

Some of these depend on the hardware configuration, let's add them
to the mdp5_config struct.

In some hw configurations, some MMBs are statically tied to RGB
pipes and cannot be re-allocated dynamically. This change
introduces the concept of MMB static usage and makes sure that
dynamic MMB requests are dimensioned accordingly.

A note on passing a pipe pointer, instead of client IDs:
Client IDs are SMP-related information. Passing PIPE information
to SMP lets SMP module to find out which SMP client(s) are used.
This allows the SMP module to access the PIPE pointer, which can
be used for FIFO watermark configuration.
By the way, even though REG_MDP5_PIPE_REQPRIO_FIFO_WM_* registers
are part of the PIPE registers, their functionality is to reflect
the behavior of the SMP block. These registers access is now
restricted to the SMP module.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

A left-over from prior to component framework.  The original intent was
to deal with hdmi getting unloaded before the master component, but that
isn't really going to work anyways.  These days with the component
framework taking care to unload the master component first, we don't
have to worry about this.
Signed-off-by: NRob Clark <robdclark@gmail.com>

The core clock rate depends on the hw configuration. Once we have
read the hardware revision, we can set the core clock to its
maximum value.
Before then, the clock is set at a rate supported by all MDP5
revisions.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

For mdp5, the irqs of hdmi/eDP/dsi0/dsi1 blocks get routed through the
mdp block.  In order to decouple hdmi/eDP/etc, register an irq domain
in mdp5.  When hdmi/dsi/etc are used with mdp4, they can directly setup
their irqs in their DT nodes as normal.  When used with mdp5, instead
set the mdp device as the interrupt-parent, as in:

	mdp: qcom,mdss_mdp@fd900000 {
		compatible = "qcom,mdss_mdp";
		interrupt-controller;
		#interrupt-cells = <1>;
		...
	};

	hdmi: qcom,hdmi_tx@fd922100 {
		compatible = "qcom,hdmi-tx-8074";
		interrupt-parent = <&mdp>;
		interrupts = <8 0>;   /* MDP5_HW_INTR_STATUS.INTR_HDMI */
		...
	};

There is a slight awkwardness, in that we cannot disable child irqs
at the mdp level, they can only be cleared in the child block.  So
you must not use threaded irq handlers in the child.  I'm not sure
if there is a better way to deal with that.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Added a4xx GPU support.
Signed-off-by: NAravind Ganesan <aravindg@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Register offsets have changed between a3xx and a4xx GPUs.
To be able access these registers in common code, we create
a lookup table, and set of read-write APIs to access the
register through the lookup table.
Signed-off-by: NAravind Ganesan <aravindg@codeaurora.org>
[robclark: remove REG_ADRENO_UNDEFINED, just use zero, and minor
tweaks for latest generated headers]
Signed-off-by: NRob Clark <robdclark@gmail.com>

Use pre-computed iova when unmapping, to reduce the places we assume iova
and mmap offset are (at the moment) the same.  And get rid of an extra
drm_gem_free_mmap_offset() call (since it is already called from
drm_gem_object_release())
Signed-off-by: NRob Clark <robdclark@gmail.com>

Convert mdp4 display controller backend to atomic helpers.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

The core parts for async commit.
Signed-off-by: NRob Clark <robdclark@gmail.com>

It's a problem that can't happen yet, since we don't support any
multi-planar formats yet.  But let's avoid nasty surprises when the
time comes.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Atomic wants to split the prepare/pin from where we actually program the
scanout address (so that any part that can fail is done synchronously).
Add some fb/gem apis to make this easier to use from the kms parts.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

Give ourselves a way to wait for certain fence #..  makes it easier to
wait on a set of bo's, which we'll need for atomic.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Simplify things a bit for atomic, gets rid of some bookkeeping, and
makes the code cleaner.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Simplify things a bit for atomic, gets rid of some bookkeeping, and
makes the code cleaner.

TODO move iterator macro somewhere common.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Since we are configuring things via MDP4_PIPE regs in the plane, it seems
like setting the dimensions of the primary plane on the OVLP/DMA regs in
crtc is unnecessary.  This will make life easier when we want to do a
nofb modeset.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Since primary-plane support in core, we can just use crtc->primary.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Since primary-plane support in core, we can just use crtc->primary.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Currently forcing the video mode from the kernel command line (for example
video=HDMI-A-1:1280x720-16@60) does not correctly set the number of bits
per pixel. This is due to a rather aggressive override in
msm_fbdev_create(). This is a particular problem for Android bring up
because the software EGL fallbacks don't support 32bpp.

Since the overrides are actually the default values anyway then this
problem can be trivially fixed by removing the overrides completely.

Change was tested by dd'ing a test image to /dev/fb0 with no video=
(still 32bpp), video=1920x1080-32@60, video=1920x1080-24@60 and
video=1920x1080-16@60 .
Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>