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. Then there are the SPMI regulators which seem like the same set of regulators but via a different bus. Is that the case? Why is there the need for two representations of the same regulators? Thanks, -- 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
