From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (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 2D0533BE167 for ; Mon, 30 Mar 2026 10:39:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774867169; cv=none; b=B6sfyAEZ6X5SRkh1z9IKkJNSKXHEcotqUzwEHNhc5gHjrApsmE80SgcbCLY0C8g9BfO3WxvQNzVEN0nHdac9kobTub/YHZKj5vsWGC7eoksuu1EaBjcN79M86XxCi4eY8SgvY/nH2zcNx6a9VF7FspbYywSQq2YWvnroIIvGPyE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774867169; c=relaxed/simple; bh=Yhx0f5IKrfL2voq4NVHqWSkTdxT4Ya1YHwbFpIGoERM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=JbMTY1E4pH95v72CVc4g97uGv2NrTxaPc3H8FIeLJjZV5zrCe0drXLUGBvioU+6Pa6U5rOUIKd+3Gmo/UZ3q9yp0PlNP+mTdZWQLyvKVyWSMDRUUPSzyINrSBbP7Wf2r1kBothkDahzmFUQh/MMZNaEcm1XKCnnFjHuw5Kc3GB4= 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=OIShHM02; arc=none smtp.client-ip=209.85.208.170 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="OIShHM02" Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-38be3a161a9so6987631fa.0 for ; Mon, 30 Mar 2026 03:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1774867165; x=1775471965; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=kjWd3BKgQaFoYYfVE9rGe8nNVHUMawLjZDnU5IK/ObE=; b=OIShHM02C/ZgP3gmBpqyCOhXlqo9zNQu6Timg2DscitXyFv4A25AcOy59rHduPs21J m30Ej0lb8v21o6TKkMhaUmqenxCDjQZlqUZ8kdof1o4JNZSxasEyQbw98uZ4PmEFUqR+ 3K0/ohIWeOAJUikNV/ZITvwq8sLpA1ZhhZfHcwt9oyhdIJcRAWhcGHB8l0pJxOeMwxme uf+CPNmAV6zJ0dDH3b9xbjiS98/2Ulgs+q8+swiSwhM4qusKUrcyg304GKgWeg5NRi+7 lG3hQ6VkmgtXMixa+p7Mwe8LIy3OF4oDjPSfLaDvw8e/nxD+ZWTTVVr31z5yNG4b0V+I CEUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774867165; x=1775471965; h=content-transfer-encoding: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; bh=kjWd3BKgQaFoYYfVE9rGe8nNVHUMawLjZDnU5IK/ObE=; b=cGoeq8j+U5wonI2Rm7aE/ex22yuiAogUjAvC3jfC59qnwc0HLAhyWip0ClNNbKHssU J67LM3ML3FdK4RP8DPdWk7UE8brcHz9PssmxaKZCkvN2REhxAO+l1dsmxEP04ONAIb4W lAh8Ng1ZBhLt5IiVwKZgVr8yXdUdWxHqn9kJN+aEy9xwKgW+ISDUgXfSWZihWIwMr5RY vddFaz+4FyoYXn4Jb2bHVBh9/TSADFVhCZu3Lolc83JWajmCpyEKC6wGhA8RQ1jCoyA6 wGOGA5vxVrhunoKrpwUWh+w+s6dI0kVptXQN4q/lZzv/dZs2YmTA/1GZmt56ATlfvhVZ CPIw== X-Forwarded-Encrypted: i=1; AJvYcCVIe1GSKxOTaHBAfaEEzkIlRcAErZbn7B0BaJcAsM2gJQMAm9CXWQDiwRpl2zm0uBky7KRQ46PSZheVMSo=@vger.kernel.org X-Gm-Message-State: AOJu0YwxhnI/x8RW32llyetb8NRiBkowcHE1y6V4mxY9nHXDGqBmCgSS wiAsygcCb334w5N6GvIGtDWWxGJbakxORYdk7VpEmp2hiA+FMHch/Y7sB/iRSxodkQw= X-Gm-Gg: ATEYQzwE0aKjvYg3oMUUWM3oMI/LTKRWP1mf5Av/mqVXa38paaPzkvJRmYN0TZvw78l eRMZWFr2MRqhdNOpDGvZwZLRsQetWlOG6PACUeJSE4QJ+jrVvQ58OlffC+gALawH4f2XDJGdZFg 5HS2oZrTDDQbzb/3q4AU2DZaa/BEeSaFRrUHZhPHU/zCPbYzAAYfUv9Vs9l0XwJFNU64/ffkhsu xDq6nNO2UvFC54a7DPJfMwGXBICl/9nKE8h4+jlCFn9trn5rKslQmkt7WRCVIrrS7QwkB5Pf9Ma myZ70Pjg1Jukvc1Ftaq60GiUrrNSfeXkJ+xkOKR9Z4/o8WbzPszMFaEcVYokYK6Eqg/E2OmiRLd /schvyPw8RUx2RjJHCjKBbl5WzzOlStkTmDh4vgLR8S+ekK5UxozqnBoROPBVMvdECAs85w+Js8 BDby2f9Cl+tE1CoVnGSCL/xa7v+rZYOHh4caq/ykckgIUjYClHiMm5B/QRMDdTDTXfhOaK3k9cH aBF/Q== X-Received: by 2002:a05:6512:514:b0:5a2:abe0:dada with SMTP id 2adb3069b0e04-5a2abe0e165mr1264088e87.1.1774867165161; Mon, 30 Mar 2026 03:39:25 -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 2adb3069b0e04-5a2b13f4294sm1570390e87.8.2026.03.30.03.39.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Mar 2026 03:39:24 -0700 (PDT) Message-ID: <6870033a-a483-401b-97c6-1df5508181b8@linaro.org> Date: Mon, 30 Mar 2026 13:39:24 +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 v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema To: Bryan O'Donoghue , Neil Armstrong , Konrad Dybcio , Vinod Koul , Kishon Vijay Abraham I , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: Bryan O'Donoghue , linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260326-x1e-csi2-phy-v5-0-0c0fc7f5c01b@linaro.org> <20260326-x1e-csi2-phy-v5-1-0c0fc7f5c01b@linaro.org> <7712fbdd-a225-49f0-aeb9-ebcbb9d5abac@oss.qualcomm.com> <1f38187a-9464-4aa9-b70a-03b767349d56@linaro.org> <016c03b8-27c3-41dc-a630-8e7095db1f88@linaro.org> <456ded59-d13e-4b61-975b-97ca48b5e771@linaro.org> From: Vladimir Zapolskiy In-Reply-To: <456ded59-d13e-4b61-975b-97ca48b5e771@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/30/26 12:02, Bryan O'Donoghue wrote: > On 30/03/2026 08:49, Neil Armstrong wrote: >> On 3/27/26 18:42, Bryan O'Donoghue wrote: >>> On 27/03/2026 15:28, Neil Armstrong wrote: >>>>> To be frankly honest you can make an argument for it either way. >>>>> However my honestly held position is analysing other upstream >>>>> implementations connecting to the PHY means we can't make the PHY >>>>> device a drivers/phy device - it would have to be a V4L2 device and >>>>> then for me the question is why is that even required ? >>>> >>>> This is plain wrong, DT definition is different from software >>>> implementation, you can do whatever you want if you describe HW >>>> accurately. >>> >>> I'm not sure what point it is you are trying to make here. Are you >>> trying to say drivers/phy is OK with you but you want an endpoint ? If >>> so, please just say so. >> >> I'm against using the "phys = <>" property in the CAMSS to reference the >> PHYs, a "PHY" in the classic terminology is tied to a single consumer, >> and if it can be shared to multiple consumer you must model a mux or >> whatever in the middle. > > The CSIPHY-to-CSID routing is runtime-configurable and is already > managed by the media controller framework. > > DT describes static hardware connections. The dynamic mux is a software > concern, not a hardware description concern. > > >> The PHY API as an internal software implementation is probably fine, >> even if it makes implementation of split mode much much harder and >> doesn't really solve anything, you can just call init()/poweron()/ >> poweroff()/exit() directly from the CSIPHY media callbacks. > > Great. > >>> I can see an argument for that hence my response to Konrad, I just >>> don't see why its a Qualcomm specific argument and of course >>> understood stuff bubbles up in review, we have a public debate and >>> come to a consensus - that's a good thing. >>> >>> However, I'd want wider buy-in and understanding that endpoints in the >>> PHYs is a more accurate description of the data-flow. >> >> It is, and it was designed for that, and extensively used in the media >> DT representation, so I wonder here you would not use it... >> In an ideal world, you would add nodes for each CAMSS hw elements and >> adds port/endpoints links between all nodes to describe the data graph, >> this would be used to construct the media controller graph, and make it >> much easier supporting new hardware. > > Yes but be pragmatic Neil. The first step in making the monolith into > sub-nodes is the CSIPHY. > > Once the CSIPHY is in, we can follow on with adding new nodes that way > IPE, BPS, ICP, JPEG whatever and also work on implementing the old stuff > in that new way. > > >> >>> >>> We've been applying DT bindings aplenty without that so far. So we >>> would establish new CSI2 PHY bindings should represent the sensor >>> endpoints. >> >> We've been using a dummy representation of CAMM in a single node with >> only endpoints connecting to the sensors and hiding all the hardware >> layout in code, it doesn't scale and makes supporting new HW hard. >> I mean this is common sense, why would we continue to stick to the >> current CAMSS bindings ??? > > We _won't_ I just don't support a big bang integration. Progressive > changes over a longer timeline make the transition manageable, without > accepting endless sub-standard stuff in the meantime or holding up all > new SoC submission unless/until. > > I mean there is a CAMSS meeting which I've been running for nearly a > year now that both you and Vlad are invited to where we have been > discussing this for months... The established process of Linux kernel development is based on email discussions, the sent changes including CSIPHY dt bindings were plainly ignored by the maintainer, because it's a NIH material or whatever. There was a chance to discuss CSIPHY dt bindings changes one year ago, now it might be not a coincidence that eventually after the series of updates the new CSIPHY dt bindings will be very close to the once displayed ones, it took a year, but still this is a good progress IMO. -- Best wishes, Vladimir