From patchwork Fri Apr 27 11:31:51 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jerome Brunet X-Patchwork-Id: 134574 Delivered-To: patch@linaro.org Received: by 10.46.151.6 with SMTP id r6csp602343lji; Fri, 27 Apr 2018 04:32:08 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp6uELO3r5HB3Jv4TbHgF/oqETyUmQKP99ss9P9iO8yRZOOAbfech2+fPmLafAgmUyUw9wq X-Received: by 2002:a17:902:bcc8:: with SMTP id o8-v6mr1961702pls.84.1524828728033; Fri, 27 Apr 2018 04:32:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524828728; cv=none; d=google.com; s=arc-20160816; b=nzXoFLrqp31VCmxOdLkqf3/9E2AFuU82d3OYAWeiRTULPx+Gpp7x3j7lUjgpOkfO3p xMPwW35/fkOFZ6pD5dX15m9GjWrmJAlgKkxr2iJ0l/FBuHzbySCcSO+4uh4QInvZIkDT U5D6kiPNLTrVQSgfJ2bnGK5Dc0H/0eympacs7VdCqr4jqygFdGK/kLLEO5XhD6cfe0ks H37VJfcFbwP/9jLhygrykgrboBROGqLrokkF3ITrHSzoomtFz2VfbJ2Ap+70n2XEWlDd GivGYKp7GbdU7VYutEQWQjpJKw0bLT6LIPTvLjzhHyDnwu9Tkb19t4PxV2EvGxLFUk/g YxwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=ROiCuodgRLBedX2Tcuh1tnhnSojQmHQDpaUuN1dz2+8=; b=gGguymHuusUBDsvLjmahpFsoeUvEibLKTNZIeJ7wGK3hBi6LX5y50ieImOUzVSCNDA wcYLk+ih5yQjqW92khR6NwroekpALVWZYKCx0e4uwK7JBuYDM8nHNpUOcYQrOXWanv7S VXMvsFCbCyte40GyUv3wfk7k4EVLrw8z/Q5Nef+wXErPThGWp7nGJyqekyFDZSe0f+jY riFX0d6SDZjt8Rs2E5PQojzI+ggK04YffPjoStU1vMyOFWZ7YgYPyj9u4KToRWA3tdF2 UjVMJm9WRoJT6NaKG2Bj/8fLwlzIsdf43A43Sc+46jhQot62olQC0W2UnsEh8olWB/HU LpKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=VXMlpj0H; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w5-v6si1053922plz.587.2018.04.27.04.32.07; Fri, 27 Apr 2018 04:32:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=VXMlpj0H; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757511AbeD0LcE (ORCPT + 29 others); Fri, 27 Apr 2018 07:32:04 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:54950 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbeD0LcD (ORCPT ); Fri, 27 Apr 2018 07:32:03 -0400 Received: by mail-wm0-f66.google.com with SMTP id f6so2080990wmc.4 for ; Fri, 27 Apr 2018 04:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=ROiCuodgRLBedX2Tcuh1tnhnSojQmHQDpaUuN1dz2+8=; b=VXMlpj0HCvGmG5Rt4ClAbZ8TWInbcb0V8zticeNYsFKG7gdrtWcQfoDK6hNSeBxdTw O6223nPF6Ezm6eFoJPXh4oB6wdvT+iL0xuni32aWugdQntVtf3yiZZcpkJsn04vZ4gHb 6xY8xFhplq6auZRQQE3F0+vbU+wzBifKIGD44SK8tRs0Hv8DxCwsbKLw6Z5i1xUSukt0 KVD+0EgA93x3PVE4MMaAmdSWiGxaN5a7Ob98nbqHTH77LHR/jppc1L3yvSX/7cLPn1i2 E8Bn73wz8U4xiti/+Lg8oQTg87WChzG/DjTfu/NZ418OKaX2lXdMmVW2UBLOg/OzuXy0 6gHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=ROiCuodgRLBedX2Tcuh1tnhnSojQmHQDpaUuN1dz2+8=; b=Friij1v4LmsHUZ+JwQFY4CNAmWB86ZaxSDnxZ2g7zCcnV1QXEKf3BrNlWD7hHXPj+m E34TtEQlMclmChZ3KucDLvsEg//cOyOkDCHTG20mLf8aSF2YVPbUOcp34UNYfggpFKQQ U/H/cerQLxeVJkJOvJinciQf7tvxXoKIcuuAaZpgu6CoI5KLByshzAEhVuCOJZXUHidm LZhZsquVogErEcNpMFmrh8utwMMGLtyDGy2Tsljg6B4b9o00CklGQCrOXXCJEGOck+PL 6Efc4Z0eaeYxssOk6WXhcjHGvoW8nTQcQlbOg5BRBY+HI/Q1avMxfEgj0x2hoGWuqWL0 SQeg== X-Gm-Message-State: ALQs6tBZMbM/y5prVST8CiE8vaVLr8DAJyfTk6JOFNHPhnUr+W/GzO8/ xPh/ZtQBKSKeut19SYJcK7o9u4KD X-Received: by 10.28.7.139 with SMTP id 133mr1200817wmh.72.1524828722386; Fri, 27 Apr 2018 04:32:02 -0700 (PDT) Received: from boomer.baylibre.local ([90.63.244.31]) by smtp.googlemail.com with ESMTPSA id v12-v6sm796019wrm.68.2018.04.27.04.32.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 27 Apr 2018 04:32:01 -0700 (PDT) From: Jerome Brunet To: Mark Brown , Liam Girdwood Cc: Jerome Brunet , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, Mark Greer Subject: [PATCH] ASoC: dai playback and capture active may be greater than 1 Date: Fri, 27 Apr 2018 13:31:51 +0200 Message-Id: <20180427113151.19299-1-jbrunet@baylibre.com> X-Mailer: git-send-email 2.14.3 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At the moment playback_active and capture_active are using only 1 bit so the maximum active count is 1. However, snd_soc_runtime_activate() may be called several time on the same dai. This happens when a dai is part of several dai_links. It is often the case for "snd-soc-dummy-dai". This is a problem if snd_soc_runtime_activate() is called an even number of times on a dai. In this case the active count overflow back to 0. As consequence, ASoC functions, such as soc_dpcm_runtime_update(), won't run correctly. Storing these usage counts on plain 'unsigned int' solves the problem. Fixes: f0fba2ad1b6b ("ASoC: multi-component - ASoC Multi-Component Support") Signed-off-by: Jerome Brunet --- Hi, I found this problem while working on ASoC support for a new platform. During a playback, using DPCM, if I changed the backend dai, nothing happened, old backend path is not pruned, new backend path is not added. Here is how it goes: 1 FE and 2 BE, all 3 using snd-soc-dummy-dai for the codec_dai (ATM). On playback start: - BE #1 activates and increments snd-soc-dummy-dai's playback_active - FE activates and increments snd-soc-dummy-dai's playback_active The playback works but snd-soc-dummy-dai's playback_active value is now 0. Through a mux kcontrol, change BE client of FE, from BE #1 to BE #2. -> trigger soc_dpcm_runtime_update(). -> checks fe's codec_dai playback_active which is zero so playback path processing is skipped, keeping the old invalid path. * No change since initial RFC [0], just droppped the RFC prefix. [0]: https://lkml.kernel.org/r/20180419140612.11049-1-jbrunet@baylibre.com include/sound/soc-dai.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.14.3 diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h index 8ad11669e4d8..35ebb0be5114 100644 --- a/include/sound/soc-dai.h +++ b/include/sound/soc-dai.h @@ -294,8 +294,8 @@ struct snd_soc_dai { struct snd_soc_dai_driver *driver; /* DAI runtime info */ - unsigned int capture_active:1; /* stream is in use */ - unsigned int playback_active:1; /* stream is in use */ + unsigned int capture_active; /* stream usage count */ + unsigned int playback_active; /* stream usage count */ unsigned int probed:1; unsigned int active;