From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40CD9376BE0 for ; Mon, 18 May 2026 08:17:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779092223; cv=none; b=k/b9dHrNXp1F+BdN9dOWoQTGKvtZxzhCaT851mHqcFrH/GSYCAFPIlWKUNswKAC+SeslAmL3a10PiIkctRjQbMFdO4b60sfvX8GM/up2DClALqaLVv8Eq1utf0sjOjyZyKiuPUmW0tCrdkGP9jxmyZm+jSX6STnbDoGRABseD80= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779092223; c=relaxed/simple; bh=hmo7xAisfGDuO9lHtx2j6W0/MRRC5RDwpKNc3RaE4u8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=f4tADoO2jy2YtTI5Rz3UL1gZH4a9FNUygeLwZqHZbkK1N356yMyjH0wW5Kru/txLIT/VvtGeK+8pdmWdckCxtpcUAi0kCOB9DIY3Z5/i9bwJORetfMxNbLMB6ZOXVzCOeBSUoNLmZwgocRdMTWA5U0LQS+B6uKjdyOFvE9/TjBg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=eEE7zizW; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="eEE7zizW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1779092220; bh=hmo7xAisfGDuO9lHtx2j6W0/MRRC5RDwpKNc3RaE4u8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eEE7zizWS9T3Ox5T2mnIhSGj7sgbuBAlPsM2FZHoYTVWZic1h4CMf0vq3mP7YG75x 7gJKJr6Rtr9kdy9Ut2f6vuWF7o2lACoH+VReVLNbuEl26o93pDGGcXl8WLL7Jj0R6t 2lmr9jU9tNPUXfgVoCBGZ1HgOM/TLjkEynJVayPXBWQz72JIg+Ku+jCuYJCWi514FE W1Dz5KMLmYU0DpLgZhoiNf8C9zQFgMiCh3+22Nls0huOqAOfgqnxgXw5DKL6T8wbPG SkzHTY2DoWXt+6fDfI9hPKszRCMXS5egV+9hQPNQ9t5S/ohU1F38HZBSO4rxYZNoNd q7gJIfp2HuSuw== Received: from fedora (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 2F73717E0566; Mon, 18 May 2026 10:17:00 +0200 (CEST) Date: Mon, 18 May 2026 10:16:56 +0200 From: Boris Brezillon To: Steven Price Cc: Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 08/11] drm/panthor: Automatically enable interrupts in panthor_fw_wait_acks() Message-ID: <20260518101656.6426fb18@fedora> In-Reply-To: <44d8b158-76bd-4ad5-9fd5-616afd432155@arm.com> References: <20260512-panthor-signal-from-irq-v2-0-95c614a739cb@collabora.com> <20260512-panthor-signal-from-irq-v2-8-95c614a739cb@collabora.com> <44d8b158-76bd-4ad5-9fd5-616afd432155@arm.com> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 14 May 2026 15:25:07 +0100 Steven Price wrote: > On 12/05/2026 12:37, Boris Brezillon wrote: > > Rather than assuming an interrupt is always expected for request > > acks, temporarily enable the relevant interrupts when the polling-wait > > failed. This should hopefully reduce the number of interrupts the CPU > > has to process. > > > > Signed-off-by: Boris Brezillon > > As mentioned in the other thread[1] it turns out this won't work with > the current firmware. > > The firmware checks the interrupt mask before signalling the ACK - so > enabling the bit in the mask just before waiting for it is problematic - > the firmware may not see the addition in the mask and will not trigger > the interrupt. Is it a problem though? wait_event_timeout() will evaluate the condition before going to sleep, so, if the FW raced with the input->ack_irq_mask update, I assume the condition will evaluate to true and wait_event_timeout() would return immediately. The only issue is if the FW updates the output->ack register after reading input->ack_irq_mask, but that would be weird, since the output->ack update doesn't depend on input->ack_irq_mask, and raising an interrupt before updating output->ack would be racy anyway. Am I missing something?