| Message ID | 1709657858-8563-1-git-send-email-quic_sriramd@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Enable firmware-managed USB resources on Qcom targets | expand |
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... > 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. Best regards, Krzysztof
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. > Best regards, > Krzysztof >
On 3/5/24 17:57, Sriram Dash wrote: > Some target systems allow multiple resources to be managed by firmware. > 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. Aside from the comments you already got from others, please change [RFC m/n] to [PATCH RFC m/n] so that your series isn't filtered out out maintainers' inboxes due to the missing PATCH keyword.. Konrad
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". Best regards, Krzysztof
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 >
On 3/6/2024 2:39 AM, Konrad Dybcio wrote: > > > On 3/5/24 17:57, Sriram Dash wrote: >> Some target systems allow multiple resources to be managed by firmware. >> 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. > > Aside from the comments you already got from others, please change > [RFC m/n] to [PATCH RFC m/n] so that your series isn't filtered out > out maintainers' inboxes due to the missing PATCH keyword.. > Sure. thanks Konrad. > Konrad
On 3/5/2024 8:57 AM, Sriram Dash wrote: > Some target systems allow multiple resources to be managed by firmware. > 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. What is some target? What does "target" means?
On Tue, Mar 05, 2024 at 10:27:35PM +0530, Sriram Dash wrote: > Some target systems allow multiple resources to be managed by firmware. > 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. > Currently it is just 2 IIUC. Better to be specific with more details and point to the exact binding. > 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. > > fw-managed dt property allows the driver to determine whether > device resources are managed by Linux or firmware, ensuring > backward compatibility. > And provide the reason why this additional property is a must ? Why can't the implementation deal with absence of it on these systems ? Not sure if you have seen/followed this[1] discussion before, but please do now if not already and contribute. It is definitely related to this patch set and all possible very similar patch sets Qcom might have in the future across various subsystems in the Linux kernel. In general, Qcom must stop pushing such changes to individual drivers in isolation and confuse the reviewers to some extent without giving the complete view(or rather providing partial view) which may result in them agreeing with proposed solution without considering the overall impact on various subsystems and DT bindings. -- Regards, Sudeep [1] https://lore.kernel.org/all/be31801e-bb21-426b-f7aa-2b52727de646@quicinc.com/
Some target systems allow multiple resources to be managed by firmware. 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. fw-managed dt property allows the driver to determine whether device resources are managed by Linux or firmware, ensuring backward compatibility. Establish the channel and domain mapping for the power domains to connect with firmware, enabling the firmware to handle the assigned resources. Since these delegated resources will remain invisible to the operating system, ensure that any references to them are removed. Sriram Dash (3): dt-bindings: usb: qcom,dwc3: Add support for multiple power-domains USB: dwc3: qcom: Add support for firmware managed resources arm64: dts: qcom: sa8775p-ride: Enable support for firmware managed resources .../phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml | 74 ++++-- .../bindings/phy/qcom,usb-snps-femto-v2.yaml | 49 +++- .../devicetree/bindings/usb/qcom,dwc3.yaml | 37 ++- arch/arm64/boot/dts/qcom/sa8775p-ride.dts | 96 +++++-- drivers/phy/qualcomm/phy-qcom-qmp-usb.c | 290 ++++++++++++++++----- drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 213 ++++++++++++--- drivers/usb/dwc3/dwc3-qcom.c | 259 +++++++++++++----- 7 files changed, 801 insertions(+), 217 deletions(-)