From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (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 B1F1730EF68 for ; Tue, 30 Jun 2026 21:02:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782853370; cv=none; b=rzJY/hHLB6gE3/H60BIyW+kMCw8Gfmzk6fp9nMB+Tn/35kBuQRaq2+1AWXldGha5TMNPXL5wYKODgMHRVugO9N02/41hI03YH2L9jpQBhZcpdxaJ5HEiXF2SXEbJ6TAPt2TmItOLDNfyO70DNXuiVOk+NoB6bX2o+SZeVhQFGhU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782853370; c=relaxed/simple; bh=am/loPvYVzdyGkax/MQb7j+deiZ5J2fIhC8Mv3BpdnM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cCXzILjdRHNV+l+C7BZEB8pQKTlxLc4zsWj9YFaLUrYuwGpndKYlfR4FCbw/jSG4Dk2S1lxwGA2c61g9xSvWbrByg3N15fLUt2P0VqNnvrGrm/WfVGmOS50crKLPnRVHo8kMJi0IdKGYr/RkiPOs8C2+zZRQJAVDRG/emyAZdEg= 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=eZmKz5nk; arc=none smtp.client-ip=209.85.167.48 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="eZmKz5nk" Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-5aebd7da975so177476e87.2 for ; Tue, 30 Jun 2026 14:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1782853367; x=1783458167; 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=JBDyBnY0nJ7RYEFWtLzKwV49v5iiA3WOTXV6Ek5GG04=; b=eZmKz5nkrP8o7yh/aBVfRf8KW+qF3wfDn89cOEievA1uf9SzjM+Pdm2cFBzyRshy3w 7RQMI1mBBW7c625Zeq+B8s3Z7ilBLCxizBscKHGLnTUD7ylmExciv/5H/qz7SsJvB+Da s1H3tZiLvXNli2bJaQl+SROwHeNVzeegfYhRXNcwMUgfg3FZAXxhzsIXIrmjwtaTROKV Zw2kBrt96NPxBmhuLDefSshUeB4rj8LkojRXxdhG+VKxY0+KpxZIOIJzPhiF/66XyK0F AvTDbpbDtuK11/LVU8+tcWZS5UxFNkCJTs4oTNC7dNG0PBwtJN0NSowKNsd+k0dtaTRe GMGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782853367; x=1783458167; 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=JBDyBnY0nJ7RYEFWtLzKwV49v5iiA3WOTXV6Ek5GG04=; b=fcxqw9MmkCsaT6mpj+NvzihN0+s6DoAbnF+EUoPLqI5bHzyAPIuH2oG7Qo/c5G1Zzs z6yKPZzQ6bdGy2/jD65ZCPfTJjCTgKSF+zfgL0Q0+4Mn6Jsksn5TTzuwPY9Trx/dfG/v 7Equ3CVxIetk4VZbvZNuSgLzcpoBLMT1X58mw0E1IStm5nkVocGugDfTZ8S2P3LhG7aC aLJIict3/IjzLnrQ6E32+p6H/zDQgO6Ks6FOP38T4yqRZHf8wxPKlzq/u7HFXnFxpI48 IxD23dnmqoirUfTuufuuc+Zm4hCDOgn/ZkR/6XbiPb1kLwyu/TpyIGPRuZRP7kVQzcg8 cGmg== X-Forwarded-Encrypted: i=1; AHgh+RoKsO+gMHPy5TDTL3GYJdaxVvXPjr7M3bfgQz/rgmL5ebziircpzSvzinaPom99asMPesbs75DKF3Q6DM8=@vger.kernel.org X-Gm-Message-State: AOJu0YyemlUgpELjoTdmNZdqvoxVql4kyfLsfXYx8bJ9EYi7qUHkSycS QjLQlkg72li6ARW6nnT8vfP/+O2fl/oUG4X5lX79QTZokuGT7dYodbFomdRc+gCIhog= X-Gm-Gg: AfdE7cmpdeZSrb0b7CEcQg9UjKtMlxJ8BDZf7HozBzGulZbygmMHkBCB1eD+UptcDhS PTCMUUl3Z8WZ65PlWmb9FAWde1GlmMYDD0WuB0WEL3chq/CFNg7b+/jfnVMAJTiDxNHacoMWkT7 L22UN9tHa4L8ywuiG71BpKPBreQajmFCbLoSaUj64JDDD2iW/o95sHKBQEn6ssTDmynIdsYMP0S 7ZkIA5uIW15dINnCdsKzEgQ3Z5nNY/3+RHhKCECQaGGb2i2qLZnSMErunc1FN+K+oqbhFEUpnlc zb8gvzySq2AgiKQZiR+nuqOOnV1nmiKc5iIzmDNJWYhlIleauCHujXEfKF2jFvvq6J2S7aotUK3 EvGmYxb3nRbqOpmarLQ48SHP/j3P2tvS063UTjwEBnXIr9unnGZ1ZW0fZV+W/CCGEiZCUOdrwPm 5XiVTY/f9wbjvguvG3d9ALNvm0DHIfl8Suz77WKItx6vqd230OOq+0WKBajTdu1VA32fRH0eihv zx6jg== X-Received: by 2002:a05:6512:8353:b0:5ae:a6fc:171c with SMTP id 2adb3069b0e04-5aebdba8241mr427628e87.3.1782853366845; Tue, 30 Jun 2026 14:02:46 -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-5aebe4a884dsm814235e87.67.2026.06.30.14.02.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2026 14:02:45 -0700 (PDT) Message-ID: Date: Wed, 1 Jul 2026 00:02:45 +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 v3 2/4] dt-bindings: media: qcom: Add JPEG encoder binding To: Bryan O'Donoghue , Atanas Filipov , linux-media@vger.kernel.org Cc: mchehab@kernel.org, robh@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, andersson@kernel.org, quic_vgarodia@quicinc.com, quic_jesszhan@quicinc.com, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260629121750.3469292-1-atanas.filipov@oss.qualcomm.com> <20260629121750.3469292-3-atanas.filipov@oss.qualcomm.com> <_zZ7OLAmvphzTdIURTW71m_LKDwA-DEQ-a40gIiLYSqgDrdOOEf1bElz53zTbmSaDoqc8PDFyQXa7bycFaSTXw==@protonmail.internalid> <569539db-b079-439a-bd05-cb97c30141c1@linaro.org> <0161b69d-62fb-46b8-a43a-df0c8af4956a@linaro.org> <257f9f48-4831-4f36-84c0-f7e6c257dd3a@nxsw.ie> From: Vladimir Zapolskiy In-Reply-To: <257f9f48-4831-4f36-84c0-f7e6c257dd3a@nxsw.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/30/26 23:24, Bryan O'Donoghue wrote: > On 30/06/2026 14:32, Vladimir Zapolskiy wrote: >> On 6/30/26 16:19, Bryan O'Donoghue wrote: >>> On 29/06/2026 14:38, Vladimir Zapolskiy wrote: >>>>> + interconnects = >>>>> + <&gem_noc MASTER_AMPSS_M0 0 &config_noc SLAVE_CAMERA_CFG 0>, >>>>> + <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI_CH0 0>, >>>>> + <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI_CH0 0>, >>>>> + <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI_CH0 0>; >>>>> + interconnect-names = "cpu-cfg", >>>>> + "hf-mnoc", >>>>> + "sf-mnoc", >>>>> + "icp-mnoc"; >>>> Since the proper option for describing this hardware is to have it as >>>> a child device tree node of CAMSS device tree node, which should serve >>>> or be percepted as a bus, it makes no sense to repeat and moreover rename >>>> bus/parent's resources, here is the list: >>>> >>>> * "hf_axi", "sf_axi", "core_ahb", "cpas_ahb" and "cnoc_axi" clocks, >>>> * Titan GDSC power domain and all four interconnects. >>>> >>>> Only "jpeg" clock and iommus are left specific to the hardware description >>>> of this IP under CAMSS, right? Thus, it should be reflected like this in >>>> the dt description as well, and the complexity of shared resource management >>>> has to be done in the driver, which might be tedious unfortunately, but >>>> certainly doable. >>> >>> JPEG should be able to vote for its individual NoC / CamNoC dependencies >>> / requirements. >> >> There is no individual interconnects, JPEG interconnects are equal to >> bus/parent CAMSS ones. > > Not true. This is exactly what is present in the dt binding, if it has to be changed, please report it to the author of the change. > As a matter of fact, the JPEG encoder has no use-case for the ICP MNOC, > now that I look at this again. > > Even if the list is identical the clocks, bandwidth, opp tables > represent individual consumers with individual votes. I cannot parse "the clocks etc. represent individual consumers". Anyway, it has no contradiction with what I've said above, all shared "CAMSS bus" specific resources should get description in the CAMSS device tree node, all individual subdevice resources should get description in their own device tree nodes, that's so simple. There might be no SM8250 CAMSS subcomponent, which operates without Titan GDSC or cpas and bus clocks, then these are "CAMSS bus" resources, then it is immediately known that every CAMSS child needs to acquire these resources from the bus/parent, and it means there is no any single reason to repeat them in each of 20 CAMSS subnodes. >>> >>> Both GDSCs and interconnects should be described in the sub-node. >> >> Why to do it in each child, if GDSCs and interconnects are CAMSS bus/domain >> specific? There is no acceptable explanation so far. > > As we've already established some of the power-domains are function > specific - for example MXA in the PHYs. > It has no contradiction with what I've said earlier. >>> There's no functional linkage between CAMSS/IFE and JPEG - they are >>> peers within the CAMSS power-island. Over time we will migrate to >> >> I do not refer to any "functional linkage". >> >>> individual nodes for IFE CSID and these too will appear inside of the >>> CAMSS "bus" -> JPEG etc should describe their nocs and power-domains >>> individually. >>> >>> camss@X{ >>> camnoc@{} >>> csid@{ >>> interconnects = , ; >>> }; >>> jpeg@ { >>> interconnects = , ; >>> }; >>> ife@ { >>> interconnects = , ; >>> }; >>> }; >> >> It makes sense only if the lists of interconnects are different, this >> is not the case. -- Best wishes, Vladimir