OMAP DSS hardware supports changing the output port to which an overlay
manager's video stream goes. For example, DPI video stream can come from
any of the four overlay managers on OMAP5.

However, as it's difficult to manage the change in the driver, the
omapdss driver does not support that at the moment, and has a hardcoded
overlay manager per output.

omapdrm, on the other hand, uses the hardware features to find out which
overlay manager to use for an output, which causes problems. For
example, on OMAP5, omapdrm tries to use DIGIT overlay manager for DPI
output, instead of the LCD3 required by the omapdss driver.

This patch changes the omapdrm to use the omapdss driver's hardcoded
overlay managers, which fixes the issue.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

The next commit will need functions to be reordered. Do it separately to
help review.

This only moves functions without any change to the code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Planes are destroyed after framebuffers, which has the side effect of
disabling all planes. There is thus no need to disable planes explicitly
when destroying them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

The function will convert the Q16 source coordinates to integers, avoid
converting integers to Q16 first and perform the opposite conversion.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

This matches the rest of the file and clarifies the functions' purpose.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Move the set_enabled function to avoid the forward declaration. While at
it prefix it with omap_crtc_ like most other functions in the file, and
fix the comment stating in which contexts the function is called.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

The full_update field is always set to true before calling
omap_crtc_appy(), resulting in its value always being true in the single
location where it is tested, in omap_crtc_pre_apply(). Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

The vblank interrupt is used by the driver as a completion signal when
applying new settings.

A race condition exist between enabling the vblank interrupt and
applying new settings to the hardware by setting the GO bit. If a vblank
interrupt occurs in-between, the driver will incorrectly consider the
new settings to be applied. Fix this by enabling the interrupt after
setting the GO bit.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Whether to reset plane properties at disable time isn't well-defined in
DRM, but resetting only part of them is probably as bad as it can get.
Make the behaviour coherent by resetting the zorder property in addition
to the rotation property.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

The planes don't care about DPMS states, don't propagate it
unnecessarily to the plane functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Remove the CRTC private planes by switching to the universal plane API.
This results in a merge of the CRTC private plane created by the driver
(omap_crtc->plane) and the CRTC primary plane created by the DRM core
(crtc->primary).

Reference counting of the framebuffers in the update plane operation is
thus simplified as no reference needs to be stored in the private plane
anymore.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

The ilace variable is unused and the replication variable is assigned to
false and just passed to a function. Remove them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Create a omap_modeset_create_crtc() function to avoid duplicating plane
and CRTC creation code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Indenting by one tab is enough.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

rockchip fixes.

* 'drm_next' of https://github.com/markyzq/kernel-drm-rockchip:
  drm/rockchip: vop: power off until vop standby take effect
  drm/rockchip: vop: set vop enabled after enable iommu
  drm/rockchip: vop use is_enabled instead of dpms mode
  drm/rockchip: vop: fix vop vsync/hsync polarity
  drm/rockchip: Only alloc a kmap for fbdev gem object

Another drm-misch pull request. Mostly the fbdev sizes deconfusion series
from Rob, everything else is small stuff all over. And the large i2c over
aux transfers patch, too.

* tag 'topic/drm-misc-2015-03-18' of git://anongit.freedesktop.org/drm-intel:
  drm: check that planes types are correct while initializing CRTC
  drm: change connector to tmp_connector
  drm: Fix some typo mistake of the annotations
  drm: Silence sparse warnings
  drm: %pF is only for function pointers
  drm/fb: handle tiled connectors better
  drm/fb: small cleanup
  drm/rockchip: use correct fb width/height
  drm/exynos: use correct fb width/height
  drm/cma: use correct fb width/height
  drm/atomic: minor kerneldoc typo fix
  drm/fb: document drm_fb_helper_surface_size
  drm/dp: Use large transactions for I2C over AUX
  drm/plane-helper: Fixup mismerge
  drm/atomic: Constify a bunch of functions pointer structs

Be warned if primary or cursor planes haven't the correct type
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This wasn't too harmful since we already look at connector,
which has the same effect as the loop for any non-cloned configs.
Only when we have a cloned configuration is it important to look
at other connectors. Furthermore existing userspace always changes
dpms on all of them anyway.
Signed-off-by: JohnHunter <zhjwpku@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

There are some mistakes that the function name in the annotaions
is not matching the real function name.
And some duplication word in annotations
Signed-off-by: John Hunter <zhjwpku@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Vop standby will take effect at end of current frame,
if dsp_hold_valid_irq happen, it means vop standby complete.

we must wait standby complete when we want to disable aclk,
if not, memory bus maybe dead.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

there is a Bug that:
  vop_enable()->drm_vblank_on, drm_vblank_on may call vop
enable vblank. if it happen, vblank enable would failed,
then cause irq status error. because is_enabled value is set
after drm_vblank_on.

after enable vop clocks and iommu regs, we can sure that
R/W vop regs and do vop plane flip is safe, so place
is_enabled = true after enable iommu is suitable.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm dpms have many power modes: ON,OFF,SUSPEND,STANDBY, etc.
but vop only have enable/disable mode, maybe case such bug:
 --> DRM_DPMS_ON: power on vop
 --> DRM_DPMS_SUSPEND: power off vop
 --> DRM_DPMS_OFF: already power off at SUSPEND, crash
so use a bool val is more suitable.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

Vop set wrong vsync/hsync polarity, it may cause some
display problem. known problem is that caused HDMI hdcp
authenticate failed, caused pixel offset with hdmi display.
the polarity description at RK3288 TRM doc:
  dsp_vsync_pol
    VSYNC polarity
      1'b0 : negative
      1'b1 : positive
      dsp_hsync_pol
    HSYNC polarity
      1'b0 : negative
      1'b1 : positive
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>

