On Mon, 2010-04-19 at 12:23 -0700, Dima Zavin wrote: > But smd_core_init is already waiting for smd to be up. It waits for > SMEM_SMSM_SHARED_STATE to be published. What does proc_comm have to do > with it except for the fact that PCOM_READY gets set relatively late > in the modem boot? If the shared state infrastructure is not yet > initialized, it shouldn't be publishing it. Otherwise, you are just > overloading PCOM_READY and again masking issues. Especially when we > move to chips that don't need proc_comm for most things, and 7x30 is > one of them where we get a lot of local clock control, it really seems > wrong to wait for proc_comm to be up. > > You mentioned that this change will prevent some random crashes. Have > you traced them down to what exactly is failing? I traced the failures down to SMD failing to get initialized .. Be aware that I'm using this version of SMD, but not a Google kernel. My kernel has most of the drivers stripped away, with only SMD and MMC and a few other things. I've spoken with our SMD expert on this side, and waiting for PCOM_READY appears to be the right thing to do here.. As for SMEM_SMSM_SHARED_STATE I don't know, it's possible it's part of the modem simply not being ready for input from SMD.. I can ask around on this side why that isn't getting set or checked properly. Even if this is a defect in the modem we still need to formalize this check since this problem exists in released phones (like trout where I found it). Daniel -- 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
