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? -- 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
