From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from codeconstruct.com.au (pi.codeconstruct.com.au [203.29.241.158]) (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 00A023C9444 for ; Wed, 1 Apr 2026 09:14:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=203.29.241.158 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775034872; cv=none; b=s5TE+VRrbMsonOm153QXBokzgHpUOVL6A4auaZq1fzox5hbcCZZ6UgEnWZESOCflkY5Wl+rvJutO0Fg+xpEGseDNZIeuJMBo+hRoWV1YWs7K8hxCvWnAYf21v+cAOGlfBRQZaK2NS9LRrqVyDflBQeZenncjt1JiyQf7xpMZRRo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775034872; c=relaxed/simple; bh=GuqSIVNsuPKeKiOtrThRYOe5+o6JcSmMgNIoqUElxqo=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Kre/j4WIhsu315sRVX1MYi2C+dFeAYV1Y9GCgT0Umj8ozzSJGDIOgVqNYn0x/rs3usClY+gKT6/Ilaw0c4VPH+9SmTRHvkpSF9IXKEvuxiq2loWOIKmmCQqth2UCUughja4AdaVOIl86oWefxm/2sZVbCaP7zbEeZRAtEItij/Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codeconstruct.com.au; spf=pass smtp.mailfrom=codeconstruct.com.au; dkim=pass (2048-bit key) header.d=codeconstruct.com.au header.i=@codeconstruct.com.au header.b=Iler7UFT; arc=none smtp.client-ip=203.29.241.158 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codeconstruct.com.au Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codeconstruct.com.au Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codeconstruct.com.au header.i=@codeconstruct.com.au header.b="Iler7UFT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1775034863; bh=GuqSIVNsuPKeKiOtrThRYOe5+o6JcSmMgNIoqUElxqo=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=Iler7UFT8F7J5wiTy6etV2KZh38RY/JUUq+sOpSM4/mCuGpc1DHW5HOrODwaw2kd1 9/H2/hYVJ7/nNERA4kHb7pxGN8XNdTzCUNyTRMIOwdAM4/s92XkiHZi3U7VA4yFLQm XBYzaQqOPU5/vHpny8VzQhj9ck3yU4QhzTgzPqzDF8LRnmqQmP2+E7Fgl2H0ehfMrQ gzUm5CxbHYadRmUwDon1zajvA2pXsBOtRmIBo+wi+WTyyeK970g+fwaTsgcBojPNG5 I4Q8peiOoGJrkn+X53fcyD8YzBtLInHinYRfeZX+chZVM0wWVKy+JukcPNtFEjyMhn hKIa4ycX+pPFQ== Received: from pecola.lan (unknown [159.196.93.152]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 7B8316506C; Wed, 1 Apr 2026 17:14:22 +0800 (AWST) Message-ID: Subject: Re: [PATCH v2] i3c: dw-i3c-master: Fix IBI count register selection for versalnet From: Jeremy Kerr To: Shubhrajyoti Datta , linux-kernel@vger.kernel.org Cc: git@amd.com, Alexandre Belloni , Frank Li , Joel Stanley , linux-i3c@lists.infradead.org Date: Wed, 01 Apr 2026 17:14:22 +0800 In-Reply-To: <20260401084430.436059-1-shubhrajyoti.datta@amd.com> References: <20260401084430.436059-1-shubhrajyoti.datta@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2+deb12u1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi Shubhrajyoti, > On DesignWare I3C controllers where IC_HAS_IBI_DATA=3D0 (such as versalne= t), > the IBI_STS_CNT field (bits [28:24] of QUEUE_STATUS_LEVEL) is hardwired > to 0. The IBI status entry count is instead reported via IBI_BUF_BLR > (bits [23:16] of the same register). >=20 > irq_handle_ibis() was unconditionally reading IBI_STS_CNT, causing it to > always see 0 pending IBIs on versalnet and return early without draining > the IBI buffer. Since INTR_IBI_THLD_STAT is level-triggered against the > buffer fill level, this left the interrupt permanently asserted. >=20 > Detect IBI data capability at probe time by writing the IBI data threshol= d > field in QUEUE_THLD_CTRL and reading it back. Use the result to select th= e > correct register field in irq_handle_ibis(). >=20 > Signed-off-by: Shubhrajyoti Datta > --- >=20 > Changes in v2: > Remove the fixes tag The base context looks better now, thanks. One other question though: > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/* > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Detect IBI data capability = (IC_HAS_IBI_DATA): write a non-zero value > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * to IBI_DATA_THLD and read b= ack. On controllers like Versalnet > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * the field is hardwired to 0= and the write is ignored. Restore the > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * original register value aft= er detection. > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 */ > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0thld_ctrl =3D readl(master->re= gs + QUEUE_THLD_CTRL); > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ret =3D thld_ctrl | QUEUE_THLD= _CTRL_IBI_DATA(2); > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0writel(ret, master->regs + QUE= UE_THLD_CTRL); > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ret =3D readl(master->regs + Q= UEUE_THLD_CTRL); > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (ret & QUEUE_THLD_CTRL_IBI_= DATA_MASK) > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0master->has_ibi_data =3D true; > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0writel(thld_ctrl, master->regs= + QUEUE_THLD_CTRL); How are you binding the driver to this device? Are you using a unique OF compatible string, or something ACPI-based? ... and if that can be specific to this hardware instance, would that be an effective mechanism to select the IBI read method instead? Cheers, Jeremy