On 17/09/13 22:40, Mike Turquette wrote: > I hope that the existing CLK_SET_RATE_PARENT flag could help you get > the frequency you need; it causes a call to clk_set_rate(leaf_clk, > target_rate) to walk up the chain of parents and configure rates as > needed. Hmm, I'm not quite sure what that does, but it doesn't sound like it would help. The only way I know to find good clocks is to iterate over the dividers for each clock on the path. And to complicate things, clocks from the "middle" of the path are used for some purposes, so it's not only the final clock that we're interested in. For example, DSI: DSI PLL produces a high freq clock that goes to DSI PHY. That one is used for the DSI bus clock. The high freq clock from DSI PLL also goes to two dividers, of which one goes to DSI IP, and the second goes to DISPC. DISPC clock is then divided with two dividers in row, and the resulting clock goes also to DSI IP. All those different clocks have restrictions and dependencies to each other, like this one needs to be higher than that one, or ClkA = N * ClkB, etc. > However I have been looking at standardizing a way to define clock > rate tables, possibly in DT. In many cases it is a board-specific > issue (e.g. different oscillators or other reference clocks that feed > into the SoC) and specifying rate tables in DT is one way to store > known-good configurations for complex clock subtrees. Well, for some boards, which only have an LCD, we could probably get the clock from a table. But if the display used (say, external monitor) supports multiple resolutions, such a table is not feasible. We could have some clocks there in the table, but we'd still need a dynamic way to figure out the dividers for other clock rates. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
