From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wolverine02.qualcomm.com ([199.106.114.251]:31256 "EHLO wolverine02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752666Ab0DSTmg (ORCPT ); Mon, 19 Apr 2010 15:42:36 -0400 Subject: Re: [PATCH 5/5] arm: msm: smd: fix SMD modem processor sync condition From: Daniel Walker In-Reply-To: References: <1271700189-8376-5-git-send-email-dwalker@codeaurora.org> <1271703705.15004.4.camel@c-dwalke-linux.qualcomm.com> <1271704277.15004.8.camel@c-dwalke-linux.qualcomm.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 19 Apr 2010 12:42:32 -0700 Message-ID: <1271706152.15004.26.camel@c-dwalke-linux.qualcomm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: Dima Zavin Cc: linux-arm-msm@vger.kernel.org, zpfeffer@quicinc.com 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