The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They're described in DT using the
OF graph bindings and a list of custom properties pertaining to the
input video bus configuration.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The drm_get_edid() function performs direct I2C accesses to read EDID
blocks, assuming that the monitor DDC interface is directly connected to
the I2C bus. It can't thus be used with HDMI encoders that control the
DDC bus and expose EDID blocks through a different interface.

Refactor drm_do_get_edid() to take a block read callback function
instead of an I2C adapter, and export it for direct use by drivers.

As in the general case the DDC bus is accessible by the kernel at the
I2C level, drivers must make all reasonable efforts to expose it as an
I2C adapter and use drm_get_edid() instead of abusing this function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

SoCs that integrate the DU have no internal HDMI encoder, support
external encoders only.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

DRM slave encoders require their associated struct drm_encoder instance
to be embedded in a struct drm_slave_encoder. This makes processing
encoders regardless of their types needlessly and painfully complex in
drivers that use a mix of slave encoders and custom encoders. Such a
driver will need to either create drm_slave_encoder instances that fake
their embedded encoder instance, or to turn all drm_encoder instances
into drm_slave_encoder instances.

Between the two evils, one must choose the lesser. Use drm_slave_encoder
everywhere.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Add a new macro to downcast an rcar_du_encoder pointer to a drm_encoder
pointer and use it. This prepares for the replacement of the
rcar_drm_encoder encoder field with a drm_slave_encoder.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The encoder DT node will be needed to register an external HDMI encoder.
Pass it to the rcar_du_encoder_init() function to prepare for HDMI
support.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

All platforms now instantiate the DU through DT, platform data support
isn't needed anymore.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Propagate the error code on failure.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Renesas ARM Based SoC DT DU Updates for v3.19

* Enable DU using DT on marzen/r8a7779, lager/r8a7790 and koelsch/r8a7791

Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next

  Add Exynos4415 SoC support, some fixups and cleanups.

   Summary:
   - Resolve kernel lockup issue incurred by probe request in probe context.
     . For this, it moves all register codes of sub drivers into init function
       and adds component binding support for vidi driver.
   - Add Exynos4415 SoC support.
   - Make each manager and display object to be embedded
     in each driver context.
   - Fix and clean up FIMD and MIPI-DSI drivers.
   - Clean up unnecesary or wrong descriptions.
   - And trivial cleanups.

* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (58 commits)
  drm/exynos: avoid leak if exynos_dpi_probe() fails
  drm/exynos: Fix exynos_dpi_remove() parameter
  drm/exynos: vidi: add component support
  drm/exynos: fix exynos_drm_component_del
  drm/exynos/ipp: fix error return code
  drm/exynos: clean up machine compatible string check
  drm/exynos: move Exynos platform drivers registration to init
  Revert "drm/exynos: fix null pointer dereference issue"
  drm/exynos/dpi: stop using display->ctx pointer
  drm/exynos/dpi: embed display into private context
  drm/exynos/dp: stop using display->ctx pointer
  drm/exynos/dp: embed display into private context
  drm/exynos/vidi: stop using display->ctx pointer
  drm/exynos/vidi: embed display into private context
  drm/exynos/hdmi: stop using display->ctx pointer
  drm/exynos/hdmi: embed display into private context
  drm/exynos/fimd: stop using manager->ctx pointer
  drm/exynos/fimd: embed manager into private context
  drm/exynos/vidi: stop using manager->ctx pointer
  drm/exynos/vidi: embed manager into private context
  ...

Now that we have the bits needed for mdp5 atomic, here is the followup
pull request I mentioned.  Main highlights are:

1) mdp5 multiple crtc and public plane support (no more hard-coded mixer setup!)
2) mdp5 atomic conversion
3) couple atomic helper fixes for issues found during mdp5 atomic
debug (reviewed by danvet.. but he didn't plane to send an
atomic-fixes pull request so I agreed to tack them on to mine)

* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
  drm/atomic: shutdown *current* encoder
  drm/atomic: check mode_changed *after* atomic_check
  drm/msm/mdp4: fix mixer setup for multi-crtc + planes
  drm/msm/mdp5: dpms(OFF) cleanups
  drm/msm/mdp5: atomic
  drm/msm: atomic fixes
  drm/msm/mdp5: remove global mdp5_ctl_mgr
  drm/msm/mdp5: don't use void * for opaque types
  drm/msm: add multiple CRTC and overlay support
  drm/msm/mdp5: set rate before enabling clk
  drm/msm/mdp5: introduce mdp5_cfg module
  drm/msm/mdp5: make SMP module dynamically configurable
  drm/msm/hdmi: remove useless kref
  drm/msm/mdp5: get the core clock rate from MDP5 config
  drm/msm/mdp5: use irqdomains

The component must be deleted if the probe fails.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

exynos_dpi_remove() should receive a exynos_drm_display but when
DRM_EXYNOS_DPI was disabled it was receiving a struct device resulting in
ia compiler warning.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This patch adds component support for vidi driver.

vidi driver is a kms driver so it doesn't need to be registered
to exynos_drm_subdrv_list. For this, it changes for the component
framework to be used for vidi driver.

This patch fixes below error also,

