Am 18.08.19 um 09:19 schrieb Chuanhong Guo: > Hi! > > On Sun, Aug 18, 2019 at 2:10 PM Oleksij Rempel <linux@xxxxxxxxxxxxxxxx> wrote: >> >>>> We have at least 2 know registers: >>>> SYSC_REG_CPLL_CLKCFG0 - it provides some information about boostrapped >>>> refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). >>>> SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for >>>> all or some ip cores. >>>> What is probably missing is a set of dividers for >>>> each ip core. From your words it is not document. >>> >>> The specific missing part I was referring to, is parent clocks for >>> every gates. I'm not going to assume this with current openwrt device >>> tree because some peripherals doesn't have a clock binding at all or >>> have a dummy one there. >> >> Ok, then I do not understand what is the motivation to upstream >> something what is not nearly ready for use. > > Why isn't it "ready for use" then? > A complete mt7621-pll driver will contain two parts: > 1. A clock provider which outputs several clocks > 2. A clock gate with parent clocks properly configured > > Two clocks provided here are just two clocks that can't be controlled > in kernel no matter where it goes (arch/mips/ralink or drivers/clk). > Having a working CPU clock provider is better than defining a fixed > clock in dts because CPU clock can be controlled by bootloader. > (BTW description for CPU PLL register is also missing in datasheet.) > Clock gate is an unrelated part and there is no information to > properly implement it unless MTK decided to release a clock plan > somehow. With other words, your complete system is running with unknown clock rates. The source clock in the clock three can be configured differently by bootloader but you don't know how it is done how and it is not documented. >> This code is currently on prototyping phase > > Code for clock calculation is done, not "prototyping". > >> It means, we cannot expect that this driver will be fixed any time soon. > > I think clock gating is a separated feature instead of a broken part > that has to be fixed. Ok, i would agree with it. But from what you said, this feature will be never implemented. So, I repeat my question. What is the point to upstream code for a system, which has not enough information to get proper clock rate even for uart? or is uart running with cpu or bus clock rate? -- Regards, Oleksij _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
