linux-toradex.git/drivers/gpu/drm/bridge/dw_hdmi.c, branch v4.4.68 Linux kernel for Apalis and Colibri modules drm: bridge/dw_hdmi: replace CTS calculation for the ACR 2015-10-09T16:21:21+00:00 Russell King rmk+kernel@arm.linux.org.uk 2015-07-22T15:54:37+00:00 dfbdaf50460479446a258ef781683e7d7d6349d7 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: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
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: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drm: bridge/dw_hdmi: remove ratio support from ACR code 2015-10-09T16:21:05+00:00 Russell King rmk+kernel@arm.linux.org.uk 2015-07-22T10:28:16+00:00 b195fbdbdf5f6712beec09bb9009f99ff9ecd912 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: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell 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: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drm: bridge/dw_hdmi: adjust pixel clock values in N calculation 2015-10-09T16:17:34+00:00 Russell King rmk+kernel@arm.linux.org.uk 2015-07-22T09:39:27+00:00 426701d0ccc13a2819fd99938ec50a888817e77d 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: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell 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: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drm: bridge/dw_hdmi: avoid being recursive in N calculation 2015-10-09T16:17:32+00:00 Russell King rmk+kernel@arm.linux.org.uk 2015-07-22T09:35:41+00:00 d0c96d168021a60555c692d860334814cc694d8b 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: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell 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: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver 2015-10-09T16:17:24+00:00 Russell King rmk+kernel@arm.linux.org.uk 2013-11-07T16:06:01+00:00 f5ce405722e410a69da4604285ae5e9210011ffe 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: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell 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: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drm: bridge/dw_hdmi-ahb-audio: add audio driver 2015-10-09T16:14:12+00:00 Russell King rmk+kernel@arm.linux.org.uk 2013-11-07T16:01:45+00:00 7ed6c665e19d4c0456d01c01147e82563c482c4d 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: Takashi Iwai <tiwai@suse.de> Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell 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: Takashi Iwai <tiwai@suse.de>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drm: bridge/dw_hdmi: improve HDMI enable/disable handling 2015-10-06T18:59:14+00:00 Russell King rmk+kernel@arm.linux.org.uk 2015-06-05T12:46:22+00:00 aeac23bda87fd98049352d3bc27a1cb80445e7a0 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: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell 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: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drm: bridge/dw_hdmi: add connector mode forcing 2015-10-06T18:58:55+00:00 Russell King rmk+kernel@arm.linux.org.uk 2015-06-05T14:25:08+00:00 381f05a7a8428c84483d6bbd0aa3f4ced463c278 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: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell 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: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drm: bridge/dw_hdmi: add support for interlaced video modes 2015-10-06T18:58:40+00:00 Russell King rmk+kernel@arm.linux.org.uk 2015-07-21T10:08:25+00:00 e80b9f4eea2649f67edc05d4f2e7ddc250f91453 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: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell 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: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Merge branch 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm into drm-next 2015-08-27T03:01:57+00:00 Dave Airlie airlied@redhat.com 2015-08-27T03:01:57+00:00 d7b273685fedba5359a4ba0ae4f542e3ece28153 Here are some development updates for the Synopsis Designware HDMI driver, which clean up some of the code, and start preparing to add audio support to the driver. This series of patches are based on a couple of dependent commits from the ALSA tree. Briefly, the updates are: - move comments which should have moved with the phy values to the IMX part of the driver. - clean up the phy configuration: to all lookups before starting to program the phy. - clean up the HDMI clock regenerator code - use the drm_hdmi_avi_infoframe_from_display_mode() helper which allows the code to be subsequently simplified - remove the unused 'regmap' pointer in struct dw_hdmi - use the bridge drm device rather than the connector (we're the bridge code) - remove private hsync/vsync/interlaced flags, getting them from the DRM mode structure instead. - implement interface functions to support audio - setting the audio sample rate, and enabling the audio clocks. - removal of broken pixel repetition support - cleanup DVI vs HDMI sink handling - enable audio only if connected device supports audio - avoid double-enabling bridge in the sink path (once in mode_set, and again in commit) - rename mis-named dw_hdmi_phy_enable_power() - fix bridge enable/disable handing, so a plug-in event doesn't reconfigure the bridge if DRM has disabled the output - fix from Vladimir Zapolskiy for the I2CM_ADDRESS macro name These are primerily preparitory patches for the AHB audio driver and the I2S audio driver (from Rockchip) for this IP. * 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name drm: bridge/dw_hdmi: fix phy enable/disable handling drm: bridge/dw_hdmi: rename dw_hdmi_phy_enable_power() drm: bridge/dw_hdmi: avoid enabling interface in mode_set drm: bridge/dw_hdmi: enable audio only if sink supports audio drm: bridge/dw_hdmi: clean up HDMI vs DVI mode handling drm: bridge/dw_hdmi: don't support any pixel doubled modes drm: bridge/dw_hdmi: remove pixel repetition setting for all VICs drm: bridge/dw_hdmi: introduce interfaces to enable and disable audio drm: bridge/dw_hdmi: introduce interface to setting sample rate drm: bridge/dw_hdmi: remove mhsyncpolarity/mvsyncpolarity/minterlaced drm: bridge/dw_hdmi: use our own drm_device drm: bridge/dw_hdmi: remove unused 'regmap' struct member drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode() drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator() drm: bridge/dw_hdmi: clean up phy configuration drm: imx/dw_hdmi: move phy comments drm/edid: add function to help find SADs 
Here are some development updates for the Synopsis Designware HDMI driver,
which clean up some of the code, and start preparing to add audio support
to the driver.  This series of patches are based on a couple of dependent
commits from the ALSA tree.

Briefly, the updates are:
- move comments which should have moved with the phy values to the IMX
  part of the driver.
- clean up the phy configuration: to all lookups before starting to
  program the phy.
- clean up the HDMI clock regenerator code
- use the drm_hdmi_avi_infoframe_from_display_mode() helper which allows
  the code to be subsequently simplified
- remove the unused 'regmap' pointer in struct dw_hdmi
- use the bridge drm device rather than the connector (we're the bridge
  code)
- remove private hsync/vsync/interlaced flags, getting them from the
  DRM mode structure instead.
- implement interface functions to support audio - setting the audio
  sample rate, and enabling the audio clocks.
- removal of broken pixel repetition support
- cleanup DVI vs HDMI sink handling
- enable audio only if connected device supports audio
- avoid double-enabling bridge in the sink path (once in mode_set, and
  again in commit)
- rename mis-named dw_hdmi_phy_enable_power()
- fix bridge enable/disable handing, so a plug-in event doesn't
  reconfigure the bridge if DRM has disabled the output
- fix from Vladimir Zapolskiy for the I2CM_ADDRESS macro name

These are primerily preparitory patches for the AHB audio driver and
the I2S audio driver (from Rockchip) for this IP.

* 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name
  drm: bridge/dw_hdmi: fix phy enable/disable handling
  drm: bridge/dw_hdmi: rename dw_hdmi_phy_enable_power()
  drm: bridge/dw_hdmi: avoid enabling interface in mode_set
  drm: bridge/dw_hdmi: enable audio only if sink supports audio
  drm: bridge/dw_hdmi: clean up HDMI vs DVI mode handling
  drm: bridge/dw_hdmi: don't support any pixel doubled modes
  drm: bridge/dw_hdmi: remove pixel repetition setting for all VICs
  drm: bridge/dw_hdmi: introduce interfaces to enable and disable audio
  drm: bridge/dw_hdmi: introduce interface to setting sample rate
  drm: bridge/dw_hdmi: remove mhsyncpolarity/mvsyncpolarity/minterlaced
  drm: bridge/dw_hdmi: use our own drm_device
  drm: bridge/dw_hdmi: remove unused 'regmap' struct member
  drm: bridge/dw_hdmi: simplify hdmi_config_AVI() a little
  drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode()
  drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator()
  drm: bridge/dw_hdmi: clean up phy configuration
  drm: imx/dw_hdmi: move phy comments
  drm/edid: add function to help find SADs