Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2356314ybe; Sat, 14 Sep 2019 13:11:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqzLdecVb9XN71ahiePMZKDa+fGErQIskPTIrRLrFamb70wH5flI0tavs5vvFjdXqX132pL8 X-Received: by 2002:aa7:c80e:: with SMTP id a14mr36284701edt.205.1568491918897; Sat, 14 Sep 2019 13:11:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568491918; cv=none; d=google.com; s=arc-20160816; b=lqRZniChrxsGQcE2HJZmij8ky7OUbeAdC73xxm0KDokiphNoCvOnSXcdxVLGGQ3py/ UuvQNd8LHobro32R8vL6e297V+SduajgeQur+OTHVMeCdtz0O/GSxNA6zOv1htuzP2/g saNQG/z9M5RVhnPNoEJjiR7YfYcxMvvRb8sE83ZqBToGOONsxCqeWWwRRgY7OQCPLt/U QdaEj1a3/2umYR0cZy+a5aR4BzNpCjhwHouYbDcmcpM4KLJR8t9KxzzBhM2I0Yg0WyTZ cY8TJWXbat9OsaU4/uDTN3/RC8GxP6lmFciv5fr4IXVRO+wUA7J3EKpBrBos5kZVCNTp JstA== 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; bh=8oy1EiYOKedMbK6kCjbWvN4F3gY8adLU7DVmy7snBTU=; b=DJ6OiszLy2vtrLZZZn91oJs+oXjYErKxVU5U0NXryLzxGyUR55DrOqWUS3KNIimExb bXrTKnjPuUDpML2ut0lJP/J3sMVISjT/mdJUYNeZrqDGDms8a/doFSh9TdOOzUoTn4/6 kG7FHwea782TLQbBiTPFhOYyzlRxnGoYagKzvFNuBdP0P1jKJXLHI3ZbSqCQRf1tRcyc 5LnWukp1IX46x3+5f7FLR5acIrmhhbO4GB1lY0SDzVjlOwsgVRBl/hgg9MrptklUACtV TtMbqXzsCkWHYfGKKH6xCWr5ohs3wf5kkkgO/v1i2Jn/w9kM0782T1jcUyQCjag+cDA5 82Nw== ARC-Authentication-Results: i=1; mx.google.com; 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 g2si16358679eji.228.2019.09.14.13.11.33; Sat, 14 Sep 2019 13:11:58 -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; 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 S1726795AbfINPZA (ORCPT + 99 others); Sat, 14 Sep 2019 11:25:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:43260 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725920AbfINPY7 (ORCPT ); Sat, 14 Sep 2019 11:24:59 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id F0887AEB3; Sat, 14 Sep 2019 15:24:57 +0000 (UTC) From: Takashi Iwai To: Eric Anholt , Stefan Wahren , Greg Kroah-Hartman Cc: linux-rpi-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH] staging: bcm2835-audio: Fix draining behavior regression Date: Sat, 14 Sep 2019 17:24:05 +0200 Message-Id: <20190914152405.7416-1-tiwai@suse.de> X-Mailer: git-send-email 2.16.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The PCM draining behavior got broken since the recent refactoring, and this turned out to be the incorrect expectation of the firmware behavior regarding "draining". While I expected the "drain" flag at the stop operation would do processing the queued samples, it seems rather dropping the samples. As a quick fix, just drop the SNDRV_PCM_INFO_DRAIN_TRIGGER flag, so that the driver uses the normal PCM draining procedure. Also, put some caution comment to the function for future readers not to fall into the same pitfall. Fixes: d7ca3a71545b ("staging: bcm2835-audio: Operate non-atomic PCM ops") BugLink: https://github.com/raspberrypi/linux/issues/2983 Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai --- drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 4 ++-- drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c index bc1eaa3a0773..826016c3431a 100644 --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c @@ -12,7 +12,7 @@ static const struct snd_pcm_hardware snd_bcm2835_playback_hw = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | - SNDRV_PCM_INFO_DRAIN_TRIGGER | SNDRV_PCM_INFO_SYNC_APPLPTR), + SNDRV_PCM_INFO_SYNC_APPLPTR), .formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE, .rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_48000, .rate_min = 8000, @@ -29,7 +29,7 @@ static const struct snd_pcm_hardware snd_bcm2835_playback_hw = { static const struct snd_pcm_hardware snd_bcm2835_playback_spdif_hw = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | - SNDRV_PCM_INFO_DRAIN_TRIGGER | SNDRV_PCM_INFO_SYNC_APPLPTR), + SNDRV_PCM_INFO_SYNC_APPLPTR), .formats = SNDRV_PCM_FMTBIT_S16_LE, .rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000, diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c index 23fba01107b9..c6f9cf1913d2 100644 --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c @@ -289,6 +289,7 @@ int bcm2835_audio_stop(struct bcm2835_alsa_stream *alsa_stream) VC_AUDIO_MSG_TYPE_STOP, false); } +/* FIXME: this doesn't seem working as expected for "draining" */ int bcm2835_audio_drain(struct bcm2835_alsa_stream *alsa_stream) { struct vc_audio_msg m = { -- 2.16.4