On Wed 23 Feb 03:15 CST 2022, Krzysztof Kozlowski wrote: > On 22/02/2022 19:16, Bjorn Andersson wrote: > > On Tue 22 Feb 06:58 PST 2022, Krzysztof Kozlowski wrote: > > > >> The 'freq-table-hz' is not correct in DT schema, because '-hz' suffix > >> defines uint32 type, not an array. Therefore deprecate 'freq-table-hz' > >> and use 'freq-table' instead. > >> > > > > Patch looks good in itself, but why don't we use opp-table to describe > > the performance states? > > > > In particular looking at the two columns of frequencies for various > > Qualcomm boards they require different performance-states. > > > > A concrete example is sm8350.dtsi, which specifies 75MHz and 300MHz as > > the first frequency pair. The lower level requires the VDD_CX power rail > > to be at least &rpmhpd_opp_low_svs, the higher frequency has a > > required-opps of &rpmhpd_opp_nom. > > > > > > As this isn't possible to express in the current binding we've just been > > forced to always run at a higher voltage level and kept this in the todo > > list. > > > > But rather than migrating freq-table-hz to freq-table and then having to > > introduce an opp table to express the power constraints, could we > > perhaps skip the intermediate step? > > > > Or would you have any other suggestion about how we can represent the > > required-opps level together with the freq-table (if that's what we want > > to stick with). > > Usage of OPP tables is interesting solution. It would solve your problem > of power rail levels. This would need several opp-tables - one for each > clock, which is not a big problem. > Ahh, so we can only have a single clock, but multiple regulators and interconnect paths tied to the opp table. We have a couple of cases where it would have been nice to be able to key the opp-table off some index (e.g. the UFS gear or PCI Gen) and control multiple clocks. So I think we need to look into this further... > The problem is that I do not have any UFS hardware (none of my Samsung > Exynos boards have UFS... I don't have even arm64 Exynos chips :( ), so > implementing it theoretically will be painful. > OTOH, I believe that having a working dtschema is very useful. Having > dtschema without errors/warnings is even worth some churn/intermediary work. > > The intermediary work is also not that big. Once proper OPP is > implemented, we will have "just" two deprecated properties in the bindings. > Fair enough, was just hoping to avoid the middle step. But that's fine, we'll continue to carry this on our todo list then. Thanks, Bjorn
