From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752693AbdLCRIF (ORCPT ); Sun, 3 Dec 2017 12:08:05 -0500 Received: from mga02.intel.com ([134.134.136.20]:39172 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752377AbdLCRIE (ORCPT ); Sun, 3 Dec 2017 12:08:04 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,354,1508828400"; d="scan'208";a="183096996" Date: Sun, 3 Dec 2017 22:41:39 +0530 From: Vinod Koul To: Pierre-Louis Bossart Cc: Greg Kroah-Hartman , LKML , ALSA , Mark , Takashi , patches.audio@intel.com, alan@linux.intel.com, Charles Keepax , Sagar Dharia , srinivas.kandagatla@linaro.org, plai@codeaurora.org, Sudheer Papothi Subject: Re: [alsa-devel] [PATCH v4 09/15] soundwire: Add slave status handling Message-ID: <20171203171139.GQ32417@localhost> References: <1512122177-2889-1-git-send-email-vinod.koul@intel.com> <1512122177-2889-10-git-send-email-vinod.koul@intel.com> <693f15b3-3751-2416-5d81-abd362464309@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <693f15b3-3751-2416-5d81-abd362464309@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 01, 2017 at 05:52:03PM -0600, Pierre-Louis Bossart wrote: > >+ status = sdw_read(slave, SDW_DP0_INT); > >+ if (status < 0) { > >+ dev_err(slave->bus->dev, > >+ "SDW_DP0_INT read failed:%d", status); > >+ return status; > >+ } > >+ > >+ count++; > >+ > >+ /* we can get alerts while processing so keep retrying */ > > This is not incorrect, but this goes beyond what the spec requires. > > The additional read is to make sure some interrupts are not lost due to a > known race condition. It would be enough to mask the status read the second > time to only check if the interrupts sources which were cleared are still > signaling something. > > With the code as it is, you may catch *new* interrupt sources, which could > impact the arbitration/priority/policy in handling interrupts. It's not > necessarily bad, but you'd need to document whether you want to deal with > the race condition described in the MIPI spec or try to be smarter. This was based on your last comment, lets discuss more offline on this to see what else is required here. -- ~Vinod From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Koul Subject: Re: [PATCH v4 09/15] soundwire: Add slave status handling Date: Sun, 3 Dec 2017 22:41:39 +0530 Message-ID: <20171203171139.GQ32417@localhost> References: <1512122177-2889-1-git-send-email-vinod.koul@intel.com> <1512122177-2889-10-git-send-email-vinod.koul@intel.com> <693f15b3-3751-2416-5d81-abd362464309@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by alsa0.perex.cz (Postfix) with ESMTP id 96E0F266B0F for ; Sun, 3 Dec 2017 18:08:04 +0100 (CET) Content-Disposition: inline In-Reply-To: <693f15b3-3751-2416-5d81-abd362464309@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Pierre-Louis Bossart Cc: ALSA , Charles Keepax , Sudheer Papothi , Takashi , Greg Kroah-Hartman , plai@codeaurora.org, LKML , patches.audio@intel.com, Mark , srinivas.kandagatla@linaro.org, Sagar Dharia , alan@linux.intel.com List-Id: alsa-devel@alsa-project.org On Fri, Dec 01, 2017 at 05:52:03PM -0600, Pierre-Louis Bossart wrote: > >+ status = sdw_read(slave, SDW_DP0_INT); > >+ if (status < 0) { > >+ dev_err(slave->bus->dev, > >+ "SDW_DP0_INT read failed:%d", status); > >+ return status; > >+ } > >+ > >+ count++; > >+ > >+ /* we can get alerts while processing so keep retrying */ > > This is not incorrect, but this goes beyond what the spec requires. > > The additional read is to make sure some interrupts are not lost due to a > known race condition. It would be enough to mask the status read the second > time to only check if the interrupts sources which were cleared are still > signaling something. > > With the code as it is, you may catch *new* interrupt sources, which could > impact the arbitration/priority/policy in handling interrupts. It's not > necessarily bad, but you'd need to document whether you want to deal with > the race condition described in the MIPI spec or try to be smarter. This was based on your last comment, lets discuss more offline on this to see what else is required here. -- ~Vinod