There is no one using the legacy drm_connector_funcs structure since
the imx-drm has been converted to atomic, so we may remove it.
Signed-off-by: NLiu Ying <gnuiyl@gmail.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>

Wire up CRTCs', planes' and connectors' ->reset, ->duplicate and ->destroy state
hooks to use the default implementations from the atomic helper library.
The helpers track each DRM object state.
Signed-off-by: NLiu Ying <gnuiyl@gmail.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>

We have a 1:1 relationship between connectors and encoders, which means
we can rely on the drm_atomic_helper_best_encoder() behavior.

We still have to explicitly assign ->best_encoder() to
drm_atomic_helper_best_encoder(), because the automated fallback to
drm_atomic_helper_best_encoder() when ->best_encoder() is NULL is only
available when the DRM device is using the atomic helpers, and this bridge
is compatible with non-atomic and atomic devices.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465300095-16971-21-git-send-email-boris.brezillon@free-electrons.com

We don't need to keep empty callbacks for the (pre/post) enable/disable
drm_bridge ops anymore. Remove the nop callback used here for
pre_enable and post_disable ops.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1459329804-10488-1-git-send-email-architt@codeaurora.org

Other bridge drivers don't implement this optional function.
Removed dummy code from dw-hdmi brigde driver.
Signed-off-by: NCarlos Palminha <palminha@synopsys.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455120639-29934-1-git-send-email-palminha@synopsys.com

Fill atomic needed funcs with default atomic helper library.

Rockchip use dw_hdmi, and drm/rockchip will covert to atomic api,
we need dw_hdmi support atomic funcs.

Now another drm driver use dw_hdmi is imx, not yet atomic, so
check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>

For consistency with other drivers, use dashes instead of underscores in
filenames.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Given the TDMS clock, audio sample rate, and the N parameter, we can
calculate the CTS value for the audio clock regenerator (ACR) using the
following calculation given in the HDMI specification:

	CTS = ftdms * N / (128 * fs)

The specification says that the CTS value is an average value, which is
true if the source hardware measures it.  Where source hardware needs it
to be programmed, it is particularly difficult to alternate between two
values correctly to ensure that we achieve a correct "average"
fractional value at the sink.

Also, there's the problem that our "ftdms" is not a fully accurate
value; it is rounded to a kHz value.  This introduces an unnecessary
(and harmless) fractional value into the above equation for combinations
like 148.5MHz/1.001 for 44100Hz - we still calculate the correct CTS
value.
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We never set the ratio for CTS/N calculation for the audio clock
regenerator (ACR) to anything but 100, so this adds pointless
complexity.  Should we support pixel repetition, we should update the
CTS/N calculation code to use those parameters or the actual TMDS clock
rate instead of a ratio.
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Adjust the pixel clock values in the N calculation to match the more
accurate clock values we're given by the DRM subsystem, which are the
kHz pixel rate, with any fractional kHz rounded down in the case of
the non-240, non-480 line modes, or rounded up for the others.  So,

	 25.20 / 1.001 =>  25175
	 27.00 * 1.001 =>  27027
	 74.25 / 1.001 =>  74176
	148.50 / 1.001 => 148352

DRM derives these rates from the EDID CEA mode identifiers, which are
looked up in the tables in drivers/gpu/drm/drm_edid.c.  The values on
the right are the clock values found in these tables, and are
currently expected to be passed to the HDMI driver unchanged.
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There's no need to be recursive when computing the N value for the ACR
packet - we can instead calculate the multiplier prior to our switch()
based lookup, and multiply the N value appropriately afterwards.
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Parse the ELD (EDID like data) stored from the HDMI driver to restrict
the sample rates and channels which are available to ALSA.  This causes
the ALSA device to reflect the capabilities of the overall audio path,
not just what is supported at the HDMI source interface level.
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add ALSA based HDMI AHB audio driver for dw_hdmi.  The only buffer
format supported by the hardware is its own special IEC958 based format,
which is not compatible with any ALSA format.  To avoid doing too much
data manipulation within the driver, we support only ALSAs IEC958 LE and
24-bit PCM formats for 2 to 6 channels, which we convert to its hardware
format.

A more desirable solution would be to have this conversion in userspace,
but ALSA does not appear to allow such transformations outside of
libasound itself.
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

HDMI sinks are permitted to de-assert and re-assert the HPD signal to
indicate that their EDID has been updated, which may not involve a
change of video information.

An example of where such a situation can arise is when an AV receiver
is connected between the source and the display device.  Events which
can cause the HPD to be deasserted include:

 * turning on or switching to standby the AV receiver.
 * turning on or switching to standby the display device.

Each of these can change the entire EDID data, or just a part of the
EDID data - it's up to the connected HDMI sink to do what they desire
here.  For example

 - with the AV receiver and display device both in standby, a source
   connected to the AV receiver may provide its own EDID to the source.
 - turning on the display device causes the display device's EDID to be
   made available in an unmodified form to the source.
 - subsequently turning on the AV receiver then provides a modified
   version of the display device's EDID.

