Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 18 1月, 2017 10 次提交
  3. 18 12月, 2016 1 次提交
  5. 24 11月, 2016 1 次提交
  7. 10 10月, 2016 1 次提交
  9. 19 9月, 2016 2 次提交
  11. 30 8月, 2016 1 次提交
  13. 29 8月, 2016 1 次提交
  15. 13 7月, 2016 2 次提交
  17. 10 6月, 2016 1 次提交
  19. 30 3月, 2016 1 次提交
  21. 11 2月, 2016 1 次提交
  23. 28 12月, 2015 1 次提交
    • M
      drm: bridge/dw_hdmi: add atomic API support · 2c5b2ccc
      由 Mark Yao 提交于 
      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>
      2c5b2ccc
  25. 25 11月, 2015 1 次提交
  27. 10 10月, 2015 6 次提交
  29. 07 10月, 2015 3 次提交
    • R
      drm: bridge/dw_hdmi: improve HDMI enable/disable handling · aeac23bd
      由 Russell King 提交于 
      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>
      aeac23bd
    • R
      drm: bridge/dw_hdmi: add connector mode forcing · 381f05a7
      由 Russell King 提交于 
      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>
      381f05a7
    • R
      drm: bridge/dw_hdmi: add support for interlaced video modes · e80b9f4e
      由 Russell King 提交于 
      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>
      e80b9f4e
  31. 18 8月, 2015 7 次提交
    • R
      drm: bridge/dw_hdmi: fix phy enable/disable handling · b872a8e1
      由 Russell King 提交于 
      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>
      b872a8e1
    • R
      drm: bridge/dw_hdmi: rename dw_hdmi_phy_enable_power() · 2fada109
      由 Russell King 提交于 
      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>
      2fada109
    • R
      drm: bridge/dw_hdmi: avoid enabling interface in mode_set · 552e6785
      由 Russell King 提交于 
      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>
      552e6785
    • R
      drm: bridge/dw_hdmi: enable audio only if sink supports audio · f709ec07
      由 Russell King 提交于 
      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>
      f709ec07
    • R
      drm: bridge/dw_hdmi: clean up HDMI vs DVI mode handling · 05b1342f
      由 Russell King 提交于 
      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>
      05b1342f
    • R
      drm: bridge/dw_hdmi: don't support any pixel doubled modes · 8add4190
      由 Russell King 提交于 
      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>
      8add4190
    • R
      drm: bridge/dw_hdmi: remove pixel repetition setting for all VICs · d10ca826
      由 Russell King 提交于 
      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>
      d10ca826