On Mon, Aug 11, 2014 at 1:42 PM, Linus Walleij <[email protected]> wrote:
> On Mon, Aug 11, 2014 at 1:21 PM, Linus Walleij <[email protected]>
> wrote:
>
>> The symptom is that not even earlyprints come up if I put some
>> printascii() in start_kernel.
>
> Bah that was me not realizing that the defaults for DEBUG_UART_PHYS
> and DEBUG_UART_VIRT has to be set up properly... now I get the
> earlyprints.
>
> It seems to hang in the gsbi driver probe, off to debug.
It appears that this oneliner gets the kernel booting again:
diff --git a/drivers/soc/qcom/qcom_gsbi.c b/drivers/soc/qcom/qcom_gsbi.c
index 447458e696a9..1759a3c9140a 100644
--- a/drivers/soc/qcom/qcom_gsbi.c
+++ b/drivers/soc/qcom/qcom_gsbi.c
@@ -57,7 +57,7 @@ static int gsbi_probe(struct platform_device *pdev)
/* make sure the gsbi control write is not reordered */
wmb();
- clk_disable_unprepare(hclk);
+ //clk_disable_unprepare(hclk);
return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
}
The kernel hangs during disable/unprepare of the hclk for the GSBI.
Turning off hclk's could be dangerous if there are vital system
components using the hclk which does not yet have a reference
taken in the kernel, due to missing drivers or similar.
Any ideas?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
