Hi Mike,

On Fri, Jul 08, 2016 at 06:17:16PM -0700, Michael Turquette wrote:
> Quoting Maxime Ripard (2016-07-08 14:35:06)
> > Hi Mike,
> > 
> > On Wed, Jul 06, 2016 at 07:33:08PM -0700, Michael Turquette wrote:
> > > Hi Maxime,
> > > 
> > > Quoting Maxime Ripard (2016-06-29 12:05:34)
> > > > +static void __init sun8i_h3_ccu_setup(struct device_node *node)
> > > > +{
> > > > +       void __iomem *reg;
> > > > +       u32 val;
> > > > +
> > > > +       reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> > > > +       if (IS_ERR(reg)) {
> > > > +               pr_err("%s: Could not map the clock registers\n",
> > > > +                      of_node_full_name(node));
> > > > +               return;
> > > > +       }
> > > > +
> > > > +       /* Force the PLL-Audio-1x divider to 4 */
> > > > +       val = readl(reg + SUN8I_H3_PLL_AUDIO_REG);
> > > > +       val &= ~GENMASK(4, 0);
> > > > +       writel(val | 3, reg + SUN8I_H3_PLL_AUDIO_REG);
> > > > +
> > > > +       sunxi_ccu_probe(node, reg, &sun8i_h3_ccu_desc);
> > > > +}
> > > > +CLK_OF_DECLARE(sun8i_h3_ccu, "allwinner,sun8i-h3-ccu",
> > > > +              sun8i_h3_ccu_setup);
> > > 
> > > There are several examples of drivers that split the clocks between
> > > "early" CLK_OF_DECLARE clocks and "late" module clocks. If you really
> > > need early clocks (which is less likely on a 64-bit platform with
> > > architected timers), it would be nice to pair that with a proper
> > > platform_driver (using builtin_platform_driver most likely).
> > 
> > I think we discussed that already, but yeah, we do have timers that
> > are not the architected ones (and this is a ARMv7 platform). I have
> > the feeling that splitting the two doesn't really bring any benefit,
> > but complexify a lot the driver.
> 
> Cool. I've pushed patches 1-13 to the clk tree under a shared, immutable
> branch: clk-sunxi-ng
> 
> I've merged this branch into clk-next to get some soak testing.
> 
> I did not merge patch #14. Feel free to add my reviewed-by to that
> patch.

Thanks for merging the other patches, but can you merge patch 14 too?
Merging it through my tree would break bisectability, and it should
apply properly on your tree.

> Were you going to spin another version? If so I can replace v3 with v4
> when it is ready. Thanks again for your hard work on this! Very happy to
> see the binding be reworked :-)

I'll send another patch to fix the bug found by Jean-Francois, and one
to fix a typo. Feel free to squash them in.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com