The DRM driver's ->load() implementation didn't do a good job (no job at
all really) cleaning up on failure. Fix that by undoing any prior setup
when an error occurs. This requires a bit of rework to make it possible
to clean up fbdev midway.

This was tested by injecting errors at various points during the
initialization sequence and verifying that error cleanup didn't crash
and no memory leaked (using kmemleak).

Reported-by: Stéphane Marchesin <marcheu@chromium.org>
Reported-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Use the existing API rather than open-coding equivalent functionality
in the driver.

Signed-off-by: Thierry Reding <treding@nvidia.com>

The drm_gem_object_release() function already performs this cleanup, so
there is no reason to do it explicitly.

Signed-off-by: Thierry Reding <treding@nvidia.com>

There is only a single location where the function needs to do cleanup.
Skip the error unwinding path and call the cleanup function directly
instead.

Signed-off-by: Thierry Reding <treding@nvidia.com>

This function implements the common buffer object allocation used for
both allocation and import paths.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Make sure the DSI PHY_TIMING and BTA_TIMING registers are initialized
when the clocks are set up as opposed to when the output is enabled.
This makes sure that the PHY timings are properly set up when the panel
is prepared and that DCS commands sent at that time use the appropriate
timings.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Using the symbolic constant instantly provides a lot more context.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Using the symbolic constant instantly provides a lot more context.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Add support for sending MIPI DSI command packets from the host to a
peripheral. This is required for panels that need configuration before
they accept video data.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Implement ganged mode support for the Tegra DSI driver. The DSI host
controller to gang up with is specified via a phandle in the device tree
and the resolved DSI host controller used for the programming of the
ganged-mode registers.

Signed-off-by: Thierry Reding <treding@nvidia.com>

In preparation for adding ganged-mode support, this commit splits out
the tegra_dsi_set_timeout() function so that it can be reused for the
slave DSI controller.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Add support for DC-driven command mode. This is a mode where the video
stream sent by the display controller is packed into DCS command packets
(write_memory_start and write_memory_continue) by the DSI controller. It
can be used for panels with a remote framebuffer and is useful to save
power when used with a dynamic refresh rate (not yet supported by the
driver).

Signed-off-by: Thierry Reding <treding@nvidia.com>

For command mode panels, the DSI controller needs to be enabled and
configured so that panel drivers can send commands prior to the video
stream being enabled.

Move code from the monolithic output enable/disable functions into
smaller, reusable units to allow more fine-grained control over the
controller state.

Signed-off-by: Thierry Reding <treding@nvidia.com>

The driver wasn't even attempting to do any cleanup when probing failed.
Fix this by releasing any resources acquired up to the point of failure
and putting the device back into the original state (reset, clocks off).

Signed-off-by: Thierry Reding <treding@nvidia.com>

DSI panels can always be hotplugged via the DSI bus' attach/detach
infrastructure, so unconditionally mark the connector hotpluggable.

While at it, also make sure that when a panel is detached the connector
is marked unconnected before calling into the DRM hotplug helpers to
reflect the correct state.

Signed-off-by: Thierry Reding <treding@nvidia.com>

The common clock framework will take care of preparing and enabling the
parent of the DSI clock automatically.

Signed-off-by: Thierry Reding <treding@nvidia.com>

In preparation for supporting command mode panels, don't disable the
clock when the output is disabled. The output will be enabled only after
the panel has been programmed in command mode, so the clock must always
remain on.

As a side-effect, pad calibration now only needs to be done at driver
probe time, since neither power nor controller state will go away before
driver removal. While at it, use a 32-bit variable to store register
content because the registers are 32-bit even on 64-bit Tegra.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Rather than hardcoding them as macros, make the host and video FIFO
depths parameters so that they can be more easily adjusted if a new
generation of the Tegra SoC changes them.

While at it, set the depth of the video FIFO to the correct value of
1920 *words* rather than *bytes*.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Previously the panel and output were only enabled on encoder->dpms(). If
userspace called dpms on before doing a modeset, the driver would get into
a state where the connector had a dpms state of ON, but the encoder and output
were not enabled (because the encoder is not yet attached to the connector).
Subsequent dpms ON calls are ignored b/c the connector's state already matches
the desired state.

This patch enables/disables the panel and output on modeset as well, so we
can catch the above case.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>

The output is already enabled in .dpms(), doing it in .mode_set() too
can cause noticeable flicker.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Both display controllers are in their own power partition. Currently the
driver relies on the assumption that these partitions are on (which is
the hardware default). However some bootloaders may disable them, so the
driver must make sure to turn them back on to avoid hangs.

Signed-off-by: Thierry Reding <treding@nvidia.com>

The introduction of the COMPILE_TEST dependency in commit 158b50ae
(drm/tegra: Increase compile test coverage) removes the dependency on
COMMON_CLK (implicitly selected via ARCH_TEGRA, ARCH_MULTI_V7 and
ARCH_MULTIPLATFORM).

Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>

struct mipi_dsi_msg is a read-only structure, drivers should never need
to modify it. Make this explicit by making all references to the struct
const.

Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Currently the mipi_dsi_dcs_write() function requires the DCS command
byte to be embedded within the write buffer whereas mipi_dsi_dcs_read()
has a separate parameter. Make them more symmetrical by adding an extra
command parameter to mipi_dsi_dcs_write().

