On 05/22/2015 11:04 AM, Rob Herring wrote: > On Fri, May 22, 2015 at 9:04 AM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: >> On 21-05-15, 01:02, Nishanth Menon wrote: >>> This argues that clock is an input to the cpu, this is not in-correct, >>> but, it could also be argued that OPP tables are clock dependent. > > What piece of h/w is the clock an input to then? The case(from one of the SoCs I deal with) I had in my mind was something as follows: GPU can get it's clock from a tree derived out of DPLL X OR a clock derived out of DPLL Y. Frequencies a,b,c can only be supported on DPLL X, where as frequencies d,e,f on DPLL Y based tree. There are many ways to skin the cat in this case.. if the clk mux is glitchless, then a-f can be supported, else, we have to have two opp tables which are selected by driver based on clock parent. With the case where we cannot switch between the DPLLs, the question was interesting if we decided to hook up the clock into the opp table based on the fact that the frequencies are based of the clock. The final clock feeding in to GPU, is the mux clock - every thing else gets hidden by CCF, unless the driver is aware of the clock topology (which we dont like to see in driver, since the driver is supposed to work across multiple SoCs) - Now, the OPP tables would obviously be based on which DPLL the source is from. Our interest was not to have SoC specificity inside the driver and help try and describe everything within DT itself - including the choice of DPLL X based or DPLL Y based selection being made based on board (each board tends to be targetted for some unique performance needs based on usecase the board is being planned to be used for). Ofcourse, with some platform specific code, this might be very easy to do as well.. so not really very hard reasoning for me to have clock in OPP table description itself. > >>> For example, with multiple clock source options that a device might >>> choose to select from internally(by some means.. lets not just restrict >>> ourselves to just CPUs here for a moment), the tables might be >>> different. We can always debate that this then is the responsibility of >>> the driver handling the description for that device and we might want >>> possibility of vice versa as well - same OPP table used by different >>> clock source selections as well. >> >> @Rob: Any inputs ? > > If you are going to describe this clock mux in DT, then that mux > should be part of the h/w block that controls it. You could always add > entries that describe what parent clock must be used for a given OPP, > but that is a new binding and not part of the existing clock binding. > > If things get too complicated, then don't try to describe this in DT. > That is always an option. Yes, ofcourse... it is always an option, we just tend to like to have all data in the same place if possible - DT is the preferred approach. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
