Re: [PATCH 1/5] arm64: dts: qcom: x1e80100: Remove interconnect from SCM device

From: Konrad Dybcio

Date: Wed Mar 18 2026 - 05:38:43 EST


On 3/16/26 3:25 PM, Dmitry Baryshkov wrote:
> On Mon, Mar 16, 2026 at 10:39:09AM +0100, Konrad Dybcio wrote:
>> On 3/13/26 3:48 PM, Dmitry Baryshkov wrote:
>>> On Fri, Mar 13, 2026 at 12:59:46PM +0100, Konrad Dybcio wrote:
>>>> On 3/13/26 11:12 AM, Maulik Shah (mkshah) wrote:
>>>>> On 3/13/2026 7:41 AM, Dmitry Baryshkov wrote:
>>>>>> On Thu, Mar 12, 2026 at 09:26:35PM +0530, Maulik Shah wrote:
>>>>
>>>>> d) Add separate SCM child device (with interconnects) under SoC.
>>>>
>>>> We'd then have to probe it as an aux device or something, which would
>>>> either delay the probing of SCM, or introduce the need to ping-pong for
>>>> PAS availability between the API provider and consumer, since some calls
>>>> work perfectly fine without the ICC path, while others could really use
>>>> it
>>>
>>> qcom_scm_pas_is_available() ?
>>
>> This comes back to either having to wait for the interconnect provider
>> anyway, or allowing the ICC-enhanced calls to take place before they that
>> happens, stripping us of the benefits.
>
> Yes. However this way only the PAS users will have to wait (i.e.
> remoteprocs, venus, IPA, etc.). All the basic providers would be able to
> probe.

Do you then envision a separate qcom_scm_pil_is_available()?

Konrad