Moreover, HPD doesn't tell us whether something is actually listening
on the HDMI TDMS signals.  The phy gives us a set of RXSENSE indications
which tell us whether there is a sink connected to the TMDS signals.

Currently, we use the HPD signal to enable or disable the HDMI block,
which is questionable when HPD is used in this manner.  Using the
RXSENSE would be more appropriate, but there is some bad behaviour
which needs to be coped with.  The iMX6 implementation lets the TMDS
signals float when the phy is "powered down", which cause spurious
interrupts.  Rather than just using RXSENSE, use RXSENSE and HPD
becoming both active to signal the presence of a device, but loss
of RXSENSE to indicate that the device has been unplugged.

The side effect of this change is that a sink deasserting the HPD
signal to cause a re-read of the EDID data will not cause the bridge
to immediately disable the video signal.
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When connected to HDMI sources, some DVI monitors de-assert their HPD
signal and TDMS loads for one seconds every four seconds when there is
no signal present on the connection.

Unfortunately, this behaviour is indistinguishable from a proper HDMI
setup with an AV receiver in the path to the display: the HDMI spec
requires us to detect HPD deassertions as short as 100ms, which indicate
that the EDID has changed.

Since it is possible to connect a DVI monitor to an AV receiver and then
to a HDMI source, merely working around this by detecting the lack of
HDMI vendor block in the EDID is insufficient - the AV receiver is at
liberty to modify the EDID as it sees fit, and it will place its own
parameters into the EDID including the HDMI vendor block.

DRM has support for forcing the state of a connector, which we should
implement to allow us to work around these broken DVI monitors - we can
tell DRM to force the connection state to indicate that there is always
a device connected to work around this problem.  Although this requires
manual configuration, it is better than nothing at all.

When a forced connection state has been set, there is no point handling
our RXSENSE interrupts, so disable them in this circumstance.
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add support for interlaced video modes to the dw_hdmi bridge.  This
mainly involves halving the vertical parameters to be programmed into
the bridge registers, and setting the interlace_allowed connector flag.

This brings working 1080i support.  However, 480i and 576i fail to
work due to the lack of proper pixel repetition support, which is not
trivial to add due to the tabular PLL parameterisation.  Hence, we
filter out these modes in our mode_valid() method.
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The dw_hdmi enable/disable handling is particularly weak in several
regards:
* The hotplug interrupt could call hdmi_poweron() or hdmi_poweroff()
  while DRM is setting a mode, which could race with a mode being set.
* Hotplug will always re-enable the phy whenever it detects an active
  hotplug signal, even if DRM has disabled the output.

Resolve all of these by introducing a mutex to prevent races, and a
state-tracking bool so we know whether DRM wishes the output to be
enabled.  We choose to use our own mutex rather than ->struct_mutex
so that we can still process interrupts in a timely fashion.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

dw_hdmi_phy_enable_power() is not about enabling and disabling power.
It is about allowing or preventing power-down mode being entered - the
register is documented as "Power-down enable (active low 0b)."

This can be seen as the bit has no effect when the HDMI phy is
operational on iMX6 hardware.

Rename the function to dw_hdmi_phy_enable_powerdown() to reflect the
documentation, make it take a bool for the 'enable' argument, and invert
the value to be written.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

On a mode set, DRM makes the following sequence of calls:
* for_each_encoder
*   bridge	mode_fixup
*   encoder	mode_fixup
* crtc		mode_fixup
* for_each_encoder
*   bridge	disable
*   encoder	prepare
*   bridge	post_disable
* disable unused encoders
* crtc		prepare
* crtc		mode_set
* for_each_encoder
*   encoder	mode_set
*   bridge	mode_set
* crtc		commit
* for_each_encoder
*   bridge	pre_enable
*   encoder	commit
*   bridge	enable

dw_hdmi enables the HDMI output in both the bridge mode_set() and also
the bridge enable() step.  This is duplicated work - we can avoid the
setup in mode_set() and just do it in the enable() stage.  This
simplifies the code a little.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Only enable audio support if the sink supports audio in some form, as
defined via its EDID.  We discover this capability using the generic
drm_detect_monitor_audio() function.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The FSL kernel detects the HDMI vendor id, and uses this to set
hdmi->edid_cfg.hdmi_cap, which is then used to set mdvi appropriately,
rather than detecting whether we are outputting a CEA mode.  Update
the dw_hdmi code to use this logic, but lets eliminate the mdvi
variable, prefering the more verbose "hdmi->sink_is_hdmi" instead.

Use the generic drm_detect_hdmi_monitor() to detect a HDMI sink.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As mentioned in the previous commit, the dw-hdmi driver does not support
pixel doubled modes at present; it does not configure the PLL correctly
for these modes.  Therefore, filter out the double-clocked modes as we
presently are unable to support them.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

