Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 1月, 2017 7 次提交
  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 10 次提交