The hardware requires all planes to have an identical pitch in number of
pixels. Given that all supported formats use the same number of bytes
per pixel in all planes, framebuffer creation checks can be simplified.
The implementations assumes that no format use more than two planes
which is true with the existing hardware.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Merge the single-user objects_lookup inline function into its caller,
allowing reuse of the error code path.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The driver stores in a custom structure named format several pieces of
information about the format that are available in the DRM core. Remove
them and get the information from the DRM core instead.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The only multi-planar format supported by the driver is NV12, there will
thus never be more than two planes per framebuffer.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Only property creation uses the rotation as an index, so convert the
to figure the index when needed.

v2: Use the new defines to build the _MASK defines (Sean)

Cc: intel-gfx@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: malidp@foss.arm.com
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469771405-17653-1-git-send-email-joonas.lahtinen@linux.intel.com

The following functions test whether their argument is NULL and then
return immediately.
* backlight_device_unregister
* drm_gem_object_unreference_unlocked

Thus the test around the calls is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/72ff4670-4f3d-c7ed-4f37-e49f2bbc7aba@users.sourceforge.net

The function is never used, remove it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

It's an optional hook.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-23-git-send-email-daniel.vetter@ffwll.ch

The omapdrm driver relies on this header to be included
implicitly, but this does not always work, and I get
this error in randconfig builds:

gpu/drm/omapdrm/dss/hdmi_phy.c: In function 'hdmi_phy_dump':
gpu/drm/omapdrm/dss/hdmi_phy.c:34:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration]
gpu/drm/omapdrm/dss/hdmi_wp.c: In function 'hdmi_wp_dump':
gpu/drm/omapdrm/dss/hdmi_wp.c:26:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration]
gpu/drm/omapdrm/dss/hdmi_pll.c: In function 'hdmi_pll_dump':
gpu/drm/omapdrm/dss/hdmi_pll.c:30:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration]

This adds the #include statements in all files that have
a seq_printf statement.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

drm_gem_object_lookup() has never required the drm_device for its file
local translation of the user handle to the GEM object. Let's remove the
unused parameter and save some space.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: dri-devel@lists.freedesktop.org
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Fixup kerneldoc too.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

omapdrm is missing a check on the validity of the rotation property.
This leads to omapdrm possibly trying to use rotation on non-rotateable
framebuffer, which causes the overlay setup to fail.

This patch adds the necessary check to omap_plane_atomic_check().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The DSS hardware uses the same ROW_INC value for both Y and UV planes
for NV12 format. This means that the pitches of the Y and UV planes have
to match. omapdrm doesn't check this at the moment, and this can lead
into a broken NV12 fb on the screen.

This patch adds the check.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Drivers shouldn't clobber the passed in addfb ioctl parameters.
i915 was doing just that. To prevent it from happening again,
pass the struct around as const, starting all the way from
internal_framebuffer_create().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Avoid magic numbers and use the introduced defines.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

omap_framebuffer_unpin() check the return value of omap_gem_put_paddr()
and return immediately if omap_gem_put_paddr() fails.

This patch removes the check for the return value, and also removes the
return value of omap_framebuffer_unpin(), because:

 * Nothing checks the return value of omap_framebuffer_unpin(), and even
   something did check it, there's nothing the caller can do to handle
   the error.

 * If a omap_gem_put_paddr() fails, the framebuffer's other planes will
   be left unreleased. So it's better to call omap_gem_put_paddr() for
   all the planes, even if one would fail.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Before atomic modesetting omap_framebuffer_pin() and
omap_framebuffer_unpin() were always called with modesetting locks
taken. With atomic modesetting support this is no longer the case, and
we need locking to protect the pin_count and the paddr, as multiple
threads may pin the same fb concurrently.

This patch adds a mutex to struct omap_framebuffer, and uses it in
omap_framebuffer_pin() and omap_framebuffer_unpin().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Use the <...> include style instead of "..." for DRM headers and sort
the headers alphabetically to ease detection of duplicates.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapdrm doesn't check if the pitch of the framebuffer and the color
format's bits-per-pixel are compatible. omapdss requires that the stride
of a buffer is an integer number of pixels

For example, when using modetest with a display that has x resolution of
1280, and using packed 24 RGB mode (3 bytes per pixel), modetest
allocates a buffer with a byte stride of 4 * 1280 = 5120. But 5120 / 3 =
1706.666... pixels, which causes wrong colors and a tilt on the screen.