The S6E8AA0 driver relies on the old asymmetric API and there's concern
that moving to the new API may be less efficient. Provide a new function
with the old semantics for those cases and make the S6E8AA0 driver use
it instead.

Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>

A common pattern is starting to emerge for higher level transfer
helpers. Create a new helper that encapsulates this pattern and avoids
code duplication.

Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>

This commit introduces a new function, mipi_dsi_create_packet(), which
converts from a MIPI DSI message to a MIPI DSI packet. The MIPI DSI
packet is as close to the protocol described in the DSI specification as
possible and useful in drivers that need to write a DSI packet into a
FIFO to send a message off to the peripheral.

Suggested-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Add two helpers, mipi_dsi_packet_format_is_{short,long}(), that help in
determining the format of a packet.

Signed-off-by: Thierry Reding <treding@nvidia.com>

The %* format specifier expects an integer, which works fine with size_t
arguments on 32-bit because the types match. However on 64-bit, size_t
is typedef'd to unsigned long and will cause a build warning.

Signed-off-by: Thierry Reding <treding@nvidia.com>

The %* format specifier expects an integer, which works fine with size_t
arguments on 32-bit because the types match. However on 64-bit, size_t
is typedef'd to unsigned long and will cause a build warning.

Signed-off-by: Thierry Reding <treding@nvidia.com>

There are several different models of N116BGE. According to commit
0a2288c0 ("drm/panel: simple: Add Innolux N116BGE panel support"),
the video timings are for the eDP variant.

The clock and htotal values added by that patch are out of spec
according to the datasheets I have seen for the eDP N116BGE (-EA2 and
-EB2).

This patch changes the values to the "Typ" values on the datasheet.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
[tested that these timings work with the Tegra132 Norrin panel]
Signed-off-by: Thierry Reding <treding@nvidia.com>

The Hitachi TX23D38VM0CAA is a 9" WVGA TFT LCD panel and can be
supported by the simple-panel driver.

This panel is connected via LVDS and uses the data enable signal for
timing. Since HSYNC/VSYNC are ignored, the split between sync length and
porches is arbitrary, as long as the complete horizontal blanking interval
is 256 clocks, and the vertical blanking interval is 45 lines.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>

The Innolux G121I1-L01 is a 12.1" TFT LCD panel and can be supported by
the simple-panel driver.

This panel is connected via LVDS and uses the data enable signal for
timing. Since HSYNC/VSYNC are ignored, the split between sync length and
porches is arbitrary, as long as the complete horizontal blanking interval
is 160 clocks, and the vertical blanking interval is 24 lines.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Various panels were missing the .bpc field which encodes the number of
bits per color. Not every display driver relies on this value, but since
the panels can be used with any display engine it must be specified so
that if a driver knows how to differentiate based on this field it can
do so.

Signed-off-by: Thierry Reding <treding@nvidia.com>

The AUO B116XW03 is a 11.6" HD TFT LCD panel connecting to a LVDS
interface and with an integrated LED backlight unit.

This panel is used on the Samsung Chromebook(XE303C12).

Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
[treding@nvidia.com: add missing .bpc field]
Signed-off-by: Thierry Reding <treding@nvidia.com>

This patch adds support for the HannStar Display Corp. HSD070PWW1 7.0"
WXGA TFT LCD panel to the simple-panel driver. The binding documentation
is included.
This panel is connected via LVDS and uses the data enable signal for
timing. Since HSYNC/VSYNC are ignored, the split between sync length and
porches is arbitrary, as long as the complete horizontal blanking interval
is 160 clocks, and the vertical blanking interval is 23 lines.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Add the new flags argument to calls of (devm_)gpiod_get*() and remove
any direction setting code afterwards.

Currently both forms (with or without the flags argument) are valid
thanks to transitional macros in <linux/gpio/consumer.h>. These macros
will be removed once all consumers are updated and the flags argument
will become compulsary.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Add the new flags argument to calls of (devm_)gpiod_get*() and remove
any direction setting code afterwards.

Currently both forms (with or without the flags argument) are valid
thanks to transitional macros in <linux/gpio/consumer.h>. These macros
will be removed once all consumers are updated and the flags argument
will become compulsary.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Add the new flags argument to calls of (devm_)gpiod_get*() and remove
any direction setting code afterwards.

Currently both forms (with or without the flags argument) are valid
thanks to transitional macros in <linux/gpio/consumer.h>. These macros
will be removed once all consumers are updated and the flags argument
will become compulsary.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

The old code has problems with the Dell MST monitors due to some
assumptions I made that weren't true.

I initially thought the Virtual Channel Payload IDs had to be in
the DPCD table in ascending order, however it appears that assumption
is bogus.

The old code also assumed it was possible to insert a member
into the table and it would move other members up, like it does
when you remove table entries, however reality has shown this
isn't true.

So the new code allocates VCPIs separate from entries in the payload
tracking table, and when we remove an entry from the DPCD table,
I shuffle the tracking payload entries around in the struct.

This appears to make VT switch more robust (still not perfect)
with an MST enabled Dell monitor.

Signed-off-by: Dave Airlie <airlied@redhat.com>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>