On Fri, Dec 8, 2017 at 5:07 PM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote: > On 12/08, Will Newton wrote: >> On Thu, Dec 7, 2017 at 2:13 PM, Will Newton <will.newton@xxxxxxxxx> wrote: >> > >> > 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. > > No, not really. This sounds like a similar problem that was seen > on msm8994, but I can't recall if it was ever resolved. Maybe > that was channel closing instead of flushing. Are there any potential issues with coherency between the cpu and rpm? e.g. I haven't put much thought into how the L2 is initialized. -- 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