Add a check into omapdrm to return an error if the user tries to use
such a combination.

Note: this is not a HW requirement at least for non-rotation use cases,
but a SW driver requirement. In the future we should study if also
rotation use cases are fine with any stride size, and if so, change the
driver to allow these strides.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When an error happens in omap_framebuffer_create(),
omap_framebuffer_create() calls omap_framebuffer_destroy() if the fb
struct has been allocated. However, that crashes, as
omap_framebuffer_destroy(), which calls drm_framebuffer_cleanup(),
should only be called after drm_framebuffer_init()

Fix this by just calling kfree() for the allocated fb when an error
happens.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omap_framebuffer_pin() and omap_framebuffer_unpin() are currently
broken, as they cannot be called multiple times (i.e. pin, pin, unpin,
unpin), which is what happens in certain cases. This issue causes the
driver to possibly use 0 as an address for a displayed buffer, leading
to OCP error from DSS.

This patch fixes the issue by adding a simple pin_count, used to track
the number of pins.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

All the manual update display code implements eventually ends up to just
calls to omap_connector_flush(), currently implemented as an empty TODO
stub. Remove it, the code can always be revived and implemented later if
interest in manual update displays becomes a reality.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
  properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
  modeset-relevant connector state (e.g. properties which control the
  panel fitter).

The later is used by modeset operations. But they don't really care
about the former since it's allowed to e.g. enable a disconnected VGA
output or with a mode not in the probed list.

Thus far this hasn't been a problem, but for the atomic modeset
conversion Rob Clark needs to convert all modeset relevant locks into
w/w locks. This is required because the order of acquisition is
determined by how userspace supplies the atomic modeset data. This has
run into troubles in the detect path since the i915 load detect code
needs _both_ protections offered by the mode_config.mutex: It updates
probe state and it needs to change the modeset configuration to enable
the temporary load detect pipe.

The big deal here is that for the probe/detect users of this lock a
plain mutex fits best, but for atomic modesets we really want a w/w
mutex. To fix this lets split out a new connection_mutex lock for the
modeset relevant parts.

For simplicity I've decided to only add one additional lock for all
connector/encoder links and modeset configuration states. We have
piles of different modeset objects in addition to those (like bridges
or panels), so adding per-object locks would be much more effort.

Also, we're guaranteed (at least for now) to do a full modeset if we
need to acquire this lock. Which means that fine-grained locking is
fairly irrelevant compared to the amount of time the full modeset will
take.

I've done a full audit, and there's just a few things that justify
special focus:
- Locking in drm_sysfs.c is almost completely absent. We should
  sprinkle mode_config.connection_mutex over this file a bit, but
  since it already lacks mode_config.mutex this patch wont make the
  situation any worse. This is material for a follow-up patch.

- omap has a omap_framebuffer_flush function which walks the
  connector->encoder->crtc links and is called from many contexts.
  Some look like they don't acquire mode_config.mutex, so this is
  already racy. Again fixing this is material for a separate patch.

- The radeon hot_plug function to retrain DP links looks at
  connector->dpms. Currently this happens without any locking, so is
  already racy. I think radeon_hotplug_work_func should gain
  mutex_lock/unlock calls for the mode_config.connection_mutex.

- Same applies to i915's intel_dp_hot_plug. But again, this is already
  racy.

- i915 load_detect code needs to acquire this lock. Which means the
  w/w dance due to Rob's work will be nicely contained to _just_ this
  function.

I've added fixme comments everywhere where it looks suspicious but in
the sysfs code. After a quick irc discussion with Dave Airlie it
sounds like the lack of locking in there is due to sysfs cleanup fun
at module unload.

v1: original (only compile tested)

v2: missing mutex_init(), etc (from Rob Clark)

v3: i915 needs more care in the conversion:
- Protect the edp pp logic with the connection_mutex.
- Use connection_mutex in the backlight code due to
  get_pipe_from_connector.
- Use drm_modeset_lock_all in suspend/resume paths.
- Update lock checks in the overlay code.

Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRob Clark <robdclark@gmail.com>

Print a warning when the user tries to rotate a non-TILER framebuffer.

Also set the rotation to 0, to avoid constant flood of the warnings in
case of page flipping.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

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>