# echo 1 > /sys/devices/platform/exynos-drm-vidi/connection
[   55.618529] ------------[ cut here ]------------
[   55.621960] WARNING: CPU: 0 PID: 1397 at drivers/gpu/drm/drm_irq.c:1203 exynos_drm_crtc_dpms+0x88/0x17c()
[   55.631268] Modules linked in:
[   55.634278] CPU: 0 PID: 1397 Comm: sh Not tainted 3.18.0-rc2-146253-g31449d7 #1154
[   55.641885] [<c0014400>] (unwind_backtrace) from [<c0011570>] (show_stack+0x10/0x14)
[   55.649597] [<c0011570>] (show_stack) from [<c04764f4>] (dump_stack+0x84/0xc4)
[   55.656802] [<c04764f4>] (dump_stack) from [<c00218b8>] (warn_slowpath_common+0x6c/0x88)
[   55.664866] [<c00218b8>] (warn_slowpath_common) from [<c0021970>] (warn_slowpath_null+0x1c/0x24)
[   55.673632] [<c0021970>] (warn_slowpath_null) from [<c027a780>] (exynos_drm_crtc_dpms+0x88/0x17c)
[   55.682482] [<c027a780>] (exynos_drm_crtc_dpms) from [<c027a910>] (exynos_drm_crtc_commit+0x14/0x44)
[   55.691622] [<c027a910>] (exynos_drm_crtc_commit) from [<c025521c>] (drm_crtc_helper_set_mode+0x3d0/0x51c)
[   55.701233] [<c025521c>] (drm_crtc_helper_set_mode) from [<c0255d68>] (drm_crtc_helper_set_config+0x87c/0x9dc)
[   55.711230] [<c0255d68>] (drm_crtc_helper_set_config) from [<c026afa8>] (drm_mode_set_config_internal+0x58/0xd4)
[   55.721380] [<c026afa8>] (drm_mode_set_config_internal) from [<c025c208>] (restore_fbdev_mode+0xcc/0xec)
[   55.730834] [<c025c208>] (restore_fbdev_mode) from [<c025c244>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x30)
[   55.741424] [<c025c244>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c025e0a8>] (drm_fb_helper_set_par+0x1c/0x60)
[   55.752271] [<c025e0a8>] (drm_fb_helper_set_par) from [<c025e174>] (drm_fb_helper_hotplug_event+0x88/0xc4)
[   55.761906] [<c025e174>] (drm_fb_helper_hotplug_event) from [<c02571c4>] (drm_helper_hpd_irq_event+0xc8/0x134)
[   55.771898] [<c02571c4>] (drm_helper_hpd_irq_event) from [<c028e27c>] (vidi_store_connection+0x90/0xc8)
[   55.781268] [<c028e27c>] (vidi_store_connection) from [<c0125f80>] (kernfs_fop_write+0xc0/0x180)
[   55.790045] [<c0125f80>] (kernfs_fop_write) from [<c00cdf60>] (vfs_write+0xa0/0x1ac)
[   55.797757] [<c00cdf60>] (vfs_write) from [<c00ce468>] (SyS_write+0x44/0x9c)
[   55.804790] [<c00ce468>] (SyS_write) from [<c000e6a0>] (ret_fast_syscall+0x0/0x30)
[   55.812328] ---[ end trace 3c0fe4386702d4dd ]---

This issue occurs when modeset to vidi is tried in case that drm_vblank_init
is called prior to crtc creation of vidi driver. In this case, crtc number
of vidi is invalid so any requests with the crtc number will fail.
This patch guarantees drm_vblank_init to be called after all kms drivers
are ready by using component framework.
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>

Propagate the returned error code on failure.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
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>

The patch replaces accesses to display->ctx pointer by container_of
construct. The field is removed as well as dpi was the last user of it.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dpi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple dpi devices in the system.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dp
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple dp devices in the system.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to vidi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple vidi devices in the system.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to hdmi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple hdmi devices in the system.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The patch replaces accesses to manager->ctx pointer by container_of
construct. As fimd was the last user of ctx the patch removes
this field as well.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple FIMD devices in the system.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The patch replaces accesses to manager->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to vidi private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple mixer devices in the system.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The patch replaces accesses to manager->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple mixer devices in the system.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The exynos_dsi_te_irq_handler() works only dsi(DPMS) is on.
So it is enough to enable and disable TE GPIO IRQ in
exynos_dsi_enable(disable)_irq() like DSI IRQ.
Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>a
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The drm_helper_hpd_irq_event() does dpms control and
the panel is initialized and displayed on by it.
So the exynos_dsi_te_irq_handler() should be registered
beforehand.
Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The drm_handle_vblank should be called whenever be vsync, te interrupt
means vsync on i80 interface.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

There is a case like set config which requires triggering
but vblank is not enabled yet.
So triggering unset routine is required to exit from
triggering mode.
Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

For the I80 interface, the video interrupt pending register(VIDINTCON1)
should be handled in fimd_irq_handler() and the video interrupt control
register(VIDINTCON0) should be handled in fimd_enable_vblank() and
fimd_disable_vblank() like RGB interface.
So this patch moves each set / unset routines into proper positions.
Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This function is valid only the SoC has SHADOWCON register
and it should be used together with fimd_enable_video_output()
to match the ENWIN_F bit in WINCON# and C#_EN_F bit in SHADOWCON.
Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This bit is used for video output and logic signal control.
So it is better for readability.
Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>