From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (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 16FDA27442 for ; Wed, 17 Dec 2025 00:02:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765929730; cv=none; b=oB1m4lRh/7JNURRsLUqoWTFOWf7rfgRJ6Q33pQE6bvRz83/oYVHaE9nv/wrI6wU2/K57DVWg7klMTv7ysplxdDbGXigrlNvUvY26mW5o2kGYPGJrzgzLBa9e7ruVTW/mHH9UV0lbpy48RE4W21tAa8Py2lelIHukYgpCYN2zUwA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765929730; c=relaxed/simple; bh=4fX+V0YnP016/orDpEqU5FVPZMbBz2SoqmDB72xWnxo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uW/ImneSnT5R58wQ2fiJrbywsMwpROlewpkGi/flgBbSR1Lt/d0Kxq6zbEyjOedmg+3TnN7/HvGi9jHj5XStWaC0k52+z9bPelW7B4dd0Heuyo5EoKZjJt918FMmnpQgWF0VBUFNzsQdTUUCzaLQFg//Low92N40+4/fTk+Me3g= 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=HQlbyih/; arc=none smtp.client-ip=209.85.167.52 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="HQlbyih/" Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-598e9f63169so478296e87.2 for ; Tue, 16 Dec 2025 16:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1765929726; x=1766534526; 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=IESsZe/W5RT7xiwRsUhKBankOTgyA4GaQytGF+x9/ao=; b=HQlbyih/hF8Rr/mlZjbvv+2aMIdGeeus6lTlvrnPcN7MWvKkt+t7SZ+COqi6TGkj8D +yw1C5vTf/mFJLcSn9t0/xsn4lmoemuGL2L1BMPXI/8ddbg334OJomVKdsLSfHIGQeHT M8Wtbwf8rD6gq8aLJZ12whS4DNRZ0UC+O40lCYvCbeKCL1zdFoBCEZkgKWAuOUkf7+4k bi/xBOFs7kK3isMBh5mzUD5MnYHWrQrTSO6pbKMHwt9PQx61sbTB12gdoHIuPYwhc9fq LXDcwgkSDmLXByrkbGz0qJCXnLJG2lXO4YwXzHnzvN9RaTDJpBMrsXlysfKrYF2UoqBG W0vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765929726; x=1766534526; 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=IESsZe/W5RT7xiwRsUhKBankOTgyA4GaQytGF+x9/ao=; b=aSrHvVYksm7boll+dHhijNUlgXwfjOyks5BeM4L8DW5jlN7x2vcoPu4xlH6qOx4oOK VtnaEMwEwoZNPqzTsc/p4BnI2Klvvk/7GtZC69d6IUBpxcQ1IyIjvINhSbewrNCbY7V7 BMkKjSkdZbmm8Qqlra3ObhrY7XnjpASno+QG8B/LdJi/ppK0KFA07NDhfLFCaq7UIeyZ OdoFvDJkUAx0WQhFkho8nbctq8hpDHjxw1Rrc/S301HbIeQh/E/SW3YdsYtx4mP1ezu4 lVsTTQfMOWaTVprz+kh/104/2z9VY0ZQtY7VneCncCyZWNn1nrV79tCrcnvTYh72/UiM dKXA== X-Forwarded-Encrypted: i=1; AJvYcCX4EKQmidois3iS/lBjcvxzfwgYBP7zcF5NaJdcxdlQQictRY+eY2xBXO26MiLqJvANotfoU3yiYc8bWYE=@vger.kernel.org X-Gm-Message-State: AOJu0YyciwyUQMDuCE8fryA9fVIah0YrxDXKeKTLgpbb0SW+ku1XL3A5 yeiwCtEC+K+j3vxiWG0s26NJy3QL5ieiEgIHQvbtfu1ffv6LBfwWTjjQ4pAcHgdFA18= X-Gm-Gg: AY/fxX4VsURP5+zY9tpIHiQN537tctL6qVGZC3e4YAe1IkJ0VFdL39WceuHkMurfD0l +J8cS4Hq5VCf3h+PD1BXZpKv6qcI1C1qGlH7M70CTeESx0mwlYY4BHtNV/OgAJcZFit7qqVzZxS 9sftSYQabiSPLS3Vd7/UFEeX34YDIzBppzYbOE8lxEYiv17BlLcQOA6hyC+/zGBIYyzRFlMkT8B Cm9QbBU2RdheGiv3aiNyO6qSIrFLT4oGv7C50hrIIgwe3ay/CdpyFv9t+5X396zj9+6vafbX0A+ JTbsQtF2jYQJHcTfyCLJ3gwf9JezIYzsDPGZuv1yp95LijqDs+80BotFGlxr/TLm3JCSvXb3mvq LJRbZkUCfTfGUYP1WOek14PEMpc/R4iWz952zsKxG8ck+cypJYUNKFSqYaVS6rdEISsg/gosF64 NY6h2nbyyvwXNVv5eyc0jfXq9QbCnm6O0PrJu10JtN4xkPWoczpdSRfJV3Fric+DWQbw== X-Google-Smtp-Source: AGHT+IFrCa4ZjN33CIw4ShWO7Hf+XIWaZzk0eJOF4MY7Y25K8sz5SXR5eCMOVJwo9hvvGRP1v96ung== X-Received: by 2002:a05:6512:3f1a:b0:594:4c87:a8f9 with SMTP id 2adb3069b0e04-598faa62e77mr3237266e87.4.1765929725412; Tue, 16 Dec 2025 16:02:05 -0800 (PST) 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-5990da1aa2dsm1454881e87.42.2025.12.16.16.02.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Dec 2025 16:02:03 -0800 (PST) Message-ID: Date: Wed, 17 Dec 2025 02:02:01 +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 v6 1/5] media: dt-bindings: Add CAMSS device for Kaanapali To: Vijay Kumar Tumati , Konrad Dybcio , Bryan O'Donoghue , Hangxiang Ma , Loic Poulain , Robert Foss , Andi Shyti , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Todor Tomov , Mauro Carvalho Chehab Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, aiqun.yu@oss.qualcomm.com, tingwei.zhang@oss.qualcomm.com, trilok.soni@oss.qualcomm.com, yijie.yang@oss.qualcomm.com, Jingyi Wang , Atiya Kailany References: <20251113-add-support-for-camss-on-kaanapali-v6-0-1e6038785a8e@oss.qualcomm.com> <20251113-add-support-for-camss-on-kaanapali-v6-1-1e6038785a8e@oss.qualcomm.com> <37d0f89f-69be-45a7-90fa-347d6a3800bf@oss.qualcomm.com> <2d7ac7e8-ab69-44a6-b732-3657abf3a5a6@oss.qualcomm.com> From: Vladimir Zapolskiy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Vijay. On 12/16/25 19:55, Vijay Kumar Tumati wrote: > > On 12/12/2025 4:49 AM, Vladimir Zapolskiy wrote: >> On 11/18/25 20:44, Konrad Dybcio wrote: >>> On 11/18/25 7:25 PM, Vijay Kumar Tumati wrote: >>>> >>>> On 11/18/2025 7:00 AM, Bryan O'Donoghue wrote: >>>>> On 14/11/2025 03:29, Hangxiang Ma wrote: >>>>>> +                  <0x0 0x0900e000 0x0 0x1000>, >>>>> >>>>> Why aren't you starting @ 0x0900e000 ? seems to be omitting some of >>>>> the registers in the ICP block. Should start at +0xd000 not +0xe000 ? >>>>> >>>>>> +                  <0x0 0x0902e000 0x0 0x1000>, >>>>> >>>>> Same here. >>>> Hi Bryan, HLOS does not have access to those registers. They are >>>> configured by the Hyp. >>> >>> If that's hyp, please add them. We already have platforms without >>> Gunyah. Remember, bindings are defined once and for good and I wouldn't >>> call it impossible that someone would want to run that configuration on >>> Kaanapali some day >>> >> >> If the ICP register block is added now, then it will practically exclude >> an option to run hardware demosaic on Kaanapali. There were notorious >> and still unresolved problems with CSIPHY blocks, which shall be split >> from CSID/VFE CAMSS on device tree level also, for similar reasons the >> same should be done with ICP or other blocks. It makes exactly zero >> sense to pile everything into a monolythic device tree node, and doing >> so undermines any future advances in CAMSS support in the upstream >> Linux, the hardware description in downstream is done thoughtfully >> better, >> and not for no reason. >> > Hi Vladimir, yes, this has been discussed in the past and the general > consensus from everyone is for not blocking KNP series on this. But yes, > there is an ongoing effort to modularize the bindings for future > chipsets and when it's ready, we can review, discuss and take it My concern is that it makes very little sense to throw any not clearly defined hardware properties and interconnections into an unorganized and unmanageable pile of everything, because this closes the door to ever update the upstream CAMSS driver by adding better CAMSS IP support for any already manufactured and sold Qualcomm SoC powered board with done CAMSS support. If some user already holds a phone, a laptop and expects to offload CPU to CAMSS IP one happy day, it's pretty unsatisfactory to say that it will never happen on legacy hardware, because there was done an unrecoverable mistake by adding never tested properties into CAMSS DT bindings, and the remained option is to "wait for future chipsets". Each added unsupported and unused property boards up the window of better CAMSS support on manufactured boards. I don't understand a reason why to do worse for the upstream, when there is a clear and feasible alternative not to do worse, thus my misunderstanding and my grief for upstream CAMSS are my concerns. > forward. As for your ICP concern, if you are referring to the Demosaic > in OFE, I believe we might still be able to do it either with direct OFE > config from CPU or using the firmware (preferred), given that we > properly establish the shared memory and SID IOVA ranges for ICP, > assuming that the load and authenticate will be taken care by Hyp or TZ. > Please share your thoughts if I missed something. > > Hi Bryan, please feel free to add your thoughts. > -- Best wishes, Vladimir