dw_hdmi sets a pixel repetition factor of 1 for VICs 10-15, 25-30 and
35-38.  However, DRM uses their native resolutions in its timing
information.  For example, VIC 14 can be 1440x480 with no repetition,
or 720x480 with one pixel repetition.  As DRM uses 1440 pixels per line
for this video mode, we need no pixel repetition.

In any case, pixel repetition appears broken in dw_hdmi.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

iMX6 devices suffer from an errata (ERR005174) where the audio FIFO can
be emptied while it is partially full, resulting in misalignment of the
audio samples.

To prevent this, the errata workaround recommends writing N as zero
until the audio FIFO has been loaded by DMA.  Writing N=0 prevents the
HDMI bridge from reading from the audio FIFO, effectively disabling
audio.

This means we need to provide the audio driver with a pair of functions
to enable/disable audio.  These are dw_hdmi_audio_enable() and
dw_hdmi_audio_disable().

A spinlock is introduced to ensure that setting the CTS/N values can't
race, ensuring that the audio driver calling the enable/disable
functions (which are called in an atomic context) can't race with a
modeset.
Tested-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Introduce dw_hdmi_set_sample_rate(), which allows us to configure the
audio sample rate, setting the CTS/N values appropriately.
Tested-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove the struct hdmi_vmode mhsyncpolarity/mvsyncpolarity/minterlaced
members, which are only used within a single function.  We can directly
reference the appropriate mode->flags instead.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This driver does not make use of regmaps, let's remove this unnecessary
structure member.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When a YCBCR format is selected, we can merely copy the colorimetry
information directly as we use the same definitions for both the
unpacked AVI info frame and the hdmi_data_info structure.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use drm_hdmi_avi_infoframe_from_display_mode() to compose the AVI
frame.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Clean up hdmi_set_clk_regenerator() by allowing it to take the audio
sample rate and ratio directly, rather than hiding it inside the
function.  Raise the unsupported pixel clock/sample rate message from
debug to error level as this results in audio not working correctly.
Tested-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The phy configuration is dependent on the SoC, and we look up values for
some of the registers in SoC specific data.  However, we had partially
programmed the phy before we had successfully looked up the clock rate.
Also, we were only checking that we had a valid configuration for the
currctrl register.

Move all these lookups to the start of this function instead, so we can
check that all lookups were successful before beginning to program the
phy.
Tested-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The phy comments in dw_hdmi.c applied to the iMX6 version.  Move these
comments to the iMX6 dw_hdmi-imx data along side the data.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The dw_hdmi_connector_get_modes() function accidentally forgets to
return the number of modes it added, although it has this information
stored in a local variable.  Let's fix that.

Without this fix, drm_helper_probe_single_connector_modes_merge_bits()
could get confused and always call drm_add_modes_noedid().  That's not
right.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Staticize dw_hdmi_bridge_funcs to fix the following sparse warning:

drivers/gpu/drm/bridge/dw_hdmi.c:1458:25: warning: symbol 'dw_hdmi_bridge_funcs' was not declared. Should it be static?
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Because of iMX6 & Rockchip have differnet mpll config parameter,
the VLEVCTRL parameter would be different. In this case we should
separate VLEVCTRL setting from the common dw_hdmi driver, config
this parameter in platform driver(dw_hdmi-imx and dw_hdmi-rockchip)
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Using a local struct pointer to reduce one level of indirection
makes the code slightly more readable.
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch derived from one from Yakir Yang.  Yakir Yang says:
For Designerware HDMI, the following write sequence is recommended:
1. aud_n3 (set bit ncts_atomic_write if desired)
2. aud_cts3 (set CTS_manual and CTS value if desired/enabled)
3. aud_cts2 (required in CTS_manual)
4. aud_cts1 (required in CTS_manual)
5. aud_n3 (bit ncts_atomic_write with same value as in step 1.)
6. aud_n2
7. aud_n1

However, avoid the ncts_atomic_write_bit and CTS_manual settings in this
patch, both of which are marked reserved in the iMX6 documentation.  All
iMX6 code in the wild seems to want CTS_manual cleared.

Having requested clarification from FSL, it appears that neither of
these bits are implemented in their version of the IP.
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NAndy Yan <andy.yan@rock-chips.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The HDMI n/cts settings need to be updated whenever the audio sample
rate or the video pixel clock changes.  This needs to be protected
against concurrency as there is no synchronisation between these two
operations.  Introduce a mutex (called audio_mutex) to protect against
two threads trying to update the video clock rate and pixel clock
simultaneously.
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NAndy Yan <andy.yan@rock-chips.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Combine these two functions into a single implementation.  These two
functions are called consecutively anyway.  Idea from a patch by
Yakir Yang.
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NAndy Yan <andy.yan@rock-chips.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>