DRM_MSM_FBDEV config is used to enable/disable fbdev emulation for the
msm kms driver.

Replace this with the top level DRM_FBDEV_EMULATION config option where
applicable. This also prevents build breaks caused by undefined
drm_fb_helper_* functions when legacy fbdev support was disabled.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

This change adds the basic MDP5 support for MSM8996.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In order to produce an image, the scalar needs to be fed extra
pixels. These top/bottom/left/right values depend on a various of
factors, including resolution, scaling type, phase step and
initial phase.

Pixel Extension are programmed by hardware in most targets - and
can be overwritten by software. For some targets (e.g.: msm8996),
software *must* program those registers.

In order to ease this computation, let's always use bilinear
filters, which are easier to program from kernel. Eventually,
all of these values will come down from user space for better
quality.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

When calculating phase steps, let's use the same enum
mdp_component_type in order to ease the readability; 0/1 indexes
are a bit confusing and we now have explicit values to index
this type of arrays.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The HDMI controller is new in MDP5 v1.7. As of now, this change
doesn't reflect the novelty and only adds the basics so the probe
gets triggered.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The current behavior is to try to get optional clocks and print a
dev_err message in case of failure. This looks rather confusing
and may increase with the amount of optional clocks.

We may need a cleaner way to handle per-device clocks but in the
meantime, let's reduce the amount of dev_err messages during the
probe.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

msm_iommu_new() can fail and this change makes sure that we
detect the failure and free the allocated domain before going
any further.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We want to make sure we control all the information being passed
down to SMP block. Having access to the cfg pointer here may create
bad things in the future.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The current settings for 28nm PHY data lane CFG4 registers do
not work with certain panels. This change is to modify them to
hw recommended values.
Signed-off-by: NHai Li <hali@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In some configurations the supplies are voltage switches and not LDOs,
making the set voltage call to fail. Check with the regulator framework
if the supply can change voltage before attempting.
Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

The R8A7794 DU has a fixed output routing configuration with one RGB
output per CRTC and thus lacks the RGB output routing register field.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R8A7793 DU is identical to the R8A7791 and thus only requires a new
DT compatible string.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Signed-off-by: NDerek Foreman <derekf@osg.samsung.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Keep the fbdev_cma pointer around so we can use it on hotplog and close
to ensure the frame buffer console is in a useful state.
Signed-off-by: NDerek Foreman <derekf@osg.samsung.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This is enough for fbcon and bringing up X using
xf86-video-modesetting.  It doesn't support the 3D accelerator or
power management yet.

v2: Drop FB_HELPER select thanks to Archit's patches.  Do manual init
    ordering instead of using the .load hook.  Structure registration
    more like tegra's, but still using the typical "component" code.
    Drop no-op hooks for atomic_begin and mode_fixup() now that
    they're optional.  Drop sentinel in Makefile.  Fix minor style
    nits I noticed on another reread.

v3: Use the new bcm2835 clk driver to manage pixel/HSM clocks instead
    of having a fixed video mode.  Use exynos-style component driver
    matching instead of devicetree nodes to list the component driver
    instances.  Rename compatibility strings to say bcm2835, and
    distinguish pv0/1/2.  Clean up some h/vsync code, and add in
    interlaced mode setup.  Fix up probe/bind error paths.  Use
    bitops.h macros for vc4_regs.h

v4: Include i2c.h, allow building under COMPILE_TEST, drop msleep now
    that other bugs have been fixed, add timeouts to cpu_relax()
    loops, rename hpd-gpio to hpd-gpios.
Signed-off-by: NEric Anholt <eric@anholt.net>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The plane reset handler frees the plane state and allocates a new
default state, but when doing so attempt to free the plane state using
the base plane state pointer instead of casting it to the
driver-specific state object that has been allocated. Fix it by using
the rcar_du_plane_atomic_destroy_state() function to destroy the plane
state instead of duplicating the code.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>

The DPAD RGB output can be driven by both DU0 and DU1 on R8A7791. Mark
the DU0 connection as possible.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The driver requires OF support, add a dependency in Kconfig and remove
the platform_device_id table that isn't used anymore.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>

