[PATCH 3/6] arm/imx6q: add core drivers clock, gpc, mmdc and src
21cnbao at gmail.com
Sat Sep 10 22:28:53 EDT 2011
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 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.
More information about the linux-arm-kernel