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

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

quoted

quoted

quoted

 arch/arm/mach-imx/Kconfig       |   13 +
 arch/arm/mach-imx/Makefile      |    4 +
 arch/arm/mach-imx/clock-imx6q.c | 1990 +++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/gpc.c         |  110 +++
 arch/arm/mach-imx/mmdc.c        |   71 ++
 arch/arm/mach-imx/src.c         |   52 +
 6 files changed, 2240 insertions(+), 0 deletions(-)

This is unfortunately still a major problem.

It's so sad to still get this comment.  Back to Linaro Connect on
Cambridge, I believe I asked for your opinion on new SoC clock support
without waiting for the clock framework.  You said you do not have a
strong position on this and would defer to others' judgement.  Then
I talked to Russell and Grant respectively, and they both agree that
we should not be blocked by the clock framework.  That's why I decided
to start upstreaming imx6q.

I don't mind being overruled on this if Russell, Grant or others have a good
feeling about the clock code going in like this.

I thought that the discussion we had in Cambridge was about migrating the
existing i.mx code to device tree without waiting for the clock framework.
If I misremember that and we had actually made a different decision back
then, then please forgive my overreaction.

quoted

quoted

I realize that we don't
yet have a good framework to do this with significantly less code,
but adding a platform that is mostly consisting of stupid additions
of clock descriptions that really should be in the device tree does
not scale much longer.

I definitely agree this does not scale for long term.  And I would
immediately migrate it to clock framework once it gets ready and put
the description into device tree when clock binding is ready.  Before
we get there, we need a way out.  It's unreasonable for us to hold
the new soc support for an unspecified time.  It's been 20 months since
we saw the common clock patches[1] from Jeremy, and we do not know yet
how many months we still have to wait.  Grant worked out the auxdata to
remove the device tree dependency on clock framework.  I think we
should not get new soc support blocked by clock framework either.

quoted

We decided to let this still get in for prima2,
which was also ugly in this regard but much simpler than imx6.

It's unfair to me that you reject imx6q clock code just because it's
an implementation for a hardware complexer than prima2.

We have to stop taking new platform clock code at some point and get
all new platforms to use common code as much as possible. The unresolved
question here is when that will be. My feeling is that prima2 was
borderline and this is too far, but I may be pushing it here given
that we are still waiting for the clock framework to actually get
merged.

However, if there is no pressure at all, we might never see that framework.

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?

Regards,
Shawn

quoted

quoted

The other three drivers in this patch are basically ok, so you can
definitely post them as a separate patch and perhaps get minor comments
for those, similar to what I commented on the other patches.

For the clock-imx6q.c file, what I first want to hear from someone
is how this is supposed to look like in the long run with device tree
integration, and how far away from that we are.

Can you comment on how far we get without the clock driver with imx6?
Is is basically useless, or is there a way we can merge the remaining
imx6 code and other drivers but postpone the large clock driver?

Unfortunately, clock is pretty fundamental for imx6q support.  Without
clock support, imx6q platform is useless.  We have a real example here.
Back to Dec. 2010, Sascha refused to take clock patch when Freescale
was submitting imx50 platform support, because he thought the clock
framework will get merged pretty soon.  But we end up with the facts
that clock framework is still up in the air and imx50 platform support
on mainline is totally useless.

I have been tried very hard to reduce the LOC of clock-imx6q.c.  It's
a 5K LOC file in the Freescale internal tree.  Now it's 2K LOC.  I know
it's still large enough for you to dislike it.  But this is the clock
that the hardware has.  I'm afraid we can not do much to reduce the LOC
significantly, unless we only implement the small portion other than
the full clock tree, which is what I really hate to do.

I actually think that you have done a great job on the code and that it
certainly looks better than a lot of the other implementations that we
have in the tree.

Also, at least half of the code is now real driver code that we won't
be able to reduce any further even with the clock framework. However,
when I look at long sets of DEF_CLK and DEF_*MUX and _REGISTER_CLOCK,
it feels like exactly the stuff that we should be moving into the
device tree and have automatically parsed.

	Arnd