In general, the data in drm/rockchip GEM objects is never accessed by
the kernel.  The objects are either accessed by a GPU, by display
controller DMA, or by mmap'ing them to user space.  Thus, these
buffers need not be mapped into kernel address space.

The only exception is the fbdev framebuffer(s), which may be written
in-kernel by fbcon.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

../drivers/gpu/drm/drm_vm.c:405:6: warning: symbol 'drm_vm_open_locked' was not declared. Should it be static?
../drivers/gpu/drm/drm_vm.c:431:6: warning: symbol 'drm_vm_close_locked' was not declared. Should it be static?
../drivers/gpu/drm/drm_vm.c:681:5: warning: symbol 'drm_vma_info' was not declared. Should it be static?

../drivers/gpu/drm/drm_pci.c:146:5: warning: symbol 'drm_pci_set_unique' was not declared. Should it be static?
../drivers/gpu/drm/drm_pci.c:216:5: warning: symbol 'drm_irq_by_busid' was not declared. Should it be static?

../drivers/gpu/drm/drm_info.c:47:5: warning: symbol 'drm_name_info' was not declared. Should it be static?
../drivers/gpu/drm/drm_info.c:72:5: warning: symbol 'drm_vm_info' was not declared. Should it be static?
../drivers/gpu/drm/drm_info.c:116:5: warning: symbol 'drm_bufs_info' was not declared. Should it be static?
../drivers/gpu/drm/drm_info.c:159:5: warning: symbol 'drm_clients_info' was not declared. Should it be static?
../drivers/gpu/drm/drm_info.c:209:5: warning: symbol 'drm_gem_name_info' was not declared. Should it be static?

../drivers/gpu/drm/drm_ioc32.c:1019:20: warning: symbol 'drm_compat_ioctls' was not declared. Should it be static?

../drivers/gpu/drm/drm_bridge.c:52:12: warning: function 'drm_bridge_attach' with external linkage has definition
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Use %pS for actual addresses, otherwise you'll get bad output
on arches like ppc64 where %pF expects a function descriptor.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

We don't want tile 0,0 to artificially constrain the size of the legacy
fbdev device.  Instead when reducing fb_size to be the minimum of all
displays, only consider the rightmost and bottommost tiles.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Hai Li <hali@codeaurora.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Flip conditional to reduce indentation level of rest of fxn, and use
min/max to make the code clearer.

v2: surface_width -> surface_height typo
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

What is passed to drm_fb_helper_fill_var() should be fb_width/fb_height,
rather than the surface size.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

What is passed to drm_fb_helper_fill_var() should be fb_width/fb_height,
rather than the surface size.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

What is passed to drm_fb_helper_fill_var() should be fb_width/fb_height,
rather than the surface size.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

There has been some confusion about this struct.  Lack of documentation
probably didn't help.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.

It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.

Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.

Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.

Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:

Device under test:     old  -> with this patch
DP->DVI (OUI 001cf8):  40ms -> 35ms
DP->VGA (OUI 0022b9):  45ms -> 38ms
Zotac DP->2xHDMI:      25ms ->  4ms
Asus PB278 monitor:    22ms ->  3ms

A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I somehow manage to screw up applying Laurent's patch in eca93e28c256:
"drm: Check in setcrtc if the primary plane supports the fb pixel
format". It was a conflict with

commit 3461b30b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Mar 5 10:32:44 2015 +0100

    drm/plane-helper: unexport drm_primary_helper_create_plane

and I just didn't check that the solution from wiggle made sense.

Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: laurent.pinchart@ideasonboard.com
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: laurent.pinchart@ideasonboard.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Make the helper function pointer structs const to make it clear they
should not be modified.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Another pile of misc drm patches all over, mostly polish for atomic. Last
minute rebase was to avoid the broken merge.

* tag 'topic/drm-misc-2015-03-10' of git://anongit.freedesktop.org/drm-intel:
  drm: Check in setcrtc if the primary plane supports the fb pixel format
  drm: Lighten sysfs connector 'status'
  drm/plane-helper: unexport drm_primary_helper_create_plane
  drm: Share plane pixel format check code between legacy and atomic
  drm: Fix trivial typos in comments
  drm/dp: add DPCD definitions from eDP 1.4
  drm/dp: add DPCD definitions from DP 1.1 and 1.2a
  drm: Fixup racy refcounting in plane_force_disable
  drm/i915: Rotation property is now handled in DRM core
  drm: Complete moving rotation property to core
  drm/dp: add DPCD definitions from eDP 1.2
  drm/dp: indentation and ordering cleanups
  drm/atomic-helper: Fix kerneldoc for prepare_planes
  drm: Remove redundant code in the getencoder ioctl

Drivers implementing the universal planes API report the list of
supported pixel formats for the primary plane. Make sure the fb passed
to the setcrtc ioctl is compatible.

Drivers not implementing the universal planes API will have no format
reported for the primary plane, skip the check in that case.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Since the beginning, sysfs/connector/status has done a heavyweight
detection of the current connector status. But no user, such as upowerd
or logind, has ever desired to initiate a probe. Move the probing into a
new attribute so that existing readers get the behaviour they desire.

v2: David Herrmann suggested using "echo detect > /sys/.../status" to
trigger the probing, which is a fine idea. This extends that to also
allow the user to apply the force detection overrides at runtime.

v3: Now with airlied's email address fixed! Requires sysfs_streq()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>