Quoting Maxime Ripard (2014-09-11 13:36:23) > Hi Chen-Yu, > > On Sat, Sep 06, 2014 at 06:47:21PM +0800, Chen-Yu Tsai wrote: > > Hi everyone, > > > > This series unifies the mux and divider parts of the AHB1 clock found > > on sun6i and sun8i, while also adding support for the pre-divider on > > the PLL6 input. > > > > The rate calculation logic must factor in which parent it is using to > > calculate the rate, to decide whether to use the pre-divider or not. > > This is beyond the original factors clk design in sunxi. To avoid > > feature bloat, this is implemented as a seperate composite clk. > > > > The new clock driver is registered with a separate OF_CLK_DECLARE. > > This is done so that assigned-clocks* properties on the clk provider > > node can actually work. The clock framework arranges the clock setup > > order by checking whether all clock parents are available, by checking > > the node matching OF_CLK_DECLARE. > > > > However, the sunxi clk driver is based on the root node compatible, > > has no defined dependencies (parents), and is setup before the fixed-rate > > clocks. Thus when the ahb1 clock is added, all parents have rate = 0. > > There is no way to calculate the required clock factors to set a default > > clock rate under these circumstances. This happens when we set the > > defaults in the clock node (provider), rather than a clock consumer. > > > > I can think of 2 ways to solve the dependency issue, but neither is > > pretty. One would be to move the root fixed-rate clocks into the sunxi > > clk driver. The other would be separating all the clocks into individual > > OF_CLK_DECLARE statements, which adds a lot of boilerplate code. > > I don't know what Mike thinks of this, but I'd prefer the second. I do not fully understand the problem. Ideally the clock driver should have some way to fail with EPROBE_DEFER until the fixed-rate clocks are registered. Those fixed-rate parents are enumerated in your dts, right? Why isn't this enough? Thanks, Mike > > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
