If probe fails after IOMMU is attached, we need to detach in order to
clean up properly.  Before this change, IOMMU faults would occur if the
probe failed (-EPROBE_DEFER).
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

use mm.h definition

Cc: David Airlie <airlied@linux.ie>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The clock driver usually complains when a clock is being prepared
before setting its rate. It is the case here for "core_clk" which
needs to be set at 19.2 MHz before we attempt a prepare_enable().
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NRob Clark <robdclark@gmail.com>

This patch helps to avoid the following build issue:

drivers/gpu/drm/msm/msm_fbdev.c:108:2: error: passing argument 3 of 'msm_gem_get_iova_locked' from incompatible pointer type [-Werror]
   msm_gem_get_iova_locked(fbdev->bo, 0, &paddr);
   ^
In file included from drivers/gpu/drm/msm/msm_fbdev.c:18:0:
drivers/gpu/drm/msm/msm_drv.h:153:5: note: expected 'uint32_t *' but argument is of type 'dma_addr_t *'
  int msm_gem_get_iova_locked(struct drm_gem_object *obj, int id,
      ^
Signed-off-by: NMatwey V. Kornilov <matwey@sai.msu.ru>
Signed-off-by: NRob Clark <robdclark@gmail.com>

All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same
locking.  Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked().
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We want at least __GFP_WAIT, otherwise dma-mapping tries to use coherent
pool rather than CMA pool.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

Now that drm core knows about private planes, it cleans them up for us.
Trying to do this twice results in badness.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

To ease debugging, add debugfs file which can be cat/tail'd to log
submits, along with fence #.  If GPU hangs, you can look at 'gpu'
debugfs file to find last completed fence and current register state,
and compare with logged rd file to narrow down the DRAW_INDX which
triggered the GPU hang.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Architecture rename/split..  ARCH_QCOM is for the non-legacy platforms
(ie. device-tree, multiplatform support, etc).
Signed-off-by: NRob Clark <robdclark@gmail.com>

The hotplug detect and irq does not seem to be reliable on all devices
for some reason.  For now it is more reliable to use polling, and give
preference to raw gpio status if it disagrees with the debounced hpd
status.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

The hw cursor is relatively adept at triggering underflows, which
manifest as a "blue flash" (since blue is configured as the underflow
color).  Juggle a few things around to tighten up the timing for setting
cursor registers in DONE irq.

And most importantly, don't ever disable the hw cursor.  Instead flip it
to a blank/empty cursor.  This seems far more reliable, as even simply
clearing the cursor-enable bit (with no other updates in previous/
following frames) can in some cases cause underflow.

v1: original
v2: add missing locking spotted by Micah

Cc: Micah Richert <richert@braincorporation.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Since X11 is going to create an XR24 fb, if the pixel formats do not
match then crtc helpers will think it is a full modeset even if mode is
the same, which prevents smooth/flickerless handover from fbcon/plymouth
to X11.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NMicah Richert <richert@braincorporation.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Unfortunately this requires a drm-wide change, and I didn't see a sane
way around that. Luckily it's fairly simple, we just need to inline
the respective get_irq implementation from either drm_pci.c or
drm_platform.c.

With that we can now also remove drm_dev_to_irq from drm_irq.c.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC.  Replace all references to the CRTC fb with the
primary plane's fb.

This patch was generated by the Coccinelle semantic patching tool using
the following rules:

        @@ struct drm_crtc C; @@
        -   (C).fb
        +   C.primary->fb

        @@ struct drm_crtc *C; @@
        -   (C)->fb
        +   C->primary->fb

v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
    moved to a subsequent patch.

v2: Fixup several lingering crtc->fb instances that were missed in the
    first patch iteration.  [Rob Clark]
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

Use drm_universal_plane_init() and drm_crtc_init_with_planes() rather
than the legacy drm_plane_init() / drm_crtc_init().  This will ensure
that the proper primary plane is registered with the DRM (and eventually
exposed to userspace in future patches).

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Make things recover a bit more gracefully if we get stuck with no vblank
irq ever coming.
Signed-off-by: NRob Clark <robdclark@gmail.com>

After reading a nice article on LWN[1], I went back and double checked
my handling of invalid-input checking.  Turns out there were a couple
places I had missed.

Since the driver is fairly young, and the devices it supports are really
only just barely usable for basic stuff (serial console) with an
upstream kernel, I think we should fix this now and revert specific
parts of this patch later in the unlikely event that a regression is
reported.

[1] https://lwn.net/Articles/588444/Signed-off-by: NRob Clark <robdclark@gmail.com>

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

Some of the w/a or different behavior of userspace blob driver seem to
be keyed to gpu patch revision, rather than gpu-id.  So expose the full
chip-id to userspace so it can DTRT.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Shut down the clks when the gpu has nothing to do.  A short inactivity
timer is used to provide a low pass filter for power transitions.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Helper macro to simplify places where we need to poll with timeout
waiting for gpu.
Signed-off-by: NRob Clark <robdclark@gmail.com>

msm.hang_debug=y will dump out current register values if the gpu locks
up, for easier debugging.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

The ARCH_MSM depend is redundant with ARCH_MSM8960, so we can remove it.
Additionally, we are splitting Qualcomm MSM support into legacy (ARCH_MSM)
and multiplatform (ARCH_QCOM).  The MSM8960 with be ARCH_QCOM going forward
so dropping ARCH_MSM will work properly for the new ARCH_QCOM multiplatform
build.
Acked-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NKumar Gala <galak@codeaurora.org>

Because we use a list_head in the bo to track it's position in a submit,
we need to serialize at a higher layer.  Otherwise there are problems
when multiple contexts are SUBMIT'ing in parallel cmdstreams referencing
a shared bo.
Signed-off-by: NRob Clark <robdclark@gmail.com>

We already hold struct_mutex here.
Signed-off-by: NRob Clark <robdclark@gmail.com>

It seems we need to update all cursor registers from vblank.  This
appears to be the cause of intermittent underflows when enabling/
disabling cursor.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Backport a few fixes found in the course of getting mdp5 working.
There is a window of time after pageflip is requested, before we
start scanning out the new fb (ie. while we are waiting for gpu).
During that time we need to continue holding a reference to the
still-current scanout fb, to avoid the backing gem bo's from being
destroyed.

Possibly a common mdp_crtc parent class could be useful to share
some of this logic between mdp4_crtc and mdp5_crtc.  OTOH, this
all can be removed from the driver once atomic is in place, as
plane/crtc updates get deferred until all fb's are ready before
calling in to .page_flip(), etc.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

Small typo I noticed in the mdp4_plane code.. no consequence because
PIPE_SRC_XY and PIPE_DST_XY have same register layout.
Signed-off-by: NRob Clark <robdclark@gmail.com>

This was hidden in a generic void * dev->mm_private. But only ever
used for gem. But thanks to this fake generic pretension no one
noticed that Rob's drm drivers are now all broken.

So just give the offset manager a type pointer and fix up msm, omapdrm
and tilcdc.

v2: Fixup compile fail.

v3: Fixup rebase fail that David spotted.

Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add support for adreno 330.  Not too much different, just a few
differences in initial configuration plus setting OCMEM base.
Userspace support is already in upstream mesa.

Note that the existing DT code is simply using the bindings from
downstream android kernel, to simplify porting of this driver to
existing devices.  These do not constitute any committed/stable
DT ABI.  The addition of proper DT bindings will be a subsequent
patch, at which point (as best as possible) I will try to support
either upstream bindings or what is found in downstream android
kernel, so that existing device DT files can be used.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Add support for the new MDP5 display controller block.  The mapping
between parts of the display controller and KMS is:

  plane   -> PIPE{RGBn,VIGn}             \
  crtc    -> LM (layer mixer)            |-> MDP "device"
  encoder -> INTF                        /
  connector -> HDMI/DSI/eDP/etc          --> other device(s)

Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc.  (Ie. the
register interface is same, just different bases.)

Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.

And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: NRob Clark <robdclark@gmail.com>

The HDMI block is basically the same between older SoC's with mdp4
display controller, and newer ones with mdp5.

So mostly this consists of better abstracting out the different sets of
regulators, clks, etc.  In particular, for regulators and clks we can
split it up by what is needed for hot plug detect to work, and what is
needed to light up the display.

Also, 8x74 has a new phy.. a very simple one, but split out into a
different mmio space.  And with mdp5, the irq is shared with mdp, so we
don't directly register our own irq handler.
Signed-off-by: NRob Clark <robdclark@gmail.com>

We'll want basically the same thing for mdp5, so refactor it out so it
can be shared.
Signed-off-by: NRob Clark <robdclark@gmail.com>