From: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Andy Gross <andy.gross-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux ARM
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/2] arm64: dts: sdm845: Add serial console support
Date: Tue, 6 Feb 2018 12:05:27 -0800 [thread overview]
Message-ID: <20180206200527.GM9465@builder> (raw)
In-Reply-To: <CAD=FV=Whxf1VRJ6qx9mioEEkTeS+uJfJKPbOMcGy-Wigh_NORw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue 06 Feb 11:49 PST 2018, Doug Anderson wrote:
> Hi,
>
> On Tue, Feb 6, 2018 at 11:06 AM, Bjorn Andersson
> <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Tue 06 Feb 10:37 PST 2018, Doug Anderson wrote:
> >
> >> Hi,
> >>
> >> On Fri, Jan 26, 2018 at 2:18 PM, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> >> > On 01/25, Rajendra Nayak wrote:
> >> >> diff --git a/arch/arm64/boot/dts/qcom/sdm845-pins.dtsi b/arch/arm64/boot/dts/qcom/sdm845-pins.dtsi
> >> >> new file mode 100644
> >> >> index 000000000000..b97f99e6f4b4
> >> >> --- /dev/null
> >> >> +++ b/arch/arm64/boot/dts/qcom/sdm845-pins.dtsi
> >> >> @@ -0,0 +1,32 @@
> >> >> +// SPDX-License-Identifier: GPL-2.0
> >> >> +/*
> >> >> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> >> >> + */
> >> >> +
> >> >> +&tlmm {
> >> >
> >> > I'm not the maintainer, but I find this approach to the pins
> >> > really annoying. I have to flip to another file to figure out how
> >> > a board has configured the pins. And we may bring in a bunch of
> >> > settings that we don't ever use on some board too. Why can't we
> >> > put the settings in the board file directly?
> >>
> >> I'm not so familiar with how things work with Qualcomm, but in general
> >> I think putting this in the "board" file is a bad idea. I'd be OK
> >> with putting this directly in the SoC file (though it might get
> >> unwieldy?), but not moving things to the board file as was done with
> >> v2 of this patch.
> >>
> >> Said another way: nearly board that uses SDM845 that uses UART2 will
> >> have the same definitions for these pins so we shouldn't be
> >> duplicating it across every board, right?
> >>
> >
> > We've run into several cases where different boards uses the same
> > function but requires board specific electrical configuration.
> >
> > So what we decided was to keep the pinmux in the soc-file (where e.g.
> > the uart definition is) and then extend it with the board specific
> > electrical properties (the pinconf), in the board files.
> >
> > This does come with the complexity of having the pinctrl nodes split in
> > two places, but the responsibilities of the two parts is clear and we
> > remove the need for all board files to ensure the appropriate pinmux is
> > in place.
> >
> >
> > NB. We did discuss adding "sane defaults" for the pinconf in the soc
> > dtsi, but we end up spending considerable time debugging issues stemming
> > from not having the right pinconf; so better make this explicit and say
> > that the board has to specify it's config.
>
> Whoops, saw your responses _after_ I sent my response to v2. In any
> case this makes sense to me then! On Rockchip boards I've been
> involved in we often added "sane defaults", but I can see how that
> could be confusing in different ways. I'm happy with your choice and
> it seems like a happy medium. The sdm845.dtsi file can have the main
> definition of the nodes and can thus refer to the nodes. Then you
> just add the extra bit in the board file.
>
> What you propose is not what happened in v2 of the series
> <https://patchwork.kernel.org/patch/10194201/> though. In v2 _both_
> the pinconf and the pinmux moved to the board file. That's wrong.
>
>
> To make it concrete, you'd have something like this (this has the
> wrong bindings from the UART, but folks get the picture hopefully):
>
>
> In sdm845.dtsi:
>
> qup_uart2: serial@a84000 {
> compatible = "qcom,geni-console", "qcom,geni-uart";
> reg = <0xa84000 0x4000>;
> reg-names = "se_phys";
> clock-names = "se-clk", "m-ahb", "s-ahb";
> clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>,
> <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
> <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <&qup_uart2_default>;
> pinctrl-1 = <&qup_uart2_sleep>;
> interrupts = <GIC_SPI 354 IRQ_TYPE_NONE>;
> qcom,wrapper-core = <&qup_1>;
> status = "disabled";
> };
>
> tlmm: pinctrl@3400000 {
> compatible = "qcom,sdm845-pinctrl";
> reg = <0x03400000 0xc00000>;
> interrupts = <GIC_SPI 208 IRQ_TYPE_NONE>;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
>
> qup_uart2_default: qup_uart2_default {
> pinmux {
> function = "qup9";
> pins = "gpio4", "gpio5";
> };
> };
>
> qup_uart2_sleep: qup_uart2_sleep {
> pinmux {
> function = "gpio";
> pins = "gpio4", "gpio5";
> };
> };
> };
>
> In sdm845-mtp.dts:
>
> &qup_uart2_default {
> pinconf {
> pins = "gpio4", "gpio5";
> drive-strength = <2>;
> bias-disable;
> };
> };
>
> &qup_uart2_sleep {
> pinconf {
> pins = "gpio4", "gpio5";
> drive-strength = <2>;
> bias-disable;
> };
> };
Correct.
This example does however show another thing that I really do not like;
When you have a lot of nodes I find it very useful to maintain some sort
of grouping, to know that I can find a node describing properties
related to some block close to related blocks - e.g. nodes describing
a pmic block is close to other nodes for that pmic.
Today we seem to have a mixture of bus-based grouping, arbitrary
grouping and no grouping at all in our upstream dtsi files, so I think
we should set some guidelines here as well.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-02-06 20:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-25 16:32 [PATCH 0/2] Add DTS for SDM845 SoC and MTP Rajendra Nayak
[not found] ` <20180125163216.29018-1-rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-01-25 16:32 ` [PATCH 1/2] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 " Rajendra Nayak
[not found] ` <20180125163216.29018-2-rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-01-26 20:31 ` Evan Green
2018-01-30 8:48 ` Rajendra Nayak
2018-01-26 22:15 ` Stephen Boyd
[not found] ` <20180126221501.GD28313-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-01-29 8:13 ` Rajendra Nayak
2018-01-30 9:48 ` Stephen Boyd
2018-01-30 10:25 ` Rajendra Nayak
2018-02-06 20:26 ` Rob Herring
[not found] ` <CAL_JsqJ1xjQ5ZP-KXeZQ0s=ib8GTfvfYjFqyy+Zcub-akCs7Bw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-07 4:14 ` Rajendra Nayak
2018-02-06 18:54 ` Bjorn Andersson
2018-02-07 4:15 ` Rajendra Nayak
2018-02-06 20:31 ` Rob Herring
2018-02-07 4:47 ` Rajendra Nayak
2018-02-07 17:37 ` Rob Herring
2018-01-25 16:32 ` [PATCH 2/2] arm64: dts: sdm845: Add serial console support Rajendra Nayak
2018-01-26 22:18 ` Stephen Boyd
2018-01-29 8:18 ` Rajendra Nayak
2018-02-06 19:00 ` Bjorn Andersson
2018-02-06 18:37 ` Doug Anderson
[not found] ` <CAD=FV=WcCnQJc25=sKWtOi=ZWi=ium6DVsexuQnsLDL=aJE6-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-06 19:06 ` Bjorn Andersson
2018-02-06 19:49 ` Doug Anderson
[not found] ` <CAD=FV=Whxf1VRJ6qx9mioEEkTeS+uJfJKPbOMcGy-Wigh_NORw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-06 20:05 ` Bjorn Andersson [this message]
2018-02-07 4:12 ` Rajendra Nayak
[not found] ` <20180126221808.GE28313-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-02-06 20:36 ` Rob Herring
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=20180206200527.GM9465@builder \
--to=bjorn.andersson-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=andy.gross-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.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).