* Re: [PATCH] of/platform: dynamic: Use of_platform_bus_create() to create devices
From: Rob Herring @ 2017-01-21 19:51 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Frank Rowand,
Pantelis Antoniou, Grant Likely
In-Reply-To: <3da6854d-8361-1724-2a8a-36f28449733e-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
On Fri, Jan 20, 2017 at 11:38 AM, Alexander Sverdlin
<alexander.sverdlin-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> wrote:
> Hello Rob,
>
> On 27/10/16 15:00, Rob Herring wrote:
>>> @@ -534,15 +535,15 @@ static int of_platform_notify(struct notifier_block *nb,
>>>
>>> /* pdev_parent may be NULL when no bus platform device */
>>> pdev_parent = of_find_device_by_node(rd->dn->parent);
>>> - pdev = of_platform_device_create(rd->dn, NULL,
>>> - pdev_parent ? &pdev_parent->dev : NULL);
>>> + ret = of_platform_bus_create(rd->dn, of_default_bus_match_table,
>>> + NULL, pdev_parent ?
>>> + &pdev_parent->dev : NULL, true);
>> I think this should be of_platform_default_populate() instead.
>
> I've just tested: it cannot be. It calls of_platform_populate(), which ignores "status" property.
> This not only brakes half of the unit tests, but also would change the existing behavior of
> overlays (they will completely ignore "status" too).
That's a bug. I assume that's only at the 1st level or things would be
completely broken.
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 1/3] Documentation: devicetree: Add Kingnovel vendor prefix
From: Rob Herring @ 2017-01-21 20:01 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Carlo Caione,
Kevin Hilman, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ada-MUr+2Ic57fgS+FvcfC7Uqw,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170117225459.4438-1-afaerber-l3A5Bk7waGM@public.gmane.org>
On Tue, Jan 17, 2017 at 11:54:57PM +0100, Andreas Färber wrote:
> Their domain name is spelled kingnoval, but textually Kingnovel.
>
> Cc: ada-MUr+2Ic57fgS+FvcfC7Uqw@public.gmane.org
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.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 2/3] Documentation: devicetree: amlogic: Add R-Box Pro
From: Rob Herring @ 2017-01-21 20:02 UTC (permalink / raw)
To: Andreas Färber
Cc: Mark Rutland, devicetree, Kevin Hilman, linux-kernel, ada,
Carlo Caione, linux-amlogic, linux-arm-kernel
In-Reply-To: <20170117225459.4438-2-afaerber@suse.de>
On Tue, Jan 17, 2017 at 11:54:58PM +0100, Andreas Färber wrote:
> Cc: ada@kingnoval.com
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
> Originally I thought we would group by SoC (6, 8, 8b, gxbb, gxl, gmx, etc.)
> but this got out of order with nexbox,a95x - so inserting kingnovel between
> amlogic and nexbox here. If that's what we want going forward, we should move
> the old entries to make the scheme clearer. The alternative would be to
> reorder alphabetically within each SoC group, but nexbox,a95x with two SoCs
> makes it difficult to categorize, we could choose gxbb as the earlier one.
>
> Documentation/devicetree/bindings/arm/amlogic.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform
From: Rob Herring @ 2017-01-21 20:08 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Kishon Vijay Abraham I, Matthias Brugger, Felipe Balbi,
Mark Rutland, Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484719214-11989-6-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Wed, Jan 18, 2017 at 02:00:14PM +0800, Chunfeng Yun wrote:
> add a new compatible string for "mt2712", and a new reference clock
> for SuperSpeed analog phy;
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 81 +++++++++++++++++---
> 1 file changed, 70 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> index 33a2b1e..8f91136 100644
> --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> @@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
> Required properties (controller (parent) node):
> - compatible : should be one of
> "mediatek,mt2701-u3phy"
> + "mediatek,mt2712-u3phy"
> "mediatek,mt8173-u3phy"
> - - reg : offset and length of register for phy, exclude port's
> - register.
> - clocks : a list of phandle + clock-specifier pairs, one for each
> entry in clock-names
> - clock-names : must contain
> - "u3phya_ref": for reference clock of usb3.0 analog phy.
> + "u2ref_clk": 48M reference clock of HighSpeed analog phy.
> + "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
> + sometimes is 24M, 25M or 27M, depended on platform.
_clk is redundant.
>
> Required nodes : a sub-node is required for each port the controller
> provides. Address range information including the usual
> 'reg' property is used inside these nodes to describe
> the controller's topology.
>
> +Optional properties (controller (parent) node):
> + - reg : offset and length of register shared by multiple ports,
> + exclude port's private register. It is needed on mt2701
> + and mt8173, but not on mt2712.
> +
> Required properties (port (child) node):
> - reg : address and length of the register set for the port.
> - #phy-cells : should be 1 (See second example)
> @@ -31,21 +37,27 @@ Example:
> u3phy: usb-phy@11290000 {
> compatible = "mediatek,mt8173-u3phy";
> reg = <0 0x11290000 0 0x800>;
> - clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
> - clock-names = "u3phya_ref";
> + clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>, <&clk26m>;
> + clock-names = "u2ref_clk", "u3ref_clk";
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> status = "okay";
>
> - phy_port0: port@11290800 {
> - reg = <0 0x11290800 0 0x800>;
> + u2port0: port@11290800 {
port is for OF graph. This should be usb-phy@... instead.
> + reg = <0 0x11290800 0 0x100>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +
> + u3port0: port@11290900 {
> + reg = <0 0x11290800 0 0x700>;
> #phy-cells = <1>;
> status = "okay";
> };
>
> - phy_port1: port@11291000 {
> - reg = <0 0x11291000 0 0x800>;
> + u2port1: port@11291000 {
> + reg = <0 0x11291000 0 0x100>;
> #phy-cells = <1>;
> status = "okay";
> };
> @@ -64,7 +76,54 @@ Example:
>
> usb30: usb@11270000 {
> ...
> - phys = <&phy_port0 PHY_TYPE_USB3>;
> - phy-names = "usb3-0";
> + phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
> + phy-names = "usb2-0", "usb3-0";
> ...
> };
> +
> +
> +Layout differences of banks between mt8173/mt2701 and mt2712
> +-------------------------------------------------------------
> +mt8173 and mt2701:
> +port offset bank
> +shared 0x0000 SPLLC
> + 0x0100 FMREG
> +u2 port0 0x0800 U2PHY_COM
> +u3 port0 0x0900 U3PHYD
> + 0x0a00 U3PHYD_BANK2
> + 0x0b00 U3PHYA
> + 0x0c00 U3PHYA_DA
> +u2 port1 0x1000 U2PHY_COM
> +u3 port1 0x1100 U3PHYD
> + 0x1200 U3PHYD_BANK2
> + 0x1300 U3PHYA
> + 0x1400 U3PHYA_DA
> +u2 port2 0x1800 U2PHY_COM
> + ...
> +
> +mt2712:
> +port offset bank
> +u2 port0 0x0000 MISC
> + 0x0100 FMREG
> + 0x0300 U2PHY_COM
> +u3 port0 0x0700 SPLLC
> + 0x0800 CHIP
> + 0x0900 U3PHYD
> + 0x0a00 U3PHYD_BANK2
> + 0x0b00 U3PHYA
> + 0x0c00 U3PHYA_DA
> +u2 port1 0x1000 MISC
> + 0x1100 FMREG
> + 0x1300 U2PHY_COM
> +u3 port1 0x1700 SPLLC
> + 0x1800 CHIP
> + 0x1900 U3PHYD
> + 0x1a00 U3PHYD_BANK2
> + 0x1b00 U3PHYA
> + 0x1c00 U3PHYA_DA
> +u2 port2 0x2000 MISC
> + ...
> +
> + SPLLC shared by u3 ports and FMREG shared by u2 ports on
> +mt8173/mt2701 are put back into each port; a new bank MISC for
> +u2 ports and CHIP for u3 ports are added on mt2712.
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 5/6] dt-bindings: mt8173-xhci: add reference clock
From: Rob Herring @ 2017-01-21 20:10 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mathias Nyman, Felipe Balbi, Greg Kroah-Hartman, Matthias Brugger,
Mark Rutland, Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484719707-12107-5-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Wed, Jan 18, 2017 at 02:08:26PM +0800, Chunfeng Yun wrote:
> add a reference clock for compatibility
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/usb/mt8173-xhci.txt | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
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 6/6] dt-bindings: mt8173-mtu3: add reference clock
From: Rob Herring @ 2017-01-21 20:11 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Mathias Nyman, Felipe Balbi,
Ian Campbell, Greg Kroah-Hartman, linux-usb, linux-kernel,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1484719707-12107-6-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Jan 18, 2017 at 02:08:27PM +0800, Chunfeng Yun wrote:
> add a reference clock for compatibility
Why? This block suddenly has 2 clocks instead of 1?
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> .../devicetree/bindings/usb/mt8173-mtu3.txt | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> index e049d19..8c976cd 100644
> --- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> +++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> @@ -10,7 +10,7 @@ Required properties:
> - vusb33-supply : regulator of USB avdd3.3v
> - clocks : a list of phandle + clock-specifier pairs, one for each
> entry in clock-names
> - - clock-names : must contain "sys_ck" for clock of controller;
> + - clock-names : must contain "sys_ck" and "ref_ck" for clock of controller;
> "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
> depends on "mediatek,enable-wakeup"
> - phys : a list of phandle + phy specifier pairs
> @@ -56,10 +56,10 @@ ssusb: usb@11271000 {
> phys = <&phy_port0 PHY_TYPE_USB3>,
> <&phy_port1 PHY_TYPE_USB2>;
> power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> - clocks = <&topckgen CLK_TOP_USB30_SEL>,
> + clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>,
> <&pericfg CLK_PERI_USB0>,
> <&pericfg CLK_PERI_USB1>;
> - clock-names = "sys_ck",
> + clock-names = "sys_ck", "ref_ck",
> "wakeup_deb_p0",
> "wakeup_deb_p1";
> vusb33-supply = <&mt6397_vusb_reg>;
> @@ -79,8 +79,8 @@ ssusb: usb@11271000 {
> reg-names = "mac";
> interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_LOW>;
> power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> - clocks = <&topckgen CLK_TOP_USB30_SEL>;
> - clock-names = "sys_ck";
> + clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>;
> + clock-names = "sys_ck", "ref_ck";
> vusb33-supply = <&mt6397_vusb_reg>;
> status = "disabled";
> };
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH 5/6] dt-bindings: mt8173-xhci: add reference clock
From: Rob Herring @ 2017-01-21 20:12 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mathias Nyman, Felipe Balbi, Greg Kroah-Hartman, Matthias Brugger,
Mark Rutland, Ian Campbell, linux-kernel, linux-arm-kernel,
linux-usb, linux-mediatek, devicetree
In-Reply-To: <1484719707-12107-5-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Jan 18, 2017 at 02:08:26PM +0800, Chunfeng Yun wrote:
> add a reference clock for compatibility
Same question here, too.
^ permalink raw reply
* Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn
From: Guenter Roeck @ 2017-01-21 20:14 UTC (permalink / raw)
To: Florian Fainelli, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Mark Rutland, Jean Delvare, Jonathan Corbet,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:HARDWARE MONITORING, open list:DOCUMENTATION
In-Reply-To: <20170121192010.30681-2-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 01/21/2017 11:20 AM, Florian Fainelli wrote:
> We have a device reference, utilize it instead of pr_warn().
>
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
Applied to -next.
Thanks,
Guenter
--
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 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Rob Herring @ 2017-01-21 20:21 UTC (permalink / raw)
To: Jerry Huang
Cc: balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <DB5PR0401MB181361EBAD1B2BFA8DC5ED7AFE610-GXldUsIPo7bx2nbxLE2obo3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Tue, Jan 3, 2017 at 8:24 PM, Jerry Huang <jerry.huang-3arQi8VN3Tc@public.gmane.org> wrote:
> Hi, Rob,
>
>> -----Original Message-----
>> From: Rob Herring [mailto:robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
>> Sent: Wednesday, January 04, 2017 5:24 AM
>> To: Jerry Huang <jerry.huang-3arQi8VN3Tc@public.gmane.org>
>> Cc: balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org; catalin.marinas-5wv7dgnIgG8@public.gmane.org;
>> will.deacon-5wv7dgnIgG8@public.gmane.org; linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
>> linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
>> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-
>> type-adjustment" for INCR burst type
>>
>> On Thu, Dec 22, 2016 at 8:52 PM, Jerry Huang <jerry.huang-3arQi8VN3Tc@public.gmane.org> wrote:
>> > Hi, Rob,
>> >> -----Original Message-----
>> >> From: Rob Herring [mailto:robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
>> >> Sent: Friday, December 23, 2016 2:45 AM
>> >> To: Jerry Huang <jerry.huang-3arQi8VN3Tc@public.gmane.org>
>> >> Cc: balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org; catalin.marinas-5wv7dgnIgG8@public.gmane.org;
>> >> will.deacon-5wv7dgnIgG8@public.gmane.org; linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org;
>> >> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
>> >> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm- kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> >> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps,
>> >> incr-burst- type-adjustment" for INCR burst type
>> >>
>> >> On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote:
>> >> > New property "snps,incr-burst-type-adjustment = <x>, <y>" for
>> >> > USB3.0
>> >> DWC3.
>> >> > Field "x": 1/0 - undefined length INCR burst type enable or not;
>> >> > Field
>> >> > "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst type.
>> >> >
>> >> > While enabling undefined length INCR burst type and INCR16 burst
>> >> > type, get better write performance on NXP Layerscape platform:
>> >> > around 3% improvement (from 364MB/s to 375MB/s).
>> >> >
>> >> > Signed-off-by: Changming Huang <jerry.huang-3arQi8VN3Tc@public.gmane.org>
>> >> > ---
>> >> > Changes in v3:
>> >> > - add new property for INCR burst in usb node.
>> >> >
>> >> > Documentation/devicetree/bindings/usb/dwc3.txt | 5 +++++
>> >> > arch/arm/boot/dts/ls1021a.dtsi | 1 +
>> >> > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
>> >> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 2 ++
>> >> > 4 files changed, 11 insertions(+)
>> >> >
>> >> > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
>> >> > b/Documentation/devicetree/bindings/usb/dwc3.txt
>> >> > index e3e6983..8c405a3 100644
>> >> > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>> >> > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>> >> > @@ -55,6 +55,10 @@ Optional properties:
>> >> > fladj_30mhz_sdbnd signal is invalid or incorrect.
>> >> >
>> >> > - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be
>> >> reallocated.
>> >> > + - snps,incr-burst-type-adjustment: Value for INCR burst type of
>> >> GSBUSCFG0
>> >> > + register, undefined length INCR burst type enable and INCRx type.
>> >> > + First field is for undefined length INCR burst type enable or not.
>> >> > + Second field is for largest INCRx type enabled.
>> >>
>> >> Why do you need the first field? Is the 2nd field used if the 1st is 0?
>> >> If not, then just use the presence of the property to enable or not.
>> > The first field is one switch.
>> > When it is 1, means undefined length INCR burst type enabled, we can use
>> any length less than or equal to the largest-enabled burst length of
>> INCR4/8/16/32/64/128/256.
>> > When it is zero, means INCRx burst mode enabled, we can use one fixed
>> burst length of 1/4/8/16/32/64/128/256 byte.
>> > So, the 2nd field is used if the 1st is 0, we need to select one largest burst
>> length the USB controller can support.
>> > If we don't want to change the value of this register (use the default value),
>> we don't need to add this property to usb node.
>>
>> Just make this a single value with 0 meaning INCR and 4/8/16/etc being INCRx.
> Maybe, I didn't describe it clearly.
> According to DWC3 spec, the value "0" of field INCRBrstEna means INCRx burst mode, 1 means INCR burst mode.
> Regardless of the value of INCRBrstEna [bit0], we need to modify the other field bit[1,2,3,4,5,6,7] to one INCR burst type for the platform supported.
> Ad you mentioned, if we just use a single value with 0 meaning INCR and 4/8/16/etc being INCRx.
> I understand totally that when it is none-zero, we can use it for INCR burst mode.
> Then, when it is 0, how to select the INCRx value?
What I mean is:
<no prop> - burst disabled
0 - INCR burst. INCR is undefined length burst IIRC.
4/8/16/etc. - INCR4/INCR8/INCR16/etc.
What case does this not cover?
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [RESEND PATCH 1/2] Documentation: devicetree: Add i2c binding for mediatek MT2701 Soc Platform
From: Rob Herring @ 2017-01-21 20:22 UTC (permalink / raw)
To: Jun Gao
Cc: devicetree, srv_heupstream, Wolfram Sang, linux-kernel,
linux-mediatek, linux-i2c, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1484732461-13594-2-git-send-email-jun.gao@mediatek.com>
On Wed, Jan 18, 2017 at 05:41:00PM +0800, Jun Gao wrote:
> From: Jun Gao <jun.gao@mediatek.com>
>
> This add i2c DT binding to i2c-mt6577.txt for MT2701.
>
> Signed-off-by: Jun Gao <jun.gao@mediatek.com>
> ---
> .../devicetree/bindings/i2c/i2c-mt6577.txt | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] hwmon: (lm70) Add support for TI TMP122/124
From: Guenter Roeck @ 2017-01-21 20:25 UTC (permalink / raw)
To: Florian Fainelli, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Mark Rutland, Jean Delvare, Jonathan Corbet,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:HARDWARE MONITORING, open list:DOCUMENTATION
In-Reply-To: <20170121192010.30681-3-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 01/21/2017 11:20 AM, Florian Fainelli wrote:
> Add support for Texas Instruments TMP122/124 which are nearly identical to
> their TMP121/123 except that they also support programmable temperature
> thresholds.
>
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied to -next.
Any plans to add support for the thresholds ?
Thanks,
Guenter
> ---
> Documentation/devicetree/bindings/hwmon/lm70.txt | 1 +
> Documentation/hwmon/lm70 | 8 ++++++--
> drivers/hwmon/lm70.c | 9 ++++++++-
> 3 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/lm70.txt b/Documentation/devicetree/bindings/hwmon/lm70.txt
> index e7fd921aa4f1..ea417a0d32af 100644
> --- a/Documentation/devicetree/bindings/hwmon/lm70.txt
> +++ b/Documentation/devicetree/bindings/hwmon/lm70.txt
> @@ -4,6 +4,7 @@ Required properties:
> - compatible: one of
> "ti,lm70"
> "ti,tmp121"
> + "ti,tmp122"
> "ti,lm71"
> "ti,lm74"
>
> diff --git a/Documentation/hwmon/lm70 b/Documentation/hwmon/lm70
> index 1bb2db440671..c3a1f2ea017d 100644
> --- a/Documentation/hwmon/lm70
> +++ b/Documentation/hwmon/lm70
> @@ -6,6 +6,8 @@ Supported chips:
> Datasheet: http://www.national.com/pf/LM/LM70.html
> * Texas Instruments TMP121/TMP123
> Information: http://focus.ti.com/docs/prod/folders/print/tmp121.html
> + * Texas Instruments TMP122/TMP124
> + Information: http://www.ti.com/product/tmp122
> * National Semiconductor LM71
> Datasheet: http://www.ti.com/product/LM71
> * National Semiconductor LM74
> @@ -35,8 +37,10 @@ As a real (in-tree) example of this "SPI protocol driver" interfacing
> with a "SPI master controller driver", see drivers/spi/spi_lm70llp.c
> and its associated documentation.
>
> -The LM74 and TMP121/TMP123 are very similar; main difference is 13-bit
> -temperature data (0.0625 degrees celsius resolution).
> +The LM74 and TMP121/TMP122/TMP123/TMP124 are very similar; main difference is
> +13-bit temperature data (0.0625 degrees celsius resolution).
> +
> +The TMP122/TMP124 also feature configurable temperature thresholds.
>
> The LM71 is also very similar; main difference is 14-bit temperature
> data (0.03125 degrees celsius resolution).
> diff --git a/drivers/hwmon/lm70.c b/drivers/hwmon/lm70.c
> index 52c5cdd00448..543556dc563b 100644
> --- a/drivers/hwmon/lm70.c
> +++ b/drivers/hwmon/lm70.c
> @@ -46,6 +46,7 @@
> #define LM70_CHIP_TMP121 1 /* TI TMP121/TMP123 */
> #define LM70_CHIP_LM71 2 /* NS LM71 */
> #define LM70_CHIP_LM74 3 /* NS LM74 */
> +#define LM70_CHIP_TMP122 4 /* TI TMP122/TMP124 */
>
> struct lm70 {
> struct spi_device *spi;
> @@ -92,7 +93,7 @@ static ssize_t temp1_input_show(struct device *dev,
> * Celsius.
> * So it's equivalent to multiplying by 0.25 * 1000 = 250.
> *
> - * LM74 and TMP121/TMP123:
> + * LM74 and TMP121/TMP122/TMP123/TMP124:
> * 13 bits of 2's complement data, discard LSB 3 bits,
> * resolution 0.0625 degrees celsius.
> *
> @@ -106,6 +107,7 @@ static ssize_t temp1_input_show(struct device *dev,
> break;
>
> case LM70_CHIP_TMP121:
> + case LM70_CHIP_TMP122:
> case LM70_CHIP_LM74:
> val = ((int)raw / 8) * 625 / 10;
> break;
> @@ -143,6 +145,10 @@ static const struct of_device_id lm70_of_ids[] = {
> .data = (void *) LM70_CHIP_TMP121,
> },
> {
> + .compatible = "ti,tmp122",
> + .data = (void *) LM70_CHIP_TMP122,
> + },
> + {
> .compatible = "ti,lm71",
> .data = (void *) LM70_CHIP_LM71,
> },
> @@ -191,6 +197,7 @@ static int lm70_probe(struct spi_device *spi)
> static const struct spi_device_id lm70_ids[] = {
> { "lm70", LM70_CHIP_LM70 },
> { "tmp121", LM70_CHIP_TMP121 },
> + { "tmp122", LM70_CHIP_TMP122 },
> { "lm71", LM70_CHIP_LM71 },
> { "lm74", LM70_CHIP_LM74 },
> { },
>
--
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 02/11] [media] s5p-mfc: Adding initial support for MFC v10.10
From: Rob Herring @ 2017-01-21 20:28 UTC (permalink / raw)
To: Smitha T Murthy
Cc: devicetree, a.hajda, pankaj.dubey, kamil, krzk, linux-kernel,
jtp.park, kyungmin.park, s.nawrocki, m.szyprowski, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <1484733729-25371-3-git-send-email-smitha.t@samsung.com>
On Wed, Jan 18, 2017 at 03:32:00PM +0530, Smitha T Murthy wrote:
> Adding the support for MFC v10.10, with new register file and
> necessary hw control, decoder, encoder and structural changes.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree@vger.kernel.org
> Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
> ---
> .../devicetree/bindings/media/s5p-mfc.txt | 1 +
> drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 36 ++++++++++++++++
> drivers/media/platform/s5p-mfc/s5p_mfc.c | 30 +++++++++++++
> drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 4 +-
> drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 4 ++
> drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 44 +++++++++++---------
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 21 +++++----
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 9 +++-
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 2 +
> 9 files changed, 118 insertions(+), 33 deletions(-)
> create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> index 2c90128..b70c613 100644
> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> @@ -13,6 +13,7 @@ Required properties:
> (c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
> (d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
> (e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
> + (f) "samsung,mfc-v10" for MFC v10 present in a variant of Exynos7 SoC
You are up to v10 in how many SoCs? Please stop with versions and use
SoC numbers. It's one thing to use versions when you have many SoCs per
version, but that doesn't seem to be happening here.
Rob
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: vendor-prefix: Add wetek vendor prefix
From: Rob Herring @ 2017-01-21 20:29 UTC (permalink / raw)
To: Neil Armstrong
Cc: khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484736642-5451-2-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Wed, Jan 18, 2017 at 11:50:40AM +0100, Neil Armstrong wrote:
> Add prefix for WeTek Electronics, limited, a company producing multimedia
> Set-Top-Boxes and supporting KODI and OpenELEC distributions.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
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 3/3] dt-bindings: amlogic: Add WeTek boards
From: Rob Herring @ 2017-01-21 20:30 UTC (permalink / raw)
To: Neil Armstrong
Cc: khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484736642-5451-4-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Wed, Jan 18, 2017 at 11:50:42AM +0100, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/amlogic.txt | 2 ++
> 1 file changed, 2 insertions(+)
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: [PATCHv5 2/2] dt-bindings: iio: document MAX11100 ADC
From: Rob Herring @ 2017-01-21 20:33 UTC (permalink / raw)
To: Jacopo Mondi
Cc: wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, marek.vasut-Re5JQEeQqe8AvxtiuMwx3w,
geert-Td1EMuHUCqxL1ZNQvxDV9g, mark.rutland-5wv7dgnIgG8,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484757053-7102-3-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
On Wed, Jan 18, 2017 at 05:30:53PM +0100, Jacopo Mondi wrote:
> Add device tree bindings documentation for Maxim MAX11100 single-channel
> ADC
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> Acked-by: Wolfram Sang <wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org>
> ---
> .../devicetree/bindings/iio/adc/max11100.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/max11100.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 v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
From: Rob Herring @ 2017-01-21 20:39 UTC (permalink / raw)
To: Markus Mayer
Cc: Mark Rutland, Rafael J . Wysocki, Arnd Bergmann,
Power Management List, Viresh Kumar, Michael Turquette,
Stephen Boyd, Linux Kernel Mailing List, Device Tree List,
Broadcom Kernel List, Markus Mayer, Linux Clock List,
ARM Kernel List
In-Reply-To: <20170119002933.7529-2-code@mmayer.net>
On Wed, Jan 18, 2017 at 04:29:32PM -0800, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> Add binding document for brcm,brcmstb-cpu-clk-div.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> ---
> .../bindings/clock/brcm,brcmstb-cpu-clk-div.txt | 27 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> new file mode 100644
> index 0000000..c4acb53
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> @@ -0,0 +1,27 @@
> +The CPU divider node serves as the sole clock for the CPU complex. It supports
> +power-of-2 clock division, with a divider of "1" as the default highest-speed
> +setting.
> +
> +Required properties:
> +- compatible: shall be "brcm,brcmstb-cpu-clk-div"
> +- reg: address and width of the divider configuration register
> +- #clock-cells: shall be set to 0
> +- clocks: phandle of clock provider which provides the source clock
> + (this would typically be a "fixed-clock" type PLL)
> +- div-table: list of (raw_value,divider) ordered pairs that correspond to the
> + allowed clock divider settings
Why do you need 2 values? Can't you use the index or calculate the
register value from the divider value?
> +- div-shift-width: least-significant bit position and width of divider value
> +
> +Optional properties:
> +- clock-names: the clock may be named
> +
> +Example:
> + cpuclkdiv: cpu-clk-div@f03e257c {
clock-controller@...
> + compatible = "brcm,brcmstb-cpu-clk-div";
> + reg = <0xf03e257c 0x4>;
> + div-table = <0x00 1>;
> + div-shift-width = <0 5>;
> + #clock-cells = <0>;
> + clocks = <&cpupll>;
> + clock-names = "cpupll";
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cfff2c9..690761d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2786,6 +2786,7 @@ M: bcm-kernel-feedback-list@broadcom.com
> L: linux-pm@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
> +F: Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> F: drivers/cpufreq/brcmstb*
>
> BROADCOM SPECIFIC AMBA DRIVER (BCMA)
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: Document Broadcom iProc mailbox controller driver
From: Rob Herring @ 2017-01-21 20:40 UTC (permalink / raw)
To: Jonathan Richardson
Cc: Jassi Brar, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Russell King, Vikram Prakash, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
BCM Kernel Feedback
In-Reply-To: <1484789980-6812-2-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Jan 18, 2017 at 05:39:38PM -0800, Jonathan Richardson wrote:
Changelog?
> Reviewed-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Tested-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Vikram Prakash <vikram.prakash-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/mailbox/brcm,iproc-mailbox.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
> new file mode 100644
> index 0000000..f4c4f96
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
> @@ -0,0 +1,14 @@
> +* Broadcom's iProc Mailbox Controller
> +
> +Required properties:
> +- compatible: Must be "brcm,iproc-mailbox"
> +- reg: Defines the base address of the mailbox controller.
> +- #mbox-cells: Must be 1.
> +
> +Example:
> +
> + mailbox: mailbox@03024024 {
Drop the leading 0.
> + compatible = "brcm,iproc-mailbox";
> + reg = <0x03024024 0x8>;
> + #mbox-cells = <1>;
> + };
> --
> 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: add Asus Tinker board
From: Rob Herring @ 2017-01-21 20:42 UTC (permalink / raw)
To: Eddie Cai
Cc: mark.rutland-5wv7dgnIgG8, heiko-4mtYJXux2i+zQB+pC5nmwQ,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eddie Cai
In-Reply-To: <1484791919-4665-2-git-send-email-eddie.cai-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Thu, Jan 19, 2017 at 10:11:58AM +0800, Eddie Cai wrote:
> Tinker board is a credit card size develop board designed by Asus.
> Powered by RK3288.
>
> Signed-off-by: Eddie Cai <eddie.cai-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/rockchip.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
> index cc4ace6..ce1f04a 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -1,5 +1,8 @@
> Rockchip platforms device tree bindings
> ---------------------------------------
> +- Asus Tinker board
> + Required root node properties:
> + - compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
This should be asus,tinker if that's specific enough. At least the board
manufacturer should be the vendor.
>
> - Kylin RK3036 board:
> Required root node properties:
> --
> 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 3/4] phy: qcom-ufs: Remove -always-on property
From: Rob Herring @ 2017-01-21 20:43 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Kishon Vijay Abraham I, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Subhash Jadavani, Vivek Gautam
In-Reply-To: <20170119104739.4376-3-bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Jan 19, 2017 at 02:47:38AM -0800, Bjorn Andersson wrote:
> The fact that a regulator is always-on is a property of the regulator,
> not a specific consumer. Implementing this in the driver leads to a
> system behaviour that is dependent on if the Qualcomm UFS PHY was ever
> (partially) probed.
>
> If the specific regulator should be always on in a particular device,
> mark it so by specifying "regulator-always-on" in the regulator node.
>
> Cc: Subhash Jadavani <subhashj-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: Vivek Gautam <vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 1 -
> drivers/phy/phy-qcom-ufs-i.h | 1 -
> drivers/phy/phy-qcom-ufs.c | 5 +----
> 3 files changed, 1 insertion(+), 6 deletions(-)
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 linux v3 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations
From: Benjamin Herrenschmidt @ 2017-01-21 20:53 UTC (permalink / raw)
To: Guenter Roeck, eajames.ibm-Re5JQEeQqe8AvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, jdelvare-IBi9RG/b67k,
corbet-T1hC0tSOHrs, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, wsa-z923LK4zBo2bacvFa/9K2g,
andrew-zrmu5oMJ5Fs, joel-U3u1mxZcP9KHXe+LvDLADg, Edward A. James
In-Reply-To: <b47e5359-5587-cc89-43e2-379eb9e95fc8-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
On Sat, 2017-01-21 at 10:11 -0800, Guenter Roeck wrote:
> > +int occ_i2c_getscom(void *bus, u32 address, u64 *data)
> > +{
> > + ssize_t rc;
> > + u64 buf;
> > + struct i2c_client *client = bus;
> > +
> > + rc = i2c_master_send(client, (const char *)&address,
> > sizeof(u32));
> > + if (rc < 0)
> > + return rc;
> > + else if (rc != sizeof(u32))
> > + return -EIO;
> > +
> > + rc = i2c_master_recv(client, (char *)&buf, sizeof(u64));
> > + if (rc < 0)
> > + return rc;
> > + else if (rc != sizeof(u64))
> > + return -EIO;
> > +
> > + *data = be64_to_cpu(buf);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(occ_i2c_getscom);
Additionally, this assumes that is is the only other user of that i2c
path to P8. Something interleaving will break it. pdbg for example.
Talk to Alistair, the right thing here would probably be to have
a separate driver that provides the XSCOM interface via i2c to both
in-kernel and userspace, with proper arbitration.
An expedient might be to instead have the address and data cycles
of the above be 2 i2c messages in one i2c request, thus being
serialized somewhat atomically with other transactions to that i2c
bus.
You may need to make sure the underlying i2c controller driver supports
dual messages, and if it doesn't fix it. This is rather classic 4-bytes
subaddress style i2c, it shouldn't be too hard.
Cheers,
Ben.
--
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] ARM: dts: Add support for phyCORE-AM335x PCM-953 carrier board
From: Rob Herring @ 2017-01-21 20:53 UTC (permalink / raw)
To: Teresa Remmet
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, Tony Lindgren, Mark Rutland, Wadim Egorov
In-Reply-To: <1484831270-7251-1-git-send-email-t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
On Thu, Jan 19, 2017 at 02:07:48PM +0100, Teresa Remmet wrote:
> The phyCORE-AM335x development kit is a combination of the
> phyCORE-AM335x SoM and a PCM-953 carrier board. The features
> of the PCM-953 are:
> * ETH phy on carrier board: 1x RGMII
> * 1x CAN
> * Up to 4x UART
> * USB0 (otg)
> * USB1 (host)
> * SD slot
> * User gpio-keys
> * User LEDs
>
> Signed-off-by: Teresa Remmet <t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Reviewed-by: Wadim Egorov <w.egorov-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> ---
> .../devicetree/bindings/arm/omap/omap.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am335x-pcm-953.dtsi | 303 +++++++++++++++++++++
> arch/arm/boot/dts/am335x-phycore-rdk.dts | 27 ++
> 4 files changed, 334 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-pcm-953.dtsi
> create mode 100644 arch/arm/boot/dts/am335x-phycore-rdk.dts
[...]
> + user_leds: user_leds {
> + compatible = "gpio-leds";
> + };
> +
> + user_buttons: user_buttons {
> + compatible = "gpio-keys";
> + };
With only a compatible, I don't think there's much gain to split these 2
nodes. Otherwse,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> +&user_buttons {
> + pinctrl-names = "default";
> + pinctrl-0 = <&user_buttons_pins>;
> + status = "okay";
> +
> + button@0 {
> + label = "home";
> + linux,code = <KEY_HOME>;
> + gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
> + gpio-key,wakeup;
> + };
> +
> + button@1 {
> + label = "menu";
> + linux,code = <KEY_MENU>;
> + gpios = <&gpio3 8 GPIO_ACTIVE_HIGH>;
> + gpio-key,wakeup;
> + };
> +};
> +
> +&user_leds {
> + pinctrl-names = "default";
> + pinctrl-0 = <&user_leds_pins>;
> + status = "okay";
> +
> + green {
> + label = "green:user";
> + gpios = <&gpio1 30 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "gpio";
> + default-state = "on";
> + };
> +
> + yellow {
> + label = "yellow:user";
> + gpios = <&gpio1 31 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "gpio";
> + default-state = "on";
> + };
> +};
--
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/7] Documentation: dt: iio: stm32-adc: optional dma support
From: Rob Herring @ 2017-01-21 20:54 UTC (permalink / raw)
To: Fabrice Gasnier
Cc: jic23, linux, linux-arm-kernel, devicetree, linux-kernel,
linux-iio, mark.rutland, mcoquelin.stm32, alexandre.torgue, lars,
knaack.h, pmeerw, benjamin.gaignard, benjamin.gaignard
In-Reply-To: <1484832854-6314-5-git-send-email-fabrice.gasnier@st.com>
On Thu, Jan 19, 2017 at 02:34:11PM +0100, Fabrice Gasnier wrote:
> STM32 ADC can use dma. Add dt documentation for optional dma support.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/7] Documentation: arm: fix wrong reference number in DT definition
From: Rob Herring @ 2017-01-21 20:55 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, linux-pm, linux-arm-kernel, devicetree, peterz,
vincent.guittot, mark.rutland, linux, sudeep.holla,
lorenzo.pieralisi, catalin.marinas, will.deacon, morten.rasmussen,
dietmar.eggemann, broonie, gregkh
In-Reply-To: <20170119143757.14537-2-juri.lelli@arm.com>
On Thu, Jan 19, 2017 at 02:37:51PM +0000, Juri Lelli wrote:
> Reference to cpu capacity binding has a wrong number. Fix it.
>
> Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 1/4] Documentation: dt-bindings: add the Amlogic Meson SAR ADC documentation
From: Rob Herring @ 2017-01-21 20:56 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: mark.rutland, devicetree, sboyd, lars, catalin.marinas,
narmstrong, linux-iio, khilman, mturquette, will.deacon,
linux-arm-kernel, pmeerw, knaack.h, carlo, linux-amlogic,
linux-clk, jic23
In-Reply-To: <20170119145822.26239-2-martin.blumenstingl@googlemail.com>
On Thu, Jan 19, 2017 at 03:58:19PM +0100, Martin Blumenstingl wrote:
> This adds the devicetree binding documentation for the SAR ADC found in
> Amlogic Meson SoCs.
> Currently only the GXBB, GXL and GXM SoCs are supported.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/iio/adc/amlogic,meson-saradc.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> new file mode 100644
> index 000000000000..9a0bec7afc63
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> @@ -0,0 +1,31 @@
> +* Amlogic Meson SAR (Successive Approximation Register) A/D converter
> +
> +Required properties:
> +- compatible: depending on the SoC this should be one of:
> + - "amlogic,meson-gxbb-saradc" for GXBB
> + - "amlogic,meson-gxl-saradc" for GXL and GXM
GXL and GXM should probably be 2 compatibles.
> + along with the generic "amlogic,meson-saradc"
> +- reg: the physical base address and length of the registers
> +- clocks: phandle and clock identifier (see clock-names)
> +- clock-names: mandatory clocks:
> + - "clkin" for the reference clock (typically XTAL)
> + - "core" for the SAR ADC core clock
> + optional clocks:
> + - "sana" for the analog clock
> + - "adc_clk" for the ADC (sampling) clock
> + - "adc_sel" for the ADC (sampling) clock mux
> +- vref-supply: the regulator supply for the ADC reference voltage
> +- #io-channel-cells: must be 1, see ../iio-bindings.txt
> +
> +Example:
> + saradc: adc@8680 {
> + compatible = "amlogic,meson-gxl-saradc", "amlogic,meson-saradc";
> + #io-channel-cells = <1>;
> + reg = <0x0 0x8680 0x0 0x34>;
> + clocks = <&xtal>,
> + <&clkc CLKID_SAR_ADC>,
> + <&clkc CLKID_SANA>,
> + <&clkc CLKID_SAR_ADC_CLK>,
> + <&clkc CLKID_SAR_ADC_SEL>;
> + clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
> + };
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property
From: Jacek Anaszewski @ 2017-01-21 21:42 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Greg Kroah-Hartman,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:LED SUBSYSTEM, Richard Purdie, Pavel Machek,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Rutland, Rafał Miłecki
In-Reply-To: <CACna6rx-qJ5eLMOUbMcaAxaOp9avrj1sa-8zZo2m+rVvY+Kvjw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
> On 20 January 2017 at 23:35, Jacek Anaszewski
> <jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>
>>> Some LEDs can be related to particular devices described in DT. This
>>> property allows specifying such relations. E.g. USB LED should usually
>>> be used to indicate some USB port(s) state.
>>>
>>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>> ---
>>> V2: Replace "usb-ports" with "led-triggers" property which is more generic and
>>> allows specifying other devices as well.
>>>
>>> When bindings patch is related to some followup implementation, they usually go
>>> through the same tree.
>>>
>>> Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds: Improve examples by
>>> adding some context") from kernel/git/j.anaszewski/linux-leds.git . Is there any
>>> way to solve this dependency issue? Or should this patch wait until 3.11 is
>>> released?
>>> ---
>>> Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
>>> index 24b656014089..17632a041196 100644
>>> --- a/Documentation/devicetree/bindings/leds/common.txt
>>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:
>>> - panic-indicator : This property specifies that the LED should be used,
>>> if at all possible, as a panic indicator.
>>>
>>> +- led-triggers : List of devices that should trigger this LED activity. Some
>>> + LEDs can be related to a specific device and should somehow
>>> + indicate its state. E.g. USB 2.0 LED may react to device(s) in
>>> + a USB 2.0 port(s). Another common example is switch or router
>>> + with multiple Ethernet ports each of them having its own LED
>>> + assigned (assuminled-trigger-usbportg they are not hardwired).
>>> + In such cases this property should contain phandle(s) of
>>> + related device(s). In many cases LED can be related to more
>>> + than one device (e.g. one USB LED vs. multiple USB ports) so a
>>> + list of entries can be specified.
>>> +
>>
>> This implies that it is possible to define multiple triggers for
>> a LED class device but it is not supported by LED Trigger core.
>> There is linux,default-trigger property which allows to define one
>> trigger that will be initially assigned.
>
> I think we owe some extra explanation to people not closely familiar
> with the triggers.
>
> Linux has multiple trigger drivers each supporting some *type* of
> events. Linux supports assigning only one trigger driver to LED at a
> time.
> This means you can use e.g.:
> 1) "usbport" trigger driver that supports USB events
> XOR
> 2) "timer" trigger driver that uses timer to control LED
> XOR
> 3) "cpu" trigger driver that supports CPU events
> at once.
Correct.
> With proposed "led-triggers" property one could assign different
> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network
> device & CPU to a single LED. For reason explained above Linux
> couldn't support all of them at once.
>
>
>> I am aware that this is renamed usb-ports property from v1,
>> that attempts to address Rob's comment, but we can't do that this way.
>> Maybe usb-ports property could be documented in led-trigger-usbport's
>> specific bindings and a reference to it could be added next to the
>> related entry on the list of the available LED triggers (which is
>> actually missing) in Documentation/devicetree/bindings/leds/common.txt.
>
> I'm wondering if we need to care about this Linux limitation and if it
> should stop us from adding this flexible DT property. Maybe we could
> live with Linux having limitation of supporting one trigger type at a
> time?
That's what I meant. Generally I have objections to the generic
property for defining list of allowed triggers. That's why I proposed
to stay by usb-ports property that would be specific to only one
trigger: led-trigger-usbport.
led-trigger-usbport in fact is an entirely new type of LED trigger.
LED triggers is a kernel based source of events. All existing triggers
react only to a single, well defined source of events, whereas
led-trigger-usbport allows to define the scope of events (usb ports)
to notify about. Activity on each port is treated similarly and the LED
class device that listens to the trigger notifications doesn't know
which exact port triggered the notification.
>From this POV led-trigger-usbport is kind of facade, which allows
for it to fit well into the LED Trigger design and API, and usb ports
are not identical with LED triggers, but sit rather one level below.
It is led-trigger-usbport which is visible to the LED subsystem, and
not every single usb port.
Therefore it isn't logically justified to rename usb-ports property
to led-triggers. The property should be specific to this trigger.
> So e.g. if one assigns 2 USB ports + network device + CPU and
> decides to use "usport" trigger driver he'll get LED indicating status
> of USB ports only.
How would it be different from the current state? Only in limiting
the scope of triggers available for a LED class device.
> I think we could live with such limitation in Linux support for this
> generic "led-triggers" property. I think it's also not very common to
> have LED with different types of devices assigned. Personally I've
> never seen devices with LED label "USB & CPU" or whatever.
I agree. Nonetheless led-triggers seems to support such a design.
> What do you think about this? Maybe we could also document this
> limitation in trigger docs.
I'm not entirely sure if I got your point. Your reasoning seems
self contradicting to me in few places.
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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