LKML Archive mirror
 help / color / mirror / Atom feed
From: James Liao <jamesjj.liao@mediatek.com>
To: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Arnd Bergmann <arnd@arndb.de>, <devicetree@vger.kernel.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	<linux-kernel@vger.kernel.org>, <srv_heupstream@mediatek.com>,
	<linux-mediatek@lists.infradead.org>,
	"Shunli Wang" <shunli.wang@mediatek.com>,
	Sascha Hauer <kernel@pengutronix.de>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	<linux-clk@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	John Crispin <blogic@openwrt.org>
Subject: Re: [PATCH v6 4/7] clk: mediatek: Add MT2701 clock support
Date: Mon, 21 Mar 2016 16:45:44 +0800	[thread overview]
Message-ID: <1458549944.21625.6.camel@mtksdaap41> (raw)
In-Reply-To: <1456381477.22545.24.camel@mtksdaap41>

Hi Mike,

Sorry to use this old email to ask questions. Do you have any concern to
apply this patch series into next version of kernel? Or do you really
need a new patch series with less CLK_OF_DECLARE()?


Best regards,

James


On Thu, 2016-02-25 at 14:24 +0800, James Liao wrote:
> Hi Mike,
> 
> On Wed, 2016-02-24 at 13:25 -0800, Michael Turquette wrote:
> > Hi James,
> > 
> > Quoting James Liao (2016-02-15 01:19:42)
> > > Hi Mike,
> > > 
> > > On Wed, 2016-02-10 at 12:08 -0800, Michael Turquette wrote:
> > > > Quoting James Liao (2016-02-05 01:37:27)
> > > > > +CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen", mtk_topckgen_init);
> > > > > +CLK_OF_DECLARE(mtk_infrasys, "mediatek,mt2701-infracfg", mtk_infrasys_init);
> > > > > +CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt2701-pericfg", mtk_pericfg_init);
> > > > > +CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt2701-mmsys", mtk_mmsys_init);
> > > > > +CLK_OF_DECLARE(mtk_imgsys, "mediatek,mt2701-imgsys", mtk_imgsys_init);
> > > > > +CLK_OF_DECLARE(mtk_vdecsys, "mediatek,mt2701-vdecsys", mtk_vdecsys_init);
> > > > > +CLK_OF_DECLARE(mtk_hifsys, "mediatek,mt2701-hifsys", mtk_hifsys_init);
> > > > > +CLK_OF_DECLARE(mtk_ethsys, "mediatek,mt2701-ethsys", mtk_ethsys_init);
> > > > > +CLK_OF_DECLARE(mtk_bdpsys, "mediatek,mt2701-bdpsys", mtk_bdpsys_init);
> > > > > +CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt2701-apmixedsys",
> > > > 
> > > > :-/
> > > > 
> > > > This is way too much CLK_OF_DECLARE and not enough Linux Driver Model.
> > > > 
> > > > I understand that some platforms really must initialize some clocks very
> > > > early, but can we please separate those into one table and call
> > > > CLK_OF_DECLARE on only that set, and then register the rest through a
> > > > platform_driver later on?
> > > 
> > > I know CLK_OF_DECLARE is much earlier than platform_driver, so it can
> > > ensure all drivers lookup their clocks successfully during
> > > platform_driver probe. Is there anything different to init these clock
> > > providers in CLK_OF_DECLARE and platform_driver?
> > 
> > This a common pattern we're seeing right now. Joachim did a nice job of
> > supporting early clocks with CLK_OF_DECLARE, and also using a proper
> > driver in his lpc18xx implementation:
> > 
> > http://marc.info/?l=devicetree&m=145618160610001
> 
> Do you mean we should keep most clock init in platform_driver_probe and
> use CLK_OF_DECLARE for some early clocks only?
> 
> Using CLK_OF_DECLARE() for all clock providers is convenient. The
> convenience includes coding structure and driver init order. The coding
> structure means we can use a consistency way to add clock providers, so
> we can reduce errors and apply code generator on clock drivers.
> 
> The driver init order is another issue. In lpc18xx driver you mentioned
> in [1], it uses ERR_PTR(-EPROBE_DEFER) to be the place holder for
> non-early clocks in arch_init (CLK_OF_DECLARE), and then register early
> and non-early clocks again in module_init. The EPROBE_DEFER place holder
> is an interesting idea to resolve init order issue. But to register
> clocks twice on the same clock provider seems not a good idea, although
> it can still work in current CCF implementation.
> 
> Is it important to move clock init into platform_driver? If not, I
> prefer to keep current implementation on MT2701, and look for a better
> way to init clocks in platform_driver in new SoCs.
> 
> 
> [1] http://marc.info/?l=devicetree&m=145618160610001
> 
> 

  reply	other threads:[~2016-03-21  8:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05  9:37 [PATCH v6 0/7] Add clock support for Mediatek MT2701 James Liao
2016-02-05  9:37 ` [PATCH v6 1/7] clk: mediatek: Refine the makefile to support multiple clock drivers James Liao
2016-02-05  9:37 ` [PATCH v6 2/7] dt-bindings: ARM: Mediatek: Document bindings for MT2701 James Liao
2016-02-08 19:24   ` Rob Herring
2016-02-05  9:37 ` [PATCH v6 3/7] clk: mediatek: Add dt-bindings for MT2701 clocks James Liao
2016-02-05  9:37 ` [PATCH v6 4/7] clk: mediatek: Add MT2701 clock support James Liao
2016-02-10 20:08   ` Michael Turquette
2016-02-15  9:19     ` James Liao
     [not found]       ` <20160224212533.2278.7597@quark.deferred.io>
2016-02-25  6:24         ` James Liao
2016-03-21  8:45           ` James Liao [this message]
2016-02-05  9:37 ` [PATCH v6 5/7] reset: mediatek: Add MT2701 reset controller dt-binding file James Liao
2016-02-05  9:37 ` [PATCH v6 6/7] reset: mediatek: Add MT2701 reset driver James Liao
2016-02-05  9:37 ` [PATCH v6 7/7] clk: mediatek: Enable critical clocks for MT2701 James Liao
2016-02-11 21:35   ` Michael Turquette
2016-02-15  9:50     ` James Liao
2016-02-24  2:26       ` James Liao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1458549944.21625.6.camel@mtksdaap41 \
    --to=jamesjj.liao@mediatek.com \
    --cc=arnd@arndb.de \
    --cc=blogic@openwrt.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=shunli.wang@mediatek.com \
    --cc=srv_heupstream@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).