linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jamesjj.liao@mediatek.com (James Liao)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] Add Mediatek MT8173 subsystem clocks support
Date: Fri, 5 Jun 2015 09:45:37 +0800	[thread overview]
Message-ID: <1433468737.14416.7.camel@mtksdaap41> (raw)
In-Reply-To: <20150604210212.GM676@codeaurora.org>

Hi Stephen,

On Thu, 2015-06-04 at 14:02 -0700, Stephen Boyd wrote:
> On 05/29, Sascha Hauer wrote:
> > Yes. I previously got the impression that the subsystem clocks are not
> > directly associated to the larbs, but needed to be handled by the larb
> > code due to some side effect. Now that I saw that the larbs are directly
> > in the subsystem register space it all makes sense.
> > 
> > Note that the way Mediatek SoCs are designed around sub modules is bit
> > unusual and does not fit very well in the Linux directory structure.
> > Normally SoCs have a single clocks controller which controls all clocks
> > in the SoC. Then you often have a reset controller providing reset lines
> > in the SoC. In this case it's clear that the clk driver goes to
> > drivers/clk/, the reset controller driver to drivers/reset/. Mediatek
> > SoCs instead have several blocks, each with its own clock and reset
> > controller. Splitting each block up into parts in drivers/clk/ and
> > drivers/reset/ leads to quite a code fragmentation.
> > This is my opinion, it would be great to hear something from others.
> > Matthias? I'd like to avoid running into a direction that is not
> > acceptable in the end.
> 
> We already have drivers registering clocks and resets under
> drivers/clk, so it's not unheard of. An alternative solution is
> to make child devices for the clock part and the reset part at
> runtime in the toplevel driver for the vencsys device (don't do
> any sort of DT description for this) and use regmap to mediate
> the register accesses and locking. That way we can put the clk
> driver in drivers/clk/, the reset driver in drivers/reset, etc.
> so that logically related code is grouped.

I have a question about the alternative way you mentioned. Currently
clock providers and consumers describe what clocks they will provide /
consume in device tree. If we don't describe vencsys clocks in device
tree, how to get vencsys clocks for drivers that need to control them?


Best regards,

James

  reply	other threads:[~2015-06-05  1:45 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-21  7:12 [PATCH 0/5] Add Mediatek MT8173 subsystem clocks support James Liao
2015-05-21  7:12 ` [PATCH 1/5] clk: mediatek: Fix apmixedsys clock registration James Liao
2015-05-26  7:42   ` Sascha Hauer
2015-06-04 21:07   ` Stephen Boyd
2015-05-21  7:12 ` [PATCH 2/5] clk: mediatek: mt8173: Fix enabling of critical clocks James Liao
2015-05-26  7:46   ` Sascha Hauer
2015-05-26  8:36     ` James Liao
2015-05-21  7:12 ` [PATCH 3/5] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers James Liao
2015-05-26  7:56   ` Sascha Hauer
2015-05-26  8:55     ` James Liao
2015-05-26 11:08       ` Sascha Hauer
2015-05-27  6:12         ` Yong Wu
2015-05-27  7:27           ` Sascha Hauer
2015-05-28  5:14             ` Yong Wu
2015-05-21  7:12 ` [PATCH 4/5] clk: mediatek: Add subsystem clocks of MT8173 James Liao
2015-05-22  4:22   ` Daniel Kurtz
2015-05-22  6:03     ` James Liao
2015-06-12 17:09   ` Matthias Brugger
2015-06-15  2:10     ` James Liao
2015-05-21  7:12 ` [PATCH 5/5] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS James Liao
2015-05-26  8:05   ` Sascha Hauer
2015-05-26  9:11     ` James Liao
2015-05-26  9:41       ` Sascha Hauer
2015-05-26  9:58         ` James Liao
2015-05-28 13:24 ` [PATCH 0/5] Add Mediatek MT8173 subsystem clocks support Sascha Hauer
2015-05-29  2:47   ` James Liao
2015-05-29  6:23     ` Sascha Hauer
2015-06-04 21:02       ` Stephen Boyd
2015-06-05  1:45         ` James Liao [this message]
2015-06-06  0:59           ` Stephen Boyd
2015-06-08  7:27             ` James Liao
2015-06-08  7:48             ` Sascha Hauer
2015-06-11 23:52               ` Stephen Boyd
2015-06-12 17:05                 ` Matthias Brugger

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=1433468737.14416.7.camel@mtksdaap41 \
    --to=jamesjj.liao@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 NNTP newsgroup(s).