From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (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 BC26B18E20 for ; Wed, 22 Jan 2025 00:23:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737505390; cv=none; b=p6nN7a8dLcvQ1cq+2/5/fersfM5B2hu0vlKNfr+Irgm2fQLjwcI0LLIH05tqjUlas6LUaV5Lyg+ppYOIylx3oVl65fd1YUoLLpLsidhSf9vok+nva7D4UASJw3P0FUhc6IMbGC67jbX7r15VzVfPMupKVuPGIrHBdv9nJMCymkc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737505390; c=relaxed/simple; bh=4yCpljMzPlAVYGrTlq8EYb2mmWKfdU7nrndVdkCBQKQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=d8FxOcgR6KTLLZcccoAtXyi9LTnmd5tafrsoE/aQAYQNywl6oxibqegDluZCj/ghUX8qcuZNWZPk0yI7uhzJdbefssuy3/8ycl/3DE4V8/r2QusEqlhTR3zNhVQ7HQRohSJu7Zkq8H711fEqAk3oiVnfa35CKCRwoFL0K6OeYMw= 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=s6nfezr3; arc=none smtp.client-ip=209.85.208.174 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="s6nfezr3" Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-305ff7d1f3fso4713001fa.3 for ; Tue, 21 Jan 2025 16:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1737505387; x=1738110187; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=u0HJqNUI3/7Fv7C3ghrvDvyETXZbWbMIAg+sHqC9AMM=; b=s6nfezr37lPhkB6njjLcE6VP7emBUg/LpKFDIGcW9DDdeZ7rvdgTFia64rMNNamGUu YaBlXCzFq6ks5NWnUKT/FiBqkd3dy+upMBoDUoaoZ1S6NCBDJ3yAiAxEf5Aa9iKy9n41 RCTCQXwXR3PEpXdCkpeMnT+9AzlSumV6J2aAJsG/LSbjLolIjc39RoUoAUflydfx8RVZ J0dH3fAQGqxHnmERYyXi76ryxcEe71dFA+LGp/QuepSZ2zbd3qqXxCbXc+UNBFeFGP+8 MQQDqAarjQoQelOVgW9fV8VlYcrapveocn7cMaLgabPGQTFIH55a9q1y5QqK0vF1lYYe HnsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737505387; x=1738110187; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=u0HJqNUI3/7Fv7C3ghrvDvyETXZbWbMIAg+sHqC9AMM=; b=BQuy1Aa/Tadld1Qr8YQPQuSaiqlAkrbMg9I925JvOB/NHzgih60q+KWVJ/N9dm8yx7 f+LPlFAOICQ09u5ir8UAH40ElmqBtFEDDNBRCaAUnbzadx/R9trwI703NKF5qU8NE1h3 x1XEosyPkYuJbrUdwdh1E1NfsMoTz79W459LqCLJQWvNeIt6bSi3AdpZFFed2vVpKsxP 7jM7Yw4DACK0J/yiN+0vcX5gWpz3ylO0LnBhxn8LErYvk7LHOfMjeD6iSoK34EUgQdWw W3vTRhpucSXdufi4nrrfIEiHGCIS5rY6BJh7Uedas9oHG9ZgbMLiYAxBnO56GqZ6N3tr 5D0A== X-Forwarded-Encrypted: i=1; AJvYcCXYSBvbXwcflc5NUk3V4IAZqwbAuB67rECwMoHBUSAc+yrJTdGaRySw4F/4Y6Lua0W3COmmmKRC7TIt12Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2xLDh2AaGfk4uVtS6NH4lQhdTFAT7K8Dn2H06yiy+QQJh8fGU XyqiDIM5wy9KCgTtyjvoigC9sfGkyQZmZVZjjmMgGCWmtYBrDSeU/4LagEk0rB8= X-Gm-Gg: ASbGncsAoZ+w/AWspIgJo9cdM6GByeyHXIztexJet5DgQSt7IJELC6XqYr5KrBWvAI0 ldrr18+agLVd8W+J8kwJAhPzheR5j+ouSCE+oI/pBQ7YUSQhnNPmiaSrmEI8NoHXqNSuo0q7XGf nozfZOnuzhCB0YRbGV8296cFG3n/RLE7EEzi9B/cD8kQHnR7PfV4uqWFb5i1bw3XmZknDYul9nh japm52d4ihK1Aad3oZgU11hXOdxAyLuD5rEowcMiHW7Ey6piBC+6IAp5f8bJoL9Ubllm+eFwtVn Hc7SWmmL93rZKZH0iRHh2vEnCmAaaBlHFHI9bm63CDd9XvPB X-Google-Smtp-Source: AGHT+IGehczE7c0uuAo0Zo0nBz5xQR/MBgNuOF0Q3+9sCbYo6xr1LGkNlCSvRELQ1OyRp1ZW7lODuA== X-Received: by 2002:a05:651c:221e:b0:300:c10:7c33 with SMTP id 38308e7fff4ca-3072caffef9mr24267851fa.7.1737505386792; Tue, 21 Jan 2025 16:23:06 -0800 (PST) Received: from [192.168.1.4] (88-112-131-206.elisa-laajakaista.fi. [88.112.131.206]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3072a3446c8sm23683521fa.27.2025.01.21.16.23.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jan 2025 16:23:05 -0800 (PST) Message-ID: Date: Wed, 22 Jan 2025 02:23:03 +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 5/7] media: qcom: camss: Add support for 3ph CSIPHY write settle delay Content-Language: ru-RU To: Bryan O'Donoghue , Robert Foss , Todor Tomov , Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Depeng Shao , Vikram Sharma References: <20250120-linux-next-25-01-19-x1e80100-camss-driver-v1-0-44c62a0edcd2@linaro.org> <20250120-linux-next-25-01-19-x1e80100-camss-driver-v1-5-44c62a0edcd2@linaro.org> From: Vladimir Zapolskiy In-Reply-To: <20250120-linux-next-25-01-19-x1e80100-camss-driver-v1-5-44c62a0edcd2@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/20/25 17:47, Bryan O'Donoghue wrote: > Currently we have an s32 value called delay which has been inherited from > the CamX code for PHY init. This unused value relates to a post-write delay > latching time. > > In the silicon test-bench which provides the basis for the CamX code the > write settle times are specified in nanoseconds. > > In the upstream kernel we currently take no notice of the delay value and > use all zero in any case. > > Nanosecond granularity timing from the perspective of the kernel is total > overkill, however for some PHY init sequences introduction of a settle > delay has a use. > > Add support to the 3ph init sequence for microsecond level delay. A > readback of written data would probably accomplish the same thing but, > since the PHY init sequences in the wild provide a delay value - we can > just add support here for that delay and consume the values given. > > Generally these delays are probably not necessary but, they do speak to a > theoretical delay that silicon test-benches utilise and therefore are > worthwhile to replicate if the given PHY init sequence has the data. > > Signed-off-by: Bryan O'Donoghue Reviewed-by: Vladimir Zapolskiy -- Best wishes, Vladimir