On Tue, Jul 05, 2022 at 12:30:03PM +0530, Viresh Kumar wrote: > Hello, > > This patchset adds support for devices with multiple clocks. None of the clocks > is considered primary in this case and all are handled equally. > > The drivers, for multiple clock case, are expected to call dev_pm_opp_set_opp() > to set the specific OPP. Though how they find the target OPP is left for the > users to handle. For some, we may have another unique OPP property, like level, > which can be used to find the OPP. While in case of others, we may want to > implement freq-based OPP finder APIs for multiple clock rates. I have decided > not to implement them in advance, and add them only someone wants to use them. This break OPP parsing on SC8280XP and hence cpufreq and other things: [ +0.010890] cpu cpu0: _opp_add_static_v2: opp key field not found [ +0.000019] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -19 [ +0.000060] cpu cpu0: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 300000000, volt: 576000, enabled: 1. New: freq: 403200000, volt: 576000, enabled: 1 [ +0.000030] cpu cpu0: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 300000000, volt: 576000, enabled: 1. New: freq: 499200000, volt: 576000, enabled: 1 ... I just did a rebase on next-20220708 and hit this. I've narrowed it down to _read_rate() now returning -ENODEV since opp_table->clk_count is zero. Similar to what was reported for tegra for v1: https://lore.kernel.org/all/58cc8e3c-74d4-e432-8502-299312a1f15e@xxxxxxxxxxxxx/ I don't have time to look at this any more today, but it would we nice if you could unbreak linux-next. Perhaps Bjorn or Mani can help with further details, but this doesn't look like something that is specific to SC8280XP. Johan
