On Thu, Dec 7, 2017 at 2:13 PM, Will Newton <will.newton@xxxxxxxxx> wrote: > 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. Is there any potential for version skew here between the RPM processor and Linux? I have an rpm.mbn binary but I have no idea what is in it, I just know it works with 3.18. -- 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
