This patch fixes a kernel panic issue which happened
when drm driver is closed while modetest.

This issue could be reproduced easily by launching modetest
with page flip repeatedly.

The reason is that invalid drm_file object could be accessed by
send_vblank_event function when finishing page flip if the drm_file
object was removed by drm_release and there was a pended page
flip event which was already committed to hardware.

So this patch makes the pended page flip event to be cancelled by
preclose callback which is called at front of drm_release function.

Changelog v2:
- free vblank event objects belonging to the request process,
  increment event space and decrease pending_update when cancelling
  the event
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>

PM ops in exynos_drm_drv were split into two separate function as they were
used also by drm device. Since PM ops have been removed from drm device, the
functions can be merged together.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Latest Exynos SoCs does not have Mixer IP, but they still have HDMI IP.
Their drivers should be configurable separately.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

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>

drm_vblank_count() returns the software counter. We should not pretend
it's the hw counter since we use the hw counter to figuere out what the
software counter value should be. So instead provide a new function
drm_vblank_no_hw_counter() for drivers that don't have a real hw
counter. The new function simply returns 0, which is about the only
thing it can do.

Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVincent Abriou <vincent.abriou@st.com>
[danvet: s/int pipe/unsigned int pipe/ to follow Thierry's interface
change.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Protect the suspend and resume callbacks with an #ifdef CONFIG_PM_SLEEP
guard to avoid "defined but not used" warnings.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

With drivers supporting runtime pm it's generally not a good idea to
touch the hardware when it's off. Add an option to the commit_planes
helper to support this case.

Note that the helpers already add all planes on a crtc when a modeset
happens, hence plane updates will not be lost if drivers set this to
true.

v2: Check for NULL state->crtc before chasing the pointer. Also check
both old and new crtc if there's a switch. Finally just outright
disallow switching crtcs for a plane if the plane is in active use, on
most hardware that doesn't make sense.

v3: Since commit_planes(active_only = true) is for enabling things
only after all the crtc are on we should only look at the new crtc to
decide whether to call the plane hooks - if the current CRTC isn't on
then skip. If the old crtc (when moving a plane) went down then the
plane should have been disabled as part of the pipe shutdown work
already. For which there's currently no helper really unfortunately.
Also move the check for wether a plane gets a new CRTC assigned while
still in active use out of this patch.

v4: Rebase over exynos changes.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This patch allows clients who want to use render node to access
rendering relevant ioctls - g2d, post processor and gem allocation.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

These legacy helpers should only be used by shadow-attaching drivers.
KMS drivers has its own way to handle suspend/resume and don't need to
use these two helpers.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <daeinki@gmail.com>

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Now that atomic modesetting is implemented for exynos enable the
DRIVER_ATOMIC flag on the driver's features.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Add infrastructure to wait for all planes updates to finish by using
an atomic_t variable to track how many pending updates we are waiting
plus a wait_queue for the wait part.

It also changes vblank behaviour and keeps it enabled for all types
of updates
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The atomic modesetting interfaces supports async commits that should be
implemented by the drivers. If drm core requests an async commit
exynos_atomic_commit() will now schedule a work task to run the update later.

It also serializes commits that needs to run on the same crtc, putting the
following commit to wait until the current one is finished.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The dma-buf codes of exynos drm is almost same with prime helpers. A
difference is that consider DMA_NONE when import dma-buf, but it's wrong
and we don't consider it any more, so we can use prime interface.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
only a drm_encoder member and the internal exynos_drm_encoders ops that
was directly mapped to the drm_encoder helper funcs.

So now exynos DRM uses struct drm_encoder directly, this removes
completely the struct exynos_drm_encoder.

v2: add empty .mode_fixup() and .mode_set() to DSI and DPI to avoid null
pointer.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

As we are removing the exynos encoder move the encoder setup operation
directly inside the exynos_drm_load()
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The vidi is virtual kms driver and now it is registered earlier than
actual hw kms drivers, so it will occupy crtc index 0. Some users
assume the condition yet that actual hw kms driver has crtc index 0.
It may or may not be matter but let's arrange register order.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
resides between decon and mipi dsim, and compresses frame data by 50%.
With dsi, not display port, to send frame data to the panel, the
bandwidth is not enough. That is why this compressor is introduced.
Signed-off-by: NHyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

SoC checking code is not necessary anymore, as exynos_drm_match_add and
exynos_drm_platform_probe already properly handles situation when there are
no Exynos DRM components.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Tested-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

In case there are multiple pipelines and deferred probe occurs, only components
of the first pipeline were bound. As a result only one pipeline was available.
The main cause of this issue was dynamic generation of component match table -
every component driver during probe registered itself on helper list, if there
was at least one pipeline present on this list component match table were
created without deferred components.
This patch removes this helper list, instead it creates match table from
existing devices requiring exynos_drm KMS drivers. This way match table do not
depend on probe/deferral order and contains all KMS components.
As a side effect patch makes the code cleaner and significantly smaller.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Code registering different drivers and simple platform devices was dispersed
across multiple sub-modules. This patch moves it to one place. As a result
initialization code is shorter and cleaner and should simplify further
development.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Tested-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.

Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.
Signed-off-by: NMandeep Singh Baines <msb@chromium.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.

It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.

v2: check for return of exynos_plane_init()
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This patch is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.

DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)

