aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/msm/hdmi
AgeCommit message (Collapse)Author
2014-06-22drm/msm/hdmi: set hdp clock rate before prepare_enableStephane Viau
The clock driver usually complains when a clock is being prepared before setting its rate. It is the case here for "core_clk" which needs to be set at 19.2 MHz before we attempt a prepare_enable(). Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-05-30drm/msm/hdmi: use gpio and HPD pollingRob Clark
The hotplug detect and irq does not seem to be reliable on all devices for some reason. For now it is more reliable to use polling, and give preference to raw gpio status if it disagrees with the debounced hpd status. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-03-31drm/msm: use componentised device supportRob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-03-31drm/msm: hdmi audio supportRob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: add hdmi support for apq8x74/mdp5Rob Clark
The HDMI block is basically the same between older SoC's with mdp4 display controller, and newer ones with mdp5. So mostly this consists of better abstracting out the different sets of regulators, clks, etc. In particular, for regulators and clks we can split it up by what is needed for hot plug detect to work, and what is needed to light up the display. Also, 8x74 has a new phy.. a very simple one, but split out into a different mmio space. And with mdp5, the irq is shared with mdp, so we don't directly register our own irq handler. Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: split out msm_kms.hRob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: resync generated headersRob Clark
resync to latest envytools db, add mdp5 registers Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-01-09drm/msm: add support for msm8060ab/bstemRob Clark
This adds the necessary configuration for the APQ8060A SoC (dual-core krait + a320 gpu) as found on the bstem board. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-11-01drm/msm: resync generated headersRob Clark
resync to latest envytools db, fixes a typo: s/mpd4/mdp4/ Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: David Brown <davidb@codeaurora.org>
2013-09-02drm/msm: convert to drm_bridgeRob Clark
Drop the msm_connector base class, and special calls to base class methods from the encoder, and use instead drm_bridge. This allows for a cleaner division between the hdmi (and in future dsi) blocks, from the mdp block. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-24drm/msm: basic KMS driver for snapdragonRob Clark
The snapdragon chips have multiple different display controllers, depending on which chip variant/version. (As far as I can tell, current devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And then external to the display controller are HDMI, DSI, etc. blocks which may be shared across devices which have different display controller blocks. To more easily add support for different display controller blocks, the display controller specific bits are split out into a "kms" module, which provides the kms plane/crtc/encoder objects. The external HDMI, DSI, etc. blocks are part encoder, and part connector currently. But I think I will pull in the drm_bridge patches from chromeos tree, and split them into a bridge+connector, with the registers that need to be set in modeset handled by the bridge. This would remove the 'msm_connector' base class. But some things need to be double checked to make sure I could get the correct ON/OFF sequencing.. This patch adds support for mdp4 crtc (including hw cursor), dtv encoder (part of MDP4 block), and hdmi. Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-08-24drm/msm: add register definitionsRob Clark
Generated from rnndb files in: https://github.com/freedreno/envytools Keep this split out as a separate commit to make it easier to review the actual driver. Signed-off-by: Rob Clark <robdclark@gmail.com>