summaryrefslogtreecommitdiff
path: root/firmware/keyspan_pda
diff options
context:
space:
mode:
authorArchit Taneja <architt@codeaurora.org>2016-06-15 18:04:31 +0530
committerRob Clark <robdclark@gmail.com>2016-07-16 10:08:58 -0400
commitcd79272696ef21fb03d8b140c4530ac6b049e417 (patch)
treed818d621336badc9d9bac431b5a252e6602ec0ec /firmware/keyspan_pda
parent031d63dd9d06b7f70b060e461b18ccdd2e7e80bc (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