Flagged by sparse.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620113916.6967-4-kraxel@redhat.com

Flagged by sparse.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620113916.6967-3-kraxel@redhat.com

Drop them from u64 fields, tag local variables correctly instead.
While being at it switch the code to use u64_to_user_ptr().
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620113916.6967-2-kraxel@redhat.com

For RK3399's GRF module, if we want to operate the graphic related grf
registers, we need to enable the pclk_vio_grf which supply power for VIO
GRF IOs, so it's better to introduce an optional grf clock in driver.
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
Acked-by: NRob Herring <robh@kernel.org>

For RK3399 HDMI, there is an external clock need for HDMI PHY,
and it should keep the same clock rate with VOP DCLK.

VPLL have supported the clock for HDMI PHY, but there is no
clock divider bewteen VPLL and HDMI PHY. So we need to set the
VPLL rate manually in HDMI driver.
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
Acked-by: NRob Herring <robh@kernel.org>

RK3399 and RK3288 shared the same HDMI IP controller, only some light
difference with GRF configure.
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
Acked-by: NRob Herring <robh@kernel.org>

All layers of all supported chips support this, the only variable is the
base address of the lookup table in the register map.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498107791-17450-3-git-send-email-peda@axentia.se

The default implementation should be used.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498107791-17450-2-git-send-email-peda@axentia.se