The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.

The current version of the driver supports video mode displays.

Changelog v2:
- Change config name, DRM_EXYNOS_DECON to DRM_EXYNOS7_DECON.
Signed-off-by: NAkshu Agrawal <akshua@gmail.com>
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This code is unnecessary, because same logic is already included. Refer
this mail thread[1] for detail.

[1] http://lists.freedesktop.org/archives/dri-devel/2015-January/075132.htmlSigned-off-by: NHyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This patch resolves the issue that component object isn't removed
correctly.

A given component object couldn't be placed to head of drm_component_list
so all component objects added to the drm_component_list should be checked
to remove the given component object.
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Use 'for' statemant instead of hard-coded 'if' statement.
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Registering the Exynos DRM subdevices platform drivers in the probe
function is causing an infinite loop. Fix this by moving it to the
exynos_drm_init() function to register the drivers on module init.

Registering drivers in the probe functions causes a deadlock in the parent
device lock. See Grant Likely explanation on the topic:

"I think the problem is that exynos_drm_init() is registering a normal
(non-OF) platform device, so the parent will be /sys/devices/platform.
It immediately gets bound against exynos_drm_platform_driver which
calls the exynos drm_platform_probe() hook. The driver core obtains
device_lock() on the device *and on the device parent*.

Inside the probe hook, additional platform_drivers get registered.
Each time one does, it tries to bind against every platform device in
the system, which includes the ones created by OF. When it attempts to
bind, it obtains device_lock() on the device *and on the device
parent*.

Before the change to move of-generated platform devices into
/sys/devices/platform, the devices had different parents. Now both
devices have /sys/devices/platform as the parent, so yes they are
going to deadlock.

The real problem is registering drivers from within a probe hook. That
is completely wrong for the above deadlock reason. __driver_attach()
will deadlock. Those registrations must be pulled out of .probe().

