On Wed, Dec 6, 2017 at 9:58 PM, Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: Hi Bjorn, >> 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. I think I have narrowed down the issue to the fact that the qcom_smd driver is not getting any interrupts. I get a channel created: [ 0.728352] smd:rpm: new channel 'rpm_requests' info-size: 88 fifo-size: 1024 [ 0.731684] smd:rpm: new channel found: 'rpm_requests' But on the first (and only) time through qcom_channel_state_worker the channel is in state FLUSHING so we never create a device. Any idea why I might not be getting any interrupts? The irq numbers etc. all look correct as far as I can tell. smem and tcsr-mutex also look OK. I'm not sure about apcs as I don't have clear documentation on what it actually entails e.g. I have SAW devices setup which seem to be part of APCS but not sure what else. -- 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
