On 3/13/2024 3:40 PM, Trilok Soni wrote:
On 3/13/2024 4:49 AM, Srinivas Kandagatla wrote:
On 12/03/2024 17:25, Trilok Soni wrote:
On 3/12/2024 10:21 AM, Srinivas Kandagatla wrote:
Basically, I would prefer better than "qcom, fw-managed" since this is not
a qcom specific problem.
We already have something like this in mainline where the BAM DMA controller is remotely powered.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml?h=v6.8
As you can see it is already fragmented. Why we need to create one more approach
which is not scalable and specific to SOC vendor?
The whole issue around this new checks is that the driver/binding is not designed to expect same set of resources from different TYPES of providers.
If the driver was designed to support opp's and power domains and make the resources handle in a unified way then some/all of these changes will naturally fit in.
SCMI or RPMI based firmware is not a QC specific. I also have allergic reaction
I agree this are not QC specific, am fine with generic dt-binding like firmware-managed-resources or something on those lines if DT-maintainers are happy with.
What is your suggestion?
Yes, DT-spec will be a good start.
when I see drivers modified w/ if (fw_managed) {..} but that is a discussion
I don't think we have a choice here, either we do this check at compatible level or dt-property level or resource level in every drivers.
I don't understand yet why we don't have any other choices but do the conditional checks? Maybe explaining
with the example will help? Start w/ clocks?
We are not using SCMI in traditional way in that, we are not dealing
with individual resources(clocks, regulators, phy, gpio, interconnect
etc.). We are defining logical/modelled domains(power and performance).
We need to think in terms of device states. For example, emac device
might have two states like this:
Clock C1 running at frequency F1 + Regulators R running at voltage V1 +
Interconnect I running at B1 bandwidth --> Lets call it a level-1 (for
the performance domain)
Clock C1 running at frquuency F2 + Regulators R running at voltage V1 +
Interconnect I running at B1 bandwidth --> Lets call it a level-2
Now if the emac driver needs to set the device performance state to
Level-1, it will call the OPP APIs to set the device performance state
to Level-1.
Similarly, emac may also define power domains like this:
Power_on --> enable ‘n’ clocks + enable ‘m’ regulators + set ICB
bandwidth to default ‘b’ + setting some GPIO pin + Enabling n` phy
clocks + enabling m` phy regulators + follow phy_init sequence and
caliberation
Power_off --> does just the opposite.
So now you can see dealing with individual clocks etc. would not be
always possible in our scenario. Therefore, we need to use ‘qcom,
firmware-managed-resources’ property to figure out if we are abstracting
resources or not.
