* Re: [PATCH V7 04/12] clk: sprd: add mux clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-5-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> This patch adds clock multiplexor support for Spreadtrum platforms,
> the mux clocks also can be found in sprd composite clocks, so
> provides two helpers that can be reused later on.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 03/12] clk: sprd: add gate clock support
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-4-chunyan.zhang@spreadtrum.com>
On 12/07, Chunyan Zhang wrote:
> Some clocks on the Spreadtrum's SoCs are just simple gates. Add
> support for those clocks.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 02/12] clk: sprd: Add common infrastructure
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
Mark Brown, Xiaolong Zhang, Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-3-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
On 12/07, Chunyan Zhang wrote:
> Added Spreadtrum's clock driver framework together with common
> structures and interface functions.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
^ permalink raw reply
* Re: [PATCH V7 01/12] drivers: move clock common macros out from vendor directories
From: Stephen Boyd @ 2017-12-21 23:02 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
Mark Brown, Xiaolong Zhang, Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171207125715.16160-2-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
On 12/07, Chunyan Zhang wrote:
> These macros are used by more than one SoC vendor platforms, avoid to
> have many copies of these code, this patch moves them to the common
> header file which every clock drivers can access to.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
^ permalink raw reply
* Re: [PATCH v2 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
From: Rob Herring @ 2017-12-21 22:59 UTC (permalink / raw)
To: jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ
Cc: Mark Rutland, Thierry Reding, David Airlie, Russell King,
Shawn Guo, Sascha Hauer, Fabio Estevam, Andreas Färber,
Kevin Hilman, Maxime Ripard, Alexandre Belloni, SZ Lin,
Greg Kroah-Hartman, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171220134710.64479-2-jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ@public.gmane.org>
On Wed, Dec 20, 2017 at 02:47:01PM +0100, jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ@public.gmane.org wrote:
> From: Jan Tuerk <jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ@public.gmane.org>
>
> The Emerging Display Technology ETM0700G0BDH6 is exactly
> the same display as the ETM0700G0DH6, exept the pixelclock
> polarity. Therefore re-use the ETM0700G0DH6 modes. It is
> used by default on emtrion Avari based development kits.
As I asked on v1, why not document the panels together in a single doc?
>
> Signed-off-by: Jan Tuerk <jan.tuerk-BU0Y/NROKIhBDgjK7y7TUQ@public.gmane.org>
> ---
> .../bindings/display/panel/edt,etm0700g0bdh6.txt | 9 +++++++++
> drivers/gpu/drm/panel/panel-simple.c | 15 +++++++++++++++
> 2 files changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
--
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
^ permalink raw reply
* Re: [PATCH net 1/2] dt-bindings: net: mediatek: add condition to property mediatek,pctl
From: Rob Herring @ 2017-12-21 22:55 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, mark.rutland-5wv7dgnIgG8,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w, john-Pj+rj9U5foFAfugRpC6u6w,
nbd-p3rKhJxN3npAfugRpC6u6w, nelson.chang-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <e366efc29985d3292c8a1afb1389b5eac57c9037.1513762066.git.sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Wed, Dec 20, 2017 at 05:47:05PM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> The property "mediatek,pctl" is only required for SoCs such as MT2701 and
> MT7623, so adding a few words for stating the condition.
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/mediatek-net.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Linus Walleij @ 2017-12-21 22:53 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Andrew Lunn, Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo,
Stefan Agner, Florian Fainelli,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM
In-Reply-To: <20171221173235.GK10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On Thu, Dec 21, 2017 at 6:32 PM, Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> What we have here is _really_ a shared interrupt between four
> separate devices, and we need a way to sanely describe resources
> shared between several device instances to pinmux. Unfortunately,
> it seems pinmux is designed around one device having exclusive use
> of a resource, which makes it hard to describe shared interrupts in
> DT.
>
> Given that DT should be a description of the hardware, and should be
> independent of the OS implementation, I'd say this is a pinmux bug,
> because pinmux gets in the way of describing the hardware correctly.
> ;)
Hm that would be annoying. But when I look at it I think it would
actually work. Did you try just assigning the same pin control
state to all the PHY's and see what happens?
Just set
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mv88e1545>;
on all of them?
I don't think DTC would complain at least.
When I look at the driver subsystem, I don't see anything really
stopping you from doing that and even have three devices selecting
the same "default" pin control state. It seems it will just wind up
three times in pinctrl_select_state() and the first time it calls the pin
control driver to actually set it and the three other times it finds the
state is already correct and returns success.
So the way I read it actually several devices can reference the
same pin control state.
That is, unless there is something I missed. Which I often do...
If it happens to work we should probably put a blurb in the
DT binding that this is expected behaviour though.
Yours,
Linus Walleij
--
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
^ permalink raw reply
* Re: [RFC] irqchip: add support for LS1021A external interrupt lines
From: Rob Herring @ 2017-12-21 22:45 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Mark Rutland,
Alexander Stein, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <62c4af0c-ffe5-23c9-9ef6-2e4b8ab90050-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
On Fri, Dec 15, 2017 at 11:55:34PM +0100, Rasmus Villemoes wrote:
> On 2017-12-13 00:28, Rob Herring wrote:
> > On Fri, Dec 08, 2017 at 03:33:00PM +0100, Rasmus Villemoes wrote:
> >>
> >> .../interrupt-controller/fsl,ls1021a-extirq.txt | 19 +++
> >
> > Please split to separate patch.
>
> Will do.
>
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls1021a-extirq.txt
> >> @@ -0,0 +1,19 @@
> >> +* Freescale LS1021A external IRQs
> >> +
> >> +The LS1021A supports inverting the polarity of six external interrupt lines.
> >> +
> >> +Required properties:
> >> +- compatible: should be "fsl,ls1021a-extirq"
> >> +- interrupt-controller: Identifies the node as an interrupt controller
> >> +- #interrupt-cells: Use the same format as specified by GIC in arm,gic.txt.
> >> +- interrupt-parent: phandle of GIC.
> >> +- syscon: phandle of Supplemental Configuration Unit (scfg).
> >
> > Can this be a child of that node instead?
>
> I suppose it could, but I don't think it would make much sense. In any
> case, I did it this way because that seemed to be the way the syscon
> driver is used in lots of other cases, cf. all the occurrences of
> syscon_regmap_lookup_by_phandle() and the corresponding bindings - I
> don't think I've seen any of those cases represent the syscon-using node
> as a child of the syscon node.
I'm sure there are examples because this is a frequent review comment.
In any case, define the binding by what the h/w looks like, not what the
kernel *currently* wants.
Rob
--
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
^ permalink raw reply
* Re: [PATCH v2 2/2] dt/bindings: Add bindings for Layerscape external irqs
From: Rob Herring @ 2017-12-21 22:44 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Mark Rutland,
Andy Tang, Shawn Guo, Alexander Stein,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513758631-19909-2-git-send-email-rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
On Wed, Dec 20, 2017 at 09:30:30AM +0100, Rasmus Villemoes wrote:
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
> ---
> .../interrupt-controller/fsl,ls-extirq.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
> new file mode 100644
> index 000000000000..7e4680866364
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
> @@ -0,0 +1,37 @@
> +* Freescale Layerscape external IRQs
> +
> +Some Layerscape SOCs (LS1021A, LS1043A, LS1046A) support inverting
> +the polarity of certain external interrupt lines.
> +
> +Required properties:
> +- compatible: should be "fsl,<soc-name>-extirq", e.g. "fsl,ls1021a-extirq".
> +- interrupt-controller: Identifies the node as an interrupt controller
> +- #interrupt-cells: Use the same format as specified by GIC in arm,gic.txt.
> +- interrupt-parent: phandle of GIC.
> +- syscon: phandle of Supplemental Configuration Unit (scfg) and offset
> + to the INTPCR register.
> +- interrupts: Specifies the mapping to interrupt numbers in the parent
> + interrupt controller. Interrupts are mapped one-to-one to parent
> + interrupts.
> +
> +Optional properties:
> +- bit-reverse: This boolean property should be set on the LS1021A if
fsl,bit-reverse
> + the SCFGREVCR register has been set to all-ones (which is usually
> + the case), meaning that all reads and writes of SCFG registers are
> + implicitly bit-reversed. Other compatible platforms do not have such
> + a register.
> +
> +Example:
> + extirq: extirq {
Node name should still be "interrupt-controller".
> + compatible = "fsl,ls1021a-extirq";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + interrupt-parent = <&gic>;
> + syscon = <&scfg 0x1ac>;
> + interrupts = <163 164 165 167 168 169>;
> + bit-reverse;
> + };
> +
> +
> + interrupts-extended = <&gic GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
> + <&extirq GIC_SPI 1 IRQ_TYPE_LEVEL_LOW>;
> --
> 2.7.4
>
--
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
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: soc: qcom: Add label for GLINK bindings
From: Rob Herring @ 2017-12-21 22:39 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Chris Lew, Andy Gross, David Brown, Arun Kumar Neelakantam,
linux-arm-msm, open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM,
open list:ARM/QUALCOMM SUPPORT,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org
In-Reply-To: <20171221013557.GE12655@minitux>
On Wed, Dec 20, 2017 at 7:35 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 20 Dec 10:30 PST 2017, Rob Herring wrote:
>
>> On Mon, Dec 18, 2017 at 02:02:09PM -0800, Chris Lew wrote:
>> > Add a label property to identify the edge this node represents.
>>
>> Why does a user need to know this?
>>
>
> We have multiple remoteproc instances, each one having one or more
> associated SMD or GLINK links (this node), exposing logical
> communication channels. Some of these logical channels are exposed to
> user space and we need a way to distinguish them there.
They should have some sort of discoverable property. There must be
some reason why you need a specific channel. I think of label as being
a sticker or silkscreen on a device which doesn't seem to be the case
here. This seems more like wanting fixed device numbering like disks
and I assume you know the position on fixed device numbers.
Rob
^ permalink raw reply
* Re: [PATCH V8 2/3] OPP: Introduce "required-opp" property
From: Rob Herring @ 2017-12-21 22:26 UTC (permalink / raw)
To: Viresh Kumar
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, sudeep.holla-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <6615035f294a64a4c17e5b44ac6690d1c2ac127c.1513591822.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Dec 18, 2017 at 03:51:29PM +0530, Viresh Kumar wrote:
> Devices have inter-dependencies some times. For example a device that
> needs to run at 800 MHz, needs another device (e.g. Its power domain) to
> be configured at a particular operating performance point.
>
> This patch introduces a new property "required-opp" which can be present
> directly in a device's node (if it doesn't need to change its OPPs), or
> in device's OPP nodes. More details on the property can be seen in the
> binding itself.
>
> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 8 +++
> .../devicetree/bindings/power/power_domain.txt | 59 ++++++++++++++++++++++
> 2 files changed, 67 insertions(+)
A couple of nits, otherwise:
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index a3953a1bb1a1..4e4f30288c8b 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -159,6 +159,14 @@ properties.
>
> - status: Marks the node enabled/disabled.
>
> +- required-opp: This contains phandle to an OPP node in another device's OPP
> + table. It may contain an array of phandles, where each phandle points to an
> + OPP of a different device. It should not contain multiple phandles to the OPP
> + nodes in the same OPP table. This specifies the minimum required OPP of the
> + device(s), whose OPP's phandle is present in this property, for the
> + functioning of the current device at the current OPP (where this property is
> + present).
> +
> Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
>
> / {
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 61549840ab3b..f824763b202e 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -126,4 +126,63 @@ The node above defines a typical PM domain consumer device, which is located
> inside a PM domain with index 0 of a power controller represented by a node
> with the label "power".
>
> +Optional properties:
> +- required-opp: This contains phandle to an OPP node in another device's OPP
> + table. It may contain an array of phandles, where each phandle points to an
> + OPP of a different device. It should not contain multiple phandles to the OPP
> + nodes in the same OPP table. This specifies the minimum required OPP of the
> + device(s), whose OPP's phandle is present in this property, for the
> + functioning of the current device at the current OPP (where this property is
> + present).
> +
> +Example:
> +- OPP table for domain provider that provides two domains.
> +
> + domain0_opp_table: opp_table0 {
opp-table0
> + compatible = "operating-points-v2";
> +
> + domain0_opp_0: opp-1000000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-microvolt = <975000 970000 985000>;
> + };
> + domain0_opp_1: opp-1100000000 {
> + opp-hz = /bits/ 64 <1100000000>;
> + opp-microvolt = <1000000 980000 1010000>;
> + };
> + };
> +
> + domain1_opp_table: opp_table1 {
opp-table1
> + compatible = "operating-points-v2";
> +
> + domain1_opp_0: opp-1200000000 {
> + opp-hz = /bits/ 64 <1200000000>;
> + opp-microvolt = <975000 970000 985000>;
> + };
> + domain1_opp_1: opp-1300000000 {
> + opp-hz = /bits/ 64 <1300000000>;
> + opp-microvolt = <1000000 980000 1010000>;
> + };
> + };
> +
> + parent: power-controller@12340000 {
> + compatible = "foo,power-controller";
> + reg = <0x12340000 0x1000>;
> + #power-domain-cells = <1>;
> + operating-points-v2 = <&domain0_opp_table>, <&domain1_opp_table>;
> + };
> +
> + leaky-device0@12350000 {
> + compatible = "foo,i-leak-current";
> + reg = <0x12350000 0x1000>;
> + power-domains = <&parent 0>;
> + required-opp = <&domain0_opp_0>;
> + };
> +
> + leaky-device1@12350000 {
> + compatible = "foo,i-leak-current";
> + reg = <0x12350000 0x1000>;
> + power-domains = <&parent 1>;
> + required-opp = <&domain1_opp_1>;
> + };
> +
> [1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
> --
> 2.15.0.194.g9af6a3dea062
>
--
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
^ permalink raw reply
* Re: [RFC 2/2] pci: dwc: pci-exynos: add the codes to support the exynos5433
From: Jaehoon Chung @ 2017-12-21 22:21 UTC (permalink / raw)
To: Jingoo Han, linux-pci
Cc: linux-samsung-soc, devicetree, linux-kernel, robh+dt, krzk, kgene,
lorenzo.pieralisi
In-Reply-To: <000401d37a76$899613c0$9cc23b40$@gmail.com>
Hi Jingoo,
On 12/22/2017 01:12 AM, Jingoo Han wrote:
> On Thursday, December 21, 2017 7:14 AM, Jaehoon Chung wrote:
>>
>> Exynos5433 has the PCIe for WiFi.
>> Added the codes relevant to PCIe for supporting the exynos5433.
>> Also changed the binding documentation name to
>> 'samsung,exynos-pcie.txt'.
>> (It's not only exynos5440 anymore.)
>>
>
> I have no objection.
> However, I added some comments about Exynos5440.
>
>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>> ---
>> ...exynos5440-pcie.txt => samsung,exynos-pcie.txt} | 2 +-
>> drivers/pci/dwc/pci-exynos.c | 183
> ++++++++++++++++-----
>> 2 files changed, 144 insertions(+), 41 deletions(-)
>> rename Documentation/devicetree/bindings/pci/{samsung,exynos5440-pcie.txt
>> => samsung,exynos-pcie.txt} (97%)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-
>> pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
>> similarity index 97%
>> rename from Documentation/devicetree/bindings/pci/samsung,exynos5440-
>> pcie.txt
>> rename to Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
>> index 34a11bfbfb60..958dcc150505 100644
>> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.txt
>> @@ -4,7 +4,7 @@ This PCIe host controller is based on the Synopsys
>> DesignWare PCIe IP
>> and thus inherits all the common properties defined in designware-
>> pcie.txt.
>>
>> Required properties:
>> -- compatible: "samsung,exynos5440-pcie"
>> +- compatible: "samsung,exynos5440-pcie" or "samsung,exynos5433-pcie"
>> - reg: base addresses and lengths of the PCIe controller,
>> the PHY controller, additional register for the PHY controller.
>> (Registers for the PHY controller are DEPRECATED.
>> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c
>> index 5596fdedbb94..8dee2e90347e 100644
>> --- a/drivers/pci/dwc/pci-exynos.c
>> +++ b/drivers/pci/dwc/pci-exynos.c
>> @@ -40,6 +40,8 @@
>> #define PCIE_IRQ_SPECIAL 0x008
>> #define PCIE_IRQ_EN_PULSE 0x00c
>> #define PCIE_IRQ_EN_LEVEL 0x010
>> +#define PCIE_SW_WAKE 0x018
>> +#define PCIE_BUS_EN BIT(1)
>> #define IRQ_MSI_ENABLE BIT(2)
>> #define PCIE_IRQ_EN_SPECIAL 0x014
>> #define PCIE_PWR_RESET 0x018
>> @@ -49,7 +51,8 @@
>> #define PCIE_NONSTICKY_RESET 0x024
>> #define PCIE_APP_INIT_RESET 0x028
>> #define PCIE_APP_LTSSM_ENABLE 0x02c
>> -#define PCIE_ELBI_RDLH_LINKUP 0x064
>> +#define PCIE_ELBI_RDLH_LINKUP 0x074
>
> The address of this register should be 0x064 for exynos5440.
> Howe about the following?
>
> +#define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP 0x064
> +#define PCIE_ELBI_RDLH_LINKUP 0x074
>
> Or you can add the following.
>
> /* Exynos5440 PCIe ELBI registers */
> #define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP 0x064
Maybe, you're right. Because i didn't have Exynos5440 TRM, it's problem to me about updating other SoCs.
I have checked almost all variants Exynos. They are using the LINKUP register as 0x74.
If i can get the exynos5440 TRM, it's much helpful to me. Is it possible?
>
>> +#define PCIE_ELBI_XMLH_LINKUP BIT(4)
>> #define PCIE_ELBI_LTSSM_ENABLE 0x1
>> #define PCIE_ELBI_SLV_AWMISC 0x11c
>> #define PCIE_ELBI_SLV_ARMISC 0x120
>> @@ -94,6 +97,10 @@
>> #define PCIE_PHY_TRSV3_PD_TSV BIT(7)
>> #define PCIE_PHY_TRSV3_LVCC 0x31c
>>
>> +/* DBI register */
>> +#define PCIE_MISC_CONTROL_1_OFF 0x8BC
>> +#define DBI_RO_WR_EN BIT(0)
>> +
>> struct exynos_pcie_mem_res {
>> void __iomem *elbi_base; /* DT 0th resource: PCIe CTRL */
>> void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
>> @@ -221,6 +228,96 @@ static const struct exynos_pcie_ops
>> exynos5440_pcie_ops = {
>> .deinit_clk_resources = exynos5440_pcie_deinit_clk_resources,
>> };
>>
>> +static int exynos5433_pcie_get_mem_resources(struct platform_device
> *pdev,
>> + struct exynos_pcie *ep)
>> +{
>> + struct dw_pcie *pci = ep->pci;
>> + struct device *dev = pci->dev;
>> + struct resource *res;
>> +
>> + ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
>> + if (!ep->mem_res)
>> + return -ENOMEM;
>> +
>> + /* External Local Bus interface(ELBI) Register */
>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "elbi");
>> + ep->mem_res->elbi_base = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(ep->mem_res->elbi_base))
>> + return PTR_ERR(ep->mem_res->elbi_base);
>> +
>> + /* Data Bus Interface(DBI) Register */
>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
>> + pci->dbi_base = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(pci->dbi_base))
>> + return PTR_ERR(pci->dbi_base);
>> +
>> + return 0;
>> +}
>> +
>> +static int exynos5433_pcie_get_clk_resources(struct exynos_pcie *ep)
>> +{
>> + struct dw_pcie *pci = ep->pci;
>> + struct device *dev = pci->dev;
>> +
>> + ep->clk_res = devm_kzalloc(dev, sizeof(*ep->clk_res), GFP_KERNEL);
>> + if (!ep->clk_res)
>> + return -ENOMEM;
>> +
>> + ep->clk_res->clk = devm_clk_get(dev, "pcie");
>> + if (IS_ERR(ep->clk_res->clk)) {
>> + dev_err(dev, "Failed to get pcie rc clock\n");
>> + return PTR_ERR(ep->clk_res->clk);
>> + }
>> +
>> + ep->clk_res->bus_clk = devm_clk_get(dev, "pcie_bus");
>> + if (IS_ERR(ep->clk_res->bus_clk)) {
>> + dev_err(dev, "Failed to get pcie bus clock\n");
>> + return PTR_ERR(ep->clk_res->bus_clk);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static void exynos5433_pcie_deinit_clk_resources(struct exynos_pcie *ep)
>> +{
>> + clk_disable_unprepare(ep->clk_res->bus_clk);
>> + clk_disable_unprepare(ep->clk_res->clk);
>> +}
>> +
>> +
>> +static int exynos5433_pcie_init_clk_resources(struct exynos_pcie *ep)
>> +{
>> + struct dw_pcie *pci = ep->pci;
>> + struct device *dev = pci->dev;
>> + int ret;
>> +
>> + ret = clk_prepare_enable(ep->clk_res->clk);
>> + if (ret) {
>> + dev_err(dev, "cannot enable pcie rc clock");
>> + return ret;
>> + }
>> +
>> + ret = clk_prepare_enable(ep->clk_res->bus_clk);
>> + if (ret) {
>> + dev_err(dev, "cannot enable pcie bus clock");
>> + goto err_bus_clk;
>> + }
>> +
>> + return 0;
>> +
>> +err_bus_clk:
>> + clk_disable_unprepare(ep->clk_res->clk);
>> +
>> + return ret;
>> +}
>> +
>> +static const struct exynos_pcie_ops exynos5433_pcie_ops = {
>> + .get_mem_resources = exynos5433_pcie_get_mem_resources,
>> + .get_clk_resources = exynos5433_pcie_get_clk_resources,
>> + .init_clk_resources = exynos5433_pcie_init_clk_resources,
>> + .deinit_clk_resources = exynos5433_pcie_deinit_clk_resources,
>> +};
>> +
>> static void exynos_pcie_writel(void __iomem *base, u32 val, u32 reg)
>> {
>> writel(val, base + reg);
>> @@ -279,7 +376,9 @@ static void exynos_pcie_deassert_core_reset(struct
>> exynos_pcie *ep)
>> exynos_pcie_writel(ep->mem_res->elbi_base, 1, PCIE_NONSTICKY_RESET);
>> exynos_pcie_writel(ep->mem_res->elbi_base, 1, PCIE_APP_INIT_RESET);
>> exynos_pcie_writel(ep->mem_res->elbi_base, 0, PCIE_APP_INIT_RESET);
>> - exynos_pcie_writel(ep->mem_res->block_base, 1, PCIE_PHY_MAC_RESET);
>> + if (ep->mem_res->block_base)
>> + exynos_pcie_writel(ep->mem_res->block_base, 1,
>> + PCIE_PHY_MAC_RESET);
>
> Good.
>
>> }
>>
>> static void exynos_pcie_assert_phy_reset(struct exynos_pcie *ep)
>> @@ -413,9 +512,6 @@ static int exynos_pcie_establish_link(struct
>> exynos_pcie *ep)
>> if (ep->using_phy) {
>> phy_reset(ep->phy);
>>
>> - exynos_pcie_writel(ep->mem_res->elbi_base, 1,
>> - PCIE_PWR_RESET);
>> -
>> phy_power_on(ep->phy);
>> phy_init(ep->phy);
>> } else {
>> @@ -430,14 +526,16 @@ static int exynos_pcie_establish_link(struct
>> exynos_pcie *ep)
>> udelay(500);
>> exynos_pcie_writel(ep->mem_res->block_base, 0,
>> PCIE_PHY_COMMON_RESET);
>> + exynos_pcie_deassert_core_reset(ep);
>> }
>>
>> - /* pulse for common reset */
>> - exynos_pcie_writel(ep->mem_res->block_base, 1,
>> PCIE_PHY_COMMON_RESET);
>> - udelay(500);
>> - exynos_pcie_writel(ep->mem_res->block_base, 0,
>> PCIE_PHY_COMMON_RESET);
>
> These codes are also necessary for Exyno5440.
> How about moving these codes instead of removing them?
>
> @@ -430,14 +526,16 @@ static int exynos_pcie_establish_link(struct
> exynos_pcie *ep)
> udelay(500);
> exynos_pcie_writel(ep->mem_res->block_base, 0,
> PCIE_PHY_COMMON_RESET);
> + /* pulse for common reset */
> + exynos_pcie_writel(ep->mem_res->block_base, 1,
> + PCIE_PHY_COMMON_RESET);
> + udelay(500);
> + exynos_pcie_writel(ep->mem_res->block_base, 0,
> + PCIE_PHY_COMMON_RESET);
> + exynos_pcie_deassert_core_reset(ep);
> }
>
>
>> + /*
>> + * Enable DBI_RO_WR_EN bit.
>> + * - When set to 1, some RO and HWinit bits are wriatble from
>> + * the local application through the DBI.
>> + */
>> + dw_pcie_writel_dbi(pci, PCIE_MISC_CONTROL_1_OFF, DBI_RO_WR_EN);
>>
>> - exynos_pcie_deassert_core_reset(ep);
>> dw_pcie_setup_rc(pp);
>> exynos_pcie_assert_reset(ep);
>>
>> @@ -472,16 +570,6 @@ static void exynos_pcie_clear_irq_pulse(struct
>> exynos_pcie *ep)
>> exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_PULSE);
>> }
>>
>> -static void exynos_pcie_enable_irq_pulse(struct exynos_pcie *ep)
>> -{
>> - u32 val;
>> -
>> - /* enable INTX interrupt */
>> - val = IRQ_INTA_ASSERT | IRQ_INTB_ASSERT |
>> - IRQ_INTC_ASSERT | IRQ_INTD_ASSERT;
>> - exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_EN_PULSE);
>> -}
>> -
>> static irqreturn_t exynos_pcie_irq_handler(int irq, void *arg)
>> {
>> struct exynos_pcie *ep = arg;
>> @@ -513,9 +601,16 @@ static void exynos_pcie_msi_init(struct exynos_pcie
>> *ep)
>> exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_EN_LEVEL);
>> }
>>
>> -static void exynos_pcie_enable_interrupts(struct exynos_pcie *ep)
>> +static void exynos_pcie_enable_irq_pulse(struct exynos_pcie *ep)
>> {
>> - exynos_pcie_enable_irq_pulse(ep);
>> + u32 val;
>> +
>> + val = IRQ_INTA_ASSERT | IRQ_INTB_ASSERT |
>> + IRQ_INTC_ASSERT | IRQ_INTD_ASSERT;
>> + exynos_pcie_writel(ep->mem_res->elbi_base, val, PCIE_IRQ_EN_PULSE);
>> +
>> + exynos_pcie_writel(ep->mem_res->elbi_base, 0, PCIE_IRQ_EN_LEVEL);
>> + exynos_pcie_writel(ep->mem_res->elbi_base, 0, PCIE_IRQ_EN_SPECIAL);
>
> Good.
>
>>
>> if (IS_ENABLED(CONFIG_PCI_MSI))
>> exynos_pcie_msi_init(ep);
>> @@ -575,10 +670,8 @@ static int exynos_pcie_link_up(struct dw_pcie *pci)
>> u32 val;
>>
>> val = exynos_pcie_readl(ep->mem_res->elbi_base,
>> PCIE_ELBI_RDLH_LINKUP);
>> - if (val == PCIE_ELBI_LTSSM_ENABLE)
>> - return 1;
>
> Exynos5440 uses 'PCIE_ELBI_LTSSM_ENABLE'.
> Can you keep this code for Exyno5440?
It's possible to keep, but if it has to keep, then it needs to distinguish between exynos5440 and other exynos.
Although I already mentioned, i needs to get Exynos5440 TRM. :)
Best Regards,
Jaehoon Chung
>
> This register can be added as below.
>
> /* Exynos5440 PCIe ELBI registers */
> #define EXYNOS5440_PCIE_ELBI_RDLH_LINKUP 0x064
> #define EXYNOS5440_PCIE_ELBI_LTSSM_ENABLE BIT(0)
>
> Best regards,
> Jingoo Han
>
>>
>> - return 0;
>> + return (val & PCIE_ELBI_XMLH_LINKUP);
>> }
>>
>> static int exynos_pcie_host_init(struct pcie_port *pp)
>> @@ -587,7 +680,7 @@ static int exynos_pcie_host_init(struct pcie_port *pp)
>> struct exynos_pcie *ep = to_exynos_pcie(pci);
>>
>> exynos_pcie_establish_link(ep);
>> - exynos_pcie_enable_interrupts(ep);
>> + exynos_pcie_enable_irq_pulse(ep);
>>
>> return 0;
>> }
>> @@ -608,8 +701,11 @@ static int __init exynos_add_pcie_port(struct
>> exynos_pcie *ep,
>>
>> pp->irq = platform_get_irq(pdev, 1);
>> if (pp->irq < 0) {
>> - dev_err(dev, "failed to get irq\n");
>> - return pp->irq;
>> + pp->irq = platform_get_irq_byname(pdev, "intr");
>> + if (pp->irq < 0) {
>> + dev_err(dev, "failed to get irq\n");
>> + return pp->irq;
>> + }
>> }
>> ret = devm_request_irq(dev, pp->irq, exynos_pcie_irq_handler,
>> IRQF_SHARED, "exynos-pcie", ep);
>> @@ -678,13 +774,23 @@ static int __init exynos_pcie_probe(struct
>> platform_device *pdev)
>>
>> ep->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
>>
>> - /* Assume that controller doesn't use the PHY framework */
>> - ep->using_phy = false;
>> + /*
>> + * In case of Exynos5440,
>> + * Assume that controller doesn't use the PHY frameork.
>> + * Other SoCs might be used the PHY framework.
>> + */
>> +
>> + if (of_device_is_compatible(np, "samsung,exynos5440-pcie"))
>> + ep->using_phy = false;
>>
>> - ep->phy = devm_of_phy_get(dev, np, NULL);
>> + ep->phy = devm_of_phy_get(dev, np, "pcie-phy");
>> if (IS_ERR(ep->phy)) {
>> if (PTR_ERR(ep->phy) == -EPROBE_DEFER)
>> return PTR_ERR(ep->phy);
>> + if (!of_device_is_compatible(np, "samsung,exynos5440-pcie"))
>> {
>> + dev_err(dev, "Can't find the pcie-phy\n");
>> + return PTR_ERR(ep->phy);
>> + }
>> dev_warn(dev, "Use the 'phy' property. Current DT of pci-
>> exynos was deprecated!!\n");
>> } else
>> ep->using_phy = true;
>> @@ -734,23 +840,20 @@ static int __exit exynos_pcie_remove(struct
>> platform_device *pdev)
>> static const struct of_device_id exynos_pcie_of_match[] = {
>> {
>> .compatible = "samsung,exynos5440-pcie",
>> - .data = &exynos5440_pcie_ops
>> + .data = &exynos5440_pcie_ops,
>> + }, {
>> + .compatible = "samsung,exynos5433-pcie",
>> + .data = &exynos5433_pcie_ops,
>> },
>> {},
>> };
>>
>> static struct platform_driver exynos_pcie_driver = {
>> + .probe = exynos_pcie_probe,
>> .remove = __exit_p(exynos_pcie_remove),
>> .driver = {
>> .name = "exynos-pcie",
>> .of_match_table = exynos_pcie_of_match,
>> },
>> };
>> -
>> -/* Exynos PCIe driver does not allow module unload */
>> -
>> -static int __init exynos_pcie_init(void)
>> -{
>> - return platform_driver_probe(&exynos_pcie_driver,
>> exynos_pcie_probe);
>> -}
>> -subsys_initcall(exynos_pcie_init);
>> +builtin_platform_driver(exynos_pcie_driver);
>> --
>> 2.15.1
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH] ARM: realview: remove eb-mp clcd IRQ
From: Linus Walleij @ 2017-12-21 22:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20171221213146.3146805-1-arnd-r2nGTMty4D4@public.gmane.org>
On Thu, Dec 21, 2017 at 10:31 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> We get a dtc warning about the CLCD interrupt being invalid:
>
> arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000
>
> According to the datasheet I found and the old board file, this
> line is not connected, so I'm removing the respective properties here.
>
> Link: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0411d/index.html
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
There is some confusion here. There is CLCD "Color LCD"
which is just a code name for PrimeCell PL111 and there is the actual
character LCD which is a hardware thin to talk to a character LCD with
some characters on.
> diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
So this DTS is for the ARM 11 MP core tile which is described in
DUI0318F. It doesn't even list an IRQ for the character LCD.
> &charlcd {
> - interrupt-parent = <&intc>;
> - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
This was probably me thinking to go back and fill in the right
IRQ and forgetting to actually do it. Sorry :(
> + /* CLCD is not connected here */
Call it character LCD instead to avoid confusion please.
> + /delete-property/interrupt-parent;
> + /delete-property/interrupts;
I don't understand this delete-property business (first time
I see it, but the top level
DTSI (arm-realview-eb.dtsi) does not define any interrupt
so can't you just delete this whole &charlcd?
I do think the reference design has a character LCD, and I
do think it has an interrupt, it's just undocumented so
someone with this board would have to test it manually
to figure out which line it is. Whoever uses this design
will get to it if ever.
Yours,
Linus Walleij
--
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
^ permalink raw reply
* Re: [PATCH V8 1/3] OPP: Allow OPP table to be used for power-domains
From: Rob Herring @ 2017-12-21 22:06 UTC (permalink / raw)
To: Viresh Kumar
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, sudeep.holla-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <9cd1e90c782a8569d098adb63bee7dd1387528c4.1513591822.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Dec 18, 2017 at 03:51:28PM +0530, Viresh Kumar wrote:
> Power-domains can also have their active states and this patch enhances
> the OPP binding to define those. The power domains can use the OPP
> bindings as is, with one additional change to Allow
> "operating-points-v2" property to contain multiple phandles for power
> domain providers providing multiple domains.
>
> Reviewed-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 5 +++++
> Documentation/devicetree/bindings/power/power_domain.txt | 6 ++++++
> 2 files changed, 11 insertions(+)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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
^ permalink raw reply
* [PATCH] ARM: dts: tango4: remove bogus interrupt-controller property
From: Arnd Bergmann @ 2017-12-21 21:48 UTC (permalink / raw)
To: Marc Gonzalez
Cc: Arnd Bergmann, Rob Herring, Mark Rutland, Olof Johansson,
Thomas Gleixner, Greg Kroah-Hartman,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
dtc points out that the parent node of the interrupt controllers is not
actually an interrupt controller itself, and lacks an #interrupt-cells
property:
arch/arm/boot/dts/tango4-vantage-1172.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/interrupt-controller@6e000
This removes the annotation.
Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
---
arch/arm/boot/dts/tango4-common.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/tango4-common.dtsi b/arch/arm/boot/dts/tango4-common.dtsi
index 0ec1b0a317b4..ff72a8efb73d 100644
--- a/arch/arm/boot/dts/tango4-common.dtsi
+++ b/arch/arm/boot/dts/tango4-common.dtsi
@@ -156,7 +156,6 @@
reg = <0x6e000 0x400>;
ranges = <0 0x6e000 0x400>;
interrupt-parent = <&gic>;
- interrupt-controller;
#address-cells = <1>;
#size-cells = <1>;
--
2.9.0
--
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
^ permalink raw reply related
* [PATCH] ARM: dts: ls1021a: fix incorrect clock references
From: Arnd Bergmann @ 2017-12-21 21:44 UTC (permalink / raw)
To: Shawn Guo
Cc: Jingchang Lu, Arnd Bergmann, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
dtc warns about two 'clocks' properties that have an extraneous '1'
at the end:
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a:clocks[1])
Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2190000/sgtl5000@a
arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2190000/sgtl5000@a:clocks[1])
The clocks that get referenced here are fixed-rate, so they do not
take any argument, and dtc interprets the next cell as a phandle, which
is invalid.
Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
---
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-qds.dts
index 940875316d0f..67b4de0e3439 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -215,7 +215,7 @@
reg = <0x2a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
};
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
index a8b148ad1dd2..44715c8ef756 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -187,7 +187,7 @@
reg = <0x0a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
--
2.9.0
--
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
^ permalink raw reply related
* [PATCH] ARM: realview: remove eb-mp clcd IRQ
From: Arnd Bergmann @ 2017-12-21 21:31 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland, devicetree, Arnd Bergmann, linux-kernel,
Rob Herring, linux-arm-kernel
We get a dtc warning about the CLCD interrupt being invalid:
arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000
According to the datasheet I found and the old board file, this
line is not connected, so I'm removing the respective properties here.
Link: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0411d/index.html
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
index 7b8d90b7aeea..e45548ca229a 100644
--- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
+++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
@@ -151,8 +151,9 @@
};
&charlcd {
- interrupt-parent = <&intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ /* CLCD is not connected here */
+ /delete-property/interrupt-parent;
+ /delete-property/interrupts;
};
&serial0 {
--
2.9.0
^ permalink raw reply related
* [PATCH] ARM: dts: exynos: fix RTC interrupt for exynos5410
From: Arnd Bergmann @ 2017-12-21 21:30 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kukjin Kim, Krzysztof Kozlowski
Cc: Arnd Bergmann, Marek Szyprowski,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
According to the comment added to exynos_dt_pmu_match[] in commit
8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
the RTC is not able to wake up the system through the PMU on Exynos5410,
unlike Exynos5420.
However, when the RTC DT node got added, it was a straight copy of
the Exynos5420 node, which now causes a warning from dtc.
This removes the incorrect interrupt-parent, which should get the
interrupt working and avoid the warning.
Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410")
Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
---
arch/arm/boot/dts/exynos5410.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index 06713ec86f0d..d2174727df9a 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -333,7 +333,6 @@
&rtc {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
- interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
--
2.9.0
--
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
^ permalink raw reply related
* Re: [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Arnd Bergmann @ 2017-12-21 20:48 UTC (permalink / raw)
To: Ludovic BARRE
Cc: Alexandre Torgue, Russell King, Rob Herring, Linus Walleij,
Maxime Coquelin, Gerald Baeza, Linux ARM,
Linux Kernel Mailing List, DTML
In-Reply-To: <4093a02c-3216-d668-a6d8-1ce76046b554-qxv4g6HH51o@public.gmane.org>
On Thu, Dec 21, 2017 at 5:39 PM, Ludovic BARRE <ludovic.barre-qxv4g6HH51o@public.gmane.org> wrote:
>>>
>> Currently "restart" is not functional on stm32 MCU (at least for
>> stm32f746, I will check on others MCU). My fear is if Ludovic made some
>> patches to make "armv7m_restart" the default ".restart" function for all
>> armv7-m platform, he will not be able to test it on stm32 MCU (as it is not
>> currently working). I propose to do it in 2 steps:
>>
>> 1-Keep as you suggest only one board-dt.c file for both (MCU and MPU) and
>> remove ".restart" function.
>>
>> 2-Investigate and send patches around ".restart" for both in an other
>> series.
>
>
> I resend
Yes, that seems fine.
Arnd
--
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
^ permalink raw reply
* Re: [patches] [PATCH] RISC-V: Support built-in dtb
From: Palmer Dabbelt @ 2017-12-21 20:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: zongbox-Re5JQEeQqe8AvxtiuMwx3w, Olof Johansson,
albert-SpMDHPYPyPbQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, Wesley Terpstra,
patches-q3qR2WxjNRFS9aJRtSZj7A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, zong-MUIXKm3Oiri1Z/+hSey0Gg
In-Reply-To: <CAK8P3a2TVbrnjN00iZe2R_FNzLB+82BkiekPOwqtt6WDgFw30w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 21 Dec 2017 12:43:20 PST (-0800), Arnd Bergmann wrote:
> On Thu, Dec 21, 2017 at 9:32 PM, Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org> wrote:
>> On Wed, 20 Dec 2017 01:14:31 PST (-0800), zongbox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>
>> I've added Arnd and Olof, in case they have a bit more perspective here. If
>> I'm reading this correctly, there isn't an arm or arm64 option to do this.
>> There is an option to built in many DTBs, which makes a lot more sense to me
>> as it doesn't tie the kernel to any one particular implementation. We'd
>> need a mechanism for picking the DTB that Linux should use. We've kicked
>> around the idea of:
>>
>> * Having the bootloader always provide a DTB.
>> * Taking a hash of that DTB when booting Linux.
>> * Using that hash to look up DTBs that are built in to Linux.
>>
>> This would allow us to support replacing broken DTBs if they escape into the
>> wild, but would still allow us to have a portable kernel.
>
> Having an embedded DTB is only necessary for platforms with a legacy bootloader
> that doesn't understand DT at all, you should never need that here.
>
> I would suggest to require each bootloader to provide a way to replace the DTB
> with one that gets installed alongside the kernel.
Sounds good to me.
--
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
^ permalink raw reply
* Re: [patches] [PATCH] RISC-V: Support built-in dtb
From: Arnd Bergmann @ 2017-12-21 20:43 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: zongbox-Re5JQEeQqe8AvxtiuMwx3w, Olof Johansson,
albert-SpMDHPYPyPbQT0dZR+AlfA, Rob Herring, Mark Rutland,
Wesley Terpstra, patches-q3qR2WxjNRFS9aJRtSZj7A,
Linux Kernel Mailing List, DTML, Zong Li
In-Reply-To: <mhng-149d8a09-420d-4edc-ab13-cb6239193fc0@palmer-si-x1c4>
On Thu, Dec 21, 2017 at 9:32 PM, Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org> wrote:
> On Wed, 20 Dec 2017 01:14:31 PST (-0800), zongbox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> I've added Arnd and Olof, in case they have a bit more perspective here. If
> I'm reading this correctly, there isn't an arm or arm64 option to do this.
> There is an option to built in many DTBs, which makes a lot more sense to me
> as it doesn't tie the kernel to any one particular implementation. We'd
> need a mechanism for picking the DTB that Linux should use. We've kicked
> around the idea of:
>
> * Having the bootloader always provide a DTB.
> * Taking a hash of that DTB when booting Linux.
> * Using that hash to look up DTBs that are built in to Linux.
>
> This would allow us to support replacing broken DTBs if they escape into the
> wild, but would still allow us to have a portable kernel.
Having an embedded DTB is only necessary for platforms with a legacy bootloader
that doesn't understand DT at all, you should never need that here.
I would suggest to require each bootloader to provide a way to replace the DTB
with one that gets installed alongside the kernel.
Arnd
--
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
^ permalink raw reply
* Re: [patches] [PATCH] RISC-V: Support built-in dtb
From: Palmer Dabbelt @ 2017-12-21 20:32 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson
Cc: albert-SpMDHPYPyPbQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, Wesley Terpstra,
patches-q3qR2WxjNRFS9aJRtSZj7A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, zong-MUIXKm3Oiri1Z/+hSey0Gg,
zongbox-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1513761271-2386-1-git-send-email-zongbox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, 20 Dec 2017 01:14:31 PST (-0800), zongbox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> Build the dtb into the kernel image.
> If the DTB is given via bootloader, the external DTB is adopted first.
>
> Signed-off-by: Zong Li <zongbox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> arch/riscv/Kconfig | 4 ++++
> arch/riscv/Makefile | 9 +++++++++
> arch/riscv/boot/Makefile | 17 +++++++++++++++++
> arch/riscv/boot/dts/Makefile | 11 +++++++++++
> arch/riscv/kernel/setup.c | 2 +-
> 5 files changed, 42 insertions(+), 1 deletion(-)
> create mode 100644 arch/riscv/boot/Makefile
> create mode 100644 arch/riscv/boot/dts/Makefile
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 2e15e85..831cbb9 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -189,6 +189,10 @@ config RISCV_ISA_C
> config RISCV_ISA_A
> def_bool y
>
> +config RISCV_BUILTIN_DTB
> + string "Builtin DTB"
> + default ""
> +
> endmenu
It looks like most other architectures handle this via something like
config RISCV_BUILTIN_DTB
bool "Embed DTB in kernel image"
select BUILTIN_DTB
help
Embeds a device tree binary in the kernel image. The
bootloader's device tree will override the kernel's if the
bootloader provides a device tree.
config RISCV_BUILTIN_DTB_NAME
string "Built in DTB"
depends on RISCV_BUILTIN_DTB
help
Set the name of the DTB to embed (leave blank to pick one
automatically based on kernel configuration).
which matches what Linux does for other things (CMDLINE_BOOL/CMDLINE and
BLK_DEV_INITRD/INITRAMFS_SOURCE are the two I can think of). I don't see any
reason to be different here.
Additionally: I'm not sure I like the idea of having a bultin DTB. We're using
device tree to ensure the kernel is portable between different RISC-V systems,
and building one into the kernel seems to defeat that purpose. Since even BBL
can provide a device tree to Linux I don't think there's any reason to build
one in -- hopefully real systems will use a proper bootloader, and that will
have support for device trees as well.
I've added Arnd and Olof, in case they have a bit more perspective here. If
I'm reading this correctly, there isn't an arm or arm64 option to do this.
There is an option to built in many DTBs, which makes a lot more sense to me as
it doesn't tie the kernel to any one particular implementation. We'd need a
mechanism for picking the DTB that Linux should use. We've kicked around the
idea of:
* Having the bootloader always provide a DTB.
* Taking a hash of that DTB when booting Linux.
* Using that hash to look up DTBs that are built in to Linux.
This would allow us to support replacing broken DTBs if they escape into the
wild, but would still allow us to have a portable kernel.
What is this Kconfig entry meant to be used for?
>
> menu "Kernel type"
> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> index 6719dd3..4c5c9f8 100644
> --- a/arch/riscv/Makefile
> +++ b/arch/riscv/Makefile
> @@ -57,6 +57,12 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
> KBUILD_CFLAGS += -mcmodel=medany
> endif
>
> +ifneq '$(CONFIG_RISCV_BUILTIN_DTB)' '""'
> +BUILTIN_DTB := y
> +else
> +BUILTIN_DTB := n
> +endif
Maybe I've lost my mind, but I can't find anything that actually uses
CONFIG_BUILTIN_DTB outside of arch-specific code.
> # GCC versions that support the "-mstrict-align" option default to allowing
> # unaligned accesses. While unaligned accesses are explicitly allowed in the
> # RISC-V ISA, they're emulated by machine mode traps on all extant
> @@ -69,4 +75,7 @@ core-y += arch/riscv/kernel/ arch/riscv/mm/
>
> libs-y += arch/riscv/lib/
>
> +boot := arch/riscv/boot
> +core-$(BUILTIN_DTB) += $(boot)/dts/
> +
> all: vmlinux
> diff --git a/arch/riscv/boot/Makefile b/arch/riscv/boot/Makefile
> new file mode 100644
> index 0000000..003d697
> --- /dev/null
> +++ b/arch/riscv/boot/Makefile
> @@ -0,0 +1,17 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +targets := Image Image.gz
> +
> +$(obj)/Image: vmlinux FORCE
> + $(call if_changed,objcopy)
> +
> +$(obj)/Image.gz: $(obj)/Image FORCE
> + $(call if_changed,gzip)
> +
> +install: $(obj)/Image
> + $(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
> + $(obj)/Image System.map "$(INSTALL_PATH)"
> +
> +zinstall: $(obj)/Image.gz
> + $(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
> + $(obj)/Image.gz System.map "$(INSTALL_PATH)"
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> new file mode 100644
> index 0000000..b65d070
> --- /dev/null
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +ifneq '$(CONFIG_RISCV_BUILTIN_DTB)' '""'
> +BUILTIN_DTB := $(patsubst "%",%,$(CONFIG_RISCV_BUILTIN_DTB)).dtb.o
> +else
> +BUILTIN_DTB :=
> +endif
> +
> +obj-$(CONFIG_OF) += $(BUILTIN_DTB)
> +
> +clean-files := *.dtb *.dtb.S
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index e59a28c..3c89f3d 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -149,7 +149,7 @@ asmlinkage void __init setup_vm(void)
>
> void __init sbi_save(unsigned int hartid, void *dtb)
> {
> - early_init_dt_scan(__va(dtb));
> + early_init_dt_scan(dtb ? __va(dtb) : __dtb_start);
> }
>
> /*
--
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
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: at24: consistently document the compatible property
From: Javier Martinez Canillas @ 2017-12-21 20:27 UTC (permalink / raw)
To: Peter Rosin
Cc: Bartosz Golaszewski, Andy Shevchenko, Rob Herring, Mark Rutland,
David Lechner, Divagar Mohandass, Linux I2C, devicetree,
Linux Kernel
In-Reply-To: <0c2455ae-2f68-5342-14c6-14706d6f0e66@axentia.se>
Hello Peter,
On Thu, Dec 21, 2017 at 5:20 PM, Peter Rosin <peda@axentia.se> wrote:
> On 2017-12-21 14:48, Bartosz Golaszewski wrote:
>> Current description of the compatible property for at24 is quite vague.
>>
>> Specify an exact list of accepted compatibles and document the - now
>> deprecated - strings which were previously used in device tree files.
>
> Why is it suddenly deprecated to correctly specify what hardware you
> have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.
Sorry but I disagree.
When you specify a compatible string, you are not specifying a
particular hardware but a device programming model.
It's very common to use a compatible string that doesn't match exactly
the specific hardware used. That's why it's called _compatible_ BTW.
For example when a DTS define a UART node with an ns16550 compatible,
they don't really mean that have a UART IC manufactured by National
Semiconductor.
> Sure, it happens to be compatible with "atmel,24c32", but that is
> supposed to be written with a fallback as
>
> "nxp,24c32", "atmel,24c32"
This isn't a requirement really, systems integrators are free to use
more than one <manufacturer,model> tuple in the compatible string if
they want the DTB to be future proof, just in case there's a need for
a more specific driver or if the programming model happened to not be
the same at the end. This is usually done for the boards compatible
string as an example, even when there isn't a struct machine_desc for
the specific board compatible and only for the SoC family.
So it's OK if you want to define the compatible as "nxp,24c32",
"atmel,24c32", but that's a general OF concept and not something
related to the at24 eeprom driver so I'm not sure if it should be
mentioned in the at24 DT binding doc.
> if I understand correctly. So, why is that deprecated in this case?
>
> What if (a few years down the line) it is discovered that some weird
> quirk is needed that is only appropriate for nxp chips?
>
> nxp is of course just an example, pick any manufacturer of eeproms
> (supposedly) compatible with the atmel interface.
>
That's indeed a possibility and the reason why most DT nodes have a
more specific <manufacturer,model> before the generic one matched by
drivers. I really doubt that in the future it will be found that a
more specific compatible string is needed for one manufacturer in this
case, specially since the driver didn't even care about the
manufacturers until recently.
So I think that makes no sense for a driver to support all possible
manufacturers as possible compatible strings if all the devices have
the same exact programming model.
> Cheers,
> Peter
Best regards,
Javier
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: soc: qcom: Add label for GLINK bindings
From: Stephen Boyd @ 2017-12-21 19:36 UTC (permalink / raw)
To: Bjorn Andersson, Rob Herring
Cc: Chris Lew, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A, aneela-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171221013557.GE12655@minitux>
On 12/20/2017 05:35 PM, Bjorn Andersson wrote:
> On Wed 20 Dec 10:30 PST 2017, Rob Herring wrote:
>
>> On Mon, Dec 18, 2017 at 02:02:09PM -0800, Chris Lew wrote:
>>> Add a label property to identify the edge this node represents.
>> Why does a user need to know this?
>>
> We have multiple remoteproc instances, each one having one or more
> associated SMD or GLINK links (this node), exposing logical
> communication channels. Some of these logical channels are exposed to
> user space and we need a way to distinguish them there.
>
> In the current implementation of SMD this value goes straight into an
> sysfs attribute that we can use when writing udev rules and for the DIAG
> implementation to pair up channels related to the same remoteproc. This
> adds the equivalent information for glink-backed channels.
>
>
> I'm therefor in favor of picking this patch.
Please add these details to the commit log. Just writing what the patch
is doing isn't very helpful.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
^ permalink raw reply
* Re: [PATCH v3 3/3] drm/tinydrm: add driver for ST7735R panels
From: David Lechner @ 2017-12-21 19:35 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Noralf Trønnes, limor-6aDhHjTmHzzR7s880joybQ, Linus Walleij,
Rob Herring, Mark Rutland, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513884233-31540-4-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On 12/21/2017 01:23 PM, David Lechner wrote:
> This adds a new driver for Sitronix ST7735R display panels.
>
> This has been tested using an Adafruit 1.8" TFT.
>
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
> ---
<snip>
> + mipi_dbi_command(mipi, ST7735R_GAMCTRP1, 0x0f, 0x1a, 0x0f, 0x18, 0x2f,
> + 0x28, 0x20, 0x22, 0x1f, 0x1b, 0x23, 0x37, 0x00, 0x07,
> + 0x02, 0x10);
> + mipi_dbi_command(mipi, ST7735R_GAMCTRN1, 0x0f, 0x1b, 0x0f, 0x17, 0x33,
> + 0x2c, 0x29, 0x2e, 0x30, 0x30, 0x39, 0x3f, 0x00, 0x07,
> + 0x03, 0x10);
By the way, how do you know what is the "right" gamma curve? I think I
copied this from the generic st7735r driver in fbtft, but I noticed that
there is also a different curve for the Adafruit 1.8" display in fbtft.
I'm wondering if I should have used that one instead. I can't really
tell a difference looking at the display.
--
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox