* [PATCH 2/2] power: supply: bq24735: bring down the noise level
From: Peter Rosin @ 2016-12-21 21:29 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Sebastian Reichel, Rob Herring, Mark Rutland,
linux-pm, devicetree
In-Reply-To: <1482355793-16190-1-git-send-email-peda@axentia.se>
If there is no ti,ac-detect-gpios configured, it is normal to
have failed reads of the options register. So, hold back on the
log spamming.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/power/supply/bq24735-charger.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
index d8be81203837..eb0145380def 100644
--- a/drivers/power/supply/bq24735-charger.c
+++ b/drivers/power/supply/bq24735-charger.c
@@ -192,7 +192,7 @@ static bool bq24735_charger_is_present(struct bq24735 *charger)
ac = bq24735_read_word(charger->client, BQ24735_CHG_OPT);
if (ac < 0) {
- dev_err(&charger->client->dev,
+ dev_dbg(&charger->client->dev,
"Failed to read charger options : %d\n",
ac);
return false;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 2/3] ARM: dts: sun5i: add a pinctrl node for 4bit mmc2
From: Maxime Ripard @ 2016-12-21 22:40 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree, Zepan, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel
In-Reply-To: <20161221200235.11617-2-icenowy@aosc.xyz>
[-- Attachment #1.1: Type: text/plain, Size: 327 bytes --]
On Thu, Dec 22, 2016 at 04:02:34AM +0800, Icenowy Zheng wrote:
> Some board only use 4bit mode of mmc2.
>
> Add a pinctrl node for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: add vendor prefix for Lichee Pi
From: Maxime Ripard @ 2016-12-21 22:40 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree, Zepan, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel
In-Reply-To: <20161221200235.11617-1-icenowy@aosc.xyz>
[-- Attachment #1.1: Type: text/plain, Size: 460 bytes --]
On Thu, Dec 22, 2016 at 04:02:33AM +0800, Icenowy Zheng wrote:
> Lichee Pi is a new "Pi"-named development board series.
>
> Currently available device, Lichee Pi One, is by only one person as
> night job, so the device series name is chosen to be the vendor prefix.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] ARM: dts: sun5i: add support for Lichee Pi One board
From: Maxime Ripard @ 2016-12-21 22:41 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree, Zepan, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel
In-Reply-To: <20161221200235.11617-3-icenowy@aosc.xyz>
[-- Attachment #1.1: Type: text/plain, Size: 632 bytes --]
On Thu, Dec 22, 2016 at 04:02:35AM +0800, Icenowy Zheng wrote:
> Lichee Pi One is a low-cost Allwinner A13-based development board, with
> an AXP209 PMU, a USB2.0 OTG port, a USB2.0 host port (or an onboard
> RTL8723BU Wi-Fi card), optional headers for LCD and CSI, two GPIO
> headers and two MicroSD card slots (connected to mmc0 and mmc2, both
> bootable).
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] clk: hi3660: Clock driver support for Hisilicon hi3660 SoC
From: Stephen Boyd @ 2016-12-21 23:25 UTC (permalink / raw)
To: Zhangfei Gao
Cc: Rob Herring, Arnd Bergmann, guodong Xu, devicetree,
haojian.zhuang, linux-arm-kernel
In-Reply-To: <1481781493-6188-3-git-send-email-zhangfei.gao@linaro.org>
On 12/15, Zhangfei Gao wrote:
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Add some commit text here?
> diff --git a/drivers/clk/hisilicon/clk-hi3660.c b/drivers/clk/hisilicon/clk-hi3660.c
> new file mode 100644
> index 0000000..42ca47d
> --- /dev/null
> +++ b/drivers/clk/hisilicon/clk-hi3660.c
> @@ -0,0 +1,601 @@
> +/*
> + * Copyright (c) 2016-2017 Linaro Ltd.
> + * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <dt-bindings/clock/hi3660-clock.h>
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
This isn't needed.
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include "clk.h"
> +
[...]
> +
> +static int hi3660_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = pdev->dev.of_node;
> + const struct of_device_id *of_id;
> + enum hi3660_clk_type type;
> +
> + of_id = of_match_device(hi3660_clk_match_table, dev);
> + if (!of_id)
> + return -EINVAL;
> +
> + type = (enum hi3660_clk_type)of_id->data;
Use of_device_get_match_data() instead please.
> +
> + switch (type) {
> + case HI3660_CRGCTRL:
> + hi3660_clk_crgctrl_init(np);
> + break;
> + case HI3660_PCTRL:
> + hi3660_clk_pctrl_init(np);
> + break;
> + case HI3660_PMUCTRL:
> + hi3660_clk_pmuctrl_init(np);
> + break;
> + case HI3660_SCTRL:
> + hi3660_clk_sctrl_init(np);
> + break;
> + case HI3660_IOMCU:
> + hi3660_clk_iomcu_init(np);
> + break;
This "multi-device" driver design is sort of odd. Why not have
different files and struct drivers for the different devices in
the system that are clock controllers? I don't really understand
why we're controlling the devices with one struct driver
instance. Is something shared between the devices?
> + default:
> + break;
> + }
> + return 0;
> +}
[...]
> +
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hi3660-clk");
> +MODULE_DESCRIPTION("HiSilicon Hi3660 Clock Driver");
You can drop these MODULE_* things as they're not going to be
used in builtin only code.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] clk: stm32f4: Use CLK_OF_DECLARE_DRIVER initialization method
From: Stephen Boyd @ 2016-12-21 23:34 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson, andrea.merello, radoslaw.pietrzyk, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, kernel, ludovic.barre,
olivier.bideau, amelie.delaunay
In-Reply-To: <1481725348-860-1-git-send-email-gabriel.fernandez@st.com>
On 12/14, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Clock and reset controller use same compatible strings (same IP).
>
> Since commit 989eafd0b609 ("clk: core: Avoid double initialization of
> clocks") the OF core flags clock controllers registered with the
> CLK_OF_DECLARE() macro as OF_POPULATED, so platform devices with the same
> compatible string will not be registered.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
From: Stephen Boyd @ 2016-12-21 23:47 UTC (permalink / raw)
To: Markus Mayer
Cc: Michael Turquette, Rob Herring, Mark Rutland, Viresh Kumar,
Rafael J . Wysocki, Arnd Bergmann, Markus Mayer,
Broadcom Kernel List, Linux Clock List, Power Management List,
Device Tree List, ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <20161220225530.96699-2-code@mmayer.net>
On 12/20, 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 | 83 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 84 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..3bc99c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> @@ -0,0 +1,83 @@
> +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
> +- div-shift-width: least-significant bit position and width of divider value
> +
> +Optional properties:
> +- clocks: additional clocks can be specified if needed
> +- clock-names: clocks can be named, so they can be looked up
> +
> +Example:
> + sw_scb: sw_scb {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <432000000>;
> + };
> +
Is this a PLL?
> + fixed0: fixed0 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <54000000>;
> + };
And perhaps some sort of oscillator?
> +
> + cpu_pdiv: cpu_pdiv@f04e0008 {
> + compatible = "divider-clock";
> + #clock-cells = <0>;
> + reg = <0xf04e0008 0x4>;
> + bit-shift = <10>;
> + bit-mask = <0xf>;
> + index-starts-at-one;
> + clocks = <&fixed0>;
> + clock-names = "fixed0";
> + };
> +
> + cpu_ndiv_int: cpu_ndiv_int {
> + compatible = "fixed-factor-clock";
Ok..
> + #clock-cells = <0>;
> + clock-div = <1>;
> + clock-mult = <167>;
> + clocks = <&cpu_pdiv>;
> + clock-names = "cpu_pdiv";
> + };
> +
> + cpu_mdiv_ch0: cpu_mdiv_ch0@f04e0000 {
> + compatible = "divider-clock";
Is there a binding for this?
> + #clock-cells = <0>;
> + reg = <0xf04e0000 0x4>;
> + bit-shift = <1>;
> + bit-mask = <0xff>;
> + index-starts-at-one;
> + clocks = <&cpu_ndiv_int>;
> + clock-names = "cpu_ndiv_int";
> + };
> +
> + cpupll: cpupll@0 {
> + #clock-cells = <0>;
> + clock-frequency = <1503000000>;
> + compatible = "fixed-clock";
> + };
> +
> + cpuclkdiv: cpu-clk-div@0 {
Wrong unit address. Should be f03e257c?
> + #clock-cells = <0>;
> + clock-names = "cpupll",
> + "cpu_mdiv_ch0",
> + "cpu_ndiv_int",
> + "sw_scb";
> + clocks = <&cpupll,
> + &cpu_mdiv_ch0,
> + &cpu_ndiv_int,
> + &sw_scb>;
> + compatible = "brcm,brcmstb-cpu-clk-div";
> + reg = <0xf03e257c 0x4>;
> + div-table = <0x00 1>;
> + div-shift-width = <0 5>;
This entire DT design seems wrong. We don't put these sorts of
register level details into DT. There should be a driver that
knows the type of device that is present and how to drive that
hardware.
>From what I can tell there's something like a mux controller at
0xf04e0000 and then there's some sort of divider controller at
0xf03e0000. Perhaps those are two different devices that need
independent drivers? My wild guess is the PLL control is in those
register regions too, but we're not exposing control of them.
That's ok, but don't put the PLL into the DT as a fixed clock.
Just register it from the driver.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH net-next 00/10] netcp: enhancements and minor fixes
From: Murali Karicheri @ 2016-12-21 23:50 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-omap, grygorii.strashko, mugunthanvnm, linux-kernel,
arnd, devicetree, mark.rutland, robh+dt
In-Reply-To: <20161220.190315.439054497576758011.davem@davemloft.net>
David,
On 12/20/2016 07:03 PM, David Miller wrote:
>
> The net-next tree is not open, do not resubmit this series until it
> is open again.
>
> Thanks.
>
Ok. Thanks
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Re: [PATCH v4 6/6] clk: qcom: ipq4019: Add the cpu clock frequency change notifier
From: Stephen Boyd @ 2016-12-21 23:56 UTC (permalink / raw)
To: Abhishek Sahu
Cc: andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
mturquette-rdvid1DuHRBWk0Htik3J/w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, varada-sgV2jX0FEOL9JmXXK+q4OQ,
pradeepb-sgV2jX0FEOL9JmXXK+q4OQ, snlakshm-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480088493-4590-7-git-send-email-absahu-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 11/25, Abhishek Sahu wrote:
> @@ -1736,13 +1737,55 @@ static int clk_cpu_div_set_rate(struct clk_hw *hw, unsigned long rate,
> };
> MODULE_DEVICE_TABLE(of, gcc_ipq4019_match_table);
>
> +/* Contains index for safe clock during APSS freq change */
> +static int gcc_ipq4019_cpu_safe_parent;
> +static int
> +gcc_ipq4019_cpu_clk_notifier_fn(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + int err = 0;
> +
> + if (action == PRE_RATE_CHANGE)
> + err = clk_rcg2_ops.set_parent(&apps_clk_src.clkr.hw,
> + gcc_ipq4019_cpu_safe_parent);
Why can't we hardcode this? It's not like this safe parent is
going to change across boards.
> +
> + return notifier_from_errno(err);
> +}
> +
> +static struct notifier_block gcc_ipq4019_cpu_clk_notifier = {
> + .notifier_call = gcc_ipq4019_cpu_clk_notifier_fn,
> +};
> +
> static int gcc_ipq4019_probe(struct platform_device *pdev)
> {
> - return qcom_cc_probe(pdev, &gcc_ipq4019_desc);
> + int err;
> +
> + err = qcom_cc_probe(pdev, &gcc_ipq4019_desc);
> + if (err)
> + return err;
> +
> + gcc_ipq4019_cpu_safe_parent = qcom_find_src_index(&apps_clk_src.clkr.hw,
> + apps_clk_src.parent_map,
> + P_FEPLL500);
> + if (gcc_ipq4019_cpu_safe_parent < 0)
> + err = gcc_ipq4019_cpu_safe_parent;
Then we don't need to do this.
> +
> + if (!err)
> + err = clk_notifier_register(apps_clk_src.clkr.hw.clk,
> + &gcc_ipq4019_cpu_clk_notifier);
> +
> + return err;
> +}
> +
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/6] clk: qcom: ipq4019: remove fixed clocks and add pll clocks
From: Stephen Boyd @ 2016-12-21 23:57 UTC (permalink / raw)
To: Abhishek Sahu
Cc: andy.gross, david.brown, mturquette, robh+dt, mark.rutland,
varada, pradeepb, snlakshm, linux-arm-msm, linux-soc, linux-clk,
linux-kernel, devicetree
In-Reply-To: <1480088493-4590-2-git-send-email-absahu@codeaurora.org>
On 11/25, Abhishek Sahu wrote:
> The current ipq4019 clock driver registered the PLL clocks and
> dividers as fixed clock. These fixed clock needs to be removed
> from driver probe function and same need to be registered with
> clock framework. These PLL clocks should be programmed only
> once and the same are being programmed already by the boot
> loader so the set rate operation is not required for these
> clocks. Only the rate can be calculated by clock operations
> in clock driver file so this patch adds the same.
>
> The PLL takes the reference clock from XO and generates the
> intermediate VCO frequency. This VCO frequency will be divided
> down by different PLL internal dividers. Some of the PLL
> internal dividers are fixed while other are programmable.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-ipq4019 and merged into clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 2/6] clk: qcom: ipq4019: Add the apss cpu pll divider clock node
From: Stephen Boyd @ 2016-12-21 23:57 UTC (permalink / raw)
To: Abhishek Sahu
Cc: andy.gross, david.brown, mturquette, robh+dt, mark.rutland,
varada, pradeepb, snlakshm, linux-arm-msm, linux-soc, linux-clk,
linux-kernel, devicetree
In-Reply-To: <1480088493-4590-3-git-send-email-absahu@codeaurora.org>
On 11/25, Abhishek Sahu wrote:
> The current ipq4019 clock driver does not have support for all
> the frequency supported by APSS CPU. APSS CPU frequency is
> provided with APSS CPU PLL divider which divides down the VCO
> frequency. This divider is nonlinear and specific to IPQ4019
> so the standard divider code cannot be used for this.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-ipq4019 and merged into clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 3/6] clk: qcom: ipq4019: Add the nodes for pcnoc
From: Stephen Boyd @ 2016-12-21 23:57 UTC (permalink / raw)
To: Abhishek Sahu
Cc: andy.gross, david.brown, mturquette, robh+dt, mark.rutland,
varada, pradeepb, snlakshm, linux-arm-msm, linux-soc, linux-clk,
linux-kernel, devicetree
In-Reply-To: <1480088493-4590-4-git-send-email-absahu@codeaurora.org>
On 11/25, Abhishek Sahu wrote:
> The current ipq4019 clock driver does not have the node for
> PCNOC so this patch adds and registers the PCNOC clock nodes.
> This PCNOC clock is critical and should not be turned off so
> setting CRITICAL flag also.
>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
Applied to clk-ipq4019 and merged into clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2] clk: qcom: smd-rpmcc: Add msm8974 clocks
From: Stephen Boyd @ 2016-12-22 0:04 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, Michael Turquette,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA, Georgi Djakov
In-Reply-To: <20161121161808.5kebw6r5lxnepqau@rob-hp-laptop>
On 11/21, Rob Herring wrote:
> On Fri, Nov 18, 2016 at 08:33:25AM -0800, Bjorn Andersson wrote:
> > This adds all RPM based clocks for msm8974, except cxo and
> > gfx3d_clk_src.
> >
> > Tested-by: Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
Applied to clk-qcom-rpm8974 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] ARM: dts: sun5i: add support for Lichee Pi One board
From: Icenowy Zheng @ 2016-12-22 0:07 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree@vger.kernel.org, Zepan, linux-kernel@vger.kernel.org,
Chen-Yu Tsai, Rob Herring, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161221224159.wnziqeanjkp63y4o@lukather>
22.12.2016, 06:42, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Thu, Dec 22, 2016 at 04:02:35AM +0800, Icenowy Zheng wrote:
>> Lichee Pi One is a low-cost Allwinner A13-based development board, with
>> an AXP209 PMU, a USB2.0 OTG port, a USB2.0 host port (or an onboard
>> RTL8723BU Wi-Fi card), optional headers for LCD and CSI, two GPIO
>> headers and two MicroSD card slots (connected to mmc0 and mmc2, both
>> bootable).
>>
>> Add support for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Excuse me. Who should apply it?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/9] clk: stm32f4: Update DT bindings documentation
From: Stephen Boyd @ 2016-12-22 0:10 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson, andrea.merello, radoslaw.pietrzyk, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, kernel, ludovic.barre,
olivier.bideau, amelie.delaunay
In-Reply-To: <1481638820-29324-2-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Creation of dt include file for specific stm32f4 clocks.
> These specific clocks are not derived from system clock (SYSCLOCK)
> We should use index 1 to use these clocks in DT.
> e.g. <&rcc 1 CLK_LSI>
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-stm32f4 and merged into clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 2/9] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Stephen Boyd @ 2016-12-22 0:10 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson, andrea.merello, radoslaw.pietrzyk, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, kernel, ludovic.barre,
olivier.bideau, amelie.delaunay
In-Reply-To: <1481638820-29324-3-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces PLL_I2S and PLL_SAI.
> Vco clock of these PLLs can be modify by DT (only n multiplicator,
> m divider is still fixed by the boot-loader).
> Each PLL has 3 dividers. PLL should be off when we modify the rate.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 3/9] clk: stm32f4: Add post divisor for I2S & SAI PLLs
From: Stephen Boyd @ 2016-12-22 0:11 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Mark Rutland, devicetree, daniel.thompson, radoslaw.pietrzyk,
Alexandre Torgue, Arnd Bergmann, Nicolas Pitre, andrea.merello,
Michael Turquette, olivier.bideau, Russell King, linux-kernel,
Rob Herring, ludovic.barre, Maxime Coquelin, amelie.delaunay,
linux-clk, linux-arm-kernel, kernel
In-Reply-To: <1481638820-29324-4-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch adds post dividers of I2S & SAI PLLs.
> These dividers are managed by a dedicated register (RCC_DCKCFGR).
> The PLL should be off before a set rate.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 4/9] clk: stm32f4: Add lcd-tft clock
From: Stephen Boyd @ 2016-12-22 0:11 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson, andrea.merello, radoslaw.pietrzyk, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, kernel, ludovic.barre,
olivier.bideau, amelie.delaunay
In-Reply-To: <1481638820-29324-5-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces lcd-tft clock for stm32f4 soc.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 5/9] clk: stm32f4: Add I2S clock
From: Stephen Boyd @ 2016-12-22 0:11 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson, andrea.merello, radoslaw.pietrzyk, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, kernel, ludovic.barre,
olivier.bideau, amelie.delaunay
In-Reply-To: <1481638820-29324-6-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces I2S clock for stm32f4 soc.
> The I2S clock could be derived from an external clock or from pll-i2s
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 6/9] clk: stm32f4: Add SAI clocks
From: Stephen Boyd @ 2016-12-22 0:11 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson, andrea.merello, radoslaw.pietrzyk, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, kernel, ludovic.barre,
olivier.bideau, amelie.delaunay
In-Reply-To: <1481638820-29324-7-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces SAI clocks for stm32f4 socs.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 7/9] clk: stm32f4: SDIO & 48Mhz clock management for STM32F469 board
From: Stephen Boyd @ 2016-12-22 0:11 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson, andrea.merello, radoslaw.pietrzyk, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, kernel, ludovic.barre,
olivier.bideau, amelie.delaunay
In-Reply-To: <1481638820-29324-8-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> In the stm32f469 soc, the 48Mhz clock could be derived from pll-q or
> from pll-sai-p.
>
> The SDIO clock could be also derived from 48Mhz or from sys clock.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCHv2 1/3] dt-bindings: arm: update Armada CP110 system controller binding
From: Stephen Boyd @ 2016-12-22 0:14 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Mark Rutland, Andrew Lunn, Yehuda Yitschak, Jason Cooper,
Pawel Moll, devicetree, Michael Turquette, Ian Campbell,
Nadav Haklai, Rob Herring, Kumar Gala, Gregory Clement,
Hanna Hawa, linux-clk, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <1482316017-22154-2-git-send-email-thomas.petazzoni@free-electrons.com>
On 12/21, Thomas Petazzoni wrote:
> It turns out that in the CP110 HW block present in Marvell Armada
> 7K/8K SoCs, gatable clock n°18 not only controls SD/MMC, but also the
> GOP block. This commit updates the Device Tree binding for this piece
> of hardware accordingly.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCHv2 2/3] clk: mvebu: adjust clock handling for the CP110 system controller
From: Stephen Boyd @ 2016-12-22 0:14 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Mark Rutland, Andrew Lunn, Yehuda Yitschak, Jason Cooper,
Pawel Moll, devicetree, Michael Turquette, Ian Campbell,
Nadav Haklai, Rob Herring, Kumar Gala, Gregory Clement,
Hanna Hawa, linux-clk, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <1482316017-22154-3-git-send-email-thomas.petazzoni@free-electrons.com>
On 12/21, Thomas Petazzoni wrote:
> This commit:
>
> - makes the GOP_DP (bit 9) gatable clock a child clock of the
> SD_MMC_GOP (bit 18) clock, as it should have been. The clock for bit
> 18 was just named SD_MMC, but since it also covers the GOP block, it
> is renamed SD_MMC_GOP.
>
> - makes the MG (bit 5) gatable clock a child clock of the MG_CORE
> clock (bit 6)
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [RESEND PATCH v2] arm64: dts: rockchip: add u2phy clock for ehci and ohci of rk3399
From: Doug Anderson @ 2016-12-22 0:47 UTC (permalink / raw)
To: Xing Zheng
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
zhangqing, Heiko Stübner, Frank Wang, Catalin Marinas,
Shawn Lin, Brian Norris, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Rob Herring, David Wu, wulf,
Jianqun,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Caesar
In-Reply-To: <1482316865-2769-1-git-send-email-zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi,
On Wed, Dec 21, 2016 at 2:41 AM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> From: William wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> We found that the suspend process was blocked when it run into
> ehci/ohci module due to clk-480m of usb2-phy was disabled.
>
> The root cause is that usb2-phy suspended earlier than ehci/ohci
> (usb2-phy will be auto suspended if no devices plug-in). and the
> clk-480m provided by it was disabled if no module used. However,
> some suspend process related ehci/ohci are base on this clock,
> so we should refer it into ehci/ohci driver to prevent this case.
>
> The u2phy clock flow like this:
> ===
> u2phy ________________
> | | |-----> UTMI_CLK ---------> | EHCI |
> OSC_24M ---|---> PHY_PLL----|----|
> |________^_______| |-----> 480M_CLK ---|G|---> | USBPHY_480M_SRC| ----> USBPHY_480M for SoC
> |
> |
> GRF
> ===
>
> Signed-off-by: William wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Changes in v2:
> - update the commit message
> - remove patches whic add and export the USBPHYx_480M_SRC clock IDs
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 28 ++++++++++++++++++++--------
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index b65c193..2ad9255 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -315,8 +315,10 @@
> compatible = "generic-ehci";
> reg = <0x0 0xfe380000 0x0 0x20000>;
> interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>;
> - clock-names = "hclk_host0", "hclk_host0_arb";
> + clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
> + <&u2phy0>;
> + clock-names = "usbhost", "arbiter",
> + "utmi";
> phys = <&u2phy0_host>;
> phy-names = "usb";
> status = "disabled";
> @@ -326,8 +328,12 @@
> compatible = "generic-ohci";
> reg = <0x0 0xfe3a0000 0x0 0x20000>;
> interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>;
> - clock-names = "hclk_host0", "hclk_host0_arb";
> + clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
> + <&u2phy0>;
> + clock-names = "usbhost", "arbiter",
> + "utmi";
> + phys = <&u2phy0_host>;
> + phy-names = "usb";
> status = "disabled";
> };
>
> @@ -335,8 +341,10 @@
> compatible = "generic-ehci";
> reg = <0x0 0xfe3c0000 0x0 0x20000>;
> interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>;
> - clock-names = "hclk_host1", "hclk_host1_arb";
> + clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>,
> + <&u2phy1>;
> + clock-names = "usbhost", "arbiter",
> + "utmi";
> phys = <&u2phy1_host>;
> phy-names = "usb";
> status = "disabled";
> @@ -346,8 +354,12 @@
> compatible = "generic-ohci";
> reg = <0x0 0xfe3e0000 0x0 0x20000>;
> interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>;
> - clock-names = "hclk_host1", "hclk_host1_arb";
> + clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>,
> + <&u2phy1>;
> + clock-names = "usbhost", "arbiter",
> + "utmi";
> + phys = <&u2phy1_host>;
> + phy-names = "usb";
This all looks better to me. From a device tree point of view it
makes lots of sense to expose this PHY clock to the controller. Thus:
Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
I can't say that I understand all the interactions between the PHY
code and the USB driver, but presumably others have reviewed that
more? Offline Heiko pointed me at rockchip_usb2phy_otg_sm_work()
which apparently calls rockchip_usb2phy_power_off() and
rockchip_usb2phy_power_on() directly sometimes behind the back of the
PHY framework. Very strange.
I will also say that there were still some unanswered questions from
the previous thread, namely:
A) Heiko: Also, with the change, the ehci will keep the clock (and
thus the phy) always on. Does the phy-autosuspend even save anything
now?
B) Brian: Is thre a race between power_off() and the delayed work in
your USB2 PHY driver?
IMHO neither of those two questions affect the correctness of this
patch: that this clock ought to be provided to the USB Controller.
...but they both are important questions that should be answered.
One other last note is that we probably should be specifying a more
specific compatible string, like:
"rk3399-ehci", "generic-ehci"
That will allow us later to use these same device tree files and
perhaps deal with the clocks / PHYs in a more efficient way.
-Doug
^ permalink raw reply
* Re: [RESEND PATCH v2] arm64: dts: rockchip: add u2phy clock for ehci and ohci of rk3399
From: Xing Zheng @ 2016-12-22 1:15 UTC (permalink / raw)
To: Doug Anderson
Cc: Heiko Stübner, open list:ARM/Rockchip SoC..., Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Caesar, Shawn Lin,
Brian Norris, Jianqun, zhangqing, David Wu, wulf,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Frank Wang
In-Reply-To: <CAD=FV=WFFGSc7yBeaE+++VAuRKwMixpGUwA9bCCro4TCe0+GAA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Doug,
在 2016年12月22日 08:47, Doug Anderson 写道:
> Hi,
>
> On Wed, Dec 21, 2016 at 2:41 AM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
>> From: William wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>
>> We found that the suspend process was blocked when it run into
>> ehci/ohci module due to clk-480m of usb2-phy was disabled.
>>
>> The root cause is that usb2-phy suspended earlier than ehci/ohci
>> (usb2-phy will be auto suspended if no devices plug-in). and the
>> clk-480m provided by it was disabled if no module used. However,
>> some suspend process related ehci/ohci are base on this clock,
>> so we should refer it into ehci/ohci driver to prevent this case.
>>
>> The u2phy clock flow like this:
>> ===
>> u2phy ________________
>> | | |-----> UTMI_CLK ---------> | EHCI |
>> OSC_24M ---|---> PHY_PLL----|----|
>> |________^_______| |-----> 480M_CLK ---|G|---> | USBPHY_480M_SRC| ----> USBPHY_480M for SoC
>> |
>> |
>> GRF
>> ===
>>
>> Signed-off-by: William wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> Signed-off-by: Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> ---
>>
>> Changes in v2:
>> - update the commit message
>> - remove patches whic add and export the USBPHYx_480M_SRC clock IDs
>>
>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 28 ++++++++++++++++++++--------
>> 1 file changed, 20 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> index b65c193..2ad9255 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -315,8 +315,10 @@
>> compatible = "generic-ehci";
>> reg = <0x0 0xfe380000 0x0 0x20000>;
>> interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH 0>;
>> - clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>;
>> - clock-names = "hclk_host0", "hclk_host0_arb";
>> + clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
>> + <&u2phy0>;
>> + clock-names = "usbhost", "arbiter",
>> + "utmi";
>> phys = <&u2phy0_host>;
>> phy-names = "usb";
>> status = "disabled";
>> @@ -326,8 +328,12 @@
>> compatible = "generic-ohci";
>> reg = <0x0 0xfe3a0000 0x0 0x20000>;
>> interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>;
>> - clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>;
>> - clock-names = "hclk_host0", "hclk_host0_arb";
>> + clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
>> + <&u2phy0>;
>> + clock-names = "usbhost", "arbiter",
>> + "utmi";
>> + phys = <&u2phy0_host>;
>> + phy-names = "usb";
>> status = "disabled";
>> };
>>
>> @@ -335,8 +341,10 @@
>> compatible = "generic-ehci";
>> reg = <0x0 0xfe3c0000 0x0 0x20000>;
>> interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH 0>;
>> - clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>;
>> - clock-names = "hclk_host1", "hclk_host1_arb";
>> + clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>,
>> + <&u2phy1>;
>> + clock-names = "usbhost", "arbiter",
>> + "utmi";
>> phys = <&u2phy1_host>;
>> phy-names = "usb";
>> status = "disabled";
>> @@ -346,8 +354,12 @@
>> compatible = "generic-ohci";
>> reg = <0x0 0xfe3e0000 0x0 0x20000>;
>> interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH 0>;
>> - clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>;
>> - clock-names = "hclk_host1", "hclk_host1_arb";
>> + clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>,
>> + <&u2phy1>;
>> + clock-names = "usbhost", "arbiter",
>> + "utmi";
>> + phys = <&u2phy1_host>;
>> + phy-names = "usb";
> This all looks better to me. From a device tree point of view it
> makes lots of sense to expose this PHY clock to the controller. Thus:
>
> Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>
>
> I can't say that I understand all the interactions between the PHY
> code and the USB driver, but presumably others have reviewed that
> more? Offline Heiko pointed me at rockchip_usb2phy_otg_sm_work()
> which apparently calls rockchip_usb2phy_power_off() and
> rockchip_usb2phy_power_on() directly sometimes behind the back of the
> PHY framework. Very strange.
>
>
> I will also say that there were still some unanswered questions from
> the previous thread, namely:
>
> A) Heiko: Also, with the change, the ehci will keep the clock (and
> thus the phy) always on. Does the phy-autosuspend even save anything
> now?
>
> B) Brian: Is thre a race between power_off() and the delayed work in
> your USB2 PHY driver?
>
>
> IMHO neither of those two questions affect the correctness of this
> patch: that this clock ought to be provided to the USB Controller.
> ...but they both are important questions that should be answered.
>
> One other last note is that we probably should be specifying a more
> specific compatible string, like:
>
> "rk3399-ehci", "generic-ehci"
>
> That will allow us later to use these same device tree files and
> perhaps deal with the clocks / PHYs in a more efficient way.
>
>
> -Doug
>
I will *ping* Frank and William to answer your questions until they
finish the business travel.
Thanks.
--
- Xing Zheng
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox