On 12/08/16 14:46, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Tue, Aug 02, 2016 at 11:34:26AM +0100, Jon Hunter wrote: >> Commit 33a8eb8d40ee ("drm/tegra: dc: Implement runtime PM") disables the >> display power partition when probing and this causes the Tegra114 >> Dalmore to hang during boot. >> >> The hang occurs when accessing the MIPI calibration registers (which are >> accessed during the configuration of the DSI interface). Ideally the >> MIPI driver should manage the power partition itself to ensure it is on >> when needed. The problem is that the legacy PMC APIs used for managing >> the power partitions do not support reference counting and so this >> cannot be easily done currently. Long-term we will migrate devices to >> use generic PM domains and such scenarios will be easy to support. For >> now fix this by removing the code to turn off the display power >> partition when probing the DC and always keep the DC on so that the >> power partition is not turned off. This is consistent with how the power >> partition was managed prior to this commit. >> >> Please note that for earlier devices such as Tegra114 the MIPI >> calibration logic is part of the display power partition, where as for >> newer devices, such as Tegra124/210 it is part of the SOR power >> partition. Hence, in the long-term is makes more sense to handle such >> power partitions via the generic PM domain framework. >> >> Fixes: 33a8eb8d40ee ("drm/tegra: dc: Implement runtime PM") >> >> Signed-off-by: Jon Hunter <jonathanh@xxxxxxxxxx> >> --- >> >> Please note that the hang is only seen on Tegra114 with v4.8 if the >> patch "ARM: tegra: Correct polarity for Tegra114 PMIC interrupt" (2nd >> patch in series) is applied without this patch. Without the fix for the >> PMIC interrupt polarity the Palmas PMIC probe fails and the display >> probe also fails because the regulators are not found. >> >> drivers/gpu/drm/tegra/dc.c | 21 ++++++++++++++------- >> 1 file changed, 14 insertions(+), 7 deletions(-) > > I don't think this fixes the problem at the root. After looking at the > code I think what you're seeing is caused by the tegra_mipi_power_up() > call that happens as part of the tegra_mipi_request() from the DSI > driver's ->probe(). No it doesn't. It is more of a bandaid. I think that this issue has always been there but no exposed until the move to RPM for the DC. I can't say I was too happy with it! > Generally there shouldn't be a problem because the display controller > will always get enabled before the encoder (DSI) and hence the power > partition should be enabled when the actual calibration happens. The > fundamental problem in this case is that we're actually powering up > the MIPI calibration logic at the wrong time. So I think what we'll > want for a proper fix is to move all register accesses out of the > tegra_mipi_request() function and add tegra_mipi_enable() and > tegra_mipi_disable() functions that power up and power down the MIPI > calibration logic, respectively. That way we can move all the code > which relies on the power partition into the tegra_dsi_encoder_enable() > and tegra_dsi_encoder_disable() functions. > > Perhaps an even better place to call these new functions from would be > the DSI driver's ->suspend() and ->resume() functions. > > An added benefit of this will be that the MIPI calibration logic could > be powered off when DSI is disabled (provided no other user requires it > to be powered on), whereas currently it will remain powered even if the > DSI output is off, since the power on happens in ->probe(). > > I'll go write a patch. Great! Thanks. Jon -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html