Quoting Thierry Reding (2019-11-07 07:21:15) > On Thu, Nov 07, 2019 at 03:54:03AM +0300, Dmitry Osipenko wrote: > > 07.11.2019 02:10, Stephen Boyd пишет: > > > Quoting Sowjanya Komatineni (2019-08-16 12:41:52) > > >> This patch adds an API clk_hw_get_parent_index to get index of the > > >> clock parent to use during the clock restore operations on system > > >> resume. > > > > > > Is there a reason we can't save the clk hw index at suspend time by > > > reading the hardware to understand the current parent? The parent index > > > typically doesn't matter unless we're trying to communicate something > > > from the framework to the provider driver. Put another way, I would > > > think the provider driver can figure out the index itself without having > > > to go through the framework to do so. > > > > Isn't it a bit wasteful to duplicate information about the parent within > > a provider if framework already has that info? The whole point of this > > new API is to allow providers to avoid that unnecessary duplication. > > > > Please note that clk_hw_get_parent_index is getting used only at the > > resume time and not at suspend. > > I agree with this. All of the information that we need is already cached > in the framework. Doing this in the driver would mean essentially adding > a "saved parent" field along with code to read the value at suspend time > to the three types of clocks that currently use this core helper. Don't we already have a "saved parent" field by storing the pointer to the clk_hw? > > That's certainly something that we *can* do, but it doesn't sound like a > better option than simply querying the framework for the value that we > need. > Let me say this another way. Why does this driver want to know the index that the framework uses for some clk_hw pointer? Perhaps it happens to align with the same value that hardware uses, but I still don't understand why the driver wants to know what the framework has decided is the index for some clk_hw pointer. Or is this something like "give me the index for the parent that the framework thinks I currently have but in reality don't have anymore because the register contents were wiped and we need to reparent it"? A generic API to get any index for this question is overkill and we should consider adding some sort of API like clk_hw_get_current_parent_index(), or a framework flag that tells the framework this parent is incorrect and we need to call the .set_parent() op again to reconfigure it.