It is no longer used as of commit 34c8ea40 ("drm/vc4: Mimic
drm_atomic_helper_commit() behavior")
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621185002.28563-4-eric@anholt.netAcked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Now that we're using the atomic helpers for fence waits, we can use
the same codepath as drm_atomic_helper_commit() does for async,
getting rid of our custom vc4_commit struct.
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621185002.28563-3-eric@anholt.netAcked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

We should allow SIGIO and things to interrupt us before we get to the
no-error stage of the commit process.  This code is effectively copied
from drm_atomic_helper_commit().
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621185002.28563-2-eric@anholt.netAcked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

This way drm_atomic_helper_wait_for_fences() will actually do
something.  The vc4_seqno_cb has been doing the fence waits on V3D
manually, so far.
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621185002.28563-1-eric@anholt.netAcked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

With instantaneous high precision vblank timestamping
that updates at leading edge of vblank, the emulated
"hw vblank counter" from vblank timestamping which
increments at leading edge of vblank, and reliable
page flip execution and completion at leading edge
of vblank, we should meet the requirements for fast
vblank irq disable/enable.

Testing against rpi-4.12-rc5 Linux kernel with timing
measurement equipment indicates this works fine,
so allow immediate vblank disable for power saving.

For debugging in case of unexpected trouble, booting
with kernel cmdline option drm.vblankoffdelay=0
would keep vblank irqs on to approximate old behavior.

v2: Respin onto drm-misc-next, per Eric's suggestion.
    Drop !vc4->firmware_kms check, as the firmware_kms
    implementation does not exist in upstream.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622012811.2139-1-mario.kleiner.de@gmail.com

Add an helper to wait for all page flips of an atomic state to be done.

v2:
- Pimp kerneldoc as discussed with Boris on irc
- Add missing doc for @dev.
- Use old_state for consitency with wait_for_vblanks

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> (v1)
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1496392332-8722-2-git-send-email-boris.brezillon@free-electrons.com

Now that we have a callback to check if crtc supports a given mode
we can use it in arcpgu so that we restrict the number of probbed
modes to the ones we can actually display.

This is specially useful because arcpgu crtc is responsible to set
a clock value in the commit() stage but unfortunatelly this clock
does not support all the needed ranges.

Also, remove the atomic_check() callback as mode_valid() callback
will be called before.
Signed-off-by: NJose Abreu <joabreu@synopsys.com>
Reviewed-by: NAlexey Brodkin <abrodkin@synopsys.com>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Changes v4->v5:
	- Change commit message to "arcpgu" (Alexey)
Changes v3->v4:
	- Do not use aux function (Laurent)
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/c3bcd69016c77f68a03ff3cb6b22ca6f90e930b0.1495720737.git.joabreu@synopsys.com

It again looks all cargo-culted for no good reasons.

Cc: Shawn Guo <shawnguo@kernel.org>
Acked-by: NShawn Guo <shawnguo@kernel.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621082850.13224-13-daniel.vetter@ffwll.ch

It doesn't do anything in the driver load error paths that the drm
core doesn't also do (cleanup is done in drm_dev_fini).

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621082850.13224-10-daniel.vetter@ffwll.ch

VBLANK events are missed when the CRTC is being disabled because the
driver does not wait till the end of the frame before stopping the
HVS and PV blocks. In this case, we should explicitly issue a VBLANK
event if there's one waiting.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/1497601833-24588-1-git-send-email-boris.brezillon@free-electrons.com

I've failed to remember that we have virtual drivers like vgem which
have no underlying struct device. Fix this asap.
Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Fixes: 5c484cee ("drm: Remove drm_driver->set_busid hook")
Cc: Thierry Reding <treding@nvidia.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621130429.20537-1-daniel.vetter@ffwll.ch

Undo preparation of a clock source, if sti_hqvdp_start_xp70 and
sti_hqvdp_atomic_check are not successful.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/7afad3012fb6e40f43a1eb5a64dc6364c38bd052.1498039961.git.arvind.yadav.cs@gmail.com

The expression &private->fbdev_helper can never be NULL, so the check is
completely unnecessary.
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>
Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-12-thierry.reding@gmail.com

drm_fbdev_cma_hotplug_event() already checks for NULL pointers before
dereferencing, so callers don't need to do that.
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>
Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-11-thierry.reding@gmail.com

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   text	   data	    bss	    dec	    hex	filename
   8836	    744	      0	   9580	   256c	drivers/gpu/drm/armada/armada_crtc.o

File size after constify armada_lcd_of_match:
   text	   data	    bss	    dec	    hex	filename
   9220	    328	      0	   9548	   254c	drivers/gpu/drm/armada/armada_crtc.o
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/ff9a9a908cf347775ab62cfadfde986de72dcf13.1497935382.git.arvind.yadav.cs@gmail.com

drm_fbdev_cma_set_suspend{,_unlocked} use an integer parameter
to describe whether the intended state is a suspend or a resume.
It then passes the value to drm_fb_helper_set_suspend{,_unlocked}
which uses a boolean. Switch to using bool everywhere.
Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620102320.8849-1-Liviu.Dudau@arm.com

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   text	   data	    bss	    dec	    hex	filename
  15845	    640	      0	  16485	   4065	drivers/gpu/drm/sti/sti_hqvdp.o

File size after constify hqvdp_of_match:
   text	   data	    bss	    dec	    hex	filename
  16229	    224	      0	  16453	   4045	drivers/gpu/drm/sti/sti_hqvdp.o
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/0a6ae44cf7d0fb54380809ae0e52234dbd3f367a.1497934979.git.arvind.yadav.cs@gmail.com

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   text	   data	    bss	    dec	    hex	filename
   4222	    664	      0	   4886	   1316	drivers/gpu/drm/sti/sti_dvo.o

File size after constify dvo_of_match:
   text	   data	    bss	    dec	    hex	filename
   4638	    248	      0	   4886	   1316	drivers/gpu/drm/sti/sti_dvo.o
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/d5ac3cb4c43338419308d658b9bcb59b7540471e.1497868332.git.arvind.yadav.cs@gmail.com

It's not obvious that when using the new color manager stuff you still
need to wire up the legacy helper to get legacy LUT support. Improve
this with more links. drm_crtc_funcs->gamma_set already explains this
properly.

Cc: Peter Rosin <peda@axentia.se>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620094228.4757-1-daniel.vetter@ffwll.ch

Now that we have a callback to check if crtc and encoder supports a
given mode we can use it in vc4 so that we restrict the number of
probed modes to the ones we can actually display.

Also, remove the mode_fixup() calls as these are no longer needed
because mode_valid() will be called before.
Signed-off-by: NJose Abreu <joabreu@synopsys.com>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Eric Anholt <eric@anholt.net>
Cc: David Airlie <airlied@linux.ie>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Compile-tested and Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/5bea792f91074688c88a2dab8b0a90eec6e98fdf.1495720737.git.joabreu@synopsys.com

I spotted a markup issue, plus adding the descriptions in drm_driver.
Plus a few more links while at it.

I'm still mildly unhappy with the split between fops and ioctls, but I
still think having the ioctls in the uapi chapter makes more sense. Oh
well ...

v2: Rebase.

v3: Move misplace hunk to the right patch.

Cc: Stefan Agner <stefan@agner.ch>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170531092045.3950-1-daniel.vetter@ffwll.ch

The magic switching between proper pci driver and shadow-attach isn't
useful anymore since there's no ums+kms drivers left. Let's split this
up properly, calling pci_register_driver for kms drivers and renaming
the shadow-attach init to drm_legacy_pci_init/exit.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-6-daniel.vetter@ffwll.ch

The only special-case is pci devices, and we can easily handle this in
the core. Do so and drop a pile of boilerplate from drivers.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-5-daniel.vetter@ffwll.ch

Since

commit ca8e2ad7
Author: Thierry Reding <treding@nvidia.com>
Date:   Fri Apr 11 15:23:00 2014 +0200

    drm: Introduce drm_dev_set_unique()

the ->set_busid callback is optional. On top of that the udl one isn't
really fully compliant with the drm uabi, but since only modesetting
ever binds to it (there's no 3d accel on udl) it doesn't matter.

Still, can't harm to aling and use the default used by everyone else.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-4-daniel.vetter@ffwll.ch

We use drm_crtc_ for all the new-style vblank functions which directly
take a struct drm_crtc *. drm_accurate_vblank_count was the odd one
out, correct this to appease my OCD.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-13-daniel.vetter@ffwll.ch

I alwasy get confused about drm_wait_vblank for a split second until I
realize it's the ioctl handler. Unconfuse me, and do it for the legacy
modeset vblank control ioctl too.

While at it also noticed that I misplaced the irq ioctl handler in the
internal header file.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-12-daniel.vetter@ffwll.ch

Unify and review everything, plus make sure it's all correct markup.
Drop the kernel-doc for internal functions. Also rework the overview
section, it's become rather outdated.

Unfortuantely the kernel-doc in drm_driver isn't rendered yet, but
that will change as soon as drm_driver is kernel-docified properly.

Also document properly that drm_vblank_cleanup is optional, the core
calls this already.

v2: Make it clear that cleanup happens in drm_dev_fini for drivers
with their own ->release callback (Thierry).
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-11-daniel.vetter@ffwll.ch

Again, doesn't seem to serve a purpose.

Cc: Thierry Reding <thierry.reding@gmail.com>
Acked-by: NThierry Reding <thierry.reding@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-34-daniel.vetter@ffwll.ch

Seems entirely cargo-culted.

Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Acked-by: NVincent Abriou <vincent.abriou@st.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-31-daniel.vetter@ffwll.ch

The VC4 KMS driver is implementing its own ->atomic_commit() but there
are a few generic helpers we can use instead of open-coding the logic.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/1496392332-8722-4-git-send-email-boris.brezillon@free-electrons.com

This allows mesa to set the tiling format for a BO and have that
tiling format be respected by mesa on the other side of an
import/export (and by vc4 scanout in the kernel), without defining a
protocol to pass the tiling through userspace.
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170608001336.12842-2-eric@anholt.netAcked-by: NDave Airlie <airlied@redhat.com>

The T tiling format is what V3D uses for textures, with no raster
support at all until later revisions of the hardware (and always at a
large 3D performance penalty).  If we can't scan out V3D's format,
then we often need to do a relayout at some stage of the pipeline,
either right before texturing from the scanout buffer (common in X11
without a compositor) or between a tiled screen buffer right before
scanout (an option I've considered in trying to resolve this
inconsistency, but which means needing to use the dirty fb ioctl and
having some update policy).

T-format scanout lets us avoid either of those shadow copies, for a
massive, obvious performance improvement to X11 window dragging
without a compositor.  Unfortunately, enabling a compositor to work
around the discrepancy has turned out to be too costly in memory
consumption for the Raspbian distribution.

Because the HVS operates a scanline at a time, compositing from T does
increase the memory bandwidth cost of scanout.  On my 1920x1080@32bpp
display on a RPi3, we go from about 15% of system memory bandwidth
with linear to about 20% with tiled.  However, for X11 this still ends
up being a huge performance win in active usage.

This patch doesn't yet handle src_x/src_y offsetting within the tiled
buffer.  However, we fail to do so for untiled buffers already.
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170608001336.12842-1-eric@anholt.netReviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>