Move out code from enable and disable routines to prepare
and unprepare routines, so that functionality is properly
distributed across all the panel functions.
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Move out code from enable and disable routines to prepare
and unprepare routines, so that functionality is properly
distributed across all the panel functions.
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Modify tegra output driver to support the new panel calls:
prepare and unprepare.
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Modify exynos_dsi driver to support the new panel calls:
prepare and unprepare.
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Modify exynos_dpi driver to support the new panel calls:
prepare and unprepare.
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This patch adds dummy definition for prepare and unprepare
routines to simple panel driver.
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This patch adds dummy definition for prepare and unprepare
routines to s6e8aa0 panel driver.
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This patch adds dummy definition for prepare and unprepare
routines to ld9040 panel driver.
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

simple-panel is not a valid panel model, so there is no data (video
timings, etc.) associated with it. Therefore drivers can't do anything
useful with it, so it should not appear in the table of OF matches.

Device trees will always need to specify the exact model of the panel.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The Innolux N116BGE is an 11.6" WXGA TFT LCD panel connecting to an eDP
interface and with an integrated LED backlight unit.

It is used in the Tegra132 Norrin reference design.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The bits-per-color is provided by the EDID normally, but if we're using
panels, we need to store it somewhere. So we add a field to the panel
descriptor for it.
Signed-off-by: NStéphane Marchesin <marcheu@chromium.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This panel is used by the Medcom Wide and supported by the
simple-panel driver.
Signed-off-by: NAlban Bedel <alban.bedel@avionic-design.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Use a static inline function for upcasting a struct drm_panel to the
driver-specific structure. The advantage over using a macro is that it
gives us additional type checking.
Acked-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

When executing DCS commands, use the channel associated with the DSI
peripheral rather than one explicitly specified in the function call.
Devices shouldn't be able to step on each others' toes like this.
Acked-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This function returns the value of the struct mipi_dsi_host_ops'
.transfer() so make sure the return types are consistent.
Acked-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This panel is used by Atmel's SAMA5D3 Evaluation Kits (sama5d3xek) and
supported by the simple-panel driver.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The LG LD070WX3-SL01 and Panasonic VVX10F004B00 are DSI support
non-continuous clock mode. Set the MIPI_DSI_CLOCK_NON_CONTINUOUS
to their definition so host drivers become aware of this capability.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Rather than DRM_PANEL_LD9040 selecting SPI, which then results in an
increase in the probability of Kconf reporting circular dependencies
(we're one "select" away from that right now), make this depend on
SPI instead.  This is akin to having some driver select DRM.

Having some drivers depend on a subsystem, and other drivers select a
subsystem is a recipe for circular dependencies, and there's really no
need for it.

The potential circular dependency (which can be caused today by the
addition of selecting DRM_PANEL from DRM_IMX_LDB) is:

  symbol DMADEVICES is selected by SAMSUNG_DMADEV
  symbol SAMSUNG_DMADEV is selected by S3C64XX_PL080
  symbol S3C64XX_PL080 is selected by SPI_S3C64XX
  symbol SPI_S3C64XX depends on SPI
  symbol SPI is selected by DRM_PANEL_LD9040
  symbol DRM_PANEL_LD9040 depends on DRM_PANEL
  symbol DRM_PANEL is selected by DRM_IMX_LDB
  symbol DRM_IMX_LDB depends on MFD_SYSCON
  symbol MFD_SYSCON is selected by POWER_RESET_KEYSTONE
  symbol POWER_RESET_KEYSTONE depends on POWER_SUPPLY
  symbol POWER_SUPPLY is selected by HID_SONY
  symbol HID_SONY depends on NEW_LEDS
  symbol NEW_LEDS is selected by BACKLIGHT_ADP8860
  symbol BACKLIGHT_ADP8860 depends on BACKLIGHT_CLASS_DEVICE
  symbol BACKLIGHT_CLASS_DEVICE is selected by FB_MX3
  symbol FB_MX3 depends on MX3_IPU
  symbol MX3_IPU depends on DMADEVICES
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NThierry Reding <treding@nvidia.com>

DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on
DRM_PANEL && DRM, whereas DRM_PANEL_SIMPLE relies upon the dependency
on the menu.

We do not need to use explicit dependencies if we make the menu depend
on DRM_PANEL && DRM - this will implicitly make each entry in the menu
depend on DRM_PANEL && DRM without this needing to be explicitly stated
against every entry.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We were sending the necessary state changes to unset the mode, but
never actually hit the big GO button unless another modeset happens
afterwards.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

And at the same time, obey the spec better wrt out-of-range requests.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

SOR_PWR has no effect to power-off DP links, unlike other SOR protocols.

Instead, on the source side, we cut power to the lanes after having put
the sink into D3.  Link training takes care of everything required to
bring it back again.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This previously worked for the most part due to userspace doing a
modeset in response to HPD interrupts.  This will allow us to
properly handle cases where sync is lost for other reasons, or if
userspace isn't caring.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Some kind of update?  Needed to make the power-down take effect at least.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We want to be able to power down the lanes for DPMS off.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Same place as for SOR, between detach and attach phases.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>