From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Georgi Djakov <georgi.djakov@linaro.org>,
jassisinghbrar@gmail.com, robh+dt@kernel.org,
mturquette@baylibre.com, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v9 3/7] mailbox: qcom: Move the apcs struct into a separate header
Date: Mon, 13 Nov 2017 20:47:02 -0800 [thread overview]
Message-ID: <20171114044702.GF28761@minitux> (raw)
In-Reply-To: <20171114021255.GY11955@codeaurora.org>
On Mon 13 Nov 18:12 PST 2017, Stephen Boyd wrote:
> On 10/27, Georgi Djakov wrote:
> > Hi Bjorn,
> >
> > Thanks for reviewing!
> >
> > On 10/26/2017 07:28 AM, Bjorn Andersson wrote:
> > > On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote:
> > >
> > >> Move the structure shared by the APCS IPC device and its subdevices
> > >> into a separate header file.
> > >>
> > >
> > > As you're creating the apcs regmap with devm_regmap_init_mmio() you can
> > > just call dev_get_regmap(dev->parent) in your child to get the handle.
> >
> > Ok, thanks!
> >
> > >
> > > But I would prefer that you just add the clock code to the existing
> > > driver.
> >
> > This will require an ack from Stephen, and i got the impression that he
> > prefers a separate clk driver [1].
> >
> > Stephen, are you ok with registering the clocks from the apcs mailbox
> > driver?
> >
> > [1] https://lkml.org/lkml/2017/6/26/750
>
> The parent regmap "trick" was the plan. Is something wrong with
> that?
>
Not at all, but then this patch (moving apcs context to a shared header
file) shouldn't be needed, or am I missing something?
> Not having random clk drivers scattered throughout the tree is
> sort of nice because it makes for an easier time finding things
> that are similar. Maybe that's an abuse of the driver model
> though? Just to get things into some same directory. I'm fine
> either way.
>
Keeping the clock driver in the clock subsystem does make sense. I see
now that there is a include of a local header file as well, so that
would just be messy to keep split.
I'm fine with the extra driver instance, it's the DT that I don't think
should describe the fact that we want to keep the clock-part in the
clock subsystem.
Do you see any problems spawning the clock driver programmatically and
then calling of_clk_add_hw_provider() on the parent's of_node?
Regards,
Bjorn
next prev parent reply other threads:[~2017-11-14 4:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 16:49 [PATCH v9 0/7] Add support for Qualcomm A53 CPU clock Georgi Djakov
2017-09-21 16:49 ` [PATCH v9 1/7] mailbox: qcom: Convert APCS IPC driver to use regmap Georgi Djakov
[not found] ` <20170921164940.20343-2-georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-10-26 4:41 ` Bjorn Andersson
[not found] ` <20170921164940.20343-1-georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-09-21 16:49 ` [PATCH v9 2/7] mailbox: qcom: Populate APCS child platform devices Georgi Djakov
2017-09-21 16:49 ` [PATCH v9 4/7] clk: qcom: Add A53 PLL support Georgi Djakov
2017-09-21 22:51 ` Rob Herring
2017-10-26 4:19 ` Bjorn Andersson
2017-09-21 16:49 ` [PATCH v9 5/7] clk: qcom: Add regmap mux-div clocks support Georgi Djakov
2017-09-21 16:49 ` [PATCH v9 3/7] mailbox: qcom: Move the apcs struct into a separate header Georgi Djakov
2017-10-26 4:28 ` Bjorn Andersson
2017-10-27 14:20 ` Georgi Djakov
[not found] ` <5bad4c4b-362b-ba9f-3072-1cced7a004dd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-11-14 2:12 ` Stephen Boyd
2017-11-14 4:47 ` Bjorn Andersson [this message]
2017-11-14 18:12 ` Stephen Boyd
2017-09-21 16:49 ` [PATCH v9 6/7] dt-bindings: clock: Document qcom,apcs binding Georgi Djakov
2017-10-03 21:41 ` Rob Herring
2017-10-26 4:13 ` Bjorn Andersson
2017-09-21 16:49 ` [PATCH v9 7/7] clk: qcom: Add APCS clock controller support Georgi Djakov
2017-10-26 4:39 ` Bjorn Andersson
2017-10-25 11:56 ` [PATCH v9 0/7] Add support for Qualcomm A53 CPU clock Georgi Djakov
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=20171114044702.GF28761@minitux \
--to=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=georgi.djakov@linaro.org \
--cc=jassisinghbrar@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.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).