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 891DD350A10 for ; Wed, 28 Jan 2026 12:55:01 +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=1769604902; cv=none; b=jJyp5qzNnoW8vq/3sIHX75BzUcL2eQZ/M1ZtTeS6W/ZdTrBP+wB+1f5dOlGP6uA2SxZqupV+kWz3Do6h+IHT0LCbe8GpTYEWgLk23ZWbVA3bwVMBV1U+uWYtJo+vUded2MfdlGRkLvbOpVeKvSHofMMLTYKLalRnkodF9jf5t5M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769604902; c=relaxed/simple; bh=cuw9kNGE9m4JDDerWO2dwAOCNF8vbiPqhzbNFs+GZXg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uslD+kw6pHUhXaH+hSVxM1r2SGjMBOtY76FTukysrgvai6hEZ9286VfVXKRPVcSxqFiysM4ACVL31tXHPP5RZn3T8hjp/AdFdFy037jOcOCty5mf5wjEj4yNFYTsRy6wMuspMIZgVVs7pBG06kCwwV39GGrAqTA4HpbgYHWlsaM= 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=XTEgHLXp; 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="XTEgHLXp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1769604899; bh=cuw9kNGE9m4JDDerWO2dwAOCNF8vbiPqhzbNFs+GZXg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=XTEgHLXpn5MFUgjBeyLRA9uh0Hs8mJ4h2BCQX7E3E76FopbiWuH9aU4YF/cQSzl3/ drsU+JRtUTev5CH1LBVI56pJRk5mBlNi3lm+jZbd8ptvdqOMJjrLSy2HvyP9iAgOZD OAu+DxqulL5EQCrglGzFTpIvmPZWL8cleQ8xpMYxsDsgyHxp08gzI4wxzCbIft/DhN KF30wZiEFvE9yVGR8um+49rLW8eb9IaEXr6N4sGZbI3PfoFyYL9tJRH1H3vJ+Pw4ra 5caKF3WTHHnVIVd7nMqnJizOfdkyNGu5eEWPjrQouXDNE6HT/w1+2npnWlr/JtnElH 2Lba6hThaU+8Q== Received: from [192.168.1.90] (unknown [82.79.138.145]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: cristicc) by bali.collaboradmins.com (Postfix) with ESMTPSA id 448E717E0E3F; Wed, 28 Jan 2026 13:54:59 +0100 (CET) Message-ID: Date: Wed, 28 Jan 2026 14:54:58 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] drm/bridge: dw-hdmi-qp: Provide HDMI Vendor Specific InfoFrame To: Daniel Stone Cc: Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , kernel@collabora.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20260125-dw-hdmi-qp-iframe-v1-0-e0f7649ecc4b@collabora.com> <20260125-dw-hdmi-qp-iframe-v1-1-e0f7649ecc4b@collabora.com> Content-Language: en-US From: Cristian Ciocaltea In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Daniel, On 1/28/26 2:11 PM, Daniel Stone wrote: > Hi Cristian, > > On Sun, 25 Jan 2026 at 00:23, Cristian Ciocaltea > wrote: >> + /* VSI packet body */ >> + for (i = 0; i < len - 3; i += 4) >> + dw_hdmi_qp_write_pkt(hdmi, buffer + 3, i, min(len - i - 3, 4), >> + PKT_VSI_CONTENTS1 + i); > > Given that this for loop occurs in all the users (other than when len > < 4 where it's not required), why not move it into the > dw_hdmi_qp_write_pkt() helper itself, such that the calls for each > infoframe could be dw_hdmi_qp_write_pkt(hdmi, buffer + 3, len, > PKT_VSI_CONTENTS1 /* base reg, incremented by helper */)? Yeah, initially planned to keep the helper simple and allow more flexibility in the callbacks. Probably now it makes sense to also write the packet header via the helper, not just the body, since this is also handled similarly in all cases. Thanks, Cristian