Hi Linus,
On 11/08/14 13:49, Linus Walleye wrote:
On Mon, Aug 11, 2014 at 1:42 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
On Mon, Aug 11, 2014 at 1:21 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> 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.
There is a patch to fix this
http://www.spinics.net/lists/linux-arm-msm/msg09633.html
Any ideas?
IMO, hclk is also used by the serial IP, disabling the clock while its
being used by early printk would result in hang, I think that's what you
are seeing.
--srini
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