Since commit a483dcbf ("ARM: shmobile: lager: Remove legacy
board support"), R-Car Gen2 SoCs are only supported in generic DT-only
ARM multi-platform builds.  The driver doesn't need to match platform
devices by name anymore, hence remove the corresponding
platform_device_id entry.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

In

commit bbb1e524
Author: Rob Clark <robdclark@gmail.com>
Date:   Tue Aug 25 15:35:58 2015 -0400

    drm/fb-helper: atomic restore_fbdev_mode()..

we've forgotten to do the plane->old_fb refcount dance for
pan_display_atomic, which can result in refcount leaks if the current
configuration is not from fbcon. Which apparently can happen when
vt-switching - fbcon does a pan first before a set_par.

OCD-align function parameters while at it.

v2: Actually git add the OCD.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92483Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445015490-27682-1-git-send-email-daniel.vetter@ffwll.chTested-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The point behind standardizing properties into core drm state
structures is also that internal code looks prettiers. Take advantage
of that and set rotation directly in the fbdev atomic code.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445012594-25988-1-git-send-email-daniel.vetter@ffwll.chAcked-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device
that returns without releasing mgr->lock, resulting a spew of kernel
messages about a kernel work function possibly having leaked a mutex
and presumably more serious adverse consequences later.  This patch
changes the error to "goto out" to unlock the mutex before returning.
Signed-off-by: NAdam J. Richter <adam_richter2004@yahoo.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of relying on the old crtc-{x,y,mode} gunk, dig out the primary
plane coordinates from the plane state when checking them against the
new framebuffer during page flip.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444930802-8515-5-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On atomic drivers we can dig out the primary plane rotation from the
plane state instead of looking at the legacy crtc->invert_dimensions
flag. The flag is not set by anyone except omapdrm, and it would be
racy to set it the same way in the atomic helpers.

v2: Kill crtc->invert_dimensions totally since omap is state based
    already and no one else ever used it (Matt)

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445009919-22746-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pull the plane src coordinate checks into a separate function so that we
can share them for the legacy and new stuff.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444930802-8515-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When converting the mode hdisplay/vdisplay to primary plane src
coordinates we need to take into account the current plane
rotation.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444930802-8515-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Compared to wrapping the final kref_put with dev->struct_mutex this
allows us to only acquire the offset manager look both in the final
cleanup and in the lookup. Which has the upside that no locks leak out
of the core abstractions. But it means that we need to hold a
temporary reference to the object while checking mmap constraints, to
make sure the object doesn't disappear. Extended the critical region
would have worked too, but would result in more leaky locking.

Also, this is the final bit which required dev->struct_mutex in gem
core, now modern drivers can be completely struct_mutex free!

This needs a new drm_vma_offset_exact_lookup_locked and makes both
drm_vma_offset_exact_lookup and drm_vma_offset_lookup unused.

v2: Don't leak object references in failure paths (David).

v3: Add a comment from Chris explaining how the ordering works, with
the slight adjustment that I dropped any mention of struct_mutex since
with this patch it's now immaterial ot core gem.

Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://mid.gmane.org/1444901623-18918-1-git-send-email-daniel.vetter@ffwll.chSigned-off-by: NDaniel Vetter <daniel.vetter@intel.com>

It's duplicating (without using some of the helpers) drm_gem_mmap with
the addition that it can redirect to drm-buf mmap support. But prime
import/export was dropped in

commit 990ed272
Author: Rob Clark <robdclark@gmail.com>
Date:   Thu May 21 11:58:30 2015 -0400

    drm/vgem: drop DRIVER_PRIME (v2)

for now, so this is dead code. And since I want to rework the locking
for drm_gem_mmap it seems simpler to de-dupe this code for now and
then start over with the reworked one again, if we want to resurrect
this all indeed.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://mid.gmane.org/1444894601-5200-8-git-send-email-daniel.vetter@ffwll.chAcked-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In its original version, drm_framebuffer_init() returned a negative int
if drm_mode_object_get() failed (f453ba04, "DRM: add mode setting
support").

This was accidentally disabled by commit 4b096ac1 ("drm: revamp
locking around fb creation/destruction"). Thus, drm_framebuffer_init()
pretends success if drm_mode_object_get() failed.

Reinstate the original behaviour. Also fix erroneous kernel-doc of
drm_mode_object_get().

Fixes: 4b096ac1 ("drm: revamp locking around fb creation/
    destruction")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just a random thing I spotted while reading code - better safe than
sorry.

Link: http://mid.gmane.org/1444894601-5200-11-git-send-email-daniel.vetter@ffwll.chReviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Since

commit 131e663b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 9 23:32:33 2015 +0200

    drm/gem: rip out drm vma accounting for gem mmaps

there is no need for this any more.

v2: Fixup compile noise spotted by 0-day build.

Link: http://mid.gmane.org/1444894601-5200-9-git-send-email-daniel.vetter@ffwll.chReviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Drop unused drm_atomic and fix comment for drm_debug.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a new debug class for _verbose_ debug message from the vblank code.
That is message we spew out potentially for every vblank interrupt.
Thierry already got annoyed at the spew, and now I managed to lock up
my box with these debug prints (seems serial console + a few debug
prints every vblank aren't a good combination).

Or should I maybe call it DRM_DEBUG_IRQ?

Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

String literals get concatenated just fine on their own,
no need to use '\'.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just one special case (since i915 lost its ums code, yay):
- radeon: Has slots for the old ums ioctls which don't have
  DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it
  everywhere.

Every other kms driver just has DRM_UNLOCKED for all their ioctls, as
they should.

v2: admgpu happened, include that one too. And i915 lost its UMS
support which means we can change all the i915 ioctls too.

v3: Rebased on top of new vmwgfx DX interface extensions.

v4: Rebase on top of render-node support in exynos.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the prep patches for i915 all kms drivers either have
DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
with an invariant return value when in modeset mode. But that's only
the case for i915 and radeon. The drm core ioctls are unfortunately
too much a mess still to dare this.

Follow-up patches will remove DRM_UNLOCKED from all kms drivers to
prove that this is indeed the case.

Also update the documentation.

v2: Really only do this for driver ioctls, spotted by David Herrmann.
And drop spurious whitespace change.

Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With kms all the data getparam looks at is actually invariant, and
certainly not protected by the global kms mutex. With ums all the
setup code is already racy as hell, so this won't make things any
worse.

I've done this change so that all ioctl still used by kms drivers
are marked as DRM_UNLOCKED, besides that we obviously don't need
it any more in kms mode.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>