Instead of always enabling all four lanes, enable only the number probed
from the link.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Power on only those lanes required for the specified link.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Interlaced mode is currently not supported on the SOR, so don't program
any associated registers.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Use the speed probed from the link at runtime rather than relying on a
hardcoded default.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The number of HBLANK and VBLANK symbols can be computed at runtime so
that they can be set appropriately depending on the video mode and DP
link.

These values are used by the packet generation logic to determine how
many audio samples can be transferred during the blanking intervals.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The currently hardcoded link parameters don't work on all eDP panels, so
compute the parameters at runtime depending on the mode and panel type
to allow the driver to cope with a wider variety of panels.

Note that the number of bits per pixel of the panel is still hardcoded,
but this can be addressed in a separate patch.

This is largely based on a patch by Stéphane Marchesin but the algorithm
was largely rewritten to be more readable and concise.
Signed-off-by: NStéphane Marchesin <marcheu@chromium.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Lanes are powered up in decreasing order. Power them down in increasing
order for consistency.
Signed-off-by: NStéphane Marchesin <marcheu@chromium.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The comment above mentions link A/B but this isn't what the code does,
so let's fix that.
Signed-off-by: NStéphane Marchesin <marcheu@chromium.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The code currently rounds up the clock to the next MHZ, which is
rounding up a 69.5MHz clock to 70MHz on my machine. This in turn
prevents the display from syncing. Removing this rounding fixes eDP
for me.
Signed-off-by: NStéphane Marchesin <marcheu@chromium.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Other output drivers set up debugfs slightly differently. Bring the SOR
driver in line with those for consistency.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Removing only the root directory will fail when there are still files in
it. Instead of manually removing all files, remove the whole directory
recursively.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Doing so allows the hotplug events generated by the connector to be
properly handled by the DRM poll helpers.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Calling the drm_helper_hpd_irq_event() helper can sleep, so instead of
invoking it directly from the interrupt handler, schedule a work queue
and run it from there.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Enable hardware cursor support on Tegra124. Earlier generations support
the hardware cursor to some degree as well, but not in a way that can be
generically exposed.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The DRM core can now cope with drivers that don't have an associated
struct drm_bus, so the host1x implementation is no longer useful.
Signed-off-by: NThierry Reding <treding@nvidia.com>

With the recent addition of the drm_set_unique() function, devices can
now be registered without requiring a drm_bus. Add a brief description
to the DRM docbook to show how that can be achieved.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Describe how devices are registered using the drm_*_init() functions.
Adding this to docbook requires a largish set of changes to the comments
in drm_{pci,usb,platform}.c since they are doxygen-style rather than
proper kernel-doc and therefore mess with the docbook generation.

While at it, mark usage of drm_put_dev() as discouraged in favour of
calling drm_dev_unregister() and drm_dev_unref() directly.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add a helper function that allows drivers to statically set the unique
name of the device. This will allow platform and USB drivers to get rid
of their DRM bus implementations and directly use drm_dev_alloc() and
drm_dev_register().
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The internal host1x_{,un}register_client() functions can potentially be
confused with public the host1x_client_{,un}register() functions.

Rename them to host1x_{add,del}_client() to remove some of the possible
confusion.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The function is never used outside of the source file and therefore can
be locally scoped.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Tegra124 is mostly backwards-compatible with Tegra114. However, Tegra124
supports a few more features (e.g. interlacing, ...). Introduce a new
compatible string and TMDS tables to cope with these differences.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Accessing the CRC debugfs file will hang the system if the SOR is not
enabled, so make sure that it is stays enabled until the CRC has been
read.
Signed-off-by: NThierry Reding <treding@nvidia.com>

In some cases the pixel clock used to not be correct, which is why it
had to be recomputed. It turns out that the reason why it wasn't correct
is that it was used wrongly. If used correctly there's not need for the
recomputation.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The shift clock divider is highly dependent on the type of output, so
push computation of it down into the output drivers. The old code used
to work merely by accident.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Program the shift clock divider in tegra_crtc_setup_clk() since that's
where the divider is computed, so passing it around can be avoided.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Assert the DSI controller's reset when the driver is unloaded to reduce
power consumption and to put the controller into a known state for
subsequent driver reloads.
Signed-off-by: NThierry Reding <treding@nvidia.com>

When disabling the DSI controller, the code wasn't really doing what it
was supposed to.
Signed-off-by: NThierry Reding <treding@nvidia.com>

To prevent the enable or disable operations to potentially be run
multiple times, add guards to return early when the output is already
in the targetted state.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The packet sequencer needs to be programmed depending on the video mode
of the attached peripheral. Add support for non-burst video modes with
sync events (as opposed to sync pulses) and select either sequence
depending on the video mode.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The DSI controllers are powered by a (typically 1.2V) regulator. Usually
this is always on, so there was no need to support enabling or disabling
it thus far. But in order not to consume any power when DSI is inactive,
give the driver a chance to enable or disable the supply as needed.
Signed-off-by: NThierry Reding <treding@nvidia.com>

A bunch of registers are initialized to 0 upon during driver probe. It
turns out that none of these are actually needed, so they can simply be
dropped.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The pixel format enumeration values used by the Tegra DSI controller
don't match those defined by the DSI framework. Make sure to convert
them to the internal format before writing it to the register.
Signed-off-by: NThierry Reding <treding@nvidia.com>

For some reason when the PW*_ENABLE and PM*_ENABLE fields are cleared
during disable, the HDMI output stops working properly. Resetting and
initializing doesn't help.

Comment out those accesses for now until it has been determined what to
do about them.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Disable LVDS mode according to register documentation. It seems like
this has no effect on the operation of HDMI, but it's probably a good
idea to do this anyway.
Signed-off-by: NThierry Reding <treding@nvidia.com>

This reflects the power-up sequence as described in the documentation,
but it doesn't seem to be strictly necessary to get HDMI to work.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Clocks are never enabled or disabled in atomic context, so we can use
the clk_prepare_enable() and clk_disable_unprepare() helpers instead.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Schematics indicate that the AVDD_HDMI_PLL supply should be enabled
prior to the AVDD_HDMI supply.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The generic Tegra output code already sets up the clocks properly, so
there's no need to do it again when the HDMI output is enabled.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Revert commit 18ebc0f4 "drm/tegra: hdmi: Enable VDD earlier for
hotplug/DDC" and instead add a new supply for the +5V pin on the HDMI
connector.

The vdd-supply property refers to the regulator that supplies the
AVDD_HDMI input on Tegra, rather than the +5V HDMI connector pin. This
was never a problem before, because all boards had that pin hooked up to
a regulator that was always on. Starting with Dalmore and continuing
with Venice2, the +5V pin is controllable via a GPIO. For reasons
unknown, the GPIO ended up as the controlling GPIO of the AVDD_HDMI
supply in the Dalmore and Venice2 DTS files. But that's not correct.
Instead, a separate supply must be introduced so that the +5V pin can be
controlled separately from the supplies that feed the HDMI block within
Tegra.

A new hdmi-supply property is introduced that takes the place of the
vdd-supply and vdd-supply is only enabled when HDMI is enabled rather
than all the time.
Signed-off-by: NThierry Reding <treding@nvidia.com>

For HDMI compliance both of these values need to be set to 1.
Signed-off-by: NThierry Reding <treding@nvidia.com>