diff options
author | Archit Taneja <architt@codeaurora.org> | 2016-06-15 18:04:31 +0530 |
---|---|---|
committer | Rob Clark <robdclark@gmail.com> | 2016-07-16 10:08:58 -0400 |
commit | cd79272696ef21fb03d8b140c4530ac6b049e417 (patch) | |
tree | d818d621336badc9d9bac431b5a252e6602ec0ec /firmware/keyspan_pda | |
parent | 031d63dd9d06b7f70b060e461b18ccdd2e7e80bc (diff) |
drm/msm: Call pm_runtime_enable/disable for newly created devices
With the new device hierarchy for MDP5, we need to enable runtime PM
for both the toplevel MDSS device and the MDP5 device itself. Enable
runtime PM for the new devices.
Since MDP4 and MDP5 now have different places where runtime PM is
enabled, remove the previous pm_runtime_enable/disable calls, and
squash them in the respective kms drivers.
The new device hierarchy (as expressed in the DT bindings) has the GDSC
tied only to the MDSS wrapper device. This GDSC needs to be enabled for
accessing any register in the MDSS sub-blocks. Once every driver is
runtime adapted, the GDSC will be enabled when any sub-block device
calls runtime_get because of the parent-child relationship with MDSS.
Until then, we call pm_runtime_get_sync() once for the MDSS device to
ensure the GDSC is never disabled. This will be removed once all the
drivers are runtime PM adapted.
The error handling paths become a bit tricky when we call these runtime
PM funcs. There doesn't seem to be any helper that checks if runtime PM
is enabled already. Add bool variables in mdp4_kms/mdp5_kms structs to
check if the driver had managed to call pm_runtime_enable before bailing
out.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Diffstat (limited to 'firmware/keyspan_pda')
0 files changed, 0 insertions, 0 deletions