On Tue, Dec 19, 2017 at 7:08 PM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote: > On 12/19, Will Newton wrote: >> On Tue, Dec 19, 2017 at 2:21 PM, Will Newton <will.newton@xxxxxxxxx> wrote: >> > On Tue, Dec 19, 2017 at 9:44 AM, Will Newton <will.newton@xxxxxxxxx> wrote: >> >> Hi, >> >> >> >> I have a git tree with my initial start at msm8909 support in Linux 4.9 here: >> >> >> >> https://bitbucket.org/andromedauk/msm8909-linux >> >> >> >> It's based off the Linaro Qualcomm landing team tree (with Android >> >> drivers merged too for no useful reason). >> >> >> >> The current state is that pinctrl is pretty much done, regulators are >> >> mostly done, clocks is quite hard to say as I'm not doing a good job >> >> of parsing the docs right now. The serial port works! I've seen the >> >> USB driver enumerate a hub but not tested any further. > > The bus clks that you're missing aren't typically exposed in > downstream kernels because we don't control the rates of those > clks. We've been putting them into upstream to keep the clk tree > connected to a root. If you can list the clks that are missing I > can give you the info you need. The two main clocks that are missing which are used in msm8916 are: pcnoc_bfdcd_clk_src system_noc_bfdcd_clk_src Which are the parents of the AXI/AHB clocks amongst others. It isn't clear from the msm8909 register reference what parent to use for these. Some of it's a bit of a mystery because there are clocks (registers) in the 3.10 kernel which are not listed in the doc I have (80-NP408-2x Rev. C) so it's hard to know if those clocks really should be there or not and the 3.10 kernel doesn't seem to list parents for these clocks (at least not in a way I have figured out yet). >> >> >> >> Outstanding tasks: >> >> >> >> 1. Semi-random resets during boot. Occasionally the board will reset >> >> for no obvious reason during boot. I suspect this is something to do >> >> with regulators as it usually seems to be around the time something is >> >> setting voltage and turning on initcall debugging seems to make it >> >> less likely to happen (by slowing the boot). >> > >> > FWIW these resets go away if I disable the wcnss driver in the dts. >> >> Specifically the code that triggers the reset is the call to >> qcom_scm_pas_auth_and_reset in qcom_wcnss.c. If I comment that call >> out then the boot seems to be stable. Does anyone have any ideas what >> might cause that behaviour? >> > > The wcnss is probably crashing because some regulator or clk is > not enabled, or voltages need to be bumped up. One idea to debug > would be to make wcnss into a module that you load with modprobe. > Then you can try turning on more regulators, and verify that > they're actually on by dumping the SPMI registers, until you > narrow down what's off that needs to be on. This would also allow > you to confirm the RPM communication is working and regulators > are actually working. Thanks, I'll give that a try. -- 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
