* [PATCH v6 0/2] Add a new Rockchip usb2 phy driver @ 2016-06-17 2:09 Frank Wang 2016-06-17 2:09 ` [PATCH v6 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY Frank Wang 2016-06-17 2:09 ` [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy Frank Wang 0 siblings, 2 replies; 13+ messages in thread From: Frank Wang @ 2016-06-17 2:09 UTC (permalink / raw) To: heiko, dianders, linux, groeck, jwerner, kishon, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak Cc: linux-kernel, devicetree, linux-usb, linux-rockchip, xzy.xu, kever.yang, huangtao, william.wu, frank.wang The newer SoCs (rk3366, rk3399) of Rock-chip take a different usb-phy IP block than rk3288 and before, and most of phy-related registers are also different from the past, so a new phy driver is required necessarily. These series patches add phy-rockchip-inno-usb2.c and the corresponding documentation. Changes in v6: - Changed '_' to '-' for otg-id and otg-bvalid property in devicetree bindings. - Fixed the output clock would be disabled more than once while phy-port was going to suspend. - Improved the driver to avoid the currently empty otg-port would cause null-pointer dereferences. Changes in v5: - Added 'reg' property both in devicetree bindings and driver to match the different phy-blocks. Changes in v4: - Used 'phy-supply' instead of 'vbus_*-supply'. Changes in v3: - Supplemented some hardware-description into the devicetree bindings. - Resolved the mapping defect between fixed value in driver and the property in devicetree. - Code cleanup. Changes in v2: - Specified more hardware-description into the devicetree bindings. - Optimized some process of driver. Frank Wang (2): Documentation: bindings: add DT documentation for Rockchip USB2PHY phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy .../bindings/phy/phy-rockchip-inno-usb2.txt | 64 ++ drivers/phy/Kconfig | 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-rockchip-inno-usb2.c | 655 ++++++++++++++++++++ 4 files changed, 727 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c -- 1.7.9.5 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v6 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY 2016-06-17 2:09 [PATCH v6 0/2] Add a new Rockchip usb2 phy driver Frank Wang @ 2016-06-17 2:09 ` Frank Wang 2016-06-17 2:09 ` [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy Frank Wang 1 sibling, 0 replies; 13+ messages in thread From: Frank Wang @ 2016-06-17 2:09 UTC (permalink / raw) To: heiko, dianders, linux, groeck, jwerner, kishon, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak Cc: linux-kernel, devicetree, linux-usb, linux-rockchip, xzy.xu, kever.yang, huangtao, william.wu, frank.wang Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> --- Changes in v6: - Changed '_' to '-' for otg-id and otg-bvalid property. Changes in v5: - Added 'reg' property to identify the different phy-blocks. Changes in v4: - Used 'phy-supply' instead of 'vbus_*-supply'. Changes in v3: - Added 'clocks' and 'clock-names' optional properties. - Specified 'otg-port' and 'host-port' as the sub-node name. Changes in v2: - Changed vbus_host optional property from gpio to regulator. - Specified vbus_otg-supply optional property. - Specified otg_id and otg_bvalid property. .../bindings/phy/phy-rockchip-inno-usb2.txt | 64 ++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt new file mode 100644 index 0000000..3c29c77 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt @@ -0,0 +1,64 @@ +ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK + +Required properties (phy (parent) node): + - compatible : should be one of the listed compatibles: + * "rockchip,rk3366-usb2phy" + * "rockchip,rk3399-usb2phy" + - reg : the address offset of grf for usb-phy configuration. + - #clock-cells : should be 0. + - clock-output-names : specify the 480m output clock name. + +Optional properties: + - clocks : phandle + phy specifier pair, for the input clock of phy. + - clock-names : input clock name of phy, must be "phyclk". + +Required nodes : a sub-node is required for each port the phy provides. + The sub-node name is used to identify host or otg port, + and shall be the following entries: + * "otg-port" : the name of otg port. + * "host-port" : the name of host port. + +Required properties (port (child) node): + - #phy-cells : must be 0. See ./phy-bindings.txt for details. + - interrupts : specify an interrupt for each entry in interrupt-names. + - interrupt-names : a list which shall be the following entries: + * "otg-id" : for the otg id interrupt. + * "otg-bvalid" : for the otg vbus interrupt. + * "linestate" : for the host/otg linestate interrupt. + +Optional properties: + - phy-supply : phandle to a regulator that provides power to VBUS. + See ./phy-bindings.txt for details. + +Example: + +grf: syscon@ff770000 { + compatible = "rockchip,rk3366-grf", "syscon", "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + +... + + u2phy: usb2-phy@700 { + compatible = "rockchip,rk3366-usb2phy"; + reg = <0x700 0x2c>; + #clock-cells = <0>; + clock-output-names = "sclk_otgphy0_480m"; + + u2phy_otg: otg-port { + #phy-cells = <0>; + interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "otg-id", "otg-bvalid", "linestate"; + status = "okay"; + }; + + u2phy_host: host-port { + #phy-cells = <0>; + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "linestate"; + status = "okay"; + }; + }; +}; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-17 2:09 [PATCH v6 0/2] Add a new Rockchip usb2 phy driver Frank Wang 2016-06-17 2:09 ` [PATCH v6 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY Frank Wang @ 2016-06-17 2:09 ` Frank Wang 2016-06-17 4:59 ` Guenter Roeck 1 sibling, 1 reply; 13+ messages in thread From: Frank Wang @ 2016-06-17 2:09 UTC (permalink / raw) To: heiko, dianders, linux, groeck, jwerner, kishon, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak Cc: linux-kernel, devicetree, linux-usb, linux-rockchip, xzy.xu, kever.yang, huangtao, william.wu, frank.wang The newer SoCs (rk3366, rk3399) take a different usb-phy IP block than rk3288 and before, and most of phy-related registers are also different from the past, so a new phy driver is required necessarily. Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Suggested-by: Guenter Roeck <linux@roeck-us.net> Suggested-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> --- Changes in v6: - Fixed the output clock would be disabled more than once while phy-port was going to suspend. - Improved the driver to avoid the currently empty otg-port would cause null-pointer dereferences. Changes in v5: - Added 'reg' in the data block to match the different phy-blocks in dt. Changes in v4: - Removed some processes related to 'vbus_host-supply'. Changes in v3: - Resolved the mapping defect between fixed value in driver and the property in devicetree. - Optimized 480m output clock register function. - Code cleanup. Changes in v2: - Changed vbus_host operation from gpio to regulator in *_probe. - Improved the fault treatment relate to 480m clock register. - Cleaned up some meaningless codes in *_clk480m_disable. - made more clear the comment of *_sm_work. drivers/phy/Kconfig | 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-rockchip-inno-usb2.c | 655 ++++++++++++++++++++++++++++++++++ 3 files changed, 663 insertions(+) create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index b869b98..29ef15c 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -347,6 +347,13 @@ config PHY_ROCKCHIP_USB help Enable this to support the Rockchip USB 2.0 PHY. +config PHY_ROCKCHIP_INNO_USB2 + tristate "Rockchip INNO USB2PHY Driver" + depends on ARCH_ROCKCHIP && OF + select GENERIC_PHY + help + Support for Rockchip USB2.0 PHY with Innosilicon IP block. + config PHY_ROCKCHIP_EMMC tristate "Rockchip EMMC PHY Driver" depends on ARCH_ROCKCHIP && OF diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index 9c3e73c..4963fbc 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o +obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c new file mode 100644 index 0000000..2ce3259 --- /dev/null +++ b/drivers/phy/phy-rockchip-inno-usb2.c @@ -0,0 +1,655 @@ +/* + * Rockchip USB2.0 PHY with Innosilicon IP block driver + * + * Copyright (C) 2016 Fuzhou Rockchip Electronics 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/clk.h> +#include <linux/clk-provider.h> +#include <linux/delay.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/gpio/consumer.h> +#include <linux/jiffies.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/of_irq.h> +#include <linux/of_platform.h> +#include <linux/phy/phy.h> +#include <linux/platform_device.h> +#include <linux/regmap.h> +#include <linux/mfd/syscon.h> + +#define BIT_WRITEABLE_SHIFT 16 +#define SCHEDULE_DELAY (60 * HZ) + +enum rockchip_usb2phy_port_id { + USB2PHY_PORT_OTG, + USB2PHY_PORT_HOST, + USB2PHY_NUM_PORTS, +}; + +enum rockchip_usb2phy_host_state { + PHY_STATE_HS_ONLINE = 0, + PHY_STATE_DISCONNECT = 1, + PHY_STATE_HS_CONNECT = 2, + PHY_STATE_FS_CONNECT = 4, +}; + +struct usb2phy_reg { + unsigned int offset; + unsigned int bitend; + unsigned int bitstart; + unsigned int disable; + unsigned int enable; +}; + +/** + * struct rockchip_usb2phy_port_cfg: usb-phy port configuration. + * @phy_sus: phy suspend register. + * @ls_det_en: linestate detection enable register. + * @ls_det_st: linestate detection state register. + * @ls_det_clr: linestate detection clear register. + * @utmi_ls: utmi linestate state register. + * @utmi_hstdet: utmi host disconnect register. + */ +struct rockchip_usb2phy_port_cfg { + struct usb2phy_reg phy_sus; + struct usb2phy_reg ls_det_en; + struct usb2phy_reg ls_det_st; + struct usb2phy_reg ls_det_clr; + struct usb2phy_reg utmi_ls; + struct usb2phy_reg utmi_hstdet; +}; + +/** + * struct rockchip_usb2phy_cfg: usb-phy configuration. + * @reg: the address offset of grf for usb-phy config. + * @num_ports: specify how many ports that the phy has. + * @clkout_ctl: keep on/turn off output clk of phy. + */ +struct rockchip_usb2phy_cfg { + unsigned int reg; + unsigned int num_ports; + struct usb2phy_reg clkout_ctl; + const struct rockchip_usb2phy_port_cfg port_cfgs[USB2PHY_NUM_PORTS]; +}; + +/** + * struct rockchip_usb2phy_port: usb-phy port data. + * @port_id: flag for otg port or host port. + * @suspended: phy suspended flag. + * @ls_irq: IRQ number assigned for linestate detection. + * @mutex: for register updating in sm_work. + * @sm_work: OTG state machine work. + * @phy_cfg: port register configuration, assigned by driver data. + */ +struct rockchip_usb2phy_port { + struct phy *phy; + unsigned int port_id; + bool suspended; + int ls_irq; + struct mutex mutex; + struct delayed_work sm_work; + const struct rockchip_usb2phy_port_cfg *port_cfg; +}; + +/** + * struct rockchip_usb2phy: usb2.0 phy driver data. + * @grf: General Register Files regmap. + * @clk: clock struct of phy input clk. + * @clk480m: clock struct of phy output clk. + * @clk_hw: clock struct of phy output clk management. + * @phy_cfg: phy register configuration, assigned by driver data. + * @ports: phy port instance. + */ +struct rockchip_usb2phy { + struct device *dev; + struct regmap *grf; + struct clk *clk; + struct clk *clk480m; + struct clk_hw clk480m_hw; + const struct rockchip_usb2phy_cfg *phy_cfg; + struct rockchip_usb2phy_port ports[USB2PHY_NUM_PORTS]; +}; + +static inline int property_enable(struct rockchip_usb2phy *rphy, + const struct usb2phy_reg *reg, bool en) +{ + unsigned int val, mask, tmp; + + tmp = en ? reg->enable : reg->disable; + mask = GENMASK(reg->bitend, reg->bitstart); + val = (tmp << reg->bitstart) | (mask << BIT_WRITEABLE_SHIFT); + + return regmap_write(rphy->grf, reg->offset, val); +} + +static inline bool property_enabled(struct rockchip_usb2phy *rphy, + const struct usb2phy_reg *reg) +{ + int ret; + unsigned int tmp, orig; + unsigned int mask = GENMASK(reg->bitend, reg->bitstart); + + ret = regmap_read(rphy->grf, reg->offset, &orig); + if (ret) + return false; + + tmp = (orig & mask) >> reg->bitstart; + return tmp == reg->enable; +} + +static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw) +{ + struct rockchip_usb2phy *rphy = + container_of(hw, struct rockchip_usb2phy, clk480m_hw); + int ret; + + /* turn on 480m clk output if it is off */ + if (!property_enabled(rphy, &rphy->phy_cfg->clkout_ctl)) { + ret = property_enable(rphy, &rphy->phy_cfg->clkout_ctl, true); + if (ret) + return ret; + + /* waitting for the clk become stable */ + mdelay(1); + } + + return 0; +} + +static void rockchip_usb2phy_clk480m_disable(struct clk_hw *hw) +{ + struct rockchip_usb2phy *rphy = + container_of(hw, struct rockchip_usb2phy, clk480m_hw); + + /* turn off 480m clk output */ + property_enable(rphy, &rphy->phy_cfg->clkout_ctl, false); +} + +static int rockchip_usb2phy_clk480m_enabled(struct clk_hw *hw) +{ + struct rockchip_usb2phy *rphy = + container_of(hw, struct rockchip_usb2phy, clk480m_hw); + + return property_enabled(rphy, &rphy->phy_cfg->clkout_ctl); +} + +static unsigned long +rockchip_usb2phy_clk480m_recalc_rate(struct clk_hw *hw, + unsigned long parent_rate) +{ + return 480000000; +} + +static const struct clk_ops rockchip_usb2phy_clkout_ops = { + .enable = rockchip_usb2phy_clk480m_enable, + .disable = rockchip_usb2phy_clk480m_disable, + .is_enabled = rockchip_usb2phy_clk480m_enabled, + .recalc_rate = rockchip_usb2phy_clk480m_recalc_rate, +}; + +static void rockchip_usb2phy_clk480m_unregister(void *data) +{ + struct rockchip_usb2phy *rphy = data; + + of_clk_del_provider(rphy->dev->of_node); + clk_unregister(rphy->clk480m); + + if (rphy->clk) + clk_put(rphy->clk); +} + +static int +rockchip_usb2phy_clk480m_register(struct rockchip_usb2phy *rphy) +{ + struct device_node *node = rphy->dev->of_node; + struct clk_init_data init; + const char *clk_name; + int ret; + + init.flags = 0; + init.name = "clk_usbphy_480m"; + init.ops = &rockchip_usb2phy_clkout_ops; + + /* optional override of the clockname */ + of_property_read_string(node, "clock-output-names", &init.name); + + rphy->clk = of_clk_get_by_name(node, "phyclk"); + if (IS_ERR(rphy->clk)) { + rphy->clk = NULL; + init.parent_names = NULL; + init.num_parents = 0; + } else { + clk_name = __clk_get_name(rphy->clk); + init.parent_names = &clk_name; + init.num_parents = 1; + } + + rphy->clk480m_hw.init = &init; + + /* register the clock */ + rphy->clk480m = clk_register(rphy->dev, &rphy->clk480m_hw); + if (IS_ERR(rphy->clk480m)) { + ret = PTR_ERR(rphy->clk480m); + goto err_register; + } + + ret = of_clk_add_provider(node, of_clk_src_simple_get, rphy->clk480m); + if (ret < 0) + goto err_clk_provider; + + ret = devm_add_action(rphy->dev, rockchip_usb2phy_clk480m_unregister, + rphy); + if (ret < 0) + goto err_unreg_action; + + return 0; + +err_unreg_action: + of_clk_del_provider(node); +err_clk_provider: + clk_unregister(rphy->clk480m); +err_register: + if (rphy->clk) + clk_put(rphy->clk); + return ret; +} + +static int rockchip_usb2phy_init(struct phy *phy) +{ + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); + int ret; + + if (rport->port_id == USB2PHY_PORT_HOST) { + /* clear linestate and enable linestate detect irq */ + mutex_lock(&rport->mutex); + + ret = property_enable(rphy, &rport->port_cfg->ls_det_clr, true); + if (ret) { + mutex_unlock(&rport->mutex); + return ret; + } + + ret = property_enable(rphy, &rport->port_cfg->ls_det_en, true); + if (ret) { + mutex_unlock(&rport->mutex); + return ret; + } + + mutex_unlock(&rport->mutex); + schedule_delayed_work(&rport->sm_work, SCHEDULE_DELAY); + } + + return 0; +} + +static int rockchip_usb2phy_resume(struct phy *phy) +{ + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); + int ret; + + dev_dbg(&rport->phy->dev, "port resume\n"); + + ret = clk_prepare_enable(rphy->clk480m); + if (ret) + return ret; + + ret = property_enable(rphy, &rport->port_cfg->phy_sus, false); + if (ret) + return ret; + + rport->suspended = false; + return 0; +} + +static int rockchip_usb2phy_suspend(struct phy *phy) +{ + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); + int ret; + + dev_dbg(&rport->phy->dev, "port suspend\n"); + + if (rport->suspended) + goto exit; + + ret = property_enable(rphy, &rport->port_cfg->phy_sus, true); + if (ret) + return ret; + + rport->suspended = true; + clk_disable_unprepare(rphy->clk480m); + +exit: + return 0; +} + +static int rockchip_usb2phy_exit(struct phy *phy) +{ + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); + + if (rport->port_id == USB2PHY_PORT_HOST) + cancel_delayed_work_sync(&rport->sm_work); + + return 0; +} + +static const struct phy_ops rockchip_usb2phy_ops = { + .init = rockchip_usb2phy_init, + .exit = rockchip_usb2phy_exit, + .power_on = rockchip_usb2phy_resume, + .power_off = rockchip_usb2phy_suspend, + .owner = THIS_MODULE, +}; + +/* + * The function manage host-phy port state and suspend/resume phy port + * to save power. + * + * we rely on utmi_linestate and utmi_hostdisconnect to identify whether + * FS/HS is disconnect or not. Besides, we do not need care it is FS + * disconnected or HS disconnected, actually, we just only need get the + * device is disconnected at last through rearm the delayed work, + * to suspend the phy port in _PHY_STATE_DISCONNECT_ case. + * + * NOTE: It may invoke *phy_suspend or *phy_resume which will invoke some + * clk related APIs, so do not invoke it from interrupt context directly. + */ +static void rockchip_usb2phy_sm_work(struct work_struct *work) +{ + struct rockchip_usb2phy_port *rport = + container_of(work, struct rockchip_usb2phy_port, sm_work.work); + struct rockchip_usb2phy *rphy = dev_get_drvdata(rport->phy->dev.parent); + unsigned int sh = rport->port_cfg->utmi_hstdet.bitend - + rport->port_cfg->utmi_hstdet.bitstart + 1; + unsigned int ul, uhd, state; + unsigned int ul_mask, uhd_mask; + int ret; + + mutex_lock(&rport->mutex); + + ret = regmap_read(rphy->grf, rport->port_cfg->utmi_ls.offset, &ul); + if (ret < 0) + goto next_schedule; + + ret = regmap_read(rphy->grf, rport->port_cfg->utmi_hstdet.offset, + &uhd); + if (ret < 0) + goto next_schedule; + + uhd_mask = GENMASK(rport->port_cfg->utmi_hstdet.bitend, + rport->port_cfg->utmi_hstdet.bitstart); + ul_mask = GENMASK(rport->port_cfg->utmi_ls.bitend, + rport->port_cfg->utmi_ls.bitstart); + + /* stitch on utmi_ls and utmi_hstdet as phy state */ + state = ((uhd & uhd_mask) >> rport->port_cfg->utmi_hstdet.bitstart) | + (((ul & ul_mask) >> rport->port_cfg->utmi_ls.bitstart) << sh); + + switch (state) { + case PHY_STATE_HS_ONLINE: + dev_dbg(&rport->phy->dev, "HS online\n"); + break; + case PHY_STATE_FS_CONNECT: + /* + * For FS device, the online state share with connect state + * from utmi_ls and utmi_hstdet register, so we distinguish + * them via suspended flag. + */ + if (!rport->suspended) { + dev_dbg(&rport->phy->dev, "FS online\n"); + break; + } + /* fall through */ + case PHY_STATE_HS_CONNECT: + if (rport->suspended) { + dev_dbg(&rport->phy->dev, "HS/FS connected\n"); + rockchip_usb2phy_resume(rport->phy); + rport->suspended = false; + } + break; + case PHY_STATE_DISCONNECT: + if (!rport->suspended) { + dev_dbg(&rport->phy->dev, "HS/FS disconnected\n"); + rockchip_usb2phy_suspend(rport->phy); + rport->suspended = true; + } + + /* + * activate the linestate detection to get the next device + * plug-in irq. + */ + property_enable(rphy, &rport->port_cfg->ls_det_clr, true); + property_enable(rphy, &rport->port_cfg->ls_det_en, true); + + /* + * we don't need to rearm the delayed work when the phy port + * is suspended. + */ + mutex_unlock(&rport->mutex); + return; + default: + dev_dbg(&rport->phy->dev, "unknown phy state\n"); + break; + } + +next_schedule: + mutex_unlock(&rport->mutex); + schedule_delayed_work(&rport->sm_work, SCHEDULE_DELAY); +} + +static irqreturn_t rockchip_usb2phy_linestate_irq(int irq, void *data) +{ + struct rockchip_usb2phy_port *rport = data; + struct rockchip_usb2phy *rphy = dev_get_drvdata(rport->phy->dev.parent); + + if (!property_enabled(rphy, &rport->port_cfg->ls_det_st)) + return IRQ_NONE; + + mutex_lock(&rport->mutex); + + /* disable linestate detect irq and clear its status */ + property_enable(rphy, &rport->port_cfg->ls_det_en, false); + property_enable(rphy, &rport->port_cfg->ls_det_clr, true); + + mutex_unlock(&rport->mutex); + + /* + * In this case for host phy port, a new device is plugged in, + * meanwhile, if the phy port is suspended, we need rearm the work to + * resume it and mange its states; otherwise, we do nothing about that. + */ + if (rport->suspended && rport->port_id == USB2PHY_PORT_HOST) + rockchip_usb2phy_sm_work(&rport->sm_work.work); + + return IRQ_HANDLED; +} + +static int rockchip_usb2phy_host_port_init(struct rockchip_usb2phy *rphy, + struct rockchip_usb2phy_port *rport, + struct device_node *child_np) +{ + int ret; + + rport->port_id = USB2PHY_PORT_HOST; + rport->port_cfg = &rphy->phy_cfg->port_cfgs[USB2PHY_PORT_HOST]; + + mutex_init(&rport->mutex); + INIT_DELAYED_WORK(&rport->sm_work, rockchip_usb2phy_sm_work); + + rport->ls_irq = of_irq_get_byname(child_np, "linestate"); + if (rport->ls_irq < 0) { + dev_err(rphy->dev, "no linestate irq provided\n"); + return rport->ls_irq; + } + + ret = devm_request_threaded_irq(rphy->dev, rport->ls_irq, NULL, + rockchip_usb2phy_linestate_irq, + IRQF_ONESHOT, + "rockchip_usb2phy", rport); + if (ret) { + dev_err(rphy->dev, "failed to request irq handle\n"); + return ret; + } + + return 0; +} + +static int rockchip_usb2phy_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct device_node *np = dev->of_node; + struct device_node *child_np; + struct phy_provider *provider; + struct rockchip_usb2phy *rphy; + const struct rockchip_usb2phy_cfg *phy_cfgs; + const struct of_device_id *match; + unsigned int reg; + int index, ret; + + rphy = devm_kzalloc(dev, sizeof(*rphy), GFP_KERNEL); + if (!rphy) + return -ENOMEM; + + match = of_match_device(dev->driver->of_match_table, dev); + if (!match || !match->data) { + dev_err(dev, "phy configs are not assigned!\n"); + return -EINVAL; + } + + if (!dev->parent || !dev->parent->of_node) + return -EINVAL; + + rphy->grf = syscon_node_to_regmap(dev->parent->of_node); + if (IS_ERR(rphy->grf)) + return PTR_ERR(rphy->grf); + + if (of_property_read_u32(np, "reg", ®)) { + dev_err(dev, "the reg property is not assigned in %s node\n", + np->name); + return -EINVAL; + } + + rphy->dev = dev; + phy_cfgs = match->data; + platform_set_drvdata(pdev, rphy); + + /* find out a proper config which can be matched with dt. */ + index = 0; + while (phy_cfgs[index].reg) { + if (phy_cfgs[index].reg == reg) { + rphy->phy_cfg = &phy_cfgs[index]; + break; + } + + ++index; + } + + if (!rphy->phy_cfg) { + dev_err(dev, "no phy-config can be matched with %s node\n", + np->name); + return -EINVAL; + } + + ret = rockchip_usb2phy_clk480m_register(rphy); + if (ret) { + dev_err(dev, "failed to register 480m output clock\n"); + return ret; + } + + index = 0; + for_each_available_child_of_node(np, child_np) { + struct rockchip_usb2phy_port *rport = &rphy->ports[index]; + struct phy *phy; + + /* + * This driver aim to support both otg-port and host-port, + * but unfortunately, the otg part is not ready in current, + * so this comments and below codes are interim, which should + * be changed after otg-port is supplied soon. + */ + if (of_node_cmp(child_np->name, "host-port")) + goto next_child; + + phy = devm_phy_create(dev, child_np, &rockchip_usb2phy_ops); + if (IS_ERR(phy)) { + dev_err(dev, "failed to create phy\n"); + ret = PTR_ERR(phy); + goto put_child; + } + + rport->phy = phy; + phy_set_drvdata(rport->phy, rport); + + ret = rockchip_usb2phy_host_port_init(rphy, rport, child_np); + if (ret) + goto put_child; + +next_child: + /* to prevent out of boundary */ + if (++index >= rphy->phy_cfg->num_ports) + break; + } + + provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate); + return PTR_ERR_OR_ZERO(provider); + +put_child: + of_node_put(child_np); + return ret; +} + +static const struct rockchip_usb2phy_cfg rk3366_phy_cfgs[] = { + { + .reg = 0x700, + .num_ports = 2, + .clkout_ctl = { 0x0724, 15, 15, 1, 0 }, + .port_cfgs = { + [USB2PHY_PORT_HOST] = { + .phy_sus = { 0x0728, 15, 0, 0, 0x1d1 }, + .ls_det_en = { 0x0680, 4, 4, 0, 1 }, + .ls_det_st = { 0x0690, 4, 4, 0, 1 }, + .ls_det_clr = { 0x06a0, 4, 4, 0, 1 }, + .utmi_ls = { 0x049c, 14, 13, 0, 1 }, + .utmi_hstdet = { 0x049c, 12, 12, 0, 1 } + } + }, + }, + { /* sentinel */ } +}; + +static const struct of_device_id rockchip_usb2phy_dt_match[] = { + { .compatible = "rockchip,rk3366-usb2phy", .data = &rk3366_phy_cfgs }, + {} +}; +MODULE_DEVICE_TABLE(of, rockchip_usb2phy_dt_match); + +static struct platform_driver rockchip_usb2phy_driver = { + .probe = rockchip_usb2phy_probe, + .driver = { + .name = "rockchip-usb2phy", + .of_match_table = rockchip_usb2phy_dt_match, + }, +}; +module_platform_driver(rockchip_usb2phy_driver); + +MODULE_AUTHOR("Frank Wang <frank.wang@rock-chips.com>"); +MODULE_DESCRIPTION("Rockchip USB2.0 PHY driver"); +MODULE_LICENSE("GPL v2"); -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-17 2:09 ` [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy Frank Wang @ 2016-06-17 4:59 ` Guenter Roeck 2016-06-17 6:43 ` Frank Wang 0 siblings, 1 reply; 13+ messages in thread From: Guenter Roeck @ 2016-06-17 4:59 UTC (permalink / raw) To: Frank Wang, heiko, dianders, groeck, jwerner, kishon, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak Cc: linux-kernel, devicetree, linux-usb, linux-rockchip, xzy.xu, kever.yang, huangtao, william.wu On 06/16/2016 07:09 PM, Frank Wang wrote: > The newer SoCs (rk3366, rk3399) take a different usb-phy IP block > than rk3288 and before, and most of phy-related registers are also > different from the past, so a new phy driver is required necessarily. > > Signed-off-by: Frank Wang <frank.wang@rock-chips.com> > Suggested-by: Guenter Roeck <linux@roeck-us.net> > Suggested-by: Doug Anderson <dianders@chromium.org> > Reviewed-by: Heiko Stuebner <heiko@sntech.de> > Tested-by: Heiko Stuebner <heiko@sntech.de> > --- [ ... ] > + > +static int rockchip_usb2phy_resume(struct phy *phy) > +{ > + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); > + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); > + int ret; > + > + dev_dbg(&rport->phy->dev, "port resume\n"); > + > + ret = clk_prepare_enable(rphy->clk480m); > + if (ret) > + return ret; > + If suspend can be called multiple times, resume can be called multiple times as well. Doesn't this cause a clock imbalance if you call clk_prepare_enable() multiple times on resume, but clk_disable_unprepare() only once on suspend ? > + ret = property_enable(rphy, &rport->port_cfg->phy_sus, false); > + if (ret) > + return ret; > + > + rport->suspended = false; > + return 0; > +} > + > +static int rockchip_usb2phy_suspend(struct phy *phy) > +{ > + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); > + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); > + int ret; > + > + dev_dbg(&rport->phy->dev, "port suspend\n"); > + > + if (rport->suspended) > + goto exit; > + I know I am nitpicking, but return 0; would be fine here, be more consistent with the rest of the code, > + ret = property_enable(rphy, &rport->port_cfg->phy_sus, true); > + if (ret) > + return ret; > + > + rport->suspended = true; > + clk_disable_unprepare(rphy->clk480m); > + > +exit: > + return 0; and this label is really unnecessary. > +} > + [ ... ] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-17 4:59 ` Guenter Roeck @ 2016-06-17 6:43 ` Frank Wang 2016-06-17 13:20 ` Guenter Roeck 0 siblings, 1 reply; 13+ messages in thread From: Frank Wang @ 2016-06-17 6:43 UTC (permalink / raw) To: Guenter Roeck, heiko Cc: dianders, groeck, jwerner, kishon, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux-kernel, devicetree, linux-usb, linux-rockchip, xzy.xu, kever.yang, huangtao, william.wu, frank.wang Hi Guenter, On 2016/6/17 12:59, Guenter Roeck wrote: > On 06/16/2016 07:09 PM, Frank Wang wrote: >> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block >> than rk3288 and before, and most of phy-related registers are also >> different from the past, so a new phy driver is required necessarily. >> >> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> >> Suggested-by: Guenter Roeck <linux@roeck-us.net> >> Suggested-by: Doug Anderson <dianders@chromium.org> >> Reviewed-by: Heiko Stuebner <heiko@sntech.de> >> Tested-by: Heiko Stuebner <heiko@sntech.de> >> --- > > [ ... ] > >> + >> +static int rockchip_usb2phy_resume(struct phy *phy) >> +{ >> + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); >> + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); >> + int ret; >> + >> + dev_dbg(&rport->phy->dev, "port resume\n"); >> + >> + ret = clk_prepare_enable(rphy->clk480m); >> + if (ret) >> + return ret; >> + > If suspend can be called multiple times, resume can be called > multiple times as well. Doesn't this cause a clock imbalance > if you call clk_prepare_enable() multiple times on resume, > but clk_disable_unprepare() only once on suspend ? > Well, what you said is reasonable, How does something like below? @@ -307,6 +307,9 @@ static int rockchip_usb2phy_resume(struct phy *phy) dev_dbg(&rport->phy->dev, "port resume\n"); + if (!rport->suspended) + return 0; + ret = clk_prepare_enable(rphy->clk480m); if (ret) return ret; @@ -327,12 +330,16 @@ static int rockchip_usb2phy_suspend(struct phy *phy) dev_dbg(&rport->phy->dev, "port suspend\n"); + if (rport->suspended) + return 0; + ret = property_enable(rphy, &rport->port_cfg->phy_sus, true); if (ret) return ret; rport->suspended = true; clk_disable_unprepare(rphy->clk480m); + return 0; } @@ -485,6 +492,7 @@ static int rockchip_usb2phy_host_port_init(struct rockchip_usb2phy *rphy, rport->port_id = USB2PHY_PORT_HOST; rport->port_cfg = &rphy->phy_cfg->port_cfgs[USB2PHY_PORT_HOST]; + rport->suspended = true; mutex_init(&rport->mutex); INIT_DELAYED_WORK(&rport->sm_work, rockchip_usb2phy_sm_work); >> + ret = property_enable(rphy, &rport->port_cfg->phy_sus, false); >> + if (ret) >> + return ret; >> + >> + rport->suspended = false; >> + return 0; >> +} >> + >> +static int rockchip_usb2phy_suspend(struct phy *phy) >> +{ >> + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); >> + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); >> + int ret; >> + >> + dev_dbg(&rport->phy->dev, "port suspend\n"); >> + >> + if (rport->suspended) >> + goto exit; >> + > > I know I am nitpicking, but > return 0; > would be fine here, be more consistent with the rest of the code, > Yeah, please see above changes. BR. Frank >> + ret = property_enable(rphy, &rport->port_cfg->phy_sus, true); >> + if (ret) >> + return ret; >> + >> + rport->suspended = true; >> + clk_disable_unprepare(rphy->clk480m); >> + >> +exit: >> + return 0; > > and this label is really unnecessary. > >> +} >> + > > [ ... ] > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-17 6:43 ` Frank Wang @ 2016-06-17 13:20 ` Guenter Roeck 2016-06-20 1:27 ` Frank Wang 0 siblings, 1 reply; 13+ messages in thread From: Guenter Roeck @ 2016-06-17 13:20 UTC (permalink / raw) To: Frank Wang, heiko Cc: dianders, groeck, jwerner, kishon, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux-kernel, devicetree, linux-usb, linux-rockchip, xzy.xu, kever.yang, huangtao, william.wu Hi Frank, On 06/16/2016 11:43 PM, Frank Wang wrote: > Hi Guenter, > > On 2016/6/17 12:59, Guenter Roeck wrote: >> On 06/16/2016 07:09 PM, Frank Wang wrote: >>> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block >>> than rk3288 and before, and most of phy-related registers are also >>> different from the past, so a new phy driver is required necessarily. >>> >>> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> >>> Suggested-by: Guenter Roeck <linux@roeck-us.net> >>> Suggested-by: Doug Anderson <dianders@chromium.org> >>> Reviewed-by: Heiko Stuebner <heiko@sntech.de> >>> Tested-by: Heiko Stuebner <heiko@sntech.de> >>> --- >> >> [ ... ] >> >>> + >>> +static int rockchip_usb2phy_resume(struct phy *phy) >>> +{ >>> + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); >>> + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); >>> + int ret; >>> + >>> + dev_dbg(&rport->phy->dev, "port resume\n"); >>> + >>> + ret = clk_prepare_enable(rphy->clk480m); >>> + if (ret) >>> + return ret; >>> + >> If suspend can be called multiple times, resume can be called >> multiple times as well. Doesn't this cause a clock imbalance >> if you call clk_prepare_enable() multiple times on resume, >> but clk_disable_unprepare() only once on suspend ? >> > > Well, what you said is reasonable, How does something like below? > > @@ -307,6 +307,9 @@ static int rockchip_usb2phy_resume(struct phy *phy) > > dev_dbg(&rport->phy->dev, "port resume\n"); > > + if (!rport->suspended) > + return 0; > + > ret = clk_prepare_enable(rphy->clk480m); > if (ret) > return ret; > @@ -327,12 +330,16 @@ static int rockchip_usb2phy_suspend(struct phy *phy) > > dev_dbg(&rport->phy->dev, "port suspend\n"); > > + if (rport->suspended) > + return 0; > + > ret = property_enable(rphy, &rport->port_cfg->phy_sus, true); > if (ret) > return ret; > > rport->suspended = true; > clk_disable_unprepare(rphy->clk480m); > + > return 0; > } > > @@ -485,6 +492,7 @@ static int rockchip_usb2phy_host_port_init(struct rockchip_usb2phy *rphy, > > rport->port_id = USB2PHY_PORT_HOST; > rport->port_cfg = &rphy->phy_cfg->port_cfgs[USB2PHY_PORT_HOST]; > + rport->suspended = true; > Why does it start in suspended mode ? That seems odd. Guenter > mutex_init(&rport->mutex); > INIT_DELAYED_WORK(&rport->sm_work, rockchip_usb2phy_sm_work); > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-17 13:20 ` Guenter Roeck @ 2016-06-20 1:27 ` Frank Wang 2016-06-20 3:00 ` Guenter Roeck 0 siblings, 1 reply; 13+ messages in thread From: Frank Wang @ 2016-06-20 1:27 UTC (permalink / raw) To: Guenter Roeck, heiko Cc: dianders, groeck, jwerner, kishon, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, linux-kernel, devicetree, linux-usb, linux-rockchip, xzy.xu, kever.yang, huangtao, william.wu, frank.wang Hi Guenter, On 2016/6/17 21:20, Guenter Roeck wrote: > Hi Frank, > > On 06/16/2016 11:43 PM, Frank Wang wrote: >> Hi Guenter, >> >> On 2016/6/17 12:59, Guenter Roeck wrote: >>> On 06/16/2016 07:09 PM, Frank Wang wrote: >>>> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block >>>> than rk3288 and before, and most of phy-related registers are also >>>> different from the past, so a new phy driver is required necessarily. >>>> >>>> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> >>>> Suggested-by: Guenter Roeck <linux@roeck-us.net> >>>> Suggested-by: Doug Anderson <dianders@chromium.org> >>>> Reviewed-by: Heiko Stuebner <heiko@sntech.de> >>>> Tested-by: Heiko Stuebner <heiko@sntech.de> >>>> --- >>> >>> [ ... ] >>> >>>> + >>>> +static int rockchip_usb2phy_resume(struct phy *phy) >>>> +{ >>>> + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); >>>> + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); >>>> + int ret; >>>> + >>>> + dev_dbg(&rport->phy->dev, "port resume\n"); >>>> + >>>> + ret = clk_prepare_enable(rphy->clk480m); >>>> + if (ret) >>>> + return ret; >>>> + >>> If suspend can be called multiple times, resume can be called >>> multiple times as well. Doesn't this cause a clock imbalance >>> if you call clk_prepare_enable() multiple times on resume, >>> but clk_disable_unprepare() only once on suspend ? >>> >> >> Well, what you said is reasonable, How does something like below? >> >> @@ -307,6 +307,9 @@ static int rockchip_usb2phy_resume(struct phy *phy) >> >> dev_dbg(&rport->phy->dev, "port resume\n"); >> >> + if (!rport->suspended) >> + return 0; >> + >> ret = clk_prepare_enable(rphy->clk480m); >> if (ret) >> return ret; >> @@ -327,12 +330,16 @@ static int rockchip_usb2phy_suspend(struct phy >> *phy) >> >> dev_dbg(&rport->phy->dev, "port suspend\n"); >> >> + if (rport->suspended) >> + return 0; >> + >> ret = property_enable(rphy, &rport->port_cfg->phy_sus, true); >> if (ret) >> return ret; >> >> rport->suspended = true; >> clk_disable_unprepare(rphy->clk480m); >> + >> return 0; >> } >> >> @@ -485,6 +492,7 @@ static int rockchip_usb2phy_host_port_init(struct >> rockchip_usb2phy *rphy, >> >> rport->port_id = USB2PHY_PORT_HOST; >> rport->port_cfg = &rphy->phy_cfg->port_cfgs[USB2PHY_PORT_HOST]; >> + rport->suspended = true; >> > > Why does it start in suspended mode ? That seems odd. > This is an initialization. Using above design which make 'suspended' as a condition both in *_usb2phy_resume and *_usb2phy_suspend, I believe if it is not initialized as suspended mode, the first resume process will be skipped. Theoretically, the phy-port in suspended mode make sense when it is at start time, then the upper layer controller will invoke phy_power_on (See phy-core.c), and it further call back *_usb2phy_resume to make phy-port work properly. So could you tell me what make you feeling odd or would you like to give another appropriate way please? :-) BR. Frank > >> mutex_init(&rport->mutex); >> INIT_DELAYED_WORK(&rport->sm_work, rockchip_usb2phy_sm_work); >> > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-20 1:27 ` Frank Wang @ 2016-06-20 3:00 ` Guenter Roeck 2016-06-20 3:32 ` Frank Wang 0 siblings, 1 reply; 13+ messages in thread From: Guenter Roeck @ 2016-06-20 3:00 UTC (permalink / raw) To: Frank Wang Cc: Guenter Roeck, Heiko Stübner, Douglas Anderson, Guenter Roeck, jwerner, Kishon Vijay Abraham I, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, Kumar Gala, linux-kernel, devicetree, linux-usb, linux-rockchip, Ziyuan Xu, Kever Yang, Tao Huang, william.wu On Sun, Jun 19, 2016 at 6:27 PM, Frank Wang <frank.wang@rock-chips.com> wrote: > Hi Guenter, > > > On 2016/6/17 21:20, Guenter Roeck wrote: >> >> Hi Frank, >> >> On 06/16/2016 11:43 PM, Frank Wang wrote: >>> >>> Hi Guenter, >>> >>> On 2016/6/17 12:59, Guenter Roeck wrote: >>>> >>>> On 06/16/2016 07:09 PM, Frank Wang wrote: >>>>> >>>>> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block >>>>> than rk3288 and before, and most of phy-related registers are also >>>>> different from the past, so a new phy driver is required necessarily. >>>>> >>>>> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> >>>>> Suggested-by: Guenter Roeck <linux@roeck-us.net> >>>>> Suggested-by: Doug Anderson <dianders@chromium.org> >>>>> Reviewed-by: Heiko Stuebner <heiko@sntech.de> >>>>> Tested-by: Heiko Stuebner <heiko@sntech.de> >>>>> --- >>>> >>>> >>>> [ ... ] >>>> >>>>> + >>>>> +static int rockchip_usb2phy_resume(struct phy *phy) >>>>> +{ >>>>> + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); >>>>> + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); >>>>> + int ret; >>>>> + >>>>> + dev_dbg(&rport->phy->dev, "port resume\n"); >>>>> + >>>>> + ret = clk_prepare_enable(rphy->clk480m); >>>>> + if (ret) >>>>> + return ret; >>>>> + >>>> >>>> If suspend can be called multiple times, resume can be called >>>> multiple times as well. Doesn't this cause a clock imbalance >>>> if you call clk_prepare_enable() multiple times on resume, >>>> but clk_disable_unprepare() only once on suspend ? >>>> >>> >>> Well, what you said is reasonable, How does something like below? >>> >>> @@ -307,6 +307,9 @@ static int rockchip_usb2phy_resume(struct phy *phy) >>> >>> dev_dbg(&rport->phy->dev, "port resume\n"); >>> >>> + if (!rport->suspended) >>> + return 0; >>> + >>> ret = clk_prepare_enable(rphy->clk480m); >>> if (ret) >>> return ret; >>> @@ -327,12 +330,16 @@ static int rockchip_usb2phy_suspend(struct phy >>> *phy) >>> >>> dev_dbg(&rport->phy->dev, "port suspend\n"); >>> >>> + if (rport->suspended) >>> + return 0; >>> + >>> ret = property_enable(rphy, &rport->port_cfg->phy_sus, true); >>> if (ret) >>> return ret; >>> >>> rport->suspended = true; >>> clk_disable_unprepare(rphy->clk480m); >>> + >>> return 0; >>> } >>> >>> @@ -485,6 +492,7 @@ static int rockchip_usb2phy_host_port_init(struct >>> rockchip_usb2phy *rphy, >>> >>> rport->port_id = USB2PHY_PORT_HOST; >>> rport->port_cfg = &rphy->phy_cfg->port_cfgs[USB2PHY_PORT_HOST]; >>> + rport->suspended = true; >>> >> >> Why does it start in suspended mode ? That seems odd. >> > > This is an initialization. Using above design which make 'suspended' as a > condition both in *_usb2phy_resume and *_usb2phy_suspend, I believe if it is > not initialized as suspended mode, the first resume process will be skipped. I had to re-read the entire patch. Turns out my problem was one of terminology. Using "suspend" and "resume" to me suggested the common use of suspend and resume functions. That is not the case here. After mentally replacing "suspend" with "power_off" and "resume" with "power_on", you are right, no problem exists. Sorry for the noise. Maybe it would be useful to replace "resume" with "power_on" and "suspend" with "power_off" in the function and variable names to reduce confusion and misunderstandings. Thanks, Guenter > Theoretically, the phy-port in suspended mode make sense when it is at start > time, then the upper layer controller will invoke phy_power_on (See > phy-core.c), and it further call back *_usb2phy_resume to make phy-port work > properly. > > So could you tell me what make you feeling odd or would you like to give > another appropriate way please? :-) > > BR. > Frank > > >> >>> mutex_init(&rport->mutex); >>> INIT_DELAYED_WORK(&rport->sm_work, rockchip_usb2phy_sm_work); >>> >> > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-20 3:00 ` Guenter Roeck @ 2016-06-20 3:32 ` Frank Wang 2016-06-20 4:56 ` Guenter Roeck 0 siblings, 1 reply; 13+ messages in thread From: Frank Wang @ 2016-06-20 3:32 UTC (permalink / raw) To: Guenter Roeck, Guenter Roeck, Heiko Stübner Cc: Douglas Anderson, Guenter Roeck, jwerner, Kishon Vijay Abraham I, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, Kumar Gala, linux-kernel, devicetree, linux-usb, linux-rockchip, Ziyuan Xu, Kever Yang, Tao Huang, william.wu, frank.wang Hi Heiko & Guenter, On 2016/6/20 11:00, Guenter Roeck wrote: > On Sun, Jun 19, 2016 at 6:27 PM, Frank Wang <frank.wang@rock-chips.com> wrote: >> Hi Guenter, >> >> >> On 2016/6/17 21:20, Guenter Roeck wrote: >>> Hi Frank, >>> >>> On 06/16/2016 11:43 PM, Frank Wang wrote: >>>> Hi Guenter, >>>> >>>> On 2016/6/17 12:59, Guenter Roeck wrote: >>>>> On 06/16/2016 07:09 PM, Frank Wang wrote: >>>>>> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block >>>>>> than rk3288 and before, and most of phy-related registers are also >>>>>> different from the past, so a new phy driver is required necessarily. >>>>>> >>>>>> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> >>>>>> Suggested-by: Guenter Roeck <linux@roeck-us.net> >>>>>> Suggested-by: Doug Anderson <dianders@chromium.org> >>>>>> Reviewed-by: Heiko Stuebner <heiko@sntech.de> >>>>>> Tested-by: Heiko Stuebner <heiko@sntech.de> >>>>>> --- >>>>> >>>>> [ ... ] >>>>> >>>>>> + >>>>>> +static int rockchip_usb2phy_resume(struct phy *phy) >>>>>> +{ >>>>>> + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); >>>>>> + struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent); >>>>>> + int ret; >>>>>> + >>>>>> + dev_dbg(&rport->phy->dev, "port resume\n"); >>>>>> + >>>>>> + ret = clk_prepare_enable(rphy->clk480m); >>>>>> + if (ret) >>>>>> + return ret; >>>>>> + >>>>> If suspend can be called multiple times, resume can be called >>>>> multiple times as well. Doesn't this cause a clock imbalance >>>>> if you call clk_prepare_enable() multiple times on resume, >>>>> but clk_disable_unprepare() only once on suspend ? >>>>> >>>> Well, what you said is reasonable, How does something like below? >>>> >>>> @@ -307,6 +307,9 @@ static int rockchip_usb2phy_resume(struct phy *phy) >>>> >>>> dev_dbg(&rport->phy->dev, "port resume\n"); >>>> >>>> + if (!rport->suspended) >>>> + return 0; >>>> + >>>> ret = clk_prepare_enable(rphy->clk480m); >>>> if (ret) >>>> return ret; >>>> @@ -327,12 +330,16 @@ static int rockchip_usb2phy_suspend(struct phy >>>> *phy) >>>> >>>> dev_dbg(&rport->phy->dev, "port suspend\n"); >>>> >>>> + if (rport->suspended) >>>> + return 0; >>>> + >>>> ret = property_enable(rphy, &rport->port_cfg->phy_sus, true); >>>> if (ret) >>>> return ret; >>>> >>>> rport->suspended = true; >>>> clk_disable_unprepare(rphy->clk480m); >>>> + >>>> return 0; >>>> } >>>> >>>> @@ -485,6 +492,7 @@ static int rockchip_usb2phy_host_port_init(struct >>>> rockchip_usb2phy *rphy, >>>> >>>> rport->port_id = USB2PHY_PORT_HOST; >>>> rport->port_cfg = &rphy->phy_cfg->port_cfgs[USB2PHY_PORT_HOST]; >>>> + rport->suspended = true; >>>> >>> Why does it start in suspended mode ? That seems odd. >>> >> This is an initialization. Using above design which make 'suspended' as a >> condition both in *_usb2phy_resume and *_usb2phy_suspend, I believe if it is >> not initialized as suspended mode, the first resume process will be skipped. > I had to re-read the entire patch. > > Turns out my problem was one of terminology. Using "suspend" and > "resume" to me suggested the common use of suspend and resume > functions. That is not the case here. After mentally replacing > "suspend" with "power_off" and "resume" with "power_on", you are > right, no problem exists. Sorry for the noise. > > Maybe it would be useful to replace "resume" with "power_on" and > "suspend" with "power_off" in the function and variable names to > reduce confusion and misunderstandings. > > Thanks, > Guenter Well, it does have a bits confusion, however, the phy-port always just goes to suspend and resume mode (Not power off and power on) in a fact. So must it be renamed? @Heiko Stübner. Hey Heiko, what is your unique perceptions? ;-) BR. Frank > >> Theoretically, the phy-port in suspended mode make sense when it is at start >> time, then the upper layer controller will invoke phy_power_on (See >> phy-core.c), and it further call back *_usb2phy_resume to make phy-port work >> properly. >> >> So could you tell me what make you feeling odd or would you like to give >> another appropriate way please? :-) >> >> BR. >> Frank >> >> >>>> mutex_init(&rport->mutex); >>>> INIT_DELAYED_WORK(&rport->sm_work, rockchip_usb2phy_sm_work); >>>> >> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-20 3:32 ` Frank Wang @ 2016-06-20 4:56 ` Guenter Roeck 2016-06-21 7:52 ` Frank Wang 0 siblings, 1 reply; 13+ messages in thread From: Guenter Roeck @ 2016-06-20 4:56 UTC (permalink / raw) To: Frank Wang Cc: Guenter Roeck, Heiko Stübner, Douglas Anderson, Guenter Roeck, jwerner, Kishon Vijay Abraham I, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, Kumar Gala, linux-kernel, devicetree, linux-usb, linux-rockchip, Ziyuan Xu, Kever Yang, Tao Huang, william.wu Hi Frank, On Sun, Jun 19, 2016 at 8:32 PM, Frank Wang <frank.wang@rock-chips.com> wrote: > Hi Heiko & Guenter, > > > On 2016/6/20 11:00, Guenter Roeck wrote: >> >> On Sun, Jun 19, 2016 at 6:27 PM, Frank Wang <frank.wang@rock-chips.com> >> wrote: >>> >>> Hi Guenter, >>> >>> >>> On 2016/6/17 21:20, Guenter Roeck wrote: >>>> >>>> Hi Frank, >>>> >>>> On 06/16/2016 11:43 PM, Frank Wang wrote: >>>>> >>>>> Hi Guenter, >>>>> >>>>> On 2016/6/17 12:59, Guenter Roeck wrote: >>>>>> >>>>>> On 06/16/2016 07:09 PM, Frank Wang wrote: >>>>>>> >>>>>>> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block >>>>>>> than rk3288 and before, and most of phy-related registers are also >>>>>>> different from the past, so a new phy driver is required necessarily. >>>>>>> >>>>>>> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> >>>>>>> Suggested-by: Guenter Roeck <linux@roeck-us.net> >>>>>>> Suggested-by: Doug Anderson <dianders@chromium.org> >>>>>>> Reviewed-by: Heiko Stuebner <heiko@sntech.de> >>>>>>> Tested-by: Heiko Stuebner <heiko@sntech.de> >>>>>>> --- >>>>>> >>>>>> >>>>>> [ ... ] >>>>>> >>>>>>> + >>>>>>> +static int rockchip_usb2phy_resume(struct phy *phy) >>>>>>> +{ >>>>>>> + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); >>>>>>> + struct rockchip_usb2phy *rphy = >>>>>>> dev_get_drvdata(phy->dev.parent); >>>>>>> + int ret; >>>>>>> + >>>>>>> + dev_dbg(&rport->phy->dev, "port resume\n"); >>>>>>> + >>>>>>> + ret = clk_prepare_enable(rphy->clk480m); >>>>>>> + if (ret) >>>>>>> + return ret; >>>>>>> + >>>>>> >>>>>> If suspend can be called multiple times, resume can be called >>>>>> multiple times as well. Doesn't this cause a clock imbalance >>>>>> if you call clk_prepare_enable() multiple times on resume, >>>>>> but clk_disable_unprepare() only once on suspend ? >>>>>> >>>>> Well, what you said is reasonable, How does something like below? >>>>> >>>>> @@ -307,6 +307,9 @@ static int rockchip_usb2phy_resume(struct phy *phy) >>>>> >>>>> dev_dbg(&rport->phy->dev, "port resume\n"); >>>>> >>>>> + if (!rport->suspended) >>>>> + return 0; >>>>> + >>>>> ret = clk_prepare_enable(rphy->clk480m); >>>>> if (ret) >>>>> return ret; >>>>> @@ -327,12 +330,16 @@ static int rockchip_usb2phy_suspend(struct phy >>>>> *phy) >>>>> >>>>> dev_dbg(&rport->phy->dev, "port suspend\n"); >>>>> >>>>> + if (rport->suspended) >>>>> + return 0; >>>>> + >>>>> ret = property_enable(rphy, &rport->port_cfg->phy_sus, true); >>>>> if (ret) >>>>> return ret; >>>>> >>>>> rport->suspended = true; >>>>> clk_disable_unprepare(rphy->clk480m); >>>>> + >>>>> return 0; >>>>> } >>>>> >>>>> @@ -485,6 +492,7 @@ static int rockchip_usb2phy_host_port_init(struct >>>>> rockchip_usb2phy *rphy, >>>>> >>>>> rport->port_id = USB2PHY_PORT_HOST; >>>>> rport->port_cfg = >>>>> &rphy->phy_cfg->port_cfgs[USB2PHY_PORT_HOST]; >>>>> + rport->suspended = true; >>>>> >>>> Why does it start in suspended mode ? That seems odd. >>>> >>> This is an initialization. Using above design which make 'suspended' as a >>> condition both in *_usb2phy_resume and *_usb2phy_suspend, I believe if it >>> is >>> not initialized as suspended mode, the first resume process will be >>> skipped. >> >> I had to re-read the entire patch. >> >> Turns out my problem was one of terminology. Using "suspend" and >> "resume" to me suggested the common use of suspend and resume >> functions. That is not the case here. After mentally replacing >> "suspend" with "power_off" and "resume" with "power_on", you are >> right, no problem exists. Sorry for the noise. >> >> Maybe it would be useful to replace "resume" with "power_on" and >> "suspend" with "power_off" in the function and variable names to >> reduce confusion and misunderstandings. >> >> Thanks, >> Guenter > > > Well, it does have a bits confusion, however, the phy-port always just goes > to suspend and resume mode (Not power off and power on) in a fact. So must > it be renamed? > Other phy drivers name the functions _power_off and _power_on and avoid the confusion. The callbacks are named .power_off and .power_on, which gives a clear indication of its intended purpose. Other drivers implementing suspend/resume (such as the omap usb phy driver) tie those functions not into the power_off/power_on callbacks, but into the driver's suspend/resume callbacks. At least the omap driver has separate power management functions. Do the functions _have_ to be renamed ? Surely not. But, if the functions are really suspend/resume functions and not power_off/power_on functions, maybe they should tie to the suspend/resume functions and not register themselves as power_off/power_on functions ? Thanks, Guenter > @Heiko Stübner. Hey Heiko, what is your unique perceptions? ;-) > > > BR. > Frank > > >> >>> Theoretically, the phy-port in suspended mode make sense when it is at >>> start >>> time, then the upper layer controller will invoke phy_power_on (See >>> phy-core.c), and it further call back *_usb2phy_resume to make phy-port >>> work >>> properly. >>> >>> So could you tell me what make you feeling odd or would you like to give >>> another appropriate way please? :-) >>> >>> BR. >>> Frank >>> >>> >>>>> mutex_init(&rport->mutex); >>>>> INIT_DELAYED_WORK(&rport->sm_work, rockchip_usb2phy_sm_work); >>>>> >>> > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-20 4:56 ` Guenter Roeck @ 2016-06-21 7:52 ` Frank Wang 2016-06-21 9:05 ` Heiko Stübner 0 siblings, 1 reply; 13+ messages in thread From: Frank Wang @ 2016-06-21 7:52 UTC (permalink / raw) To: Heiko Stübner Cc: Guenter Roeck, Guenter Roeck, Guenter Roeck, Douglas Anderson, jwerner, Kishon Vijay Abraham I, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, Kumar Gala, linux-kernel, devicetree, linux-usb, linux-rockchip, Ziyuan Xu, Kever Yang, Tao Huang, william.wu, frank.wang Hi Heiko, On 2016/6/20 12:56, Guenter Roeck wrote: > Hi Frank, > > On Sun, Jun 19, 2016 at 8:32 PM, Frank Wang <frank.wang@rock-chips.com> wrote: >> Hi Heiko & Guenter, >> >> >> On 2016/6/20 11:00, Guenter Roeck wrote: >>> On Sun, Jun 19, 2016 at 6:27 PM, Frank Wang <frank.wang@rock-chips.com> >>> wrote: >>>> Hi Guenter, >>>> >>>> >>>> On 2016/6/17 21:20, Guenter Roeck wrote: >>>>> Hi Frank, >>>>> >>>>> On 06/16/2016 11:43 PM, Frank Wang wrote: >>>>>> Hi Guenter, >>>>>> >>>>>> On 2016/6/17 12:59, Guenter Roeck wrote: >>>>>>> On 06/16/2016 07:09 PM, Frank Wang wrote: >>>>>>>> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block >>>>>>>> than rk3288 and before, and most of phy-related registers are also >>>>>>>> different from the past, so a new phy driver is required necessarily. >>>>>>>> >>>>>>>> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> >>>>>>>> Suggested-by: Guenter Roeck <linux@roeck-us.net> >>>>>>>> Suggested-by: Doug Anderson <dianders@chromium.org> >>>>>>>> Reviewed-by: Heiko Stuebner <heiko@sntech.de> >>>>>>>> Tested-by: Heiko Stuebner <heiko@sntech.de> >>>>>>>> --- >>>>>>> >>>>>>> [ ... ] >>>>>>> >>>>>>>> + >>>>>>>> +static int rockchip_usb2phy_resume(struct phy *phy) >>>>>>>> +{ >>>>>>>> + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy); >>>>>>>> + struct rockchip_usb2phy *rphy = >>>>>>>> dev_get_drvdata(phy->dev.parent); >>>>>>>> + int ret; >>>>>>>> + >>>>>>>> + dev_dbg(&rport->phy->dev, "port resume\n"); >>>>>>>> + >>>>>>>> + ret = clk_prepare_enable(rphy->clk480m); >>>>>>>> + if (ret) >>>>>>>> + return ret; >>>>>>>> + >>>>>>> If suspend can be called multiple times, resume can be called >>>>>>> multiple times as well. Doesn't this cause a clock imbalance >>>>>>> if you call clk_prepare_enable() multiple times on resume, >>>>>>> but clk_disable_unprepare() only once on suspend ? >>>>>>> >>>>>> Well, what you said is reasonable, How does something like below? >>>>>> >>>>>> @@ -307,6 +307,9 @@ static int rockchip_usb2phy_resume(struct phy *phy) >>>>>> >>>>>> dev_dbg(&rport->phy->dev, "port resume\n"); >>>>>> >>>>>> + if (!rport->suspended) >>>>>> + return 0; >>>>>> + >>>>>> ret = clk_prepare_enable(rphy->clk480m); >>>>>> if (ret) >>>>>> return ret; >>>>>> @@ -327,12 +330,16 @@ static int rockchip_usb2phy_suspend(struct phy >>>>>> *phy) >>>>>> >>>>>> dev_dbg(&rport->phy->dev, "port suspend\n"); >>>>>> >>>>>> + if (rport->suspended) >>>>>> + return 0; >>>>>> + >>>>>> ret = property_enable(rphy, &rport->port_cfg->phy_sus, true); >>>>>> if (ret) >>>>>> return ret; >>>>>> >>>>>> rport->suspended = true; >>>>>> clk_disable_unprepare(rphy->clk480m); >>>>>> + >>>>>> return 0; >>>>>> } >>>>>> >>>>>> @@ -485,6 +492,7 @@ static int rockchip_usb2phy_host_port_init(struct >>>>>> rockchip_usb2phy *rphy, >>>>>> >>>>>> rport->port_id = USB2PHY_PORT_HOST; >>>>>> rport->port_cfg = >>>>>> &rphy->phy_cfg->port_cfgs[USB2PHY_PORT_HOST]; >>>>>> + rport->suspended = true; >>>>>> >>>>> Why does it start in suspended mode ? That seems odd. >>>>> >>>> This is an initialization. Using above design which make 'suspended' as a >>>> condition both in *_usb2phy_resume and *_usb2phy_suspend, I believe if it >>>> is >>>> not initialized as suspended mode, the first resume process will be >>>> skipped. >>> I had to re-read the entire patch. >>> >>> Turns out my problem was one of terminology. Using "suspend" and >>> "resume" to me suggested the common use of suspend and resume >>> functions. That is not the case here. After mentally replacing >>> "suspend" with "power_off" and "resume" with "power_on", you are >>> right, no problem exists. Sorry for the noise. >>> >>> Maybe it would be useful to replace "resume" with "power_on" and >>> "suspend" with "power_off" in the function and variable names to >>> reduce confusion and misunderstandings. >>> >>> Thanks, >>> Guenter >> >> Well, it does have a bits confusion, however, the phy-port always just goes >> to suspend and resume mode (Not power off and power on) in a fact. So must >> it be renamed? >> > Other phy drivers name the functions _power_off and _power_on and > avoid the confusion. The callbacks are named .power_off and .power_on, > which gives a clear indication of its intended purpose. Other drivers > implementing suspend/resume (such as the omap usb phy driver) tie > those functions not into the power_off/power_on callbacks, but into > the driver's suspend/resume callbacks. At least the omap driver has > separate power management functions. > > Do the functions _have_ to be renamed ? Surely not. But, if the > functions are really suspend/resume functions and not > power_off/power_on functions, maybe they should tie to the > suspend/resume functions and not register themselves as > power_off/power_on functions ? > > Thanks, > Guenter As Guenter mentioned above, I doped out two solutions, one is that keep current process but renaming *_resume/*_suspend to *_power_on/*_power_off; another is that do not assign power_on/power_off functions for phy_ops at phy creating time, then, shorten _SCHEDULE_DELAY_ delay time less that 10 Seconds, and the phy-port suspend/resume mechanism depend on _sm_work_ completely. So which is the better way from your view? or would you like to give other unique perceptions please? BR. Frank >> >>>> Theoretically, the phy-port in suspended mode make sense when it is at >>>> start >>>> time, then the upper layer controller will invoke phy_power_on (See >>>> phy-core.c), and it further call back *_usb2phy_resume to make phy-port >>>> work >>>> properly. >>>> >>>> So could you tell me what make you feeling odd or would you like to give >>>> another appropriate way please? :-) >>>> >>>> BR. >>>> Frank >>>> >>>> >>>>>> mutex_init(&rport->mutex); >>>>>> INIT_DELAYED_WORK(&rport->sm_work, rockchip_usb2phy_sm_work); >>>>>> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-21 7:52 ` Frank Wang @ 2016-06-21 9:05 ` Heiko Stübner 2016-06-21 9:27 ` Frank Wang 0 siblings, 1 reply; 13+ messages in thread From: Heiko Stübner @ 2016-06-21 9:05 UTC (permalink / raw) To: Frank Wang Cc: Guenter Roeck, Guenter Roeck, Guenter Roeck, Douglas Anderson, jwerner, Kishon Vijay Abraham I, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, Kumar Gala, linux-kernel, devicetree, linux-usb, linux-rockchip, Ziyuan Xu, Kever Yang, Tao Huang, william.wu Hi Frank, Am Dienstag, 21. Juni 2016, 15:52:45 schrieb Frank Wang: > On 2016/6/20 12:56, Guenter Roeck wrote: > > On Sun, Jun 19, 2016 at 8:32 PM, Frank Wang <frank.wang@rock-chips.com> wrote: > >>> Turns out my problem was one of terminology. Using "suspend" and > >>> "resume" to me suggested the common use of suspend and resume > >>> functions. That is not the case here. After mentally replacing > >>> "suspend" with "power_off" and "resume" with "power_on", you are > >>> right, no problem exists. Sorry for the noise. > >>> > >>> Maybe it would be useful to replace "resume" with "power_on" and > >>> "suspend" with "power_off" in the function and variable names to > >>> reduce confusion and misunderstandings. > >>> > >>> Thanks, > >>> Guenter > >> > >> Well, it does have a bits confusion, however, the phy-port always just > >> goes > >> to suspend and resume mode (Not power off and power on) in a fact. So > >> must > >> it be renamed? > > > > Other phy drivers name the functions _power_off and _power_on and > > avoid the confusion. The callbacks are named .power_off and .power_on, > > which gives a clear indication of its intended purpose. Other drivers > > implementing suspend/resume (such as the omap usb phy driver) tie > > those functions not into the power_off/power_on callbacks, but into > > the driver's suspend/resume callbacks. At least the omap driver has > > separate power management functions. > > > > Do the functions _have_ to be renamed ? Surely not. But, if the > > functions are really suspend/resume functions and not > > power_off/power_on functions, maybe they should tie to the > > suspend/resume functions and not register themselves as > > power_off/power_on functions ? > > As Guenter mentioned above, I doped out two solutions, one is that keep > current process but renaming *_resume/*_suspend to > *_power_on/*_power_off; in a way, naming stuff "power_off", "power_on" actually matches. For one, the phy-block goes from unusable to usable by usb-devices and also will power-on a phy-supply regulator (often named vcc_host* on Rockchip boards) from the phy- core. > another is that do not assign power_on/power_off > functions for phy_ops at phy creating time, then, shorten > _SCHEDULE_DELAY_ delay time less that 10 Seconds, and the phy-port > suspend/resume mechanism depend on _sm_work_ completely. Which in turn would mean that we would always depend on a fully controllable phy block. Right now it seems, rk3036, rk3228, rk3368 (probably forgot some) have the same type of phy, but with at least the unplug-detection missing. In its current form the driver can very well support those (later on) by simply working statically (only acting on phy_power callbacks and not going to suspend on its own). Also having the work running in 10-second intervall seems wasteful. > > So which is the better way from your view? or would you like to give > other unique perceptions please? As obvious from the above, I would prefer just renaming the functions :-) Heiko ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy 2016-06-21 9:05 ` Heiko Stübner @ 2016-06-21 9:27 ` Frank Wang 0 siblings, 0 replies; 13+ messages in thread From: Frank Wang @ 2016-06-21 9:27 UTC (permalink / raw) To: Heiko Stübner Cc: Guenter Roeck, Guenter Roeck, Guenter Roeck, Douglas Anderson, jwerner, Kishon Vijay Abraham I, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, Kumar Gala, linux-kernel, devicetree, linux-usb, linux-rockchip, Ziyuan Xu, Kever Yang, Tao Huang, william.wu, frank.wang Hi Heiko, On 2016/6/21 17:05, Heiko Stübner wrote: > Hi Frank, > > Am Dienstag, 21. Juni 2016, 15:52:45 schrieb Frank Wang: >> On 2016/6/20 12:56, Guenter Roeck wrote: >>> On Sun, Jun 19, 2016 at 8:32 PM, Frank Wang <frank.wang@rock-chips.com> > wrote: >>>>> Turns out my problem was one of terminology. Using "suspend" and >>>>> "resume" to me suggested the common use of suspend and resume >>>>> functions. That is not the case here. After mentally replacing >>>>> "suspend" with "power_off" and "resume" with "power_on", you are >>>>> right, no problem exists. Sorry for the noise. >>>>> >>>>> Maybe it would be useful to replace "resume" with "power_on" and >>>>> "suspend" with "power_off" in the function and variable names to >>>>> reduce confusion and misunderstandings. >>>>> >>>>> Thanks, >>>>> Guenter >>>> Well, it does have a bits confusion, however, the phy-port always just >>>> goes >>>> to suspend and resume mode (Not power off and power on) in a fact. So >>>> must >>>> it be renamed? >>> Other phy drivers name the functions _power_off and _power_on and >>> avoid the confusion. The callbacks are named .power_off and .power_on, >>> which gives a clear indication of its intended purpose. Other drivers >>> implementing suspend/resume (such as the omap usb phy driver) tie >>> those functions not into the power_off/power_on callbacks, but into >>> the driver's suspend/resume callbacks. At least the omap driver has >>> separate power management functions. >>> >>> Do the functions _have_ to be renamed ? Surely not. But, if the >>> functions are really suspend/resume functions and not >>> power_off/power_on functions, maybe they should tie to the >>> suspend/resume functions and not register themselves as >>> power_off/power_on functions ? >> As Guenter mentioned above, I doped out two solutions, one is that keep >> current process but renaming *_resume/*_suspend to >> *_power_on/*_power_off; > in a way, naming stuff "power_off", "power_on" actually matches. For one, the > phy-block goes from unusable to usable by usb-devices and also will power-on a > phy-supply regulator (often named vcc_host* on Rockchip boards) from the phy- > core. > >> another is that do not assign power_on/power_off >> functions for phy_ops at phy creating time, then, shorten >> _SCHEDULE_DELAY_ delay time less that 10 Seconds, and the phy-port >> suspend/resume mechanism depend on _sm_work_ completely. > Which in turn would mean that we would always depend on a fully controllable > phy block. Right now it seems, rk3036, rk3228, rk3368 (probably forgot some) > have the same type of phy, but with at least the unplug-detection missing. > In its current form the driver can very well support those (later on) by > simply working statically (only acting on phy_power callbacks and not going to > suspend on its own). > > Also having the work running in 10-second intervall seems wasteful. > >> So which is the better way from your view? or would you like to give >> other unique perceptions please? > As obvious from the above, I would prefer just renaming the functions :-) > > Heiko > Got it, thanks for your comments. I am going to correct and send out a new version later today, so sorry for trouble you to sign 'Reviewed-by' again if no any other issues. BR. Frank ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-06-21 10:22 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-17 2:09 [PATCH v6 0/2] Add a new Rockchip usb2 phy driver Frank Wang 2016-06-17 2:09 ` [PATCH v6 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY Frank Wang 2016-06-17 2:09 ` [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy Frank Wang 2016-06-17 4:59 ` Guenter Roeck 2016-06-17 6:43 ` Frank Wang 2016-06-17 13:20 ` Guenter Roeck 2016-06-20 1:27 ` Frank Wang 2016-06-20 3:00 ` Guenter Roeck 2016-06-20 3:32 ` Frank Wang 2016-06-20 4:56 ` Guenter Roeck 2016-06-21 7:52 ` Frank Wang 2016-06-21 9:05 ` Heiko Stübner 2016-06-21 9:27 ` Frank Wang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).