Received-SPF: pass (google.com: domain of linux-kernel+bounces-94213-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <0d0a2ed6-92f0-440e-b241-8036a4e0ebdc@quicinc.com>
Date: Wed, 6 Mar 2024 21:30:02 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC 0/3] Enable firmware-managed USB resources on Qcom targets
Content-Language: en-US
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        <andersson@kernel.org>, <konrad.dybcio@linaro.org>, <vkoul@kernel.org>,
        <kishon@kernel.org>, <robh@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
        <gregkh@linuxfoundation.org>, <quic_wcheng@quicinc.com>,
        <Thinh.Nguyen@synopsys.com>, <p.zabel@pengutronix.de>,
        <linux-arm-msm@vger.kernel.org>, <linux-phy@lists.infradead.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-usb@vger.kernel.org>, <quic_psodagud@quicinc.com>,
        <quic_nkela@quicinc.com>, <manivannan.sadhasivam@linaro.org>,
        <ulf.hansson@linaro.org>, <sudeep.holla@arm.com>,
        <quic_shazhuss@quicinc.com>
References: <1709657858-8563-1-git-send-email-quic_sriramd@quicinc.com>
 <4d2501a7-d56d-4736-95d7-41556166859b@linaro.org>
 <1a47c20a-abda-4493-a8f0-ff7b4e144d9c@quicinc.com>
 <f2b9a9f1-0ede-4c01-9bef-ee497b3191a6@linaro.org>
From: Sriram Dash <quic_sriramd@quicinc.com>
In-Reply-To: <f2b9a9f1-0ede-4c01-9bef-ee497b3191a6@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

On 3/6/2024 12:34 PM, Krzysztof Kozlowski wrote:
> On 05/03/2024 19:04, Sriram Dash wrote:
>> On 3/5/2024 10:42 PM, Krzysztof Kozlowski wrote:
>>> On 05/03/2024 17:57, Sriram Dash wrote:
>>>> Some target systems allow multiple resources to be managed by firmware.
>>>
>>> Which? Why this is so vague...
>>>
>>
>> SA8775 will be using it as pilot. Will include the target name.
>>
>>>> On these targets, tasks related to clocks, regulators, resets, and
>>>> interconnects can be delegated to the firmware, while the remaining
>>>> responsibilities are handled by Linux.
>>>>
>>>> To support the management of partial resources in Linux and leave the rest
>>>> to firmware, multiple power domains are introduced. Each power domain can
>>>> manage one or more resources, depending on the specific use case.
>>>>
>>>> These power domains handle SCMI calls to the firmware, enabling the
>>>> activation and deactivation of firmware-managed resources.
>>>>
>>>> The driver is responsible for managing multiple power domains and
>>>> linking them to consumers as needed. Incase there is only single
>>>> power domain, it is considered to be a standard GDSC hooked on to
>>>> the qcom dt node which is read and assigned to device structure
>>>> (by genpd framework) before the driver probe even begins.
>>>
>>> This will break the ABI. Sorry, come with an ABI stable solution.
>>>
>>
>> The plan is to include multiple power-domains and fw-managed
>> property or similar in the device tree and fw-managed property
>> will be deciding if we need some resource management offloaded
>> to firmware. So, OS is always in control here. The decision
>> making will be done in the drivers. Also, there will be no
>> separate vendor hooks.
> 
> This does not answer ABI breakage. Also, I don't have a clue what are
> "vendor hooks".
> 

Apologies for the confusion, Krysztof.
The bindings will depict whether the compatible will use
clocks/ regulators, etc or not. Will take care in the
next version on top of the scmi based dt solution.

> Best regards,
> Krzysztof
>