kernel/drivers/gpu/drm/msm/hdmi, branch linux-4.1.y

drm/msm/hdmi: add 74.176MHz and 154.0MHz pix clks

2015-04-01T23:29:33Z

Signed-off-by: Rob Clark

drm/msm/hdmi: disallow interlaced

2015-02-01T20:32:47Z

So after clarification from qcom, it seems mdp4 and mdp5 support *de*interlacing but not generating an interlaced signal. Which would explain why interlaced modes never worked properly. So disable in the one connector which was claiming to support interlaced. Signed-off-by: Rob Clark

drm/msm/hdmi: rework hdmi configurations, using dt_match[]

2015-02-01T20:32:46Z

In the same idea mdp5_cfg was added, this change allows us to quickly add new instances, such as apq8084's HDMI in this case. Signed-off-by: Stephane Viau Signed-off-by: Rob Clark

drm/msm/hdmi: Add HDMI platform config for apq8084

2015-02-01T20:32:45Z

This change add the regulator/clock configuration for MDP5 v1.3. This config is close to the one already existing for 8x74, except that one more regulator is needed (hpd-5v-en). Signed-off-by: Stephane Viau Signed-off-by: Rob Clark

drm/msm/hdmi: use dynamic allocation for hdmi resources

2015-02-01T20:32:45Z

Instead of reporting BUG_ON when resources arrays are not dimensioned correctly, this patch does a dynamic allocation of these arrays. This is needed for the following patches that add a regulator for a new target. Signed-off-by: Stephane Viau Signed-off-by: Rob Clark

drm/msm: update generated headers

2015-02-01T20:30:33Z

Resync from rnndb database, to pull in register defines for: * eDP * HDMI/HDCP * mdp4/mdp5 YUV support * mdp5 hw cursor support Signed-off-by: Rob Clark

drm/msm/hdmi: fix memory leak after bridge changes

2015-02-01T20:23:35Z

3d3f8b1f8b ("drm/bridge: make bridge registration independent of drm flow") resulted that the hdmi bridge object would be leaked at teardown. Just switch over to devm_kzalloc() as the easy way to solve this. Signed-off-by: Rob Clark

drm/msm: fix fallout of atomic dpms changes

2015-02-01T20:17:32Z

As a result of atomic DPMS support, the various prepare/commit hooks get called in a way that msm dislikes. We were expecting prepare/commit to bracket a modeset, which is no longer the case. This was needed to hold various extra clk's (such as interface clks) on while we are touching registers, and in the case of mdp4 holding vblank enabled. The most straightforward way to deal with this, since we already have our own atomic_commit(), is to just handle prepare/commit internally to the driver (with some additional vfuncs for mdp4 vs mdp5), and switch everything over to instead use the new enable/disable hooks. It doesn't really change too much, despite the code motion. What used to be in the encoder/crtc dpms() fxns is split out into enable/disable. We should be able to drop our own enable-state tracking, as the atomic helpers should do this for us. But keeping that for the short term for extra debugging as atomic stablizes. Signed-off-by: Rob Clark

drm/bridge: make bridge registration independent of drm flow

2015-01-28T07:45:40Z

Currently, third party bridge drivers(ptn3460) are dependent on the corresponding encoder driver init, since bridge driver needs a drm_device pointer to finish drm initializations. The encoder driver passes the drm_device pointer to the bridge driver. Because of this dependency, third party drivers like ptn3460 doesn't adhere to the driver model. In this patch, we reframe the bridge registration framework so that bridge initialization is split into 2 steps, and bridge registration happens independent of drm flow: --Step 1: gather all the bridge settings independent of drm and add the bridge onto a global list of bridges. --Step 2: when the encoder driver is probed, call drm_bridge_attach for the corresponding bridge so that the bridge receives drm_device pointer and continues with connector and other drm initializations. The old set of bridge helpers are removed, and a set of new helpers are added to accomplish the 2 step initialization. The bridge devices register themselves onto global list of bridges when they get probed by calling "drm_bridge_add". The parent encoder driver waits till the bridge is available in the lookup table(by calling "of_drm_find_bridge") and then continues with its initialization. The encoder driver should also call "drm_bridge_attach" to pass on the drm_device to the bridge object. drm_bridge_attach inturn calls "bridge->funcs->attach" so that bridge can continue with drm related initializations. Signed-off-by: Ajay Kumar Acked-by: Inki Dae Tested-by: Rahul Sharma Tested-by: Javier Martinez Canillas Tested-by: Gustavo Padovan Tested-by: Sjoerd Simons Signed-off-by: Thierry Reding

drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init

2015-01-28T07:45:40Z

Assign the pointer to bridge ops structure(drm_bridge_funcs) in the bridge driver itself, instead of passing it to drm_bridge_init. This will allow bridge driver developer to pack bridge private information inside the bridge object and pass only the drm-relevant information to drm_bridge_init. Signed-off-by: Ajay Kumar Acked-by: Inki Dae Tested-by: Rahul Sharma Tested-by: Javier Martinez Canillas Tested-by: Gustavo Padovan Tested-by: Sjoerd Simons Signed-off-by: Thierry Reding