* Re: [PATCH v4 1/2] dt-bindings: Document the STM32 QSPI bindings
From: Rob Herring @ 2017-04-19 22:35 UTC (permalink / raw)
To: Ludovic Barre
Cc: Cyrille Pitchen, Marek Vasut, David Woodhouse, Brian Norris,
Boris Brezillon, Richard Weinberger, Alexandre Torgue,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1492103757-22375-2-git-send-email-ludovic.Barre-qxv4g6HH51o@public.gmane.org>
On Thu, Apr 13, 2017 at 07:15:56PM +0200, Ludovic Barre wrote:
> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>
> This patch adds documentation of device tree bindings for the STM32
> QSPI controller.
>
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> ---
> .../devicetree/bindings/mtd/stm32-quadspi.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/stm32-quadspi.txt
Acked-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] ASoC: cs35l35: Allow user to configure IMON SCALE
From: Rob Herring @ 2017-04-19 22:32 UTC (permalink / raw)
To: Charles Keepax
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
mark.rutland-5wv7dgnIgG8, brian.austin-jGc1dHjMKG3QT0dZR+AlfA,
Paul.Handrigan-jGc1dHjMKG3QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E
In-Reply-To: <1492098729-30491-1-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Thu, Apr 13, 2017 at 04:52:09PM +0100, Charles Keepax wrote:
> On the chip the IMON signal is a full 24-bits however normally only
> some of the bits will be sent over the bus. The chip provides a field
> to select which bits of the IMON will be sent back, this is the only
> feedback signal that has this feature.
>
> Add an additional entry to the cirrus,imon device tree property to
> allow the IMON scale parameter to be passed.
>
> Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> ---
>
> I realise this is changing the binding slightly, but thought
> we might be able to sneak it before cs35l35 ships as it hasn't
> shipped in a kernel yet. However, it would be relatively simple
> (although makes the code a little messier) to support both the 3
> and 4 entry versions of the binding if people prefer?
Given it is new, I'm okay with the change if you are.
>
> Thanks,
> Charles
>
> .../devicetree/bindings/sound/cs35l35.txt | 4 ++--
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> include/sound/cs35l35.h | 1 +
> sound/soc/codecs/cs35l35.c | 22 +++++++++++++++-------
> sound/soc/codecs/cs35l35.h | 3 +++
> 4 files changed, 21 insertions(+), 9 deletions(-)
--
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 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
From: Rob Herring @ 2017-04-19 22:09 UTC (permalink / raw)
To: Philipp Zabel
Cc: Peter Rosin, Mark Rutland, Sakari Ailus, Steve Longerbeam,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170413154812.19597-1-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Thu, Apr 13, 2017 at 05:48:11PM +0200, Philipp Zabel wrote:
> This adds device tree binding documentation for mmio-based syscon
> multiplexers controlled by a single bitfield in a syscon register
> range.
>
> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mux/mmio-mux.txt | 56 ++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mux/mmio-mux.txt
>
> diff --git a/Documentation/devicetree/bindings/mux/mmio-mux.txt b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> new file mode 100644
> index 0000000000000..11d96f5d98583
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> @@ -0,0 +1,56 @@
> +MMIO bitfield-based multiplexer controller bindings
> +
> +Define a syscon bitfield to be used to control a multiplexer. The parent
> +device tree node must be a syscon node to provide register access.
> +
> +Required properties:
> +- compatible : "gpio-mux"
?
> +- reg : register base of the register containing the control bitfield
> +- bit-mask : bitmask of the control bitfield in the control register
> +- bit-shift : bit offset of the control bitfield in the control register
> +- #mux-control-cells : <0>
> +* Standard mux-controller bindings as decribed in mux-controller.txt
> +
> +Optional properties:
> +- idle-state : if present, the state the mux will have when idle. The
> + special state MUX_IDLE_AS_IS is the default.
> +
> +The multiplexer state is defined as the value of the bitfield described
> +by the reg, bit-mask, and bit-shift properties, accessed through the parent
> +syscon.
> +
> +Example:
> +
> + syscon {
> + compatible = "syscon";
> +
> + mux: mux-controller@3 {
> + compatible = "mmio-mux";
> + reg = <0x3>;
> + bit-mask = <0x1>;
> + bit-shift = <5>;
This pattern doesn't scale once you have multiple fields @ addr 3. I
also don't really think a node per register field in DT really scales.
I think the parent should be declared as a mux controller instead. You
could encode the mux addr and bit position in the mux cells.
> + #mux-control-cells = <0>;
> + };
> + };
> +
> + video-mux {
> + compatible = "video-mux";
> + mux-controls = <&mux>;
The mux binding was largely defined for a single control controling
multiple muxes. This doesn't really fit that, but I guess this is an
improvement over a custom syscon phandle.
> +
> + ports {
> + /* input 0 */
> + port@0 {
> + reg = <0>;
> + };
> +
> + /* input 1 */
> + port@1 {
> + reg = <1>;
> + };
> +
> + /* output */
> + port@2 {
> + reg = <2>;
> + };
> + };
> + };
> --
> 2.11.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
* Re: [PATCH V3] PM / OPP: Use - instead of @ for DT entries
From: Rafael J. Wysocki @ 2017-04-19 22:06 UTC (permalink / raw)
To: Olof Johansson
Cc: Viresh Kumar, arm, Chanwoo Choi, MyungJoo Ham, Kyungmin Park,
Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Viresh Kumar, Nishanth Menon, Stephen Boyd, Beno??t Cousson,
Tony Lindgren, Rob Herring, Mark Rutland, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Maxime Ripard, Chen-Yu Tsai,
Masahiro
In-Reply-To: <20170419142215.GA12105@localhost>
On Wednesday, April 19, 2017 07:22:15 AM Olof Johansson wrote:
> Hi Viresh,
>
> On Tue, Apr 18, 2017 at 10:44:50AM +0530, Viresh Kumar wrote:
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
> > Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> (uniphier)
> > Acked-by: Rob Herring <robh@kernel.org>
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> We've already turned down other patches that does this in a sweeping manner
> like this, since they tend to be conflict prone with other DT changes.
>
> Please split per platform and merge with each maintainer.
OK
So I'm assuming that you guys will take care of this going forward.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH 2/4] net: macb: Add tsu_clk to device tree
From: Rob Herring @ 2017-04-19 21:57 UTC (permalink / raw)
To: Rafal Ozieblo
Cc: David Miller, nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
harinikatakamlinux-Re5JQEeQqe8AvxtiuMwx3w,
harini.katakam-gjFFaj9aHVfQT0dZR+AlfA,
richardcochran-Re5JQEeQqe8AvxtiuMwx3w,
Andrei.Pistirica-UWL1GkI3JZL3oGB3hsPCZA
In-Reply-To: <1492090686-14778-1-git-send-email-rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
On Thu, Apr 13, 2017 at 02:38:06PM +0100, Rafal Ozieblo wrote:
> Signed-off-by: Rafal Ozieblo <rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/macb.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-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 v2 3/4] doc,dts - add XRA1403 DTS binding documentation
From: Rob Herring @ 2017-04-19 21:55 UTC (permalink / raw)
To: Nandor Han
Cc: gregkh, davem, geert, mchehab, daniel.vetter, linus.walleij,
gnurou, mark.rutland, linux-gpio, devicetree, linux-kernel
In-Reply-To: <0d970c6a929597804eae3577ed24f57ee23b820a.1492077070.git.nandor.han@ge.com>
On Thu, Apr 13, 2017 at 01:27:50PM +0300, Nandor Han wrote:
> Add the XRA1403 DTS binding documentation.
"dt-bindings: gpio: ..." for the subject.
>
> Signed-off-by: Nandor Han <nandor.han@ge.com>
> ---
> .../devicetree/bindings/gpio/gpio-xra1403.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
Otherwise,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH V2] ARM: dts: BCM5301X: Specify MDIO bus in the DT
From: Rafał Miłecki @ 2017-04-19 21:54 UTC (permalink / raw)
To: Florian Fainelli
Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170402210840.11429-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Northstar devices have MDIO bus that may contain various PHYs attached.
A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Disable MDIO bus by default.
Add mdio label to allow enabling it easily per board
---
arch/arm/boot/dts/bcm5301x.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index acee36a61004..1f34bc6905f2 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -320,6 +320,14 @@
};
};
+ mdio: mdio@18003000 {
+ compatible = "brcm,iproc-mdio";
+ reg = <0x18003000 0x8>;
+ #size-cells = <1>;
+ #address-cells = <0>;
+ status = "disabled";
+ };
+
i2c0: i2c@18009000 {
compatible = "brcm,iproc-i2c";
reg = <0x18009000 0x50>;
--
2.11.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 1/4] dt-bindings: gpio - add exar to vendor prefixes list
From: Rob Herring @ 2017-04-19 21:48 UTC (permalink / raw)
To: Nandor Han
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, daniel.vetter-/w4YWyX8dFk,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <f02af49f4d72326c455c9137ffb2714e7236cbab.1492077070.git.nandor.han-JJi787mZWgc@public.gmane.org>
On Thu, Apr 13, 2017 at 01:27:48PM +0300, Nandor Han wrote:
> Add Exar Corporation to vendors list.
This patch has nothing to do with gpio, so that should be dropped from
the subject.
>
> Signed-off-by: Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
Otherwise,
Acked-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 1/3] dt-bindings: mt8173: Fix mdp device tree
From: Rob Herring @ 2017-04-19 21:35 UTC (permalink / raw)
To: Minghsiu Tsai
Cc: Hans Verkuil, daniel.thompson-QSEj5FYQhm4dnm+yROfE0A,
Mauro Carvalho Chehab, Matthias Brugger, Daniel Kurtz,
Pawel Osciak, Houlong Wei, srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1492068787-17838-2-git-send-email-minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Thu, Apr 13, 2017 at 03:33:05PM +0800, Minghsiu Tsai wrote:
> If the mdp_* nodes are under an mdp sub-node, their corresponding
> platform device does not automatically get its iommu assigned properly.
>
> Fix this by moving the mdp component nodes up a level such that they are
> siblings of mdp and all other SoC subsystems. This also simplifies the
> device tree.
It may simplify the DT, but it also breaks compatibility with old DT.
Not sure if that's a problem on Mediatek platforms, but please be
explicit here that you are breaking compatibility and why that is okay.
>
> Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Should this have Daniel as the author?
>
> ---
> Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++---------
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> index 4182063..0d03e3a 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> @@ -2,7 +2,7 @@
>
> Media Data Path is used for scaling and color space conversion.
>
> -Required properties (controller (parent) node):
> +Required properties (controller node):
> - compatible: "mediatek,mt8173-mdp"
> - mediatek,vpu: the node of video processor unit, see
> Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
> @@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
> for details.
>
> Example:
> -mdp {
> - compatible = "mediatek,mt8173-mdp";
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> - mediatek,vpu = <&vpu>;
> -
> mdp_rdma0: rdma@14001000 {
> compatible = "mediatek,mt8173-mdp-rdma";
> + "mediatek,mt8173-mdp";
> reg = <0 0x14001000 0 0x1000>;
> clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> <&mmsys CLK_MM_MUTEX_32K>;
> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> mediatek,larb = <&larb0>;
> + mediatek,vpu = <&vpu>;
> };
>
> mdp_rdma1: rdma@14002000 {
> @@ -106,4 +101,3 @@ mdp {
> iommus = <&iommu M4U_PORT_MDP_WROT1>;
> mediatek,larb = <&larb4>;
> };
> -};
> --
> 1.9.1
>
--
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/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings
From: Rob Herring @ 2017-04-19 21:23 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ, mark.rutland-5wv7dgnIgG8,
clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w,
romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
shannon.nelson-QHcLZuEGTsvQT0dZR+AlfA,
weiyongjun1-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1492067108-14748-2-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Thu, Apr 13, 2017 at 03:05:07PM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Document the devicetree bindings for Mediatek random number
> generator which could be found on MT7623 SoC or other similar
> Mediatek SoCs.
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
Acked-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 2/2] drm/panel: simple: add support for NLT NL192108AC18-02D
From: Rob Herring @ 2017-04-19 21:15 UTC (permalink / raw)
To: Lucas Stach; +Cc: Mark Rutland, devicetree, dri-devel, patchwork-lst, kernel
In-Reply-To: <20170412171526.32393-2-l.stach@pengutronix.de>
On Wed, Apr 12, 2017 at 07:15:26PM +0200, Lucas Stach wrote:
> This adds support for the NLT Technologies NL192108AC18-02D
> 15.6" LVDS FullHD TFT LCD panel, which can be supported
> by the simple panel driver.
>
> Timings are taken from the preliminary datasheet, as a final
> one is not yet available.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> .../display/panel/nlt,nl192108ac18-02d.txt | 7 ++++++
> drivers/gpu/drm/panel/panel-simple.c | 29 ++++++++++++++++++++++
> 2 files changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt b/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
> new file mode 100644
> index 000000000000..edc34fbd2131
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
> @@ -0,0 +1,7 @@
> +NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "nlt,nl192108ac18-02d"
Please define the power supply. Is power-supply used or are there
multiple supplies?
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: add vendor prefix for NLT Technologies, Ltd.
From: Rob Herring @ 2017-04-19 21:14 UTC (permalink / raw)
To: Lucas Stach; +Cc: Mark Rutland, devicetree, dri-devel, patchwork-lst, kernel
In-Reply-To: <20170412171526.32393-1-l.stach@pengutronix.de>
On Wed, Apr 12, 2017 at 07:15:25PM +0200, Lucas Stach wrote:
> NLT technologies is the former NEC display business, but changed its
> name to NLT Technologies when forming a joint venture with
> Shenzhen AVIC OPTOELECTRONICS, Ltd.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
From: Tyrel Datwyler @ 2017-04-19 21:13 UTC (permalink / raw)
To: Michael Ellerman, Oliver O'Halloran, Rob Herring
Cc: devicetree@vger.kernel.org, linuxppc-dev,
linux-kernel@vger.kernel.org, rostedt, Ingo Molnar,
Tyrel Datwyler, Nathan Fontenot, Frank Rowand
In-Reply-To: <87y3uw66y5.fsf@concordia.ellerman.id.au>
On 04/19/2017 03:13 AM, Michael Ellerman wrote:
> Oliver O'Halloran <oohall@gmail.com> writes:
>
>> On Wed, Apr 19, 2017 at 2:46 AM, Rob Herring <robh+dt@kernel.org> wrote:
>>> On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler
>>> <tyreld@linux.vnet.ibm.com> wrote:
>>>> This patch introduces event tracepoints for tracking a device_nodes
>>>> reference cycle as well as reconfig notifications generated in response
>>>> to node/property manipulations.
>>>>
>>>> With the recent upstreaming of the refcount API several device_node
>>>> underflows and leaks have come to my attention in the pseries (DLPAR) dynamic
>>>> logical partitioning code (ie. POWER speak for hotplugging virtual and physcial
>>>> resources at runtime such as cpus or IOAs). These tracepoints provide a
>>>> easy and quick mechanism for validating the reference counting of
>>>> device_nodes during their lifetime.
>>>
>>> Not really relevant for this patch, but since you are looking at
>>> pseries and refcounting, the refcounting largely exists for pseries.
>>> It's also hard to get right as this type of fix is fairly common. It's
>>> now used for overlays, but we really probably only need to refcount
>>> the overlays or changesets as a whole, not at a node level. If you
>>> have any thoughts on how a different model of refcounting could work
>>> for pseries, I'd like to discuss it.
>>
>> One idea I've been kicking around is differentiating short and long
>> term references to a node.
>
> I actually did this a long time ago, but balked at the size of the patch
> to do the conversion. Let me see if I can find it lying around ...
It would be interesting to revisit this, and toss around any other ideas
anyone may have.
-Tyrel
>
> cheers
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v4 04/18] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: Rob Herring @ 2017-04-19 21:06 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170412111400.2296-5-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Apr 12, 2017 at 01:13:46PM +0200, Corentin Labbe wrote:
> This patch adds documentation for Device-Tree bindings for the
> syscon present in allwinner devices.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v2 2/2] devicetree: Document the max31760 device binding.
From: Rob Herring @ 2017-04-19 21:04 UTC (permalink / raw)
To: John Muir
Cc: Jean Delvare, Guenter Roeck, Jonathan Corbet, Pawel Moll,
Ian Campbell, Kumar Gala, devicetree, linux-hwmon, linux-doc,
Anatol Pomazau, Mark Segal
In-Reply-To: <20170411213218.138718-3-john@jmuir.com>
On Tue, Apr 11, 2017 at 02:32:18PM -0700, John Muir wrote:
> v2:
> - Fixup based on comments.
While you should have a commit msg here, the patch versioning goes below
the '---'.
This history is not too useful either. You should describe what you
changed so reviewers don't have to go find the previous versions. I may
remember reviewing a patch, but I likely don't remember what I said.
>
> Signed-off-by: John Muir <john@jmuir.com>
> ---
> .../devicetree/bindings/hwmon/max31760.txt | 72 ++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/max31760.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/max31760.txt b/Documentation/devicetree/bindings/hwmon/max31760.txt
> new file mode 100644
> index 000000000000..760fdf0b55e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/max31760.txt
> @@ -0,0 +1,72 @@
> +MAX31760 fan controller
> +-----------------------
> +
> +This device supports I2C only. Fan sub-nodes must be defined in order to enable
> +the fan tachometer input. See also the datasheet:
> +https://datasheets.maximintegrated.com/en/ds/MAX31760.pdf
> +
> +Required node properties:
> + - compatible: "maxim,max31760"
> + - reg: The I2C address of the device. This is 0x50 - 0x57 depending on the
> + hardware configuration.
> + - #address-cells: Must be 1.
> + - #size-cells: Must be 0.
> +
> +Optional node properties:
> + - maxim,fan-fail-full-only: Boolean; Assert a fan failure only when the PWM is
> + at 100%.
> + - maxim,fan-rd-signal: Boolean; Fans provide a rotation detection (RD) signal
> + instead of generating square-wave pulses.
> + - maxim,fan-rd-polarity-high: Boolean; RD is high when the fan is running, not
> + low. Only relevant when fan-rd-signal is true.
> + - maxim,fan-signal-enabled: Boolean; Externally driving FF/FS low should force
> + PWM output to 100%.
> + - maxim,fan-spin-up-enabled: Boolean; For fan startup set the PWM to 100% until
> + tach is detected or two seconds have passed before reducing to the target
> + value.
> + - maxim,pwm-polarity-negative: Boolean; 100% PWM is when PWM is low, not high.
> + - maxim,pwm-pulse-stretch-enabled: Boolean; Enable PWM pulse stretching.
> + - maxim,pwm-zero-fan-can-fail: Boolean; Enable fan failure detection while
> + ramping to 0% PWM.
> +
> +Fan sub-nodes must be present in order to enable the fan.
> +
> +Required fan sub-node properties:
> + - reg: Fan address. Must be <0x00> or <0x01>.
> +
> +Optional fan sub-node properties:
> + - label: String; Assigned to the hwmon fanX_label property.
> +
> +Temperature sub-nodes are optional.
> +
> +Required temp sub-node properties:
> + - reg: Temperature sensor address. Must be <0x00> or <0x01>.
> +
> +Optional temp sub-node properties:
> + - label: String; Assigned to the hwmon tempX_label property.
> + - ideality: For temperature node with reg 1 only: Set ideality factor for the
This too needs a maxim prefix.
> + remote temperature sensor. Integer with range 0 to 63, representing a
> + multiplication factor of 0.9844 to 1.0489. Default: 24 (1.0080).
> +
> +Example:
> + max31760@50 {
> + compatible = "maxim,max31760";
> + reg = <0x50>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + maxim,fan-spin-up-enabled;
> +
> + fan@0 {
> + reg = <0x00>;
> + label = "Left";
> + };
> + fan@1 {
> + reg = <0x01>;
> + label = "Right";
> + };
> + temp@1 {
> + reg = <0x01>;
> + label = "CPU";
> + };
> + };
> --
> 2.12.2.715.g7642488e1d-goog
>
^ permalink raw reply
* Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller
From: Peter Rosin @ 2017-04-19 21:04 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-kernel, Greg Kroah-Hartman, Wolfram Sang, Rob Herring,
Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
linux-i2c, devicetree, linux-iio, linux-doc, Andrew Morton,
Colin Ian King, Paul Gortmaker, kernel
In-Reply-To: <1492609756.2970.131.camel@pengutronix.de>
On 2017-04-19 15:49, Philipp Zabel wrote:
> On Wed, 2017-04-19 at 14:00 +0200, Peter Rosin wrote:
> [...]
>>>> +int mux_control_select(struct mux_control *mux, int state)
>>>
>>> If we let two of these race, ...
>>
>> The window for this "race" is positively huge. If there are several
>> mux consumers of a single mux controller, it is self-evident that
>> if one of them grabs the mux for a long time, the others will suffer.
>>
>> The design is that the rwsem is reader-locked for the full duration
>> of a select/deselect operation by the mux consumer.
>
> I was not clear. I meant: I think this can also happen if we let them
> race with the same state target.
Right, but there is another glaring problem with the v13 implementation
of select/deselect. If there are three consumers and the first one
holds the mux while the other two tries to select it to some other
position, then even if the two "new" consumers agree on the mux state,
then both of them will end up in the "it's just contended" case and
then be serialized. So, yes, the select/deselect implementation is not
perfect. To quote the cover letter:
I'm using an rwsem to lock a mux, but that isn't really a
perfect fit. Is there a better locking primitive that I don't
know about that fits better? I had a mutex at one point, but
that didn't allow any concurrent accesses at all. At least
the rwsem allows concurrent access as long as all users
agree on the mux state, but I suspect that the rwsem will
degrade to the mutex situation pretty quickly if there is
any contention.
But with your discovery that there's a race when two consumers go
for the same state in a free mux, in addition to the above contention
problem, I'm about ready to go with Greg's suggestion and just use a
mutex. I.e. ignore the desire to allow concurrent use. Because it's
not like the sketchy thing I threw out in the other part of the thread
solves any of these problems. I can live without the concurrency, and
I guess I can also live with passing the buck to the poor sod that
eventually needs it.
>>>> +{
>>>> + int ret;
>>>> +
>>>> + if (down_read_trylock(&mux->lock)) {
>>>> + if (mux->cached_state == state)
>>>> + return 0;
>
> This check makes it clear that a second select call is not intended to
> block if the intended state is already selected. But if the instance we
> will lose the race against has not yet updated cached_state, ...
>
>>>> + /* Sigh, the mux needs updating... */
>>>> + up_read(&mux->lock);
>>>> + }
>>>> +
>>>> + /* ...or it's just contended. */
>>>> + down_write(&mux->lock);
>
> ... we are blocking here until the other instance calls up_read. Even
> though in this case (same state target) we would only have to block
> until the other instance calls downgrade_write after the mux control is
> set to the correct state.
>
> Basically there is a small window before down_write with no lock at all,
> where multiple instances can already have decided they must change the
> mux (to the same state). If this happens, they go on to block each other
> unnecessarily.
>
>>> ... then the last to get to down_write will just wait here forever (or
>>> until the first consumer calls mux_control_deselect, which may never
>>> happen)?
>>
>> It is vital that the mux consumer call _deselect when it is done with
>> the mux. Not doing so will surely starve out any other mux consumers.
>> The whole thing is designed around the fact that mux consumers should
>> deselect the mux as soon as it's no longer needed.
>
> I'd like to use this for video bus multiplexers. Those would not be
> selected for the duration of an i2c transfer, but for the duration of a
> running video capture stream, or for the duration of an enabled display
> path. While I currently have no use case for multiple consumers
> controlling the same mux, this scenario is what shapes my perspective.
> For such long running selections the consumer should have the option to
> return -EBUSY instead of blocking when the lock can't be taken.
I'll see if I can implement a try variant for the mutex based select I
will probably end up with in v14...
Cheers,
peda
^ permalink raw reply
* Re: [PATCH V5 1/3] dt-bindings: mtd: document linux,part-probe property
From: Boris Brezillon @ 2017-04-19 20:55 UTC (permalink / raw)
To: Brian Norris
Cc: Rafał Miłecki, David Woodhouse, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170419203705.GF20555-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Wed, 19 Apr 2017 13:37:05 -0700
Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi,
>
> On Mon, Apr 17, 2017 at 09:47:44PM +0200, Rafał Miłecki wrote:
> > From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> >
> > Support for this property has been introduced in 2010 with commit
> > 9d5da3a9b849 ("mtd: extend physmap_of to let the device tree specify the
> > parition probe") but it was never documented. Fix this by adding a
> > proper description and example.
> >
> > Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Acked-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/mtd/common.txt | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
> > index fc068b923d7a..1ada70e718b2 100644
> > --- a/Documentation/devicetree/bindings/mtd/common.txt
> > +++ b/Documentation/devicetree/bindings/mtd/common.txt
> > @@ -6,10 +6,17 @@ Optional properties:
> > controller based name) in order to ease flash device identification
> > and/or describe what they are used for.
> >
> > +- linux,part-probe: if present, this property should contain a list of strings
> > + with partition probes to be used for the flash device. A role of partition
> > + probe (parser) is to read/construct partition table and register found
> > + partitions. Getting partition table may be platform or device specific so
> > + various devices may use various Linux drivers for this purpose.
>
> Have you reviewed the old threads about this? I thought I already
> discouraged extending this binding to be generic. Particularly, we do
> *not* want to codify things like 'linux,part-probe = "bcm47xxpart"',
> which doesn't follow any accepted practice about naming. And you've also
> failed to document any actual strings to put here, which hides the fact
> that you're opening a can of worms.
>
> Piece of a previous thread:
> http://lists.infradead.org/pipermail/linux-mtd/2015-October/062613.html
> [PATCH] mtd: document linux-specific partition parser DT binding
>
> I attempted to resolve that here, but never made time to address the few
> not-so-constructive comments I received:
>
> https://mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1035539.html
> [RFC PATCH 0/7] mtd: partitions: add of_match_table support
Oops, completely forgot you had proposed an alternative solution. Sorry
about that.
--
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 1/4] dt-bindings: net: Add TI WiLink shared transport binding
From: Rob Herring @ 2017-04-19 20:49 UTC (permalink / raw)
To: Adam Ford
Cc: Mark Rutland, Johan Hedberg, Wei Xu, Eyal Reizer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:BLUETOOTH DRIVERS, Gustavo Padovan, Marcel Holtmann,
Satish Patel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
netdev
In-Reply-To: <CAHCN7x+G_jbQTDfyPBZ4Er8vz46tEojrWf29Eztq56c9zBnMeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Apr 16, 2017 at 9:09 AM, Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> On Apr 13, 2017 10:04 AM, "Rob Herring" <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> Add serial slave device binding for the TI WiLink series of Bluetooth/FM/GPS
> devices.
>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> v3:
> - rebase on bluetooth-next
>
> .../devicetree/bindings/net/ti,wilink-st.txt | 35
> ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
>
> diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> new file mode 100644
> index 000000000000..cbad73a84ac4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> @@ -0,0 +1,35 @@
> +TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
> +
> +TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
> +and GPS over what's called "shared transport". The shared transport is
> +standard BT HCI protocol with additional channels for the other functions.
> +
> +These devices also have a separate WiFi interface as described in
> +wireless/ti,wlcore.txt.
> +
> +This bindings follows the UART slave device binding in
> +../serial/slave-device.txt.
> +
> +Required properties:
> + - compatible: should be one of the following:
> + "ti,wl1271-st"
> + "ti,wl1273-st"
> + "ti,wl1831-st"
> + "ti,wl1835-st"
> + "ti,wl1837-st"
> +
>
>
> Would you expect the wl1283 chipset too?
Probably, but I left it out as there's no public information.
> I can help test this if you like after the holiday weekend. I have a board
> with WL1283 and currently using pdata-quirks to support it.
^ permalink raw reply
* Re: [PATCH v3 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Rob Herring @ 2017-04-19 20:47 UTC (permalink / raw)
To: Adam Ford
Cc: Marcel Holtmann, open list:BLUETOOTH DRIVERS, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Johan Hedberg,
Gustavo Padovan, Satish Patel, Wei Xu, Eyal Reizer, netdev,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAHCN7xLNcD1rmifEOyPhG2rpB_C81hsyzV9W2q6kCQkKa69sZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Apr 17, 2017 at 3:11 PM, Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 10:03 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
>> The TI-ST adds firmware loading, GPIO control, and shared access for
>> NFC, FM radio, etc. For now, we're only implementing what is needed for
>> BT. This mirrors other drivers like BCM and Intel, but uses the new
>> serdev bus.
>>
>> The firmware loading is greatly simplified by using existing
>> infrastructure to send commands. It may be a bit slower than the
>> original code using synchronous functions, but the real bottleneck is
>> likely doing firmware load at 115.2kbps.
>
> I am using pdata-quirks to drive my wl1283 Bluetooth on a DM3730. I
> have the Bluetooth set to 3000000 baud in pdata quirks. Looking at
> the binding, I don't see an option to set the baudrate. Is there (or
> will there) be a way to set the baud rate of the Bluetooth?
If you read hci_ti_probe, you will see it is already there. The
default is 3Mbps and the DT can override that with "max-speed". The
intent is that 3Mbps is the max the device can do and max-speed is
only for board or host limitations. Though I just checked the
datasheet on the 1835 and it can go up to 4364kbps. No datasheets for
wl1283, so I have no idea what the max is.
>> +static int hci_ti_probe(struct serdev_device *serdev)
>> +{
>> + struct hci_uart *hu;
>> + struct ll_device *lldev;
>> + u32 max_speed = 3000000;
[...]
>> + of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
>> + hci_uart_set_speeds(hu, 115200, max_speed);
^ permalink raw reply
* Re: [PATCH V5 1/3] dt-bindings: mtd: document linux,part-probe property
From: Brian Norris @ 2017-04-19 20:37 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Boris Brezillon, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Rob Herring, Mark Rutland, Frank Rowand,
Linus Walleij, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170417194746.10697-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
On Mon, Apr 17, 2017 at 09:47:44PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> Support for this property has been introduced in 2010 with commit
> 9d5da3a9b849 ("mtd: extend physmap_of to let the device tree specify the
> parition probe") but it was never documented. Fix this by adding a
> proper description and example.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mtd/common.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
> index fc068b923d7a..1ada70e718b2 100644
> --- a/Documentation/devicetree/bindings/mtd/common.txt
> +++ b/Documentation/devicetree/bindings/mtd/common.txt
> @@ -6,10 +6,17 @@ Optional properties:
> controller based name) in order to ease flash device identification
> and/or describe what they are used for.
>
> +- linux,part-probe: if present, this property should contain a list of strings
> + with partition probes to be used for the flash device. A role of partition
> + probe (parser) is to read/construct partition table and register found
> + partitions. Getting partition table may be platform or device specific so
> + various devices may use various Linux drivers for this purpose.
Have you reviewed the old threads about this? I thought I already
discouraged extending this binding to be generic. Particularly, we do
*not* want to codify things like 'linux,part-probe = "bcm47xxpart"',
which doesn't follow any accepted practice about naming. And you've also
failed to document any actual strings to put here, which hides the fact
that you're opening a can of worms.
Piece of a previous thread:
http://lists.infradead.org/pipermail/linux-mtd/2015-October/062613.html
[PATCH] mtd: document linux-specific partition parser DT binding
I attempted to resolve that here, but never made time to address the few
not-so-constructive comments I received:
https://mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1035539.html
[RFC PATCH 0/7] mtd: partitions: add of_match_table support
I'd still prefer that approach to supporting this shortcut for all MTDs.
Brian
> +
> Example:
>
> flash@0 {
> label = "System-firmware";
> + linux,part-probe = "cmdlinepart", "ofpart";
>
> /* flash type specific properties */
> };
> --
> 2.11.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
* Re: [PATCH v6 6/9] ASoC: simple-card-utils: enable "label" on asoc_simple_card_parse_card_name
From: Rob Herring @ 2017-04-19 20:31 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Mark Brown, Linux-ALSA, Simon, Linux-DT
In-Reply-To: <87fuh6xwt1.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Mon, Apr 17, 2017 at 9:44 PM, Kuninori Morimoto
<kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> Current asoc_simple_card_parse_card_name() detect [prefix]name,
> but in generally, we uses "label" for user visible names.
> This patch enables [prefix]label too.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> v5 -> v6
>
> - used const for names[]
>
> sound/soc/generic/simple-card-utils.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c
> index 343b291..94ceaca 100644
> --- a/sound/soc/generic/simple-card-utils.c
> +++ b/sound/soc/generic/simple-card-utils.c
> @@ -81,15 +81,25 @@ int asoc_simple_card_set_dailink_name(struct device *dev,
> int asoc_simple_card_parse_card_name(struct snd_soc_card *card,
> char *prefix)
> {
> + char * const names[] = {
> + "label", "name"
> + };
> char prop[128];
> + int i;
> int ret;
>
> - snprintf(prop, sizeof(prop), "%sname", prefix);
> + if (!prefix)
> + prefix = "";
>
> /* Parse the card name from DT */
> - ret = snd_soc_of_parse_card_name(card, prop);
> - if (ret < 0)
> - return ret;
> + for (i = 0; i < ARRAY_SIZE(names); i++) {
> + snprintf(prop, sizeof(prop), "%s%s", prefix, names[i]);
> + ret = snd_soc_of_parse_card_name(card, prop);
> + if (ret < 0)
> + return ret;
> + if (card->name)
> + break;
> + }
This is still wrong as you are allowing "<prefix>label" for property
names. I think you want something like this:
ret = snd_soc_of_parse_card_name(card, "label");
if (ret < 0) {
char prop[128];
snprintf(prop, sizeof(prop), "%sname", prefix);
/* Parse the card name from DT */
ret = snd_soc_of_parse_card_name(card, prop);
if (ret < 0)
return ret;
}
--
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 2/2] mmc: dw_mmc-rockchip: parse rockchip,default-num-phases from DT
From: Doug Anderson @ 2017-04-19 20:19 UTC (permalink / raw)
To: Shawn Lin
Cc: Jaehoon Chung, Ulf Hansson, Rob Herring,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ziyuan Xu,
open list:ARM/Rockchip SoC...,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1492592434-81312-3-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi,
On Wed, Apr 19, 2017 at 2:00 AM, Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> Currently we unconditionally do tuning for each degree, which
> costs 900ms for each boot and resume.
>
> May someone argue that this is a question of accuracy VS time. But I
> would say it's a trick of how we need to do decision for our boards.
> If we don't care the time we spend at all, we could definitely do tuning
> for each degree. But when we need to improve the user experience, for
> instance, speed up resuming from S3, we should also have the right to
> do that. This patch add parsing "rockchip,default-num-phases", for folks
> to specify the number of doing tuning. If not specified, 360 will be used
> as before.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> ---
>
> drivers/mmc/host/dw_mmc-rockchip.c | 48 ++++++++++++++++++++++++--------------
> 1 file changed, 30 insertions(+), 18 deletions(-)
No huge objection here, but I do remember we ended up at the 360
phases due to some of the craziness with dw_mmc delay elements on
rk3288. IIRC one of the big problems was that the delay elements
changed _a lot_ with the "LOGIC" voltage and we tweaked the voltage at
runtime for DDR DVFS. That imposed an extra need to be very accurate
on that SoC, at least on any board that was designed to support DDR
DVFS.
I also remember there being some weirdness on the Rockchip
implementation where there was a certain set of phases that the MMC
controller was essentially "blind". This blind spot was in the middle
of an otherwise good range of points. Unfortunately this blind spot
was somewhat hard to detect properly because it was not very big.
...the variability of the delay elements meant that there could be big
ranges where we weren't getting any good test coverage, but also the
fact that they changed with the LOGIC voltage might mean that we
weren't in the "blind" spot and then suddenly we were.
One other note is that i remember that the vast majority of time spent
tuning was dealing with "bad" phases, not dealing with "good" phases.
If you're looking to speed things up, maybe finding a way to make
"bad" phases fail faster would be wise? I think one of the reasons
bad phases failed so slowly is because the dw_mmc timeouts are all so
long.
Oh, and I guess one last note is that I have no idea if folks will
like the device bindings here. Part of me thinks it should be
something more "symbolic" like "rockchip,need-accurate-tuning" or
something like that. I guess I'd let the DT experts chime in.
So I guess to summarize:
* On rk3288 boards w/ DDR DVFS (or any other similar boards), 360
seems to provide real benefit.
* On other boards, probably you can get by with fewer phases.
-Doug
--
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] clk: hi6220: Add the hi655x's pmic clock
From: Daniel Lezcano @ 2017-04-19 19:47 UTC (permalink / raw)
To: Stephen Boyd
Cc: mturquette, lee.jones, xuwei5, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
In-Reply-To: <20170419160005.GS7065@codeaurora.org>
On Wed, Apr 19, 2017 at 09:00:05AM -0700, Stephen Boyd wrote:
> On 04/16, Daniel Lezcano wrote:
> > On Wed, Apr 12, 2017 at 08:02:45AM -0700, Stephen Boyd wrote:
> > > On 04/08, Daniel Lezcano wrote:
[ ... ]
> > > > + ret = clk_hw_register_clkdev(&hi655x_clk->clk_hw, clk_name, NULL);
> > >
> > > Missed this last time. Do you use this clkdev lookup? The name is
> > > usually supposed to be based on what the device is expecting,
> > > instead of clk_name, and we would want some device name for the
> > > third argument here.
> >
> > I'm not sure to get your comment. Are you saying the clk_name should be the
> > third argument?
> >
> >
>
> Sorry, no. I meant that con_id is typically something like "core"
> or "ahb" or something like that, and dev_id is something like
> "a456002.pmic_device" or whatever dev_name(pmic_dev) would return for
> the consuming device. That way when we call clk_get(dev, "core")
> it will find the lookup with "core" and "a456002.pmic_device" to
> match up the clk lookup.
>
> If anything, the clk_name should just go into the con_id for now,
> and then it will need to be a globally unique identifier for the
> clk. But that is going against how clkdev is supposed to be used.
> Hence the question if you even need to use it. If not, just don't
> add it. I can fix up v3 of this patch to put clk_name back at
> con_id if you like. No need to resend.
Ok, I'm not very used with the CCF, so perhaps clk_name is not needed at all. I
gave a try with the following combination:
- con_id = NULL, dev_id = clk_name
- con_id = clk_name, dev_id = NULL
- con_id = NULL, dev_id = NULL
All worked.
And finally I removed the clk_hw_register_clkdev() call and it worked also.
So I'm not sure about this function.
Any idea ?
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v3] usb: dwc3: add disable u2mac linestate check quirk
From: Guenter Roeck @ 2017-04-19 19:44 UTC (permalink / raw)
To: William Wu
Cc: Felipe Balbi, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
Heiko Stübner, linux-kernel,
linux-usb-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC...,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Frank Wang,
Tao Huang, Doug Anderson, Brian Norris,
daniel.meng-TNX95d0MmH7DzftRWevZcw,
John.Youn-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <1492603898-25070-1-git-send-email-william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Wed, Apr 19, 2017 at 5:11 AM, William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> This patch adds a quirk to disable USB 2.0 MAC linestate check
> during HS transmit. Refer the dwc3 databook, we can use it for
> some special platforms if the linestate not reflect the expected
> line state(J) during transmission.
>
> When use this quirk, the controller implements a fixed 40-bit
> TxEndDelay after the packet is given on UTMI and ignores the
> linestate during the transmit of a token (during token-to-token
> and token-to-data IPGAP).
>
> On some rockchip platforms (e.g. rk3399), it requires to disable
> the u2mac linestate check to decrease the SSPLIT token to SETUP
> token inter-packet delay from 566ns to 466ns, and fix the issue
> that FS/LS devices not recognized if inserted through USB 3.0 HUB.
>
> Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Reviewed-by: Guenter Roeck <groeck-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> Changes in v3:
> - change quirk name
> - only read and write GUCTL1 if dwc3 version >= 2.50a
>
> Changes in v2:
> - fix coding style
>
> Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
> drivers/usb/dwc3/core.c | 20 ++++++++++++++------
> drivers/usb/dwc3/core.h | 4 ++++
> 3 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index f658f39..52fb410 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -45,6 +45,8 @@ Optional properties:
> a free-running PHY clock.
> - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
> from P0 to P1/P2/P3 without delay.
> + - snps,dis-tx-ipgap-linecheck-quirk: when set, disable u2mac linestate check
> + during HS transmit.
> - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
> utmi_l1_suspend_n, false when asserts utmi_sleep_n
> - snps,hird-threshold: HIRD threshold
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 455d89a..9d5a67c 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -796,13 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
> dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
> }
>
> - /*
> - * Enable hardware control of sending remote wakeup in HS when
> - * the device is in the L1 state.
> - */
> - if (dwc->revision >= DWC3_REVISION_290A) {
> + if (dwc->revision >= DWC3_REVISION_250A) {
> reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
> - reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
> +
> + /*
> + * Enable hardware control of sending remote wakeup
> + * in HS when the device is in the L1 state.
> + */
> + if (dwc->revision >= DWC3_REVISION_290A)
> + reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
> +
> + if (dwc->dis_tx_ipgap_linecheck_quirk)
> + reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
> +
> dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
> }
>
> @@ -1023,6 +1029,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
> "snps,dis-u2-freeclk-exists-quirk");
> dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
> "snps,dis-del-phy-power-chg-quirk");
> + dwc->dis_tx_ipgap_linecheck_quirk = device_property_read_bool(dev,
> + "snps,dis-tx-ipgap-linecheck-quirk");
>
> dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
> "snps,tx_de_emphasis_quirk");
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 981c77f..6f6294d 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -204,6 +204,7 @@
> #define DWC3_GCTL_DSBLCLKGTNG BIT(0)
>
> /* Global User Control 1 Register */
> +#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
> #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
>
> /* Global USB2 PHY Configuration Register */
> @@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
> * provide a free-running PHY clock.
> * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
> * change quirk.
> + * @dis_tx_ipgap_linecheck_quirk: set if we disable u2mac linestate
> + * check during HS transmit.
> * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
> * @tx_de_emphasis: Tx de-emphasis value
> * 0 - -6dB de-emphasis
> @@ -1004,6 +1007,7 @@ struct dwc3 {
> unsigned dis_rxdet_inp3_quirk:1;
> unsigned dis_u2_freeclk_exists_quirk:1;
> unsigned dis_del_phy_power_chg_quirk:1;
> + unsigned dis_tx_ipgap_linecheck_quirk:1;
>
> unsigned tx_de_emphasis_quirk:1;
> unsigned tx_de_emphasis:2;
> --
> 2.0.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
* Re: [PATCH v5 5/8] i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example
From: Wolfram Sang @ 2017-04-19 19:41 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Aaro Koskinen, devicetree, Rob Herring,
Tony Lindgren, Lee Jones, linux-i2c, Mark Rutland
In-Reply-To: <20170412172800.23035-6-javier@osg.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
On Wed, Apr 12, 2017 at 02:27:56PM -0300, Javier Martinez Canillas wrote:
> The example contains a device node for a retu device, but
> its compatible string doesn't have a vendor prefix.
>
> While being there, drop the -mfd suffix since isn't correct.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> Acked-by: Tony Lindgren <tony@atomide.com>
>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
I assume this goes with the rest of the series and not via my tree.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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