The connectors list iterator returns the list head when the list is
empty. Fix it by returning NULL in that case.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Not all drivers will need take all the modeset locks for dirtyfb, so
push the locking down to the drivers.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

And simplify how we hold a ref+pin to what is being scanned out by using
fb refcnt'ing.  The previous logic pre-dated fb refcnt, and as a result
was less straightforward than it could have been.  By holding a ref to
the fb, we don't have to care about how many plane's there are and
holding a ref to each color plane's bo.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Now that the omapdss interface has been reworked so that omapdrm can use
dispc directly, we have been able to fix the remaining functional kms
issues with omapdrm.  And in the mean time the PM sequencing and many
other of that open issues have been solved.  So I think it makes sense
to finally move omapdrm out of staging.
Signed-off-by: NRob Clark <robdclark@gmail.com>

alloc failures already get standardized OOM
messages and a dump_stack.

For the affected mallocs around these OOM messages:

Converted kzallocs with multiplies to kcalloc.
Converted kmallocs with multiplies to kmalloc_array.
Converted a kmalloc/strlen/strncpy to kstrdup.
Moved a spin_lock below a removed OOM message and
removed a now unnecessary spin_unlock.
Neatened alignment and whitespace.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With more fine-grained locking we can no longer rely on the big
mode_config lock to prevent concurrent access to mode resources
like framebuffers. Instead a framebuffer becomes accessible to
other threads as soon as it is added to the relevant lookup
structures. Hence it needs to be fully set up by the time drivers
call drm_framebuffer_init.

This patch here is the drivers part of that reorg. Nothing really fancy
going on safe for three special cases.

- exynos needs to be careful to properly unref all handles.
- nouveau gets a resource leak fixed for free: one of the error
  cases didn't cleanup the framebuffer, which is now moot since
  the framebuffer is only registered once it is fully set up.
- vmwgfx requires a slight reordering of operations, I'm hoping I didn't
  break anything (but it's refcount management only, so should be safe).

v2: Split out exynos, since it's a bit more hairy than expected.

v3: Drop bogus cirrus hunk noticed by Richard Wilbur.

v4: Split out vmwgfx since there's a small change in return values.

Reviewed-by: Rob Clark <rob@ti.com> (core + omapdrm)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The following warnings fixed.
- WARNING: braces {} are not necessary for single statement blocks
Signed-off-by: NYAMANE Toshiaki <yamanetoshi@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When the fb is detached from one CRTC/plane, paddr was set back to
zero.  But really we don't want to do this because the fb could still
be attached to other CRTC/plane(s).  This originally worked like this
to catch cases of freeing a pinned fb (but with the refcnt'ing this
should no longer be needed).  Also, there is checking in the GEM code
for freeing a pinned GEM object, so this extra level of checking is
redundant.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use tiled buffers for rotated/reflected scanout, with CRTC and plane
properties as the interface for userspace to configure rotation.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for mmap'ing buffers via dmabuf.  For handling mmap of
cached buffers correctly, fault handling and PTE shootdown are used
to track dirty pages and automagically handle cache flushes before
dma access to the buffer.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The below patch fixes some typos that I found while reading.  Note: I
was told to hold off sending anything until *rc1 so hopefully now its
alright.(wasnt sure what kernel *rc*)
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Reviewed-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add some additional debugfs file to aid in tracking buffer usage.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When flipping, defer unpinning until scanout completes, as indicated
by the appropriate END_WIN irq.

This also re-organizes things a bit, in replacing omap_fb_{pin,unpin}
with omap_fb_replace(), to make it easier to add support for scanout
synchronized DMM refill mode (flipping by just reprogramming DMM
synchronized with DSS scanout).
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that 'struct drm_plane' has a pixel_format field, use that.  And
fix a minor typo.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Get the supported formats for a plane from ovl's supported_modes
bitmask.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support in framebuffer objects for other color formats and multi-
planar YUV (NV12).  Since this requires changing the API between the
plane and fb for getting scanout information (paddr, etc), take
advantage of the opportunity and put in place a way to allow fb's to
be unpinned when they are not being scanned out.  Now, before start
of scanout the plane calls omap_framebuffer_pin() which takes care
to pin all the backing bo's, then omap_framebuffer_update_scanout()
however many times to update the scanout address(es), etc, and then
when finished omap_framebuffer_unpin().
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>