Registering devices in .probe() is okay because __device_attach()
doesn't try to obtain device_lock() on the parent."

 INFO: task swapper/0:1 blocked for more than 120 seconds.
       Not tainted 3.18.0-rc3-next-20141105 #794
 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 swapper/0       D c052534c     0     1      0 0x00000000
 [<c052534c>] (__schedule) from [<c0525b34>] (schedule_preempt_disabled+0x14/0x20)
 [<c0525b34>] (schedule_preempt_disabled) from [<c0526d44>] (mutex_lock_nested+0x1c4/0x464

 [<c0526d44>] (mutex_lock_nested) from [<c02be908>] (__driver_attach+0x48/0x98)
 [<c02be908>] (__driver_attach) from [<c02bcc00>] (bus_for_each_dev+0x54/0x88)
 [<c02bcc00>] (bus_for_each_dev) from [<c02bdce0>] (bus_add_driver+0xe4/0x200)
 [<c02bdce0>] (bus_add_driver) from [<c02bef94>] (driver_register+0x78/0xf4)
 [<c02bef94>] (driver_register) from [<c029e99c>] (exynos_drm_platform_probe+0x34/0x234)
 [<c029e99c>] (exynos_drm_platform_probe) from [<c02bfcf0>] (platform_drv_probe+0x48/0xa4)
 [<c02bfcf0>] (platform_drv_probe) from [<c02be680>] (driver_probe_device+0x13c/0x37c)
 [<c02be680>] (driver_probe_device) from [<c02be954>] (__driver_attach+0x94/0x98)
 [<c02be954>] (__driver_attach) from [<c02bcc00>] (bus_for_each_dev+0x54/0x88)
 [<c02bcc00>] (bus_for_each_dev) from [<c02bdce0>] (bus_add_driver+0xe4/0x200)
 [<c02bdce0>] (bus_add_driver) from [<c02bef94>] (driver_register+0x78/0xf4)
 [<c02bef94>] (driver_register) from [<c029e938>] (exynos_drm_init+0x70/0xa0)
 [<c029e938>] (exynos_drm_init) from [<c00089b0>] (do_one_initcall+0xac/0x1f0)
 [<c00089b0>] (do_one_initcall) from [<c074bd90>] (kernel_init_freeable+0x10c/0x1d8)
 [<c074bd90>] (kernel_init_freeable) from [<c051eabc>] (kernel_init+0x8/0xec)
 [<c051eabc>] (kernel_init) from [<c000f268>] (ret_from_fork+0x14/0x2c)
 3 locks held by swapper/0/1:
  #0:  (&dev->mutex){......}, at: [<c02be908>] __driver_attach+0x48/0x98
  #1:  (&dev->mutex){......}, at: [<c02be918>] __driver_attach+0x58/0x98
  #2:  (&dev->mutex){......}, at: [<c02be908>] __driver_attach+0x48/0x98

Changelog v2:
- call platform_driver_register after all kms and non kms drivers are
  registered
- rebased it to exynos-drm-next
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This reverts commit cea24824ab432f8acabb254d6805e9aa756de6af.

Moving subdriver probe to exynos_drm_platform_probe() was making
exynos_drm_device_subdrv_probe() fail because the platform data wasn't set
yet. It only gets set in exynos_drm_load.

We need to find a smarter way to fix this issue.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

During system resume from suspend to RAM the Exynos DRM driver forced
CRTC mode thus turning display on (DPMS_ON). This lead to runtime resuming
of DSI which failed because whole LCD power domain was off and it was
not allowed to turn on because of system resume in progress.

Forcing mode should not be needed and removing it solves this particular
problem.

This necessary fix for following scenario reproduced on Exynos DRM:
1. Power domain is off before suspending the system.
2. System is suspended to RAM.
3. Resuming starts. The Exynos DRM driver resume callback is called.
4. The Exynos DRM driver calls drm_helper_resume_force_mode() which turns
   on the screen by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON.
5. The Exynos DSI driver calls pm_runtime_get. The driver runtime
   resumes and this should turn LCD power domain on.
6. Unfortunately the domain cannot be turned on because system resume is
   in progress and genpd->prepared_count is positive.

Steps to reproduce:
1. Add runtime PM to Exynos DSI driver.
2. Build Exynos DRM/FB without FRAMEBUFFER_CONSOLE.
3. Enable the connector and screen (e.g. with modeset-vsync).
4. echo 3 > /sys/devices/platform/exynos-drm/graphics/fb0/blank
5. echo mem > /sys/power/state
6. Resume.
[   77.712469] PM: early resume of devices complete after 3.854 msecs
[   77.712739] exynos-dsi 11c80000.dsi: pm_genpd_resume()
[   77.712758] exynos4-fimc 11800000.fimc: pm_genpd_resume()
[   77.712774] exynos4-fimc 11810000.fimc: pm_genpd_resume()
[   77.712787] exynos-drm-fimc 11820000.fimc: pm_genpd_resume()
[   77.712802] exynos-drm-fimc 11830000.fimc: pm_genpd_resume()
[   77.712815] s5p-mipi-csis 11880000.csis: pm_genpd_resume()
[   77.712829] s5p-mipi-csis 11890000.csis: pm_genpd_resume()
[   77.712843] exynos-fimc-lite 12390000.fimc-lite: pm_genpd_resume()
[   77.712856] exynos-fimc-lite 123a0000.fimc-lite: pm_genpd_resume()
[   77.713788] exynos4-fb 11c00000.fimd: pm_genpd_resume()
[   77.713912] wake disabled for irq 184
[   77.713923] wake disabled for irq 185
[   77.714082] wake disabled for irq 173
[   77.715676] wake disabled for irq 176
[   77.718540] exynos4-fb 11c00000.fimd: pm_genpd_runtime_resume()
[   77.718567] exynos4-fb 11c00000.fimd: state restore latency exceeded, new value 1708 ns
[   77.718636] exynos-dsi 11c80000.dsi: pm_genpd_runtime_resume()
[   77.892366] exynos-dsi 11c80000.dsi: PLL failed to stabilize
[   77.892377] exynos-dsi 11c80000.dsi: failed to configure DSI PLL
[   78.192168] exynos-dsi 11c80000.dsi: timeout waiting for reset
[   78.211578] exynos-dsi 11c80000.dsi: waiting for bus lanes timed out
[   78.307173] exynos-dsi 11c80000.dsi: xfer timed out: d1 00 (null)
[   78.307190] panel_s6e8aa0 11c80000.dsi.0: error -110 reading dcs seq(0xd1)
[   78.307199] panel_s6e8aa0 11c80000.dsi.0: read id failed
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The patch replaces separate calls to driver (de)registration by
loops over the array of drivers. As a result it significantly
decreases number of ifdefs. Additionally it moves device registration
related ifdefs to header file.

Changelog v2:
- Rebased.
- Consider non kms driver in respect to infinite loop issue.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This patch fixes null pointer dereference issue incurred
when ipp driver is enabled and Exynos drm driver is closed.

Non kms driver should register its own sub driver to setup necessary
resources, which is done by load(). So null pointer dereference
occurs when ipp driver is enabled and Exynos drm driver is closed
because ipp core device is registered after component_master_add_with_match
call.

This patch makes exynos_drm_device_subdrv_probe() to be called after all non
kms drivers are registered.
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This patch fixes possible infinite loop issue by postponing
registration to non kms drivers after component_master_add_with_match
call, which can be incurred in all cases that non kms driver is probed
and then component bind is failed

This patch should be applied on top of below patches,
	http://comments.gmane.org/gmane.comp.video.dri.devel/117740
	http://www.spinics.net/lists/linux-samsung-soc/msg38624.htmlSigned-off-by: NInki Dae <inki.dae@samsung.com>

This patch resovles the infinite loop issue incurred
when Exyno drm driver is enabled but all kms drivers
are disabled on Exynos board by returning -EPROBE_DEFER
only in case that there is kms device registered.
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This patch fixes possible infinite loop issue by postponing
registration to non kms drivers after component_master_add_with_match
call, which can be incurred in all cases that non kms driver is probed
and then component bind is failed

This patch should be applied on top of below patches,
	http://comments.gmane.org/gmane.comp.video.dri.devel/117740
	http://www.spinics.net/lists/linux-samsung-soc/msg38624.htmlSigned-off-by: NInki Dae <inki.dae@samsung.com>

This patch resovles the infinite loop issue incurred
when Exyno drm driver is enabled but all kms drivers
are disabled on Exynos board by returning -EPROBE_DEFER
only in case that there is kms device registered.
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Signed-off-by: NInki Dae <inki.dae@samsung.com>

During system suspend after connector switch off its dpms field
is set to connector previous dpms state. To properly resume dpms field
should be set to its actual state (off) before resuming to previous dpms state.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

HPD events can be generated by components even if drm_dev is not fully
initialized, to skip such events kms poll initialization should
be performed at the end of load callback followed directly by forced
connection detection.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>