On 16 October 2014 16:05, Krzysztof Kozlowski <[email protected]> wrote: > Hi, > > I encounter issues with DRM/panel driver for Exynos after resuming from > suspend to RAM. This is reproduced on 3.16 but I think it is applicable > also to mainline. > > The scenario: > 0. DRM DSI is in LCD power domain. Power domain is OFF before > suspending. > 1. System suspends. > 2. System resumes. > 3. DRM driver:resume(). > 4. pm_runtime_get() for DRM DSI driver. > 5. This should enable LCD power domain. > 6. but __pm_genpd_poweron() exits early because: > genpd->prepared_count = 3
I am getting to this soonish in my genpd work. Currently I am working on the boot issues. :-) At a first glance, I think the genpd->prepare_count variable shouldn't exist at all, but I need to dig into this in more detail to be sure. In principle I think genpd should rely _more_ on the PM core during system PM transitions. For example the PM core invokes a pm_runtime_get_noresume() (and for some reason genpd as well) at the ->prepare() phase. Shouldn't that be enough!? > genpd->suspend_power_off = 1 > in domain.c:183 > > 7. The domain is not powered on but it is marked as active. > 8. The DRM driver thinks everything is OK and proceeds with resume... > but it fails because whole power domain is OFF. > > The question: Shouldn't the power domain be powered up EARLY? Good question, I would like us to strive towards these goals: For CONFIG_PM_RUNTIME, I think the PM domain should be powered up at the first time a runtime PM resume callbacks gets invoked. For !CONFIG_PM_RUNTIME, I think we should restore the state the PM domain had prior we went to system PM sleep. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
