* Re: [PATCH] dt-binding: soc: qcom: smd: Add label property
From: Rob Herring @ 2016-10-26 22:08 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, David Brown, Mark Rutland, linux-arm-msm, linux-soc,
devicetree, linux-kernel
In-Reply-To: <1476931090-1616-1-git-send-email-bjorn.andersson@linaro.org>
On Wed, Oct 19, 2016 at 07:38:10PM -0700, Bjorn Andersson wrote:
> The label property can be used to specify a name of the edge, for
> consistent naming purposes.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 13/15] Documentation: devicetree: dwc2: Add host DMA binding
From: Rob Herring @ 2016-10-26 22:07 UTC (permalink / raw)
To: John Youn
Cc: Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
In-Reply-To: <1846cc28dd77ab35cd21994bb746f7685422cfb2.1476926070.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Wed, Oct 19, 2016 at 06:22:52PM -0700, John Youn wrote:
> Add the host-dma property to devicetree. This controls whether to use
> DMA in host mode.
>
> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
> index 2c30a54..17f7624 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -25,6 +25,7 @@ Optional properties:
> Refer to phy/phy-bindings.txt for generic phy consumer properties
> - dr_mode: shall be one of "host", "peripheral" and "otg"
> Refer to usb/generic.txt
> +- host-dma: turn on or off host buffer DMA (1 or 0).
Why not boolean? Seems like disabling would be rare, so name the
property something like host-dma-disable. Also, it needs a vendor
prefix.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2016-10-26 22:04 UTC (permalink / raw)
To: Dave Gerlach
Cc: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Nishanth Menon,
devicetree, Santosh Shilimkar, Keerthy, linux-pm, linux-kernel,
Tero Kristo, Russell King, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20161019203347.17893-3-d-gerlach@ti.com>
On Wed, Oct 19, 2016 at 03:33:45PM -0500, Dave Gerlach wrote:
> Add a generic power domain implementation, TI SCI PM Domains, that
> will hook into the genpd framework and allow the TI SCI protocol to
> control device power states.
>
> Also, provide macros representing each device index as understood
> by TI SCI to be used in the device node power-domain references.
> These are identifiers for the K2G devices managed by the PMMC.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
> 3 files changed, 146 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> create mode 100644 include/dt-bindings/genpd/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> new file mode 100644
> index 000000000000..32f38a349656
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> @@ -0,0 +1,54 @@
> +Texas Instruments TI-SCI Generic Power Domain
> +---------------------------------------------
> +
> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
> +responsible for controlling the state of the IPs that are present.
> +Communication between the host processor running an OS and the system
> +controller happens through a protocol known as TI-SCI [1]. This pm domain
> +implementation plugs into the generic pm domain framework and makes use of
> +the TI SCI protocol power on and off each device when needed.
> +
> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +PM Domain Node
> +==============
> +The PM domain node represents the global PM domain managed by the PMMC,
> +which in this case is the single implementation as documented by the generic
> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> +
> +Required Properties:
> +--------------------
> +- compatible: should be "ti,sci-pm-domain"
> +- #power-domain-cells: Must be 0.
> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
> +
> +Example:
> +--------------------
> +k2g_pds: k2g_pds {
> + compatible = "ti,sci-pm-domain";
> + #power-domain-cells = <0>;
> + ti,sci = <&pmmc>;
> +};
Why not just make the PMMC node be the power-domain provider itself? If
not that, then make this a child node of it. The same comment applies to
all the SCI functions, but I guess I've already acked some of them.
I really don't like reviewing all these TI SCI bindings one by one. Each
one on its own seems fine, but I don't see the full picture.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2016-10-26 21:59 UTC (permalink / raw)
To: Kevin Hilman
Cc: Dave Gerlach, Ulf Hansson, Rafael J . Wysocki,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, Nishanth Menon, Keerthy, Russell King,
Tero Kristo, Sudeep Holla, Santosh Shilimkar
In-Reply-To: <7h1sz51y3p.fsf@baylibre.com>
On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Dave Gerlach <d-gerlach@ti.com> writes:
>
>> Hi,
>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>
>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>> control device power states.
>>>>
>>>> Also, provide macros representing each device index as understood
>>>> by TI SCI to be used in the device node power-domain references.
>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>
>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>> ---
>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
>>>> MAINTAINERS | 2 +
>>>> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
>>>> 3 files changed, 146 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>> new file mode 100644
>>>> index 000000000000..32f38a349656
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>> @@ -0,0 +1,54 @@
>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>> +---------------------------------------------
>>>> +
>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>>> +responsible for controlling the state of the IPs that are present.
>>>> +Communication between the host processor running an OS and the system
>>>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>>>> +implementation plugs into the generic pm domain framework and makes use of
>>>> +the TI SCI protocol power on and off each device when needed.
>>>> +
>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>> +
>>>> +PM Domain Node
>>>> +==============
>>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>>> +which in this case is the single implementation as documented by the generic
>>>> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>>>> +
>>>> +Required Properties:
>>>> +--------------------
>>>> +- compatible: should be "ti,sci-pm-domain"
>>>> +- #power-domain-cells: Must be 0.
>>>> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
>>>>
>>>> +Example:
>>>> +--------------------
>>>> +k2g_pds: k2g_pds {
>>>
>>> should use generic name like "power-contoller", e.g. k2g_pds: power-controller
>>
>> Ok, that makes more sense.
>>
>>>
>>>> + compatible = "ti,sci-pm-domain";
>>>> + #power-domain-cells = <0>;
>>>> + ti,sci = <&pmmc>;
>>>> +};
>>>> +
>>>> +PM Domain Consumers
>>>> +===================
>>>> +Hardware blocks that require SCI control over their state must provide
>>>> +a reference to the sci-pm-domain they are part of and a unique device
>>>> +specific ID that identifies the device.
>>>> +
>>>> +Required Properties:
>>>> +--------------------
>>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>>> + be used for device control.
>>>
>>> This ID doesn't look right.
>>>
>>> Why not use #power-domain-cells = <1> and pass the index in the DT? ...
Exactly. ti,sci-id is a NAK for me.
>>>
>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
>>>> +
>>>> +Example:
>>>> +--------------------
>>>> +uart0: serial@02530c00 {
>>>> + compatible = "ns16550a";
>>>> + ...
>>>> + power-domains = <&k2g_pds>;
>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>
>>> ... like this:
>>>
>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>
>> That's how I did it in version one actually. I was able to define my
>> own xlate function to parse the phandle and get that index, but Ulf
>> pointed me to this series by Jon Hunter [1] that simplified genpd
>> providers and dropped the concept of adding your own xlate. This locks
>> the onecell approach to using a fixed static array of genpds that get
>> indexed into (without passing the index to the provider, just the
>> genpd that's looked up), which doesn't fit our usecase, as we don't
>> want a 1 to 1 genpd to device mapping based on the comments provided
>> in v1. Now we just use the genpd device attach/detach hooks to parse
>> the sci-id and then use it in the genpd device start/stop hooks.
I have no idea what any of this means. All sounds like driver
architecture, not anything to do with bindings.
>
> Ah, right. I remember now. This approach allows you to use a single
> genpd as discussed earlier.
>
> Makes sense now, suggestion retracted.
IIRC, the bindings in Jon's case had a node for each domain and didn't
need any additional property.
Rob
^ permalink raw reply
* Re: [PATCH V6 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Sinan Kaya @ 2016-10-26 21:54 UTC (permalink / raw)
To: Rob Herring
Cc: dmaengine, timur, devicetree, cov, vinod.koul, jcm, agross, arnd,
linux-arm-msm, linux-arm-kernel, Mark Rutland, linux-kernel
In-Reply-To: <20161026214512.ofwbxnl2d46n6ef5@rob-hp-laptop>
On 10/26/2016 5:45 PM, Rob Herring wrote:
> On Wed, Oct 19, 2016 at 01:51:43PM -0400, Sinan Kaya wrote:
>> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
>> MSI interrupts from the older revision.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> Please add acks when posting new versions.
>
Sure, sorry about that. Your acked version already got merged to Vinod's branch.
During the merge, Vinod got some merge conflicts for the remainder of the patches.
I was trying to post the remaining patches for Vinod to pick it up.
Apologies if it was not clear.
I posted V7 with only four remaining patches without the already merged
DT changes.
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH 4/5] net: ethernet: bgmac: add NS2 support
From: Florian Fainelli @ 2016-10-26 21:50 UTC (permalink / raw)
To: Jon Mason, David Miller, Rob Herring, Mark Rutland
Cc: rafal-g1n6cQUeyibVItvQsEIGlw,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477510561-17035-5-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 10/26/2016 12:36 PM, Jon Mason wrote:
> Add support for the variant of amac hardware present in the Broadcom
> Northstar2 based SoCs. Northstar2 requires an additional register to be
> configured with the port speed/duplexity (NICPM). This can be added to
> the link callback to hide it from the instances that do not use this.
> Also, the bgmac_chip_reset() was intentionally removed to prevent the
> resetting of the chip to the default values on open. Finally, clearing
> of the pending interrupts on init is required due to observed issues on
> some platforms.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> +{
> + struct bgmac *bgmac = netdev_priv(net_dev);
> + u32 val;
> +
> + if (!bgmac->plat.nicpm_base)
> + return;
> +
> + val = NICPM_IOMUX_CTRL_INIT_VAL;
> + switch (bgmac->net_dev->phydev->speed) {
> + default:
> + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
> + case SPEED_1000:
> + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_100:
> + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_10:
> + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + }
> +
> + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> +
> + usleep_range(10, 100);
Does not seem like a good idea, do you need that sleep?
> +
> + bgmac_adjust_link(bgmac->net_dev);
> +}
> +
> static int platform_phy_connect(struct bgmac *bgmac)
> {
> struct phy_device *phy_dev;
>
> - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> - bgmac_adjust_link);
> + if (bgmac->plat.nicpm_base)
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_nicpm_speed_set);
> + else
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_adjust_link);
> if (!phy_dev) {
> dev_err(bgmac->dev, "Phy connect failed\n");
> return -ENODEV;
> }
>
> + if (bgmac->feature_flags & BGMAC_FEAT_LANE_SWAP)
> + phy_dev->dev_flags |= PHY_BRCM_EXP_LANE_SWAP;
> +
> return 0;
> }
>
> @@ -140,6 +188,9 @@ static int bgmac_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, bgmac);
>
> + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap"))
> + bgmac->feature_flags |= BGMAC_FEAT_LANE_SWAP;
> +
> /* Set the features of the 4707 family */
> bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
> bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
> @@ -182,6 +233,14 @@ static int bgmac_probe(struct platform_device *pdev)
> if (IS_ERR(bgmac->plat.idm_base))
> return PTR_ERR(bgmac->plat.idm_base);
>
> + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> + if (regs) {
> + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> + regs);
> + if (IS_ERR(bgmac->plat.nicpm_base))
> + return PTR_ERR(bgmac->plat.nicpm_base);
> + }
> +
> bgmac->read = platform_bgmac_read;
> bgmac->write = platform_bgmac_write;
> bgmac->idm_read = platform_bgmac_idm_read;
> @@ -213,6 +272,7 @@ static int bgmac_remove(struct platform_device *pdev)
> static const struct of_device_id bgmac_of_enet_match[] = {
> {.compatible = "brcm,amac",},
> {.compatible = "brcm,nsp-amac",},
> + {.compatible = "brcm,ns2-amac",},
> {},
> };
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> index 38876ec..1796208 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.c
> +++ b/drivers/net/ethernet/broadcom/bgmac.c
> @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> static void bgmac_chip_init(struct bgmac *bgmac)
> {
> + /* Clear any erroneously pending interrupts */
> + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> +
> /* 1 interrupt per received frame */
> bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
>
> @@ -1158,8 +1161,6 @@ static int bgmac_open(struct net_device *net_dev)
> struct bgmac *bgmac = netdev_priv(net_dev);
> int err = 0;
>
> - bgmac_chip_reset(bgmac);
> -
Is this removal intentional? Maybe it should be special cased with
checking for a NS2 BGMAC instance and not do it in that case?
--
Florian
--
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 2/2] Documentation: DT: MMC: meson-gx: new bindings doc
From: Rob Herring @ 2016-10-26 21:46 UTC (permalink / raw)
To: Kevin Hilman
Cc: Ulf Hansson, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161019181825.2186-2-khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Wed, Oct 19, 2016 at 11:18:25AM -0700, Kevin Hilman wrote:
> Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/mmc/amlogic,meson-gx.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/amlogic,meson-gx.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 V6 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Rob Herring @ 2016-10-26 21:45 UTC (permalink / raw)
To: Sinan Kaya
Cc: dmaengine, timur, devicetree, cov, vinod.koul, jcm, agross, arnd,
linux-arm-msm, linux-arm-kernel, Mark Rutland, linux-kernel
In-Reply-To: <1476899512-20431-2-git-send-email-okaya@codeaurora.org>
On Wed, Oct 19, 2016 at 01:51:43PM -0400, Sinan Kaya wrote:
> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
> MSI interrupts from the older revision.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Please add acks when posting new versions.
Rob
^ permalink raw reply
* Re: [PATCH 1/2] power_supply: Add OF bindings documentation for max14656_charger_detector
From: Rob Herring @ 2016-10-26 21:43 UTC (permalink / raw)
To: Alexander Kurz
Cc: Sebastian Reichel, Dmitry Eremin-Solenikov, David Woodhouse,
linux-pm, Mark Rutland, devicetree
In-Reply-To: <1476893089-7233-1-git-send-email-akurz@blala.de>
On Wed, Oct 19, 2016 at 06:04:48PM +0200, Alexander Kurz wrote:
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> .../bindings/power_supply/maxim,max14656.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power_supply/maxim,max14656.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller
From: Rob Herring @ 2016-10-26 21:42 UTC (permalink / raw)
To: Jerome Brunet
Cc: Carlo Caione, Kevin Hilman, Thomas Gleixner, Jason Cooper,
Marc Zyngier, linux-amlogic, linux-arm-kernel, linux-gpio,
linux-kernel, devicetree, Linus Walleij, Catalin Marinas,
Will Deacon, Russell King
In-Reply-To: <1476890480-8884-3-git-send-email-jbrunet@baylibre.com>
On Wed, Oct 19, 2016 at 05:21:13PM +0200, Jerome Brunet wrote:
>
> This commit adds the device tree bindings description for Amlogic's GPIO
> interrupt controller available on the meson8, meson8b and gxbb SoC families
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> Rob, I did not include the Ack you gave for the RFC as bindings have slightly
> changed. Only the interrupt property has be removed following a discussion I
> had with Marc
As Mark R already said, you should keep the interrupts property.
^ permalink raw reply
* Re: [PATCH 1/8] drm: bridge: Add LVDS encoder driver
From: Rob Herring @ 2016-10-26 21:32 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-renesas-soc, devicetree, dri-devel
In-Reply-To: <1476887143-24831-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On Wed, Oct 19, 2016 at 05:25:36PM +0300, Laurent Pinchart wrote:
> The LVDS encoder driver is a DRM bridge driver that supports the
> parallel to LVDS encoders that don't require any configuration. The
> driver thus doesn't interact with the device, but creates an LVDS
> connector for the panel and exposes its size and timing based on
> information retrieved from DT.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> .../bindings/display/bridge/lvds-transmitter.txt | 64 +++++++
It's preferred that bindings are separate patches. That makes the
filtered DT only repo commits more sane.
Acked-by: Rob Herring <robh@kernel.org>
> drivers/gpu/drm/bridge/Kconfig | 8 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/lvds-encoder.c | 203 +++++++++++++++++++++
> 4 files changed, 276 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> create mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
From: Rob Herring @ 2016-10-26 21:18 UTC (permalink / raw)
To: Vivek Gautam
Cc: kishon-l0cyMroinI0, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476873827-7191-3-git-send-email-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Wed, Oct 19, 2016 at 04:13:47PM +0530, Vivek Gautam wrote:
> Qualcomm SOCs have QMP phy controller that provides support
> to a number of controller, viz. PCIe, UFS, and USB.
> Add a new driver, based on generic phy framework, for this
> phy controller.
>
> USB3-phy changes: Based on phy-msm-ssusb-qmp driver available on
> msm-4.4 kernel @codeaurora[1].
> PCIe-phy changes: Based on msm8996-pcie-phy driver posted by
> Srinivas [2].
>
> [1] https://source.codeaurora.org/quic/la/kernel/msm-4.4/log/?h=caf/3.18/msm-3.18
> [2] https://patchwork.kernel.org/patch/9318947/
>
> Signed-off-by: Vivek Gautam <vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> ---
> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 61 ++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/phy/Kconfig | 8 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-qcom-qmp.c | 1154 ++++++++++++++++++++
> 4 files changed, 1224 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> create mode 100644 drivers/phy/phy-qcom-qmp.c
--
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] mwifiex: parse device tree node for PCIe
From: Rajat Jain @ 2016-10-26 21:16 UTC (permalink / raw)
To: Brian Norris
Cc: Dmitry Torokhov, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xinming Hu, Amitkumar Karwar,
Brian Norris, Kalle Valo, Rob Herring, Rajat Jain
In-Reply-To: <20161026210805.GA14423@localhost>
On Wed, Oct 26, 2016 at 2:08 PM, Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> On Wed, Oct 26, 2016 at 02:06:48PM -0700, Dmitry Torokhov wrote:
>> On Wed, Oct 26, 2016 at 01:56:34PM -0700, Brian Norris wrote:
>> > On Wed, Oct 26, 2016 at 01:51:48PM -0700, Rajat Jain wrote:
>> > > On Wed, Oct 26, 2016 at 1:46 PM, Dmitry Torokhov
>> > > <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > > On Wed, Oct 26, 2016 at 01:17:36PM -0700, Brian Norris wrote:
>> > > Sorry, I just saw this... Why do we need devicetree data for
>> > > discoverable bus (PCI)? How does the driver work on systems that do not
>> > > use DT? Why do we need them to behave differently?
>> > >
>> > > There are a couple of out-of-band GPIO pins from Marvell chip that can
>> > > serve as wake-up pins (wake up the CPU when asserted). The Marvell chip
>> > > has to be told which GPIO pin is to be used as the wake-up pin. The pin to
>> > > be used is system / platform dependent. (On some systems it could be
>> > > GPIO13, on others it could be GPIO14 etc depending on how the marvell chip
>> > > is wired up to the CPU).
>>
>> So wakeup pin is not wired to PCIe WAKE?
>
> Not in our case.
>
>> > There's also calibration data. See "marvell,caldata*" and
>> > "marvell,wakeup-pin" properties. Currently only for SDIO, in
>> > Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt, but
>> > we're adding support for PCIe.
>>
>> How would it all work if I moved the PCIe module from one device to
>> another?
>
> These boards are soldered down, at least in the case I care about.
That is right. Since the out of band wake-up pin is not standard on
the PCIe connector - this feature is for soldered chips only.
>
> Brian
--
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] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
From: Rob Herring @ 2016-10-26 21:16 UTC (permalink / raw)
To: Vivek Gautam
Cc: kishon, mark.rutland, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <1476873827-7191-2-git-send-email-vivek.gautam@codeaurora.org>
On Wed, Oct 19, 2016 at 04:13:46PM +0530, Vivek Gautam wrote:
> PHY transceiver driver for QUSB2 phy controller that provides
> HighSpeed functionality for DWC3 controller present on
> Qualcomm chipsets.
>
> This driver is based on phy-msm-qusb driver available in
> msm-4.4 kernel @codeaurora[1]
>
> [1] https://source.codeaurora.org/quic/la/kernel/msm-4.4/log/?h=caf/3.18/msm-3.18
>
> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 37 ++
It's preferred the bindings are a separate patch.
> drivers/phy/Kconfig | 10 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-qcom-qusb2.c | 577 +++++++++++++++++++++
> 4 files changed, 625 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
> create mode 100644 drivers/phy/phy-qcom-qusb2.c
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
> new file mode 100644
> index 0000000..97c9ce7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
> @@ -0,0 +1,37 @@
> +Qualcomm QUSB2 phy controller
> +=============================
> +
> +QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
> +
> +Required properties:
> + - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
> + - reg: offset and length of the PHY register set.
> + - #phy-cells: must be 0.
> +
> + - clocks: a list of phandles and clock-specifier pairs,
> + one for each entry in clock-names.
> + - clock-names: must be "cfg_ahb" for phy config clock,
> + "ref_clk" for 19.2 MHz ref clk,
> + "ref_clk_src" reference clock source.
> + "iface" for phy interface clock (Optional).
> +
> + - vdd-phy-supply: Phandle to a regulator supply to PHY core block.
> + - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
> + - vdda-phy-dpdm: Phandle to 3.1V regulator supply to Dp/Dm port signals.
> +
> + - resets: a list of phandles and reset controller specifier pairs,
> + one for each entry in reset-names.
> + - reset-names: must be "phy" for reset of phy block.
> +
> +Optional properties:
> + - nvmem-cells: a list of phandles to nvmem cells that contain fused
> + tuning parameters for qusb2 phy, one for each entry
> + in nvmem-cell-names.
> + - nvmem-cell-names: must be "tune2_hstx_trim_efuse" for cell containing
> + HS Tx trim value.
> + - qcom,hstx-trim-bit-offset: bit offset within nvmem cell for
> + HS Tx trim value.
> + - qcom,hstx-trim-bit-len: bit length of HS Tx trim value within nvmem cell.
When does this change? Why is it not just a different nvmem cell?
> +
> + - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
> + - qcom,phy-clk-scheme: Offset to TCSR_PHY_CLK_SCHEME_SEL register.
^ permalink raw reply
* Re: [PATCH 2/2] hwmon: (mcp3021) add devicetree bindings documentation
From: Rob Herring @ 2016-10-26 21:12 UTC (permalink / raw)
To: Clemens Gruber
Cc: linux-hwmon, Guenter Roeck, Jean Delvare, devicetree,
linux-kernel
In-Reply-To: <20161019094056.24508-1-clemens.gruber@pqgruber.com>
On Wed, Oct 19, 2016 at 11:40:56AM +0200, Clemens Gruber wrote:
> Documents the devicetree bindings for the Microchip MCP3021/3221.
>
> Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
> ---
> Documentation/devicetree/bindings/hwmon/mcp3021.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/mcp3021.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/mcp3021.txt b/Documentation/devicetree/bindings/hwmon/mcp3021.txt
> new file mode 100644
> index 0000000..e1d1e62
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/mcp3021.txt
> @@ -0,0 +1,21 @@
> +mcp3021 properties
> +
> +Required properties:
> +- compatible: Must be one of the following:
> + - "microchip,mcp3021" for mcp3021
> + - "microchip,mcp3221" for mcp3221
> +- reg: I2C address
> +
> +Optional properties:
> +
> +- reference-voltage
> + Reference voltage in millivolt (mV)
What I said on the first version.
> +
> +Example:
> +
> +mcp3021@4d {
> + compatible = "microchip,mcp3021";
> + reg = <0x4d>;
> +
> + reference-voltage = <4500>; /* 4.5 V */
> +};
> --
> 2.10.0
>
> --
> 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 v6] mwifiex: parse device tree node for PCIe
From: Rajat Jain @ 2016-10-26 21:12 UTC (permalink / raw)
To: Brian Norris
Cc: Dmitry Torokhov, linux-wireless, devicetree, Xinming Hu,
Amitkumar Karwar, Brian Norris, Kalle Valo, Rob Herring,
Rajat Jain
In-Reply-To: <20161026210805.GA14423@localhost>
[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]
On Wed, Oct 26, 2016 at 2:08 PM, Brian Norris <briannorris@chromium.org>
wrote:
> On Wed, Oct 26, 2016 at 02:06:48PM -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 26, 2016 at 01:56:34PM -0700, Brian Norris wrote:
> > > On Wed, Oct 26, 2016 at 01:51:48PM -0700, Rajat Jain wrote:
> > > > On Wed, Oct 26, 2016 at 1:46 PM, Dmitry Torokhov
> > > > <dmitry.torokhov@gmail.com> wrote:
> > > > On Wed, Oct 26, 2016 at 01:17:36PM -0700, Brian Norris wrote:
> > > > Sorry, I just saw this... Why do we need devicetree data for
> > > > discoverable bus (PCI)? How does the driver work on systems
> that do not
> > > > use DT? Why do we need them to behave differently?
> > > >
> > > > There are a couple of out-of-band GPIO pins from Marvell chip
> that can
> > > > serve as wake-up pins (wake up the CPU when asserted). The
> Marvell chip
> > > > has to be told which GPIO pin is to be used as the wake-up pin.
> The pin to
> > > > be used is system / platform dependent. (On some systems it could
> be
> > > > GPIO13, on others it could be GPIO14 etc depending on how the
> marvell chip
> > > > is wired up to the CPU).
> >
> > So wakeup pin is not wired to PCIe WAKE?
>
> Not in our case.
>
> > > There's also calibration data. See "marvell,caldata*" and
> > > "marvell,wakeup-pin" properties. Currently only for SDIO, in
> > > Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt, but
> > > we're adding support for PCIe.
> >
> > How would it all work if I moved the PCIe module from one device to
> > another?
>
> These boards are soldered down, at least in the case I care about.
>
Correct. Since the out of band wake-up pin is not standard on the PCIe
connector - this feature is for soldered chips only.
>
> Brian
>
[-- Attachment #2: Type: text/html, Size: 2703 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] gpio: davinci: Add a separate compatible for k2g
From: Rob Herring @ 2016-10-26 21:08 UTC (permalink / raw)
To: Keerthy
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, lokeshvutla-l0cyMroinI0,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, rogerq-l0cyMroinI0,
grygorii.strashko-l0cyMroinI0
In-Reply-To: <1476855239-32730-6-git-send-email-j-keerthy-l0cyMroinI0@public.gmane.org>
On Wed, Oct 19, 2016 at 11:03:59AM +0530, Keerthy wrote:
> In the case of k2g the clocks are handled differently as when compared
> with other keystones. Hence adding a separate compatible and match tables
> accordingly.
>
> Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
> ---
> .../devicetree/bindings/gpio/gpio-davinci.txt | 2 +-
> drivers/gpio/gpio-davinci.c | 45 ++++++++++++++++++++--
> 2 files changed, 42 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
> index 5079ba7..a76abd2 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
> @@ -1,7 +1,7 @@
> Davinci/Keystone GPIO controller bindings
>
> Required Properties:
> -- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"
> +- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio", "ti,k2g-gpio"
Is this "one of" or all? Seems line the former in which case please
reformat to one per line.
>
> - reg: Physical base address of the controller and the size of memory mapped
> registers.
--
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] mwifiex: parse device tree node for PCIe
From: Brian Norris @ 2016-10-26 21:08 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rajat Jain, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xinming Hu, Amitkumar Karwar,
Brian Norris, Kalle Valo, Rob Herring, Rajat Jain
In-Reply-To: <20161026210648.GE3989@dtor-ws>
On Wed, Oct 26, 2016 at 02:06:48PM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 26, 2016 at 01:56:34PM -0700, Brian Norris wrote:
> > On Wed, Oct 26, 2016 at 01:51:48PM -0700, Rajat Jain wrote:
> > > On Wed, Oct 26, 2016 at 1:46 PM, Dmitry Torokhov
> > > <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On Wed, Oct 26, 2016 at 01:17:36PM -0700, Brian Norris wrote:
> > > Sorry, I just saw this... Why do we need devicetree data for
> > > discoverable bus (PCI)? How does the driver work on systems that do not
> > > use DT? Why do we need them to behave differently?
> > >
> > > There are a couple of out-of-band GPIO pins from Marvell chip that can
> > > serve as wake-up pins (wake up the CPU when asserted). The Marvell chip
> > > has to be told which GPIO pin is to be used as the wake-up pin. The pin to
> > > be used is system / platform dependent. (On some systems it could be
> > > GPIO13, on others it could be GPIO14 etc depending on how the marvell chip
> > > is wired up to the CPU).
>
> So wakeup pin is not wired to PCIe WAKE?
Not in our case.
> > There's also calibration data. See "marvell,caldata*" and
> > "marvell,wakeup-pin" properties. Currently only for SDIO, in
> > Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt, but
> > we're adding support for PCIe.
>
> How would it all work if I moved the PCIe module from one device to
> another?
These boards are soldered down, at least in the case I care about.
Brian
^ permalink raw reply
* Re: [PATCH v6] mwifiex: parse device tree node for PCIe
From: Dmitry Torokhov @ 2016-10-26 21:06 UTC (permalink / raw)
To: Brian Norris
Cc: Rajat Jain, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xinming Hu, Amitkumar Karwar,
Brian Norris, Kalle Valo, Rob Herring, Rajat Jain
In-Reply-To: <20161026205634.GA13170@localhost>
On Wed, Oct 26, 2016 at 01:56:34PM -0700, Brian Norris wrote:
> On Wed, Oct 26, 2016 at 01:51:48PM -0700, Rajat Jain wrote:
> > On Wed, Oct 26, 2016 at 1:46 PM, Dmitry Torokhov
> > <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Wed, Oct 26, 2016 at 01:17:36PM -0700, Brian Norris wrote:
> > Sorry, I just saw this... Why do we need devicetree data for
> > discoverable bus (PCI)? How does the driver work on systems that do not
> > use DT? Why do we need them to behave differently?
> >
> > There are a couple of out-of-band GPIO pins from Marvell chip that can
> > serve as wake-up pins (wake up the CPU when asserted). The Marvell chip
> > has to be told which GPIO pin is to be used as the wake-up pin. The pin to
> > be used is system / platform dependent. (On some systems it could be
> > GPIO13, on others it could be GPIO14 etc depending on how the marvell chip
> > is wired up to the CPU).
So wakeup pin is not wired to PCIe WAKE?
> There's also calibration data. See "marvell,caldata*" and
> "marvell,wakeup-pin" properties. Currently only for SDIO, in
> Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt, but
> we're adding support for PCIe.
How would it all work if I moved the PCIe module from one device to
another?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] mcp3021: rework for DT support of reference-voltage
From: Rob Herring @ 2016-10-26 21:06 UTC (permalink / raw)
To: Clemens Gruber
Cc: linux-hwmon, Guenter Roeck, Jean Delvare, devicetree, linux-doc,
linux-kernel
In-Reply-To: <20161018224444.11225-1-clemens.gruber@pqgruber.com>
On Wed, Oct 19, 2016 at 12:44:44AM +0200, Clemens Gruber wrote:
> Support setting the reference voltage in the device tree.
> Rework of driver structure, put chip specific data in a separate
> structure and assign it depending on device id from platform data or
> DT match.
> Extend the device documentation and add new documentation for the
> devicetree bindings.
> Also change S_IRUGO to the better readable 0444, which fixes a
> checkpatch warning.
"Also" is a keyword for put in a separate commit.
>
> Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
> ---
> .../devicetree/bindings/hwmon/mcp3021.txt | 21 +++
> Documentation/hwmon/mcp3021 | 5 +
> drivers/hwmon/mcp3021.c | 184 ++++++++++++++-------
> 3 files changed, 149 insertions(+), 61 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/hwmon/mcp3021.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/mcp3021.txt b/Documentation/devicetree/bindings/hwmon/mcp3021.txt
> new file mode 100644
> index 0000000..e1d1e62
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/mcp3021.txt
> @@ -0,0 +1,21 @@
> +mcp3021 properties
> +
> +Required properties:
> +- compatible: Must be one of the following:
> + - "microchip,mcp3021" for mcp3021
> + - "microchip,mcp3221" for mcp3221
> +- reg: I2C address
> +
> +Optional properties:
> +
> +- reference-voltage
> + Reference voltage in millivolt (mV)
Unit suffix in the property name please. The defined unit for DT is
'-microvolt'.
> +
> +Example:
> +
> +mcp3021@4d {
> + compatible = "microchip,mcp3021";
> + reg = <0x4d>;
> +
> + reference-voltage = <4500>; /* 4.5 V */
> +};
^ permalink raw reply
* Re: [RFC 1/2] mmc: sdhci: dt: Add device tree property sdhci-cap-speed-modes-broken
From: Rob Herring @ 2016-10-26 21:03 UTC (permalink / raw)
To: Zach Brown
Cc: ulf.hansson, adrian.hunter, mark.rutland, linux-mmc, devicetree,
linux-kernel
In-Reply-To: <1476824736-9337-2-git-send-email-zach.brown@ni.com>
On Tue, Oct 18, 2016 at 04:05:35PM -0500, Zach Brown wrote:
> On some systems the sdhci capabilty registers are incorrect for one
> reason or another.
>
> The sdhci-cap-speed-modes-broken property will let the driver know that
> the sdhci capability registers should not be relied on for speed modes.
> Instead the driver should check the mmc generic DT bindings.
>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
> ---
> Documentation/devicetree/bindings/mmc/mmc.txt | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 1/4] dt-bindings: Document Broadcom iProc mailbox controller driver
From: Rob Herring @ 2016-10-26 21:02 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: <1476817238-1226-2-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, Oct 18, 2016 at 12:00:35PM -0700, Jonathan Richardson wrote:
> 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>
> ---
> .../bindings/mailbox/brcm,iproc-mailbox.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.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 v6] mwifiex: parse device tree node for PCIe
From: Brian Norris @ 2016-10-26 20:56 UTC (permalink / raw)
To: Rajat Jain
Cc: Dmitry Torokhov, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xinming Hu, Amitkumar Karwar,
Brian Norris, Kalle Valo, Rob Herring, Rajat Jain
In-Reply-To: <CACK8Z6H1ACBo7nDxaXR3Vn9cPdyRqxxzdgYz7vNmojiSvjbW5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Oct 26, 2016 at 01:51:48PM -0700, Rajat Jain wrote:
> On Wed, Oct 26, 2016 at 1:46 PM, Dmitry Torokhov
> <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Oct 26, 2016 at 01:17:36PM -0700, Brian Norris wrote:
> Sorry, I just saw this... Why do we need devicetree data for
> discoverable bus (PCI)? How does the driver work on systems that do not
> use DT? Why do we need them to behave differently?
>
> There are a couple of out-of-band GPIO pins from Marvell chip that can
> serve as wake-up pins (wake up the CPU when asserted). The Marvell chip
> has to be told which GPIO pin is to be used as the wake-up pin. The pin to
> be used is system / platform dependent. (On some systems it could be
> GPIO13, on others it could be GPIO14 etc depending on how the marvell chip
> is wired up to the CPU).
There's also calibration data. See "marvell,caldata*" and
"marvell,wakeup-pin" properties. Currently only for SDIO, in
Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt, but
we're adding support for PCIe.
Brian
^ permalink raw reply
* Re: Add Allwinner Q8 tablets hardware manager
From: Rob Herring @ 2016-10-26 20:54 UTC (permalink / raw)
To: Mark Rutland, Hans de Goede
Cc: Arnd Bergmann, Greg Kroah-Hartman, Maxime Ripard, Chen-Yu Tsai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
In-Reply-To: <20161024173900.GP15620@leverpostej>
On Mon, Oct 24, 2016 at 06:39:01PM +0100, Mark Rutland wrote:
> On Fri, Oct 14, 2016 at 09:53:31AM +0200, Hans de Goede wrote:
> > Hi Rob, Mark, et al.,
>
> Hi Hans,
>
> Apologies for the delay in replying to this.
>
> I'd like to be clear that I do understand that there is a problem that
> needs to be addressed here. However, I do not believe that the *current*
> in-kernel approach is correct. More on that below.
>
> > Mark, I know that we discussed this at ELCE and you clearly indicated
> > that according to you this does not belong in the kernel. I was a bit
> > surprised by this part of the discussion.
> >
> > I had posted a RFC earlier and Rob had indicated that given that the q8
> > tablets are a special case, as my code uses actual probing rather then some
> > pre-arranged id mechanism with say an eeprom, that doing this in a
> > non-generic manner would be ok for my special case.
>
> To some extent, Rob and I may have differing views here; I'm not
> entirely sure what Rob's view is, and I cannot talk on his behalf. I
> certainly must apologise for having not commented on said RFC, however.
I've focused mainly on the bindings which I certainly had issues with
how the RFC was done. As to where this should be done, keeping all the
dirty bits in firmware/bootloader is certainly appealing. However, there
are cases where data alone can't abstract out board differences and we
need board code. Whether this is one of them, well, that is Hans' job to
convince Mark.
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 v6] mwifiex: parse device tree node for PCIe
From: Rajat Jain @ 2016-10-26 20:51 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Brian Norris, linux-wireless, devicetree, Xinming Hu,
Amitkumar Karwar, Brian Norris, Kalle Valo, Rob Herring,
Rajat Jain
In-Reply-To: <20161026204648.GD3989@dtor-ws>
[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]
On Wed, Oct 26, 2016 at 1:46 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com>
wrote:
> On Wed, Oct 26, 2016 at 01:17:36PM -0700, Brian Norris wrote:
> > Hi Rajat,
> >
> > On Fri, Oct 21, 2016 at 02:21:09PM -0700, Rajat Jain wrote:
> > > From: Xinming Hu <huxm@marvell.com>
> > >
> > > This patch derives device tree node from pcie bus layer framework, and
> > > fixes a minor memory leak in mwifiex_pcie_probe() (in failure path).
> > > Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> > > marvell-8xxx.txt) to accommodate PCIe changes.
> > >
> > > Signed-off-by: Xinming Hu <huxm@marvell.com>
> > > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > > Signed-off-by: Rajat Jain <rajatja@google.com>
> > > Reviewed-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > > v2: Included vendor and product IDs in compatible strings for PCIe
> > > chipsets(Rob Herring)
> > > v3: Patch is created using -M option so that it will only include diff
> of
> > > original and renamed files(Rob Herring)
> > > Resend v3: Resending the patch because I missed to include device tree
> mailing
> > > while sending v3.
> > > v4: Fix error handling, also move-on even if no device tree node is
> present.
> > > v5: Update commit log to include memory leak, return -EINVAL instead
> of -1.
> >
> > I've been working on reworking some bugfixes for this driver, and I
> > noticed we have some problems w.r.t. memory leaks, and the "memory leak"
> > fix is not actually a fix. See below.
>
> Sorry, I just saw this... Why do we need devicetree data for
> discoverable bus (PCI)? How does the driver work on systems that do not
> use DT? Why do we need them to behave differently?
>
There are a couple of out-of-band GPIO pins from Marvell chip that can
serve as wake-up pins (wake up the CPU when asserted). The Marvell chip has
to be told which GPIO pin is to be used as the wake-up pin. The pin to be
used is system / platform dependent. (On some systems it could be GPIO13,
on others it could be GPIO14 etc depending on how the marvell chip is wired
up to the CPU).
>
> Thanks.
>
> --
> Dmitry
>
[-- Attachment #2: Type: text/html, Size: 3155 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