On Mon, Sep 12, 2011 at 10:28:27PM +0200, Arnd Bergmann wrote:

On Monday 12 September 2011 13:40:33 Grant Likely wrote:

quoted

On Tue, Sep 13, 2011 at 12:12:02AM +0800, Shawn Guo wrote:

quoted

On Wed, Sep 07, 2011 at 09:56:21AM +0200, Arnd Bergmann wrote:

quoted

On Wednesday 07 September 2011 14:05:03 Shawn Guo wrote:

quoted

quoted

My feeling is that this time, we should wait for the common clock
framework to get in and simplify this. I believe Thomas is now planning
to do this, but I haven't followed what the current state is.

Sadly, if this is the position of entire arm-soc maintainer group,
I think I have made a wrong decision to start upstreaming imx6q now.

We haven't discussed it as a group, it's my own opinion.

Hi Thomas, Grant,

Could you please share your opinion here?

I really do not see the hope that clock framework and device tree
binding could possibly catch v3.2 window, while I'm hoping that imx6q
series can go into v3.2.

Can you please agree that we can let the imx6q clock code in and then
migrate it to clock framework and device tree once they get ready?

I've not looked very deeply at this patch, but I completely agree that
we cannot block new platforms on infrastructure that isn't remotely
mergable at this point in time.

However, imx6 is a new platform.  There isn't any non-DT board support
code to continue to support.  At the very least, the configurable
parameters, like what is passed into mx6q_clocks_init() should be
obtained from the device tree (maybe it already does this though, I
haven't looked that closely).

In general, I say merge it.

Ok, thanks for taking a look. Do you believe that the clock binding is any
closer to being finalized than the actual code implementing it? I think

Amit is assigning a Linaro engineer to look at it, and there will be a
conference call later this week to look over the work that has been
done with an eye to getting something ready to be merged.  Hopefully
with a full time engineer things will start moving forward again.  We
had a meeting about it at LPC last week.

it would be very helpful to at least put all the clock related settings
into the device tree in a way that is going to be stable, even if the
code is still in flux.

Moreover, if we have a binding document, we can start implementing code
for one platform and then generalize it later.

Yes, a binding would be useful, but I still expect that things will be
in flux during these early stages, so there will be some room to
modify insufficient early bindings.

g.