[PATCH 3/6] arm/imx6q: add core drivers clock, gpc, mmdc and src

[Barry Song]

2011/9/8 Shawn Guo <shawn.guo at freescale.com>:
> On Wed, Sep 07, 2011 at 08:43:06PM +0800, Barry Song wrote:
>> 2011/9/7 Shawn Guo <shawn.guo at freescale.com>:
>> > Hi Arnd,
>> >
>> > On Tue, Sep 06, 2011 at 09:14:29PM +0200, Arnd Bergmann wrote:
>> >> On Tuesday 06 September 2011 17:58:37 Shawn Guo wrote:
>> >> > It adds a number of core drivers support for imx6q, including clock,
>> >> > General Power Controller (gpc), Multi Mode DDR Controller(mmdc) and
>> >> > System Reset Controller (src).
>> >> >
>> >> > Signed-off-by: Ranjani Vaidyanathan <ra5478 at freescale.com>
>> >> > Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
>> >> > ---
>> >> >  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 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.
>> >
>> >> 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.
>>
>> i understand your feeling.
>>
> No, you do not :)  With the talking at Cambridge, I thought I'm allowed
> to add new platform support without being blocked by clock framework.
> That's why I have been worked very hard for 3 weeks to come up with
> this patch series.  Now I'm getting a "no", which really frustrates me.
>
>> actually i am also waiting for the common clock framework to finish
>> the whole prima2 clock tree driver. now prima2 only includes a little
>> part of clock trees, actually if i list all of them, the file will be
>> large too. And codes are ugly too.
>>
> I did not hear "ugly" from Arnd on imx6q-clock.c.  Instead, he said
> the description of the clocks and the tree should be migrated to clock
> frame and device tree clock bindings, which unfortunately have not been
> available yet.

i see :-)  might you push other imx6q stuff at first? it looks like
Arnd is really glad with your other files.

>
>> auxdata is really a temp solution, it really brings many details to
>> kernel, which should not be in kernel at all.
>>
> The auxdata was originally designed to be a temp solution.  But we
> will see if it's really temp, considering it could also be used to
> carry platform callbacks and attach device id.  There are some other
> cases beside clock lookup that we have not been able to sort out just
> by device tree and will probably have to use auxdata as well.
>
> --
> Regards,
> Shawn
>
>
-barry