From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3579334C3D for ; Tue, 28 Jul 2026 15:58:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785254285; cv=none; b=oSSrMtklHjHDVwKp+dnzPHG/YwpAvSHpG9Z8XAmheESOVgxDe3bVBXIn3qJly9UcMuMZq3wCGLoNEZBIrAIIo+IJFxdux3szAf4Cnn0HUGGshgUsG+YB/Czcnz5WY/s4VQ+IhAEutcPVWM+EfRJ4ipwtz83BdvNSWphSfWOK/Ss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785254285; c=relaxed/simple; bh=wzrSebO+w9w3kBvI6MwAzB5vFBayEMq0YCoanNZiL5o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PgZZu8cw3Yetn5azUSPrw1SUseNsRb7SO9E3RwPDM6CHkYRHoMOio8yHtUItarprmFaRSjfn5F8VBFVILn+tsz7pU8MWxanuOc8MXhHjQkbzcWWsurMvbngpp6DPdFowv0GwFp+zzA+4EjL4GTwsRS9BEoX4dhSKNF0bR/aJak4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=EQll9DjO; arc=none smtp.client-ip=209.85.167.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="EQll9DjO" Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-5aebe49b227so1090207e87.2 for ; Tue, 28 Jul 2026 08:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1785254281; x=1785859081; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=BoQDMsK71P8WdtwDto5BJ9mnOWyzEPnr5SRIuRHG/wE=; b=EQll9DjOmX0bLFvEzRKdIaMcEG1NvO0XhJjnUEpJNoOJsPq0x2ke/Kp0HM9EYRe1E/ lViPQJtf7h+aDPCftN39sYmWMkMdaEzUsKJY0yBDgTg1EXTDcqQxxNxRHszMMAe/PZWE iK5b+HBqOHFLjDx/iPBKooyOkWpL67+pI5WfInnJ53KGMkr6C7sU5o4WtEKshWe6txX5 kdzZhCwlDfNVCogYp4f2CwIBw4QiqnwKXCiyrY35a426X0+/Dbiwu0iUVQNjwvpqP3Ma hoqQ+H3k4ScFZn855pFJJq2U7VOPVcg89KYGVANOl406W1Ava6FfslRP767NDF4ViBcc z5uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785254281; x=1785859081; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BoQDMsK71P8WdtwDto5BJ9mnOWyzEPnr5SRIuRHG/wE=; b=l6hWHu/WLrFqta+eBmZuvf6Rh+CP3xKvHhZp7F2IfANQ7ODr2IY1sP4vh+lJMKXjbc 3ufoHgugClnomtsfF7gqLPh7E8p6sIGZIOIYy/4D3DTXqIUAMy2GtKWFsaP8rZ4SMYA5 QK9kEAK9m50NhneiyW6Q0OHihAfK/s71oJ22M3yFzagKcGXKlDFQJELoYAX4aQg3dvPN hNuirqrDVx8t/K2Di7hh7kja1IkvDJBY+BbacMNH000PLFQ6fqrEpbqUffNqNe6/v43L GF+C+PdKSDqLKoK56+At9vi1X0JaY8c1Zdn5hvjBBdwr82AoCWfSjEpI9Op8RiUMg18c DQMQ== X-Forwarded-Encrypted: i=1; AHgh+RqjZNFDXolil6RtzbGYtE4vwk2CdJ4pdE/4JgQNfFNhxm9CAwaZvi4TmWGbsOfk9Pq0WAfUg+fP1GDHsJY=@vger.kernel.org X-Gm-Message-State: AOJu0YzI9PdKNevp1ALt8NswhW2KJYcZDcl+Ucn9kYqtjz2+St7nyDsP 0OrYvxwTfDsNhWYv7XcIoTx7NtoQyqOR9yhP7AF3rIOq+Z5pKMCO2wl+ljaxo1SOgBUQl5kJi5T Qwz1nJtQ= X-Gm-Gg: AR+sD13JMbB+tT0NR+Sy/uDLvj8juSS+pgOHsIonpYQd/KXCbO0DKg+tFHzag/5o2qV sK8RT4AErxnn+u5FAoumkmaoWJCvwJ9tUlRFQ0I8KavLgqDaF4XYa/GR9nod+AeeUe96Woli6F1 1NEsJIHqN0n/cUw8xc31fxaDAoFn9sUyo8ToZEduRAlR8ZIE37R3zECK8dz05tLvq69swJljKz0 3notnEGfB7rnkVmeD/mQfkZmWkMHKh357OhJVoptWFKgeUnjsllsfOpkPOSZQkU70gjksuSJyvZ nV9H1pqkn4zwmXw7cu0SrjMRlhcaaRlbsQpxQqHUEQN0B8P8S6qcbWGuvNJQjZwS07egZBTJYwo EjxIuDU8Q9tdrD4USo6c5Mm6yfmLLf1LMHwqZhb+xC4YsBI/O/CdyZq22IHj71B2Hy97sj1hgyw XgwgBM7QAA+pGGEV/MeT5exy5K/tnB11l44x9XEsQkieLv3cAclNvz8eNw X-Received: by 2002:a05:651c:1504:b0:39b:302f:feb3 with SMTP id 38308e7fff4ca-39f51eaf43amr3268711fa.5.1785254280452; Tue, 28 Jul 2026 08:58:00 -0700 (PDT) Received: from [192.168.1.100] (91-159-24-186.elisa-laajakaista.fi. [91.159.24.186]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-39f2226c208sm19436771fa.41.2026.07.28.08.57.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2026 08:57:59 -0700 (PDT) Message-ID: <9fc0577e-ce2a-43fe-85ac-e382e930d5da@linaro.org> Date: Tue, 28 Jul 2026 18:57:59 +0300 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 v2 3/3] i2c: qcom-cci: Fix CCI clock rate enforcement To: Loic Poulain , Robert Foss , Andi Shyti , Wolfram Sang , Dmitry Baryshkov , Luca Weiss Cc: linux-i2c@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Wenmeng Liu , Konrad Dybcio References: <20260727-cci-clk-fix-v2-0-c3958f28b045@oss.qualcomm.com> <20260727-cci-clk-fix-v2-3-c3958f28b045@oss.qualcomm.com> From: Vladimir Zapolskiy In-Reply-To: <20260727-cci-clk-fix-v2-3-c3958f28b045@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Loic. On 7/27/26 12:21, Loic Poulain wrote: > The hw_params timing values (thigh, tlow, etc.) are in CCI clock ticks > and were calibrated for a specific clock rate per hardware variant. If > the clock is running at a different rate the I2C timings will be wrong, > potentially violating the I2C specification. > > Rather than just warning about a mismatch like before, actively set > the clock to the expected rate, using the OPP framework so that boards > which (will) describe an opp table also get the required power-domain and > regulator votes for that rate. The OPP table is optional, boards without > one simply fall back to a plain clk_set_rate() behavior, so existing DTs > keep working. > Can you please share any deficiencies you see, if a regular mechanism of 'assigned-clock-rates' is used in dt descriptions instead of setting a supported clock rate from the driver? Or is opps mechanism supposed to substitute it? For instance qcom,i2c-cci.yaml example uses 'assigned-clock-rates' properly, in many .dtsi files (NB, but not all, which means for a number of platforms CCI hw programming is done incorrectly today) CCI clock rate is set this way. It seems to be sufficient to get the clock rate in probe, compare it against the supported clock rate associated with a wanted mode, return -EOPNOTSUPP if there is no match. To get a better idea of my proposal please check this simple commit: * https://github.com/torvalds/linux/compare/master...vzapolskiy:linux-lpc32xx:cci-speed-modes > Tested-by: Wenmeng Liu > Suggested-by: Konrad Dybcio > Signed-off-by: Loic Poulain -- Best wishes, Vladimir