On Wed 06 Dec 12:10 PST 2017, Will Newton wrote: > On Wed, Dec 6, 2017 at 6:43 PM, Bjorn Andersson > <bjorn.andersson@xxxxxxxxxx> wrote: > > On Wed 06 Dec 06:39 PST 2017, Will Newton wrote: > > > >> On Wed, Dec 6, 2017 at 2:45 AM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote: > >> > On 12/01, Will Newton wrote: > >> >> On Wed, Nov 29, 2017 at 6:50 PM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote: > >> >> > >> >> > It's not completely insane to support this SoC upstream though. You'd > >> >> > have to bring in the pinctrl and clk drivers, which may be a bit of > >> >> > effort. After that it should mostly be enabling various devices by > >> >> > adding DT nodes and testing things out. It looks like this is 32-bit, so > >> >> > getting SMP support may require some tweaks to the smp_ops code for qcom > >> >> > platforms. You're right that it isn't too different from msm8916, so it > >> >> > may be that most of the driver support for that SoC transfers over > >> >> > nicely to this one. > >> >> > >> >> I've started from the 8916 drivers and started to port in the changes > >> >> from the 3.18 tree that seem relevant. I have a kernel that boots and > >> >> talks over the serial. I've done a bunch of pinctrl although it is not > >> >> complete yet. I've had a look at the clocks and got the PLL working > >> >> but I think I'm probably missing a document that describes the > >> >> clocking architecture in more detail (I have the register reference > >> >> but that's a bit of a worm's eye view). > >> >> > >> >> The current issue I am experiencing is the first write to an SPMI > >> >> channel causes the board to reset. I suspect this means that I have > >> >> not setup clocks correctly somewhere? > >> > > >> > The SPMI controller typically always has clks enabled, so I would > >> > be surprised if the clk was off. More likely, you're attempting > >> > to read/write a channel that is locked down and triggering an > >> > access control violation. Something configured incorrectly in DT > >> > perhaps? > >> > >> The DT is certainly the most likely place to find the problem, the > >> SPMI driver etc. are mostly the same as 3.18. > >> > >> The problem I am seeing is when the registers are initialized for the > >> s2 regulator (via SPMI), which I think is powering the CPU core (I > >> don't have the pm8909 docs sadly, only pm8916) and even though no bits > >> in the register get changed as part of the init, the writeback of the > >> register causes the board to reset. > >> > >> In general I am having a bit if trouble understanding the regulator > >> setup. It seems like there are the RPM regulators - these don't seem > >> to be detected correctly. I get a remote_state of FLUSHING in > >> qcom_channel_state_worker which stops the devices being setup. > >> > > > > Many regulators in the system feeds multiple subsystems, e.g. apps, > > modem, wireless. To support this there is a separate co-processor - the > > RPM - that take requests from all subsystems and then control the PMIC. > > For these regulators the PMIC registers are locked down and accessing > > these would typically cause a system reset. > > > > To communicate with the RPM you would need to enable tcsr-mutex, smem, > > apcs and smd/rpm/rpm_request like done for 8916. It's probable that the > > only code you need to write is in qcom_smd-regulator.c to add the list > > of regulators and their parameters. > > Thanks, that's really helpful, I'll make sure I have all those functioning. > > It does look like for the 8916 the same list of regulators (s1-s4, > l1-l18) is listed in both the spmi_bus section and the rpm_bus section > of the dts. What is it that decides whether a regulator is part of the > RPM set or the SPMI set - is it a property of the SoC that can be read > somewhere? I don't believe this is documented anywhere, except that by looking at the downstream DTS, where you should be able to see which ones are active and actually are referenced by clients. But as I said, you can start off by only addressing the regulators through the RPM, that should help you reach a functional state. Regards, Bjorn -- 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
