All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 0/5]
@ 2014-12-08  9:46 ` Yunzhi Li
  0 siblings, 0 replies; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08  9:46 UTC (permalink / raw)
  To: heiko, dianders, romain.perier
  Cc: olof, huangtao, zyw, cf, linux-rockchip, Yunzhi Li, devicetree,
	Paul Zimmerman, linux-usb, Kumar Gala, linux-kernel,
	Grant Likely, Ian Campbell, Rob Herring, Pawel Moll,
	Kishon Vijay Abraham I, Mark Rutland, Russell King,
	linux-arm-kernel, Greg Kroah-Hartman

Patches to add support for Rockchip usb phys.Add a new Rockchip
usb phy driver and modify dwc2 controller driver to make dwc2
platform devices support a generic PHY framework driver. This
patch set has been tested on my rk3288-evb and power off the usb
phys would reduce about 60mW power budget in total during sustem
suspend.

Changes in v3:
- Use BIT macro instead of bit shift ops.
- Rename the config entry to PHY_ROCKCHIP_USB.
- Fix coding style: both branches of the if() which only one
  branch of the conditional statement is a single statement should
  have braces.
- No need to test dwc2->phy for NULL before calling generic phy
  APIs.
- Add more context about the changes in the long description.

Yunzhi Li (5):
  phy: add a driver for the Rockchip SoC internal USB2.0 PHY
  Documentation: bindings: add doc for the Rockchip usb PHY
  usb: dwc2: add generic PHY framework support for dwc2 usb    
    controler platform driver.
  ARM: dts: add rk3288 usb PHY
  ARM: dts: Enable usb PHY on rk3288-evb board

 .../devicetree/bindings/phy/rockchip-usb-phy.txt   |  22 +++
 arch/arm/boot/dts/rk3288-evb.dtsi                  |   4 +
 arch/arm/boot/dts/rk3288.dtsi                      |  13 ++
 drivers/phy/Kconfig                                |   7 +
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-rockchip-usb.c                     | 179 +++++++++++++++++++++
 drivers/usb/dwc2/gadget.c                          |  33 ++--
 drivers/usb/dwc2/platform.c                        |  36 ++++-
 8 files changed, 272 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
 create mode 100644 drivers/phy/phy-rockchip-usb.c

-- 
2.0.0



^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2014-12-08  9:46 ` Yunzhi Li
  0 siblings, 0 replies; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08  9:46 UTC (permalink / raw)
  To: linux-arm-kernel

Patches to add support for Rockchip usb phys.Add a new Rockchip
usb phy driver and modify dwc2 controller driver to make dwc2
platform devices support a generic PHY framework driver. This
patch set has been tested on my rk3288-evb and power off the usb
phys would reduce about 60mW power budget in total during sustem
suspend.

Changes in v3:
- Use BIT macro instead of bit shift ops.
- Rename the config entry to PHY_ROCKCHIP_USB.
- Fix coding style: both branches of the if() which only one
  branch of the conditional statement is a single statement should
  have braces.
- No need to test dwc2->phy for NULL before calling generic phy
  APIs.
- Add more context about the changes in the long description.

Yunzhi Li (5):
  phy: add a driver for the Rockchip SoC internal USB2.0 PHY
  Documentation: bindings: add doc for the Rockchip usb PHY
  usb: dwc2: add generic PHY framework support for dwc2 usb    
    controler platform driver.
  ARM: dts: add rk3288 usb PHY
  ARM: dts: Enable usb PHY on rk3288-evb board

 .../devicetree/bindings/phy/rockchip-usb-phy.txt   |  22 +++
 arch/arm/boot/dts/rk3288-evb.dtsi                  |   4 +
 arch/arm/boot/dts/rk3288.dtsi                      |  13 ++
 drivers/phy/Kconfig                                |   7 +
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-rockchip-usb.c                     | 179 +++++++++++++++++++++
 drivers/usb/dwc2/gadget.c                          |  33 ++--
 drivers/usb/dwc2/platform.c                        |  36 ++++-
 8 files changed, 272 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
 create mode 100644 drivers/phy/phy-rockchip-usb.c

-- 
2.0.0

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
  2014-12-08  9:46 ` Yunzhi Li
@ 2014-12-08  9:46   ` Yunzhi Li
  -1 siblings, 0 replies; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08  9:46 UTC (permalink / raw)
  To: heiko, dianders, romain.perier
  Cc: olof, huangtao, zyw, cf, linux-rockchip, Yunzhi Li,
	Kishon Vijay Abraham I, Grant Likely, Rob Herring, linux-kernel,
	linux-arm-kernel, devicetree

This patche to add a generic PHY driver for ROCKCHIP usb PHYs,
currently this driver can support RK3288. The RK3288 SoC have
three independent USB PHY IPs which are all configured through a
set of registers located in the GRF (general register files)
module.

Signed-off-by: Yunzhi Li <lyz@rock-chips.com>

---

Changes in v3:
- Use BIT macro instead of bit shift ops.
- Rename the config entry to PHY_ROCKCHIP_USB.

 drivers/phy/Kconfig            |   7 ++
 drivers/phy/Makefile           |   1 +
 drivers/phy/phy-rockchip-usb.c | 179 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 187 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccad880..8a39d2a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -239,6 +239,13 @@ config PHY_QCOM_IPQ806X_SATA
 	depends on OF
 	select GENERIC_PHY
 
+config PHY_ROCKCHIP_USB2
+	tristate "Rockchip USB2 PHY Driver"
+	depends on ARCH_ROCKCHIP && OF
+	select GENERIC_PHY
+	help
+	  Enable this to support the Rockchip USB 2.0 PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
 	tristate "ST SPEAR1310-MIPHY driver"
 	select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..8a13f72 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -28,6 +28,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2)	+= phy-exynos5250-usb2.o
 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_USB2) += phy-rockchip-usb.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)	+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
new file mode 100644
index 0000000..98af043
--- /dev/null
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -0,0 +1,179 @@
+/*
+ * Rockchip usb PHY driver
+ *
+ * Copyright (C) 2014 Yunzhi Li <lyz@rock-chips.com>
+ * Copyright (C) 2014 ROCKCHIP, Inc.
+ *
+ * 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.
+ *
+ * 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/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+
+#define ROCKCHIP_RK3288_UOC(n)	(0x320 + n * 0x14)
+
+#define SIDDQ_MSK		BIT(13 + 16)
+#define SIDDQ_ON		BIT(13)
+#define SIDDQ_OFF		(0 << 13)
+
+enum rk3288_phy_id {
+	RK3288_OTG,
+	RK3288_HOST0,
+	RK3288_HOST1,
+	RK3288_NUM_PHYS,
+};
+
+struct rockchip_usb_phy {
+	struct regmap *reg_base;
+	unsigned int reg_offset;
+	struct clk *clk;
+	struct phy *phy;
+};
+
+static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
+					   bool siddq)
+{
+	return regmap_write(phy->reg_base, phy->reg_offset,
+			    SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
+}
+
+static int rockchip_usb_phy_power_off(struct phy *_phy)
+{
+	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+	int ret = 0;
+
+	/* Power down usb phy analog blocks by set siddq 1*/
+	ret = rockchip_usb_phy_power(phy, 1);
+	if (ret)
+		return ret;
+
+	clk_disable_unprepare(phy->clk);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int rockchip_usb_phy_power_on(struct phy *_phy)
+{
+	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+	int ret = 0;
+
+	ret = clk_prepare_enable(phy->clk);
+	if (ret)
+		return ret;
+
+	/* Power up usb phy analog blocks by set siddq 0*/
+	ret = rockchip_usb_phy_power(phy, 0);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static struct phy *rockchip_usb_phy_xlate(struct device *dev,
+					struct of_phandle_args *args)
+{
+	struct rockchip_usb_phy *phy_array = dev_get_drvdata(dev);
+
+	if (WARN_ON(args->args[0] == 0 || args->args[0] >= RK3288_NUM_PHYS))
+		return ERR_PTR(-ENODEV);
+
+	return (phy_array + args->args[0])->phy;
+}
+
+static struct phy_ops ops = {
+	.power_on	= rockchip_usb_phy_power_on,
+	.power_off	= rockchip_usb_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int rockchip_usb_phy_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rockchip_usb_phy *rk_phy;
+	struct rockchip_usb_phy *phy_array;
+	struct phy_provider *phy_provider;
+	struct regmap *grf;
+	char clk_name[16];
+	int i;
+
+	grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
+	if (IS_ERR(grf)) {
+		dev_err(&pdev->dev, "Missing rockchip,grf property\n");
+		return PTR_ERR(grf);
+	}
+
+	phy_array = devm_kzalloc(dev, RK3288_NUM_PHYS * sizeof(*rk_phy),
+				 GFP_KERNEL);
+	if (!phy_array)
+		return -ENOMEM;
+
+	for (i = 0; i < RK3288_NUM_PHYS; i++) {
+		rk_phy = &phy_array[i];
+
+		rk_phy->reg_base = grf;
+
+		rk_phy->reg_offset = ROCKCHIP_RK3288_UOC(i);
+
+		snprintf(clk_name, sizeof(clk_name), "usbphy%d", i);
+		rk_phy->clk = devm_clk_get(dev, clk_name);
+		if (IS_ERR(rk_phy->clk)) {
+			dev_warn(dev, "failed to get clock %s\n", clk_name);
+			rk_phy->clk = NULL;
+		}
+
+		rk_phy->phy = devm_phy_create(dev, NULL, &ops);
+		if (IS_ERR(rk_phy->phy)) {
+			dev_err(dev, "failed to create PHY %d\n", i);
+			return PTR_ERR(rk_phy->phy);
+		}
+		phy_set_drvdata(rk_phy->phy, rk_phy);
+	}
+
+	platform_set_drvdata(pdev, phy_array);
+
+	phy_provider = devm_of_phy_provider_register(dev,
+						     rockchip_usb_phy_xlate);
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id rockchip_usb_phy_dt_ids[] = {
+	{ .compatible = "rockchip,rk3288-usb-phy" },
+	{}
+};
+
+MODULE_DEVICE_TABLE(of, rockchip_usb_phy_dt_ids);
+
+static struct platform_driver rockchip_usb_driver = {
+	.probe		= rockchip_usb_phy_probe,
+	.driver		= {
+		.name	= "rockchip-usb-phy",
+		.owner	= THIS_MODULE,
+		.of_match_table = rockchip_usb_phy_dt_ids,
+	},
+};
+
+module_platform_driver(rockchip_usb_driver);
+
+MODULE_AUTHOR("Yunzhi Li <lyz@rock-chips.com>");
+MODULE_DESCRIPTION("Rockchip USB 2.0 PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
2.0.0



^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH v3 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
@ 2014-12-08  9:46   ` Yunzhi Li
  0 siblings, 0 replies; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08  9:46 UTC (permalink / raw)
  To: linux-arm-kernel

This patche to add a generic PHY driver for ROCKCHIP usb PHYs,
currently this driver can support RK3288. The RK3288 SoC have
three independent USB PHY IPs which are all configured through a
set of registers located in the GRF (general register files)
module.

Signed-off-by: Yunzhi Li <lyz@rock-chips.com>

---

Changes in v3:
- Use BIT macro instead of bit shift ops.
- Rename the config entry to PHY_ROCKCHIP_USB.

 drivers/phy/Kconfig            |   7 ++
 drivers/phy/Makefile           |   1 +
 drivers/phy/phy-rockchip-usb.c | 179 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 187 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccad880..8a39d2a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -239,6 +239,13 @@ config PHY_QCOM_IPQ806X_SATA
 	depends on OF
 	select GENERIC_PHY
 
+config PHY_ROCKCHIP_USB2
+	tristate "Rockchip USB2 PHY Driver"
+	depends on ARCH_ROCKCHIP && OF
+	select GENERIC_PHY
+	help
+	  Enable this to support the Rockchip USB 2.0 PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
 	tristate "ST SPEAR1310-MIPHY driver"
 	select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..8a13f72 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -28,6 +28,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2)	+= phy-exynos5250-usb2.o
 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_USB2) += phy-rockchip-usb.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)	+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
new file mode 100644
index 0000000..98af043
--- /dev/null
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -0,0 +1,179 @@
+/*
+ * Rockchip usb PHY driver
+ *
+ * Copyright (C) 2014 Yunzhi Li <lyz@rock-chips.com>
+ * Copyright (C) 2014 ROCKCHIP, Inc.
+ *
+ * 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.
+ *
+ * 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/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+
+#define ROCKCHIP_RK3288_UOC(n)	(0x320 + n * 0x14)
+
+#define SIDDQ_MSK		BIT(13 + 16)
+#define SIDDQ_ON		BIT(13)
+#define SIDDQ_OFF		(0 << 13)
+
+enum rk3288_phy_id {
+	RK3288_OTG,
+	RK3288_HOST0,
+	RK3288_HOST1,
+	RK3288_NUM_PHYS,
+};
+
+struct rockchip_usb_phy {
+	struct regmap *reg_base;
+	unsigned int reg_offset;
+	struct clk *clk;
+	struct phy *phy;
+};
+
+static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
+					   bool siddq)
+{
+	return regmap_write(phy->reg_base, phy->reg_offset,
+			    SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
+}
+
+static int rockchip_usb_phy_power_off(struct phy *_phy)
+{
+	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+	int ret = 0;
+
+	/* Power down usb phy analog blocks by set siddq 1*/
+	ret = rockchip_usb_phy_power(phy, 1);
+	if (ret)
+		return ret;
+
+	clk_disable_unprepare(phy->clk);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int rockchip_usb_phy_power_on(struct phy *_phy)
+{
+	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+	int ret = 0;
+
+	ret = clk_prepare_enable(phy->clk);
+	if (ret)
+		return ret;
+
+	/* Power up usb phy analog blocks by set siddq 0*/
+	ret = rockchip_usb_phy_power(phy, 0);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static struct phy *rockchip_usb_phy_xlate(struct device *dev,
+					struct of_phandle_args *args)
+{
+	struct rockchip_usb_phy *phy_array = dev_get_drvdata(dev);
+
+	if (WARN_ON(args->args[0] == 0 || args->args[0] >= RK3288_NUM_PHYS))
+		return ERR_PTR(-ENODEV);
+
+	return (phy_array + args->args[0])->phy;
+}
+
+static struct phy_ops ops = {
+	.power_on	= rockchip_usb_phy_power_on,
+	.power_off	= rockchip_usb_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int rockchip_usb_phy_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rockchip_usb_phy *rk_phy;
+	struct rockchip_usb_phy *phy_array;
+	struct phy_provider *phy_provider;
+	struct regmap *grf;
+	char clk_name[16];
+	int i;
+
+	grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
+	if (IS_ERR(grf)) {
+		dev_err(&pdev->dev, "Missing rockchip,grf property\n");
+		return PTR_ERR(grf);
+	}
+
+	phy_array = devm_kzalloc(dev, RK3288_NUM_PHYS * sizeof(*rk_phy),
+				 GFP_KERNEL);
+	if (!phy_array)
+		return -ENOMEM;
+
+	for (i = 0; i < RK3288_NUM_PHYS; i++) {
+		rk_phy = &phy_array[i];
+
+		rk_phy->reg_base = grf;
+
+		rk_phy->reg_offset = ROCKCHIP_RK3288_UOC(i);
+
+		snprintf(clk_name, sizeof(clk_name), "usbphy%d", i);
+		rk_phy->clk = devm_clk_get(dev, clk_name);
+		if (IS_ERR(rk_phy->clk)) {
+			dev_warn(dev, "failed to get clock %s\n", clk_name);
+			rk_phy->clk = NULL;
+		}
+
+		rk_phy->phy = devm_phy_create(dev, NULL, &ops);
+		if (IS_ERR(rk_phy->phy)) {
+			dev_err(dev, "failed to create PHY %d\n", i);
+			return PTR_ERR(rk_phy->phy);
+		}
+		phy_set_drvdata(rk_phy->phy, rk_phy);
+	}
+
+	platform_set_drvdata(pdev, phy_array);
+
+	phy_provider = devm_of_phy_provider_register(dev,
+						     rockchip_usb_phy_xlate);
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id rockchip_usb_phy_dt_ids[] = {
+	{ .compatible = "rockchip,rk3288-usb-phy" },
+	{}
+};
+
+MODULE_DEVICE_TABLE(of, rockchip_usb_phy_dt_ids);
+
+static struct platform_driver rockchip_usb_driver = {
+	.probe		= rockchip_usb_phy_probe,
+	.driver		= {
+		.name	= "rockchip-usb-phy",
+		.owner	= THIS_MODULE,
+		.of_match_table = rockchip_usb_phy_dt_ids,
+	},
+};
+
+module_platform_driver(rockchip_usb_driver);
+
+MODULE_AUTHOR("Yunzhi Li <lyz@rock-chips.com>");
+MODULE_DESCRIPTION("Rockchip USB 2.0 PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
2.0.0

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH v3 2/5] Documentation: bindings: add doc for the Rockchip usb PHY
@ 2014-12-08  9:46   ` Yunzhi Li
  0 siblings, 0 replies; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08  9:46 UTC (permalink / raw)
  To: heiko, dianders, romain.perier
  Cc: olof, huangtao, zyw, cf, linux-rockchip, Yunzhi Li, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel

Document the bindings of the Rockchip usb PHY driver.

Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
---

Changes in v3: None

 .../devicetree/bindings/phy/rockchip-usb-phy.txt   | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
new file mode 100644
index 0000000..4574696
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
@@ -0,0 +1,22 @@
+ROCKCHIP USB2 PHY
+
+Required properties:
+ - compatible: rockchip,rk3288-usb-phy
+ - rockchip,grf : phandle to the syscon managing the "general
+   register files"
+ - #phy-cells: must be 1
+
+Optional Properties:
+ - clocks : phandle + clock specifier for the phy clocks
+ - clock-names :
+		"usbphy0" - PHY clock for OTG controller
+		"usbphy1" - PHY clock for HOST0 controller
+		"usbphy2" - PHY clock for HOST1 controller
+
+Example:
+
+usbphy: phy {
+	#phy-cells = <1>;
+	compatible = "rockchip,rk3288-usb-phy";
+	rockchip,grf = <&grf>;
+};
-- 
2.0.0



^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH v3 2/5] Documentation: bindings: add doc for the Rockchip usb PHY
@ 2014-12-08  9:46   ` Yunzhi Li
  0 siblings, 0 replies; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08  9:46 UTC (permalink / raw)
  To: heiko-4mtYJXux2i+zQB+pC5nmwQ, dianders-F7+t8E8rja9g9hUCZPvPmw,
	romain.perier-Re5JQEeQqe8AvxtiuMwx3w
  Cc: olof-nZhT3qVonbNeoWH0uzbU5w, huangtao-TNX95d0MmH7DzftRWevZcw,
	zyw-TNX95d0MmH7DzftRWevZcw, cf-TNX95d0MmH7DzftRWevZcw,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Yunzhi Li,
	Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

Document the bindings of the Rockchip usb PHY driver.

Signed-off-by: Yunzhi Li <lyz-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---

Changes in v3: None

 .../devicetree/bindings/phy/rockchip-usb-phy.txt   | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
new file mode 100644
index 0000000..4574696
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
@@ -0,0 +1,22 @@
+ROCKCHIP USB2 PHY
+
+Required properties:
+ - compatible: rockchip,rk3288-usb-phy
+ - rockchip,grf : phandle to the syscon managing the "general
+   register files"
+ - #phy-cells: must be 1
+
+Optional Properties:
+ - clocks : phandle + clock specifier for the phy clocks
+ - clock-names :
+		"usbphy0" - PHY clock for OTG controller
+		"usbphy1" - PHY clock for HOST0 controller
+		"usbphy2" - PHY clock for HOST1 controller
+
+Example:
+
+usbphy: phy {
+	#phy-cells = <1>;
+	compatible = "rockchip,rk3288-usb-phy";
+	rockchip,grf = <&grf>;
+};
-- 
2.0.0


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH v3 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.
  2014-12-08  9:46 ` Yunzhi Li
                   ` (2 preceding siblings ...)
  (?)
@ 2014-12-08  9:46 ` Yunzhi Li
  2014-12-08 20:55   ` Paul Zimmerman
  -1 siblings, 1 reply; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08  9:46 UTC (permalink / raw)
  To: heiko, dianders, romain.perier
  Cc: olof, huangtao, zyw, cf, linux-rockchip, Yunzhi Li,
	Paul Zimmerman, Greg Kroah-Hartman, linux-usb, linux-kernel

Get PHY parameters from devicetree and power off usb PHY during
system suspend.

Signed-off-by: Yunzhi Li <lyz@rock-chips.com>

---

Changes in v3:
- Fix coding style: both branches of the if() which only one
  branch of the conditional statement is a single statement should
  have braces.
- No need to test dwc2->phy for NULL before calling generic phy
  APIs.

 drivers/usb/dwc2/gadget.c   | 33 ++++++++++++---------------------
 drivers/usb/dwc2/platform.c | 36 ++++++++++++++++++++++++++++++++++--
 2 files changed, 46 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 200168e..2601c61 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3410,8 +3410,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
 {
 	struct device *dev = hsotg->dev;
 	struct s3c_hsotg_plat *plat = dev->platform_data;
-	struct phy *phy;
-	struct usb_phy *uphy;
 	struct s3c_hsotg_ep *eps;
 	int epnum;
 	int ret;
@@ -3421,30 +3419,23 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
 	hsotg->phyif = GUSBCFG_PHYIF16;
 
 	/*
-	 * Attempt to find a generic PHY, then look for an old style
-	 * USB PHY, finally fall back to pdata
+	 * If platform probe couldn't find a generic PHY or an old style
+	 * USB PHY, fall back to pdata
 	 */
-	phy = devm_phy_get(dev, "usb2-phy");
-	if (IS_ERR(phy)) {
-		uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-		if (IS_ERR(uphy)) {
-			/* Fallback for pdata */
-			plat = dev_get_platdata(dev);
-			if (!plat) {
-				dev_err(dev,
-				"no platform data or transceiver defined\n");
-				return -EPROBE_DEFER;
-			}
-			hsotg->plat = plat;
-		} else
-			hsotg->uphy = uphy;
-	} else {
-		hsotg->phy = phy;
+	if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
+		plat = dev_get_platdata(dev);
+		if (!plat) {
+			dev_err(dev,
+			"no platform data or transceiver defined\n");
+			return -EPROBE_DEFER;
+		}
+		hsotg->plat = plat;
+	} else if (hsotg->phy) {
 		/*
 		 * If using the generic PHY framework, check if the PHY bus
 		 * width is 8-bit and set the phyif appropriately.
 		 */
-		if (phy_get_bus_width(phy) == 8)
+		if (phy_get_bus_width(hsotg->phy) == 8)
 			hsotg->phyif = GUSBCFG_PHYIF8;
 	}
 
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 6a795aa..ae095f0 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -155,6 +155,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
 	struct dwc2_core_params defparams;
 	struct dwc2_hsotg *hsotg;
 	struct resource *res;
+	struct phy *phy;
+	struct usb_phy *uphy;
 	int retval;
 	int irq;
 
@@ -212,6 +214,24 @@ static int dwc2_driver_probe(struct platform_device *dev)
 
 	hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
 
+	/*
+	 * Attempt to find a generic PHY, then look for an old style
+	 * USB PHY
+	 */
+	phy = devm_phy_get(&dev->dev, "usb2-phy");
+	if (IS_ERR(phy)) {
+		hsotg->phy = NULL;
+		uphy = devm_usb_get_phy(&dev->dev, USB_PHY_TYPE_USB2);
+		if (IS_ERR(uphy))
+			hsotg->uphy = NULL;
+		else
+			hsotg->uphy = uphy;
+	} else {
+		hsotg->phy = phy;
+		phy_power_on(hsotg->phy);
+		phy_init(hsotg->phy);
+	}
+
 	spin_lock_init(&hsotg->lock);
 	mutex_init(&hsotg->init_mutex);
 	retval = dwc2_gadget_init(hsotg, irq);
@@ -231,8 +251,15 @@ static int __maybe_unused dwc2_suspend(struct device *dev)
 	struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
 	int ret = 0;
 
-	if (dwc2_is_device_mode(dwc2))
+	if (dwc2_is_device_mode(dwc2)) {
 		ret = s3c_hsotg_suspend(dwc2);
+	} else {
+		if (dwc2->lx_state == DWC2_L0)
+			return 0;
+		phy_exit(dwc2->phy);
+		phy_power_off(dwc2->phy);
+
+	}
 	return ret;
 }
 
@@ -241,8 +268,13 @@ static int __maybe_unused dwc2_resume(struct device *dev)
 	struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
 	int ret = 0;
 
-	if (dwc2_is_device_mode(dwc2))
+	if (dwc2_is_device_mode(dwc2)) {
 		ret = s3c_hsotg_resume(dwc2);
+	} else {
+		phy_power_on(dwc2->phy);
+		phy_init(dwc2->phy);
+
+	}
 	return ret;
 }
 
-- 
2.0.0



^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH v3 4/5] ARM: dts: add rk3288 usb PHY
  2014-12-08  9:46 ` Yunzhi Li
@ 2014-12-08  9:46   ` Yunzhi Li
  -1 siblings, 0 replies; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08  9:46 UTC (permalink / raw)
  To: heiko, dianders, romain.perier
  Cc: olof, huangtao, zyw, cf, linux-rockchip, Yunzhi Li, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
	linux-arm-kernel, devicetree, linux-kernel

This patch adds a device_node for RK3288 SoC usb phy. It also
defines the phy to be used by three usb controllers: usb_host0/1
and usb_otg.

Signed-off-by: Yunzhi Li <lyz@rock-chips.com>

---

Changes in v3:
- Add more context about the changes in the long description.

 arch/arm/boot/dts/rk3288.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 874e66d..a663c4c 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -329,12 +329,21 @@
 		status = "disabled";
 	};
 
+	usbphy: phy {
+		#phy-cells = <1>;
+		compatible = "rockchip,rk3288-usb-phy";
+		rockchip,grf = <&grf>;
+		status = "disabled";
+	};
+
 	usb_host0_ehci: usb@ff500000 {
 		compatible = "generic-ehci";
 		reg = <0xff500000 0x100>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru HCLK_USBHOST0>;
 		clock-names = "usbhost";
+		phys = <&usbphy 1>;
+		phy-names = "usb";
 		status = "disabled";
 	};
 
@@ -347,6 +356,8 @@
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru HCLK_USBHOST1>;
 		clock-names = "otg";
+		phys = <&usbphy 2>;
+		phy-names = "usb2-phy";
 		status = "disabled";
 	};
 
@@ -357,6 +368,8 @@
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru HCLK_OTG0>;
 		clock-names = "otg";
+		phys = <&usbphy 0>;
+		phy-names = "usb2-phy";
 		status = "disabled";
 	};
 
-- 
2.0.0



^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH v3 4/5] ARM: dts: add rk3288 usb PHY
@ 2014-12-08  9:46   ` Yunzhi Li
  0 siblings, 0 replies; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08  9:46 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds a device_node for RK3288 SoC usb phy. It also
defines the phy to be used by three usb controllers: usb_host0/1
and usb_otg.

Signed-off-by: Yunzhi Li <lyz@rock-chips.com>

---

Changes in v3:
- Add more context about the changes in the long description.

 arch/arm/boot/dts/rk3288.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 874e66d..a663c4c 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -329,12 +329,21 @@
 		status = "disabled";
 	};
 
+	usbphy: phy {
+		#phy-cells = <1>;
+		compatible = "rockchip,rk3288-usb-phy";
+		rockchip,grf = <&grf>;
+		status = "disabled";
+	};
+
 	usb_host0_ehci: usb at ff500000 {
 		compatible = "generic-ehci";
 		reg = <0xff500000 0x100>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru HCLK_USBHOST0>;
 		clock-names = "usbhost";
+		phys = <&usbphy 1>;
+		phy-names = "usb";
 		status = "disabled";
 	};
 
@@ -347,6 +356,8 @@
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru HCLK_USBHOST1>;
 		clock-names = "otg";
+		phys = <&usbphy 2>;
+		phy-names = "usb2-phy";
 		status = "disabled";
 	};
 
@@ -357,6 +368,8 @@
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru HCLK_OTG0>;
 		clock-names = "otg";
+		phys = <&usbphy 0>;
+		phy-names = "usb2-phy";
 		status = "disabled";
 	};
 
-- 
2.0.0

^ permalink raw reply related	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
  2014-12-08  9:46   ` Yunzhi Li
  (?)
@ 2014-12-08  9:57     ` Kishon Vijay Abraham I
  -1 siblings, 0 replies; 40+ messages in thread
From: Kishon Vijay Abraham I @ 2014-12-08  9:57 UTC (permalink / raw)
  To: Yunzhi Li, heiko, dianders, romain.perier
  Cc: olof, huangtao, zyw, cf, linux-rockchip, Grant Likely,
	Rob Herring, linux-kernel, linux-arm-kernel, devicetree

Hi,

On Monday 08 December 2014 03:16 PM, Yunzhi Li wrote:
> This patche to add a generic PHY driver for ROCKCHIP usb PHYs,

%s/patche/patch
> currently this driver can support RK3288. The RK3288 SoC have
> three independent USB PHY IPs which are all configured through a
> set of registers located in the GRF (general register files)
> module.
> 
> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
> 
> ---
> 
> Changes in v3:
> - Use BIT macro instead of bit shift ops.
> - Rename the config entry to PHY_ROCKCHIP_USB.
> 
>  drivers/phy/Kconfig            |   7 ++
>  drivers/phy/Makefile           |   1 +
>  drivers/phy/phy-rockchip-usb.c | 179 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 187 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-usb.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index ccad880..8a39d2a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -239,6 +239,13 @@ config PHY_QCOM_IPQ806X_SATA
>  	depends on OF
>  	select GENERIC_PHY
>  
> +config PHY_ROCKCHIP_USB2
> +	tristate "Rockchip USB2 PHY Driver"
> +	depends on ARCH_ROCKCHIP && OF
> +	select GENERIC_PHY
> +	help
> +	  Enable this to support the Rockchip USB 2.0 PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>  	tristate "ST SPEAR1310-MIPHY driver"
>  	select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index aa74f96..8a13f72 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -28,6 +28,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2)	+= phy-exynos5250-usb2.o
>  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_USB2) += phy-rockchip-usb.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)	+= phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
> new file mode 100644
> index 0000000..98af043
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -0,0 +1,179 @@
> +/*
> + * Rockchip usb PHY driver
> + *
> + * Copyright (C) 2014 Yunzhi Li <lyz@rock-chips.com>
> + * Copyright (C) 2014 ROCKCHIP, Inc.
> + *
> + * 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.
> + *
> + * 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/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> +
> +#define ROCKCHIP_RK3288_UOC(n)	(0x320 + n * 0x14)
> +
> +#define SIDDQ_MSK		BIT(13 + 16)

This doesn't look correct. Won't this mask bit no:29?
> +#define SIDDQ_ON		BIT(13)
> +#define SIDDQ_OFF		(0 << 13)
> +
> +enum rk3288_phy_id {

rockchip_usb_phy_id?
> +	RK3288_OTG,
> +	RK3288_HOST0,
> +	RK3288_HOST1,
> +	RK3288_NUM_PHYS,
> +};
> +
> +struct rockchip_usb_phy {
> +	struct regmap *reg_base;
> +	unsigned int reg_offset;
> +	struct clk *clk;
> +	struct phy *phy;
> +};
> +
> +static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
> +					   bool siddq)
> +{
> +	return regmap_write(phy->reg_base, phy->reg_offset,
> +			    SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
> +}
> +
> +static int rockchip_usb_phy_power_off(struct phy *_phy)
> +{
> +	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> +	int ret = 0;
> +
> +	/* Power down usb phy analog blocks by set siddq 1*/
> +	ret = rockchip_usb_phy_power(phy, 1);
> +	if (ret)
> +		return ret;
> +
> +	clk_disable_unprepare(phy->clk);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static int rockchip_usb_phy_power_on(struct phy *_phy)
> +{
> +	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> +	int ret = 0;
> +
> +	ret = clk_prepare_enable(phy->clk);
> +	if (ret)
> +		return ret;
> +
> +	/* Power up usb phy analog blocks by set siddq 0*/
> +	ret = rockchip_usb_phy_power(phy, 0);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static struct phy *rockchip_usb_phy_xlate(struct device *dev,
> +					struct of_phandle_args *args)
> +{
> +	struct rockchip_usb_phy *phy_array = dev_get_drvdata(dev);
> +
> +	if (WARN_ON(args->args[0] == 0 || args->args[0] >= RK3288_NUM_PHYS))
> +		return ERR_PTR(-ENODEV);
> +
> +	return (phy_array + args->args[0])->phy;
> +}
> +
> +static struct phy_ops ops = {
> +	.power_on	= rockchip_usb_phy_power_on,
> +	.power_off	= rockchip_usb_phy_power_off,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int rockchip_usb_phy_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct rockchip_usb_phy *rk_phy;
> +	struct rockchip_usb_phy *phy_array;
> +	struct phy_provider *phy_provider;
> +	struct regmap *grf;
> +	char clk_name[16];
> +	int i;
> +
> +	grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
> +	if (IS_ERR(grf)) {
> +		dev_err(&pdev->dev, "Missing rockchip,grf property\n");
> +		return PTR_ERR(grf);
> +	}
> +
> +	phy_array = devm_kzalloc(dev, RK3288_NUM_PHYS * sizeof(*rk_phy),
> +				 GFP_KERNEL);
> +	if (!phy_array)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < RK3288_NUM_PHYS; i++) {

Don't hardcode NUM_PHYS. All this has to come from dt. Model each PHYs as
subnode of the phy provider node and use it here.

Thanks
Kishon

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
@ 2014-12-08  9:57     ` Kishon Vijay Abraham I
  0 siblings, 0 replies; 40+ messages in thread
From: Kishon Vijay Abraham I @ 2014-12-08  9:57 UTC (permalink / raw)
  To: Yunzhi Li, heiko, dianders, romain.perier
  Cc: huangtao, devicetree, linux-rockchip, linux-kernel, zyw,
	Rob Herring, olof, cf, linux-arm-kernel, Grant Likely

Hi,

On Monday 08 December 2014 03:16 PM, Yunzhi Li wrote:
> This patche to add a generic PHY driver for ROCKCHIP usb PHYs,

%s/patche/patch
> currently this driver can support RK3288. The RK3288 SoC have
> three independent USB PHY IPs which are all configured through a
> set of registers located in the GRF (general register files)
> module.
> 
> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
> 
> ---
> 
> Changes in v3:
> - Use BIT macro instead of bit shift ops.
> - Rename the config entry to PHY_ROCKCHIP_USB.
> 
>  drivers/phy/Kconfig            |   7 ++
>  drivers/phy/Makefile           |   1 +
>  drivers/phy/phy-rockchip-usb.c | 179 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 187 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-usb.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index ccad880..8a39d2a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -239,6 +239,13 @@ config PHY_QCOM_IPQ806X_SATA
>  	depends on OF
>  	select GENERIC_PHY
>  
> +config PHY_ROCKCHIP_USB2
> +	tristate "Rockchip USB2 PHY Driver"
> +	depends on ARCH_ROCKCHIP && OF
> +	select GENERIC_PHY
> +	help
> +	  Enable this to support the Rockchip USB 2.0 PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>  	tristate "ST SPEAR1310-MIPHY driver"
>  	select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index aa74f96..8a13f72 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -28,6 +28,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2)	+= phy-exynos5250-usb2.o
>  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_USB2) += phy-rockchip-usb.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)	+= phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
> new file mode 100644
> index 0000000..98af043
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -0,0 +1,179 @@
> +/*
> + * Rockchip usb PHY driver
> + *
> + * Copyright (C) 2014 Yunzhi Li <lyz@rock-chips.com>
> + * Copyright (C) 2014 ROCKCHIP, Inc.
> + *
> + * 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.
> + *
> + * 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/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> +
> +#define ROCKCHIP_RK3288_UOC(n)	(0x320 + n * 0x14)
> +
> +#define SIDDQ_MSK		BIT(13 + 16)

This doesn't look correct. Won't this mask bit no:29?
> +#define SIDDQ_ON		BIT(13)
> +#define SIDDQ_OFF		(0 << 13)
> +
> +enum rk3288_phy_id {

rockchip_usb_phy_id?
> +	RK3288_OTG,
> +	RK3288_HOST0,
> +	RK3288_HOST1,
> +	RK3288_NUM_PHYS,
> +};
> +
> +struct rockchip_usb_phy {
> +	struct regmap *reg_base;
> +	unsigned int reg_offset;
> +	struct clk *clk;
> +	struct phy *phy;
> +};
> +
> +static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
> +					   bool siddq)
> +{
> +	return regmap_write(phy->reg_base, phy->reg_offset,
> +			    SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
> +}
> +
> +static int rockchip_usb_phy_power_off(struct phy *_phy)
> +{
> +	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> +	int ret = 0;
> +
> +	/* Power down usb phy analog blocks by set siddq 1*/
> +	ret = rockchip_usb_phy_power(phy, 1);
> +	if (ret)
> +		return ret;
> +
> +	clk_disable_unprepare(phy->clk);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static int rockchip_usb_phy_power_on(struct phy *_phy)
> +{
> +	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> +	int ret = 0;
> +
> +	ret = clk_prepare_enable(phy->clk);
> +	if (ret)
> +		return ret;
> +
> +	/* Power up usb phy analog blocks by set siddq 0*/
> +	ret = rockchip_usb_phy_power(phy, 0);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static struct phy *rockchip_usb_phy_xlate(struct device *dev,
> +					struct of_phandle_args *args)
> +{
> +	struct rockchip_usb_phy *phy_array = dev_get_drvdata(dev);
> +
> +	if (WARN_ON(args->args[0] == 0 || args->args[0] >= RK3288_NUM_PHYS))
> +		return ERR_PTR(-ENODEV);
> +
> +	return (phy_array + args->args[0])->phy;
> +}
> +
> +static struct phy_ops ops = {
> +	.power_on	= rockchip_usb_phy_power_on,
> +	.power_off	= rockchip_usb_phy_power_off,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int rockchip_usb_phy_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct rockchip_usb_phy *rk_phy;
> +	struct rockchip_usb_phy *phy_array;
> +	struct phy_provider *phy_provider;
> +	struct regmap *grf;
> +	char clk_name[16];
> +	int i;
> +
> +	grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
> +	if (IS_ERR(grf)) {
> +		dev_err(&pdev->dev, "Missing rockchip,grf property\n");
> +		return PTR_ERR(grf);
> +	}
> +
> +	phy_array = devm_kzalloc(dev, RK3288_NUM_PHYS * sizeof(*rk_phy),
> +				 GFP_KERNEL);
> +	if (!phy_array)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < RK3288_NUM_PHYS; i++) {

Don't hardcode NUM_PHYS. All this has to come from dt. Model each PHYs as
subnode of the phy provider node and use it here.

Thanks
Kishon

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
@ 2014-12-08  9:57     ` Kishon Vijay Abraham I
  0 siblings, 0 replies; 40+ messages in thread
From: Kishon Vijay Abraham I @ 2014-12-08  9:57 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Monday 08 December 2014 03:16 PM, Yunzhi Li wrote:
> This patche to add a generic PHY driver for ROCKCHIP usb PHYs,

%s/patche/patch
> currently this driver can support RK3288. The RK3288 SoC have
> three independent USB PHY IPs which are all configured through a
> set of registers located in the GRF (general register files)
> module.
> 
> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
> 
> ---
> 
> Changes in v3:
> - Use BIT macro instead of bit shift ops.
> - Rename the config entry to PHY_ROCKCHIP_USB.
> 
>  drivers/phy/Kconfig            |   7 ++
>  drivers/phy/Makefile           |   1 +
>  drivers/phy/phy-rockchip-usb.c | 179 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 187 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-usb.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index ccad880..8a39d2a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -239,6 +239,13 @@ config PHY_QCOM_IPQ806X_SATA
>  	depends on OF
>  	select GENERIC_PHY
>  
> +config PHY_ROCKCHIP_USB2
> +	tristate "Rockchip USB2 PHY Driver"
> +	depends on ARCH_ROCKCHIP && OF
> +	select GENERIC_PHY
> +	help
> +	  Enable this to support the Rockchip USB 2.0 PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>  	tristate "ST SPEAR1310-MIPHY driver"
>  	select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index aa74f96..8a13f72 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -28,6 +28,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2)	+= phy-exynos5250-usb2.o
>  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_USB2) += phy-rockchip-usb.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)	+= phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
> new file mode 100644
> index 0000000..98af043
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -0,0 +1,179 @@
> +/*
> + * Rockchip usb PHY driver
> + *
> + * Copyright (C) 2014 Yunzhi Li <lyz@rock-chips.com>
> + * Copyright (C) 2014 ROCKCHIP, Inc.
> + *
> + * 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.
> + *
> + * 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/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> +
> +#define ROCKCHIP_RK3288_UOC(n)	(0x320 + n * 0x14)
> +
> +#define SIDDQ_MSK		BIT(13 + 16)

This doesn't look correct. Won't this mask bit no:29?
> +#define SIDDQ_ON		BIT(13)
> +#define SIDDQ_OFF		(0 << 13)
> +
> +enum rk3288_phy_id {

rockchip_usb_phy_id?
> +	RK3288_OTG,
> +	RK3288_HOST0,
> +	RK3288_HOST1,
> +	RK3288_NUM_PHYS,
> +};
> +
> +struct rockchip_usb_phy {
> +	struct regmap *reg_base;
> +	unsigned int reg_offset;
> +	struct clk *clk;
> +	struct phy *phy;
> +};
> +
> +static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
> +					   bool siddq)
> +{
> +	return regmap_write(phy->reg_base, phy->reg_offset,
> +			    SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
> +}
> +
> +static int rockchip_usb_phy_power_off(struct phy *_phy)
> +{
> +	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> +	int ret = 0;
> +
> +	/* Power down usb phy analog blocks by set siddq 1*/
> +	ret = rockchip_usb_phy_power(phy, 1);
> +	if (ret)
> +		return ret;
> +
> +	clk_disable_unprepare(phy->clk);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static int rockchip_usb_phy_power_on(struct phy *_phy)
> +{
> +	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> +	int ret = 0;
> +
> +	ret = clk_prepare_enable(phy->clk);
> +	if (ret)
> +		return ret;
> +
> +	/* Power up usb phy analog blocks by set siddq 0*/
> +	ret = rockchip_usb_phy_power(phy, 0);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static struct phy *rockchip_usb_phy_xlate(struct device *dev,
> +					struct of_phandle_args *args)
> +{
> +	struct rockchip_usb_phy *phy_array = dev_get_drvdata(dev);
> +
> +	if (WARN_ON(args->args[0] == 0 || args->args[0] >= RK3288_NUM_PHYS))
> +		return ERR_PTR(-ENODEV);
> +
> +	return (phy_array + args->args[0])->phy;
> +}
> +
> +static struct phy_ops ops = {
> +	.power_on	= rockchip_usb_phy_power_on,
> +	.power_off	= rockchip_usb_phy_power_off,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int rockchip_usb_phy_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct rockchip_usb_phy *rk_phy;
> +	struct rockchip_usb_phy *phy_array;
> +	struct phy_provider *phy_provider;
> +	struct regmap *grf;
> +	char clk_name[16];
> +	int i;
> +
> +	grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
> +	if (IS_ERR(grf)) {
> +		dev_err(&pdev->dev, "Missing rockchip,grf property\n");
> +		return PTR_ERR(grf);
> +	}
> +
> +	phy_array = devm_kzalloc(dev, RK3288_NUM_PHYS * sizeof(*rk_phy),
> +				 GFP_KERNEL);
> +	if (!phy_array)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < RK3288_NUM_PHYS; i++) {

Don't hardcode NUM_PHYS. All this has to come from dt. Model each PHYs as
subnode of the phy provider node and use it here.

Thanks
Kishon

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
  2014-12-08  9:57     ` Kishon Vijay Abraham I
@ 2014-12-08 11:04       ` Yunzhi Li
  -1 siblings, 0 replies; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08 11:04 UTC (permalink / raw)
  To: Kishon Vijay Abraham I, heiko, dianders, romain.perier
  Cc: olof, huangtao, zyw, cf, linux-rockchip, Grant Likely,
	Rob Herring, linux-kernel, linux-arm-kernel, devicetree

Hi Kishon :

On 2014/12/8 17:57, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 08 December 2014 03:16 PM, Yunzhi Li wrote:
>> This patche to add a generic PHY driver for ROCKCHIP usb PHYs,
> %s/patche/patch
Sorry for this typo.
>> +#include <linux/reset.h>
>> +#include <linux/regmap.h>
>> +#include <linux/mfd/syscon.h>
>> +
>> +#define ROCKCHIP_RK3288_UOC(n)	(0x320 + n * 0x14)
>> +
>> +#define SIDDQ_MSK		BIT(13 + 16)
> This doesn't look correct. Won't this mask bit no:29?
The higher 16-bit of this register is used for write-protect, only if 
BIT(13 + 16)
set to 1 the BIT(13) can be written. I will add some comments here in 
the next
version, to prevent others confused. ok ?

>> [...]
>>
>> +static int rockchip_usb_phy_probe(struct platform_device *pdev)
>> +{
>> +	struct device *dev = &pdev->dev;
>> +	struct rockchip_usb_phy *rk_phy;
>> +	struct rockchip_usb_phy *phy_array;
>> +	struct phy_provider *phy_provider;
>> +	struct regmap *grf;
>> +	char clk_name[16];
>> +	int i;
>> +
>> +	grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
>> +	if (IS_ERR(grf)) {
>> +		dev_err(&pdev->dev, "Missing rockchip,grf property\n");
>> +		return PTR_ERR(grf);
>> +	}
>> +
>> +	phy_array = devm_kzalloc(dev, RK3288_NUM_PHYS * sizeof(*rk_phy),
>> +				 GFP_KERNEL);
>> +	if (!phy_array)
>> +		return -ENOMEM;
>> +
>> +	for (i = 0; i < RK3288_NUM_PHYS; i++) {
> Don't hardcode NUM_PHYS. All this has to come from dt. Model each PHYs as
> subnode of the phy provider node and use it here.
I got it, it should be like this, model each PHYs as sub node and use 
of_get_child_count() to get the number of phys.





^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
@ 2014-12-08 11:04       ` Yunzhi Li
  0 siblings, 0 replies; 40+ messages in thread
From: Yunzhi Li @ 2014-12-08 11:04 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Kishon :

On 2014/12/8 17:57, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 08 December 2014 03:16 PM, Yunzhi Li wrote:
>> This patche to add a generic PHY driver for ROCKCHIP usb PHYs,
> %s/patche/patch
Sorry for this typo.
>> +#include <linux/reset.h>
>> +#include <linux/regmap.h>
>> +#include <linux/mfd/syscon.h>
>> +
>> +#define ROCKCHIP_RK3288_UOC(n)	(0x320 + n * 0x14)
>> +
>> +#define SIDDQ_MSK		BIT(13 + 16)
> This doesn't look correct. Won't this mask bit no:29?
The higher 16-bit of this register is used for write-protect, only if 
BIT(13 + 16)
set to 1 the BIT(13) can be written. I will add some comments here in 
the next
version, to prevent others confused. ok ?

>> [...]
>>
>> +static int rockchip_usb_phy_probe(struct platform_device *pdev)
>> +{
>> +	struct device *dev = &pdev->dev;
>> +	struct rockchip_usb_phy *rk_phy;
>> +	struct rockchip_usb_phy *phy_array;
>> +	struct phy_provider *phy_provider;
>> +	struct regmap *grf;
>> +	char clk_name[16];
>> +	int i;
>> +
>> +	grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
>> +	if (IS_ERR(grf)) {
>> +		dev_err(&pdev->dev, "Missing rockchip,grf property\n");
>> +		return PTR_ERR(grf);
>> +	}
>> +
>> +	phy_array = devm_kzalloc(dev, RK3288_NUM_PHYS * sizeof(*rk_phy),
>> +				 GFP_KERNEL);
>> +	if (!phy_array)
>> +		return -ENOMEM;
>> +
>> +	for (i = 0; i < RK3288_NUM_PHYS; i++) {
> Don't hardcode NUM_PHYS. All this has to come from dt. Model each PHYs as
> subnode of the phy provider node and use it here.
I got it, it should be like this, model each PHYs as sub node and use 
of_get_child_count() to get the number of phys.

^ permalink raw reply	[flat|nested] 40+ messages in thread

* RE: [PATCH v3 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.
  2014-12-08  9:46 ` [PATCH v3 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver Yunzhi Li
@ 2014-12-08 20:55   ` Paul Zimmerman
  0 siblings, 0 replies; 40+ messages in thread
From: Paul Zimmerman @ 2014-12-08 20:55 UTC (permalink / raw)
  To: Yunzhi Li, heiko, dianders, romain.perier
  Cc: olof, huangtao, zyw, cf, linux-rockchip, Greg Kroah-Hartman,
	linux-usb, linux-kernel

> From: Yunzhi Li [mailto:lyz@rock-chips.com]
> Sent: Monday, December 08, 2014 1:46 AM
> 
> Get PHY parameters from devicetree and power off usb PHY during
> system suspend.
> 
> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
> 
> ---
> 
> Changes in v3:
> - Fix coding style: both branches of the if() which only one
>   branch of the conditional statement is a single statement should
>   have braces.
> - No need to test dwc2->phy for NULL before calling generic phy
>   APIs.
> 
>  drivers/usb/dwc2/gadget.c   | 33 ++++++++++++---------------------
>  drivers/usb/dwc2/platform.c | 36 ++++++++++++++++++++++++++++++++++--
>  2 files changed, 46 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 200168e..2601c61 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -3410,8 +3410,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
>  {
>  	struct device *dev = hsotg->dev;
>  	struct s3c_hsotg_plat *plat = dev->platform_data;
> -	struct phy *phy;
> -	struct usb_phy *uphy;
>  	struct s3c_hsotg_ep *eps;
>  	int epnum;
>  	int ret;
> @@ -3421,30 +3419,23 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
>  	hsotg->phyif = GUSBCFG_PHYIF16;
> 
>  	/*
> -	 * Attempt to find a generic PHY, then look for an old style
> -	 * USB PHY, finally fall back to pdata
> +	 * If platform probe couldn't find a generic PHY or an old style
> +	 * USB PHY, fall back to pdata
>  	 */
> -	phy = devm_phy_get(dev, "usb2-phy");
> -	if (IS_ERR(phy)) {
> -		uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> -		if (IS_ERR(uphy)) {
> -			/* Fallback for pdata */
> -			plat = dev_get_platdata(dev);
> -			if (!plat) {
> -				dev_err(dev,
> -				"no platform data or transceiver defined\n");
> -				return -EPROBE_DEFER;
> -			}
> -			hsotg->plat = plat;
> -		} else
> -			hsotg->uphy = uphy;
> -	} else {
> -		hsotg->phy = phy;
> +	if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
> +		plat = dev_get_platdata(dev);
> +		if (!plat) {
> +			dev_err(dev,
> +			"no platform data or transceiver defined\n");
> +			return -EPROBE_DEFER;
> +		}
> +		hsotg->plat = plat;
> +	} else if (hsotg->phy) {
>  		/*
>  		 * If using the generic PHY framework, check if the PHY bus
>  		 * width is 8-bit and set the phyif appropriately.
>  		 */
> -		if (phy_get_bus_width(phy) == 8)
> +		if (phy_get_bus_width(hsotg->phy) == 8)
>  			hsotg->phyif = GUSBCFG_PHYIF8;
>  	}
> 
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 6a795aa..ae095f0 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -155,6 +155,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
>  	struct dwc2_core_params defparams;
>  	struct dwc2_hsotg *hsotg;
>  	struct resource *res;
> +	struct phy *phy;
> +	struct usb_phy *uphy;
>  	int retval;
>  	int irq;
> 
> @@ -212,6 +214,24 @@ static int dwc2_driver_probe(struct platform_device *dev)
> 
>  	hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
> 
> +	/*
> +	 * Attempt to find a generic PHY, then look for an old style
> +	 * USB PHY
> +	 */
> +	phy = devm_phy_get(&dev->dev, "usb2-phy");
> +	if (IS_ERR(phy)) {
> +		hsotg->phy = NULL;
> +		uphy = devm_usb_get_phy(&dev->dev, USB_PHY_TYPE_USB2);
> +		if (IS_ERR(uphy))
> +			hsotg->uphy = NULL;
> +		else
> +			hsotg->uphy = uphy;
> +	} else {
> +		hsotg->phy = phy;
> +		phy_power_on(hsotg->phy);
> +		phy_init(hsotg->phy);
> +	}
> +
>  	spin_lock_init(&hsotg->lock);
>  	mutex_init(&hsotg->init_mutex);
>  	retval = dwc2_gadget_init(hsotg, irq);
> @@ -231,8 +251,15 @@ static int __maybe_unused dwc2_suspend(struct device *dev)
>  	struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
>  	int ret = 0;
> 
> -	if (dwc2_is_device_mode(dwc2))
> +	if (dwc2_is_device_mode(dwc2)) {
>  		ret = s3c_hsotg_suspend(dwc2);
> +	} else {
> +		if (dwc2->lx_state == DWC2_L0)
> +			return 0;
> +		phy_exit(dwc2->phy);
> +		phy_power_off(dwc2->phy);
> +
> +	}
>  	return ret;
>  }
> 
> @@ -241,8 +268,13 @@ static int __maybe_unused dwc2_resume(struct device *dev)
>  	struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
>  	int ret = 0;
> 
> -	if (dwc2_is_device_mode(dwc2))
> +	if (dwc2_is_device_mode(dwc2)) {
>  		ret = s3c_hsotg_resume(dwc2);
> +	} else {
> +		phy_power_on(dwc2->phy);
> +		phy_init(dwc2->phy);
> +
> +	}
>  	return ret;
>  }
> 

Acked-by: Paul Zimmerman <paulz@synopsys.com>


^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 0/5]
  2023-05-29 15:35 ` Bernhard Rosenkränzer
@ 2023-05-29 16:30   ` Matthias Brugger
  -1 siblings, 0 replies; 40+ messages in thread
From: Matthias Brugger @ 2023-05-29 16:30 UTC (permalink / raw)
  To: Bernhard Rosenkränzer, daniel.lezcano,
	angelogioacchino.delregno, rafael, amitk, rui.zhang, robh+dt,
	krzystof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel
  Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek,
	devicetree, wenst, james.lo, rex-bc.chen, nfraprado, abailon,
	amergnat, khilman

Hi Bernhard,

Please resend with a subject line for the cover letter.

Regards,
Matthias

On 29/05/2023 17:35, Bernhard Rosenkränzer wrote:
> From: Balsam CHIHI <bchihi@baylibre.com>
> 
> Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC.
> Also, add Suspend and Resume support to LVTS Driver (all SoCs),
> and update the documentation that describes the Calibration Data Offsets.
> 
> Changelog:
>      v3 :
>          - Rebased :
>              base-commit: 6a3d37b4d885129561e1cef361216f00472f7d2e
>          - Fix issues in v2 pointed out by Nícolas F. R. A. Prado <nfraprado@collabora.com>:
>            Use filtered mode to make sure threshold interrupts are triggered,
>            protocol documentation, cosmetics
>          - I (bero@baylibre.com) will be taking care of this patchset
>            from now on, since Balsam has left BayLibre. Thanks for
>            getting it almost ready, Balsam!
> 
>      v2 :
>          - Based on top of thermal/linux-next :
>              base-commit: 7ac82227ee046f8234471de4c12a40b8c2d3ddcc
>          - Squash "add thermal zones and thermal nodes" and
>              "add temperature mitigation threshold" commits together to form
>              "arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones" commit.
>          - Add Suspend and Resume support to LVTS Driver.
>          - Update Calibration Data documentation.
>          - Fix calibration data offsets for mt8192
>              (Thanks to "Chen-Yu Tsai" and "Nícolas F. R. A. Prado").
>          https://lore.kernel.org/all/20230425133052.199767-1-bchihi@baylibre.com/
>          Tested-by: Chen-Yu Tsai <wenst@chromium.org>
> 
>      v1 :
>          - The initial series "Add LVTS support for mt8192" :
>              "https://lore.kernel.org/all/20230307163413.143334-1-bchihi@baylibre.com/".
> 
> Balsam CHIHI (5):
>    dt-bindings: thermal: mediatek: Add LVTS thermal controller definition
>      for mt8192
>    thermal/drivers/mediatek/lvts_thermal: Add suspend and resume
>    thermal/drivers/mediatek/lvts_thermal: Add mt8192 support
>    arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones
>    thermal/drivers/mediatek/lvts_thermal: Update calibration data
>      documentation
> 
>   arch/arm64/boot/dts/mediatek/mt8192.dtsi      | 454 ++++++++++++++++++
>   drivers/thermal/mediatek/lvts_thermal.c       | 160 +++++-
>   .../thermal/mediatek,lvts-thermal.h           |  19 +
>   3 files changed, 631 insertions(+), 2 deletions(-)
> 
> base-commit: 6a3d37b4d885129561e1cef361216f00472f7d2e

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 0/5]
@ 2023-05-29 16:30   ` Matthias Brugger
  0 siblings, 0 replies; 40+ messages in thread
From: Matthias Brugger @ 2023-05-29 16:30 UTC (permalink / raw)
  To: Bernhard Rosenkränzer, daniel.lezcano,
	angelogioacchino.delregno, rafael, amitk, rui.zhang, robh+dt,
	krzystof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel
  Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek,
	devicetree, wenst, james.lo, rex-bc.chen, nfraprado, abailon,
	amergnat, khilman

Hi Bernhard,

Please resend with a subject line for the cover letter.

Regards,
Matthias

On 29/05/2023 17:35, Bernhard Rosenkränzer wrote:
> From: Balsam CHIHI <bchihi@baylibre.com>
> 
> Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC.
> Also, add Suspend and Resume support to LVTS Driver (all SoCs),
> and update the documentation that describes the Calibration Data Offsets.
> 
> Changelog:
>      v3 :
>          - Rebased :
>              base-commit: 6a3d37b4d885129561e1cef361216f00472f7d2e
>          - Fix issues in v2 pointed out by Nícolas F. R. A. Prado <nfraprado@collabora.com>:
>            Use filtered mode to make sure threshold interrupts are triggered,
>            protocol documentation, cosmetics
>          - I (bero@baylibre.com) will be taking care of this patchset
>            from now on, since Balsam has left BayLibre. Thanks for
>            getting it almost ready, Balsam!
> 
>      v2 :
>          - Based on top of thermal/linux-next :
>              base-commit: 7ac82227ee046f8234471de4c12a40b8c2d3ddcc
>          - Squash "add thermal zones and thermal nodes" and
>              "add temperature mitigation threshold" commits together to form
>              "arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones" commit.
>          - Add Suspend and Resume support to LVTS Driver.
>          - Update Calibration Data documentation.
>          - Fix calibration data offsets for mt8192
>              (Thanks to "Chen-Yu Tsai" and "Nícolas F. R. A. Prado").
>          https://lore.kernel.org/all/20230425133052.199767-1-bchihi@baylibre.com/
>          Tested-by: Chen-Yu Tsai <wenst@chromium.org>
> 
>      v1 :
>          - The initial series "Add LVTS support for mt8192" :
>              "https://lore.kernel.org/all/20230307163413.143334-1-bchihi@baylibre.com/".
> 
> Balsam CHIHI (5):
>    dt-bindings: thermal: mediatek: Add LVTS thermal controller definition
>      for mt8192
>    thermal/drivers/mediatek/lvts_thermal: Add suspend and resume
>    thermal/drivers/mediatek/lvts_thermal: Add mt8192 support
>    arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones
>    thermal/drivers/mediatek/lvts_thermal: Update calibration data
>      documentation
> 
>   arch/arm64/boot/dts/mediatek/mt8192.dtsi      | 454 ++++++++++++++++++
>   drivers/thermal/mediatek/lvts_thermal.c       | 160 +++++-
>   .../thermal/mediatek,lvts-thermal.h           |  19 +
>   3 files changed, 631 insertions(+), 2 deletions(-)
> 
> base-commit: 6a3d37b4d885129561e1cef361216f00472f7d2e

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2023-05-29 15:35 ` Bernhard Rosenkränzer
  0 siblings, 0 replies; 40+ messages in thread
From: Bernhard Rosenkränzer @ 2023-05-29 15:35 UTC (permalink / raw)
  To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk,
	rui.zhang, matthias.bgg, robh+dt, krzystof.kozlowski+dt, rdunlap,
	ye.xingchen, p.zabel
  Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek,
	devicetree, wenst, james.lo, rex-bc.chen, nfraprado, abailon,
	amergnat, khilman

From: Balsam CHIHI <bchihi@baylibre.com>

Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC.
Also, add Suspend and Resume support to LVTS Driver (all SoCs),
and update the documentation that describes the Calibration Data Offsets.

Changelog:
    v3 : 
        - Rebased :
            base-commit: 6a3d37b4d885129561e1cef361216f00472f7d2e
        - Fix issues in v2 pointed out by Nícolas F. R. A. Prado <nfraprado@collabora.com>:
          Use filtered mode to make sure threshold interrupts are triggered,
          protocol documentation, cosmetics
        - I (bero@baylibre.com) will be taking care of this patchset
          from now on, since Balsam has left BayLibre. Thanks for
          getting it almost ready, Balsam!

    v2 :
        - Based on top of thermal/linux-next :
            base-commit: 7ac82227ee046f8234471de4c12a40b8c2d3ddcc
        - Squash "add thermal zones and thermal nodes" and
            "add temperature mitigation threshold" commits together to form
            "arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones" commit.
        - Add Suspend and Resume support to LVTS Driver.
        - Update Calibration Data documentation.
        - Fix calibration data offsets for mt8192
            (Thanks to "Chen-Yu Tsai" and "Nícolas F. R. A. Prado").
        https://lore.kernel.org/all/20230425133052.199767-1-bchihi@baylibre.com/
        Tested-by: Chen-Yu Tsai <wenst@chromium.org>

    v1 :
        - The initial series "Add LVTS support for mt8192" :
            "https://lore.kernel.org/all/20230307163413.143334-1-bchihi@baylibre.com/".

Balsam CHIHI (5):
  dt-bindings: thermal: mediatek: Add LVTS thermal controller definition
    for mt8192
  thermal/drivers/mediatek/lvts_thermal: Add suspend and resume
  thermal/drivers/mediatek/lvts_thermal: Add mt8192 support
  arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones
  thermal/drivers/mediatek/lvts_thermal: Update calibration data
    documentation

 arch/arm64/boot/dts/mediatek/mt8192.dtsi      | 454 ++++++++++++++++++
 drivers/thermal/mediatek/lvts_thermal.c       | 160 +++++-
 .../thermal/mediatek,lvts-thermal.h           |  19 +
 3 files changed, 631 insertions(+), 2 deletions(-)

base-commit: 6a3d37b4d885129561e1cef361216f00472f7d2e
-- 
2.41.0.rc2


^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2023-05-29 15:35 ` Bernhard Rosenkränzer
  0 siblings, 0 replies; 40+ messages in thread
From: Bernhard Rosenkränzer @ 2023-05-29 15:35 UTC (permalink / raw)
  To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk,
	rui.zhang, matthias.bgg, robh+dt, krzystof.kozlowski+dt, rdunlap,
	ye.xingchen, p.zabel
  Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek,
	devicetree, wenst, james.lo, rex-bc.chen, nfraprado, abailon,
	amergnat, khilman

From: Balsam CHIHI <bchihi@baylibre.com>

Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC.
Also, add Suspend and Resume support to LVTS Driver (all SoCs),
and update the documentation that describes the Calibration Data Offsets.

Changelog:
    v3 : 
        - Rebased :
            base-commit: 6a3d37b4d885129561e1cef361216f00472f7d2e
        - Fix issues in v2 pointed out by Nícolas F. R. A. Prado <nfraprado@collabora.com>:
          Use filtered mode to make sure threshold interrupts are triggered,
          protocol documentation, cosmetics
        - I (bero@baylibre.com) will be taking care of this patchset
          from now on, since Balsam has left BayLibre. Thanks for
          getting it almost ready, Balsam!

    v2 :
        - Based on top of thermal/linux-next :
            base-commit: 7ac82227ee046f8234471de4c12a40b8c2d3ddcc
        - Squash "add thermal zones and thermal nodes" and
            "add temperature mitigation threshold" commits together to form
            "arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones" commit.
        - Add Suspend and Resume support to LVTS Driver.
        - Update Calibration Data documentation.
        - Fix calibration data offsets for mt8192
            (Thanks to "Chen-Yu Tsai" and "Nícolas F. R. A. Prado").
        https://lore.kernel.org/all/20230425133052.199767-1-bchihi@baylibre.com/
        Tested-by: Chen-Yu Tsai <wenst@chromium.org>

    v1 :
        - The initial series "Add LVTS support for mt8192" :
            "https://lore.kernel.org/all/20230307163413.143334-1-bchihi@baylibre.com/".

Balsam CHIHI (5):
  dt-bindings: thermal: mediatek: Add LVTS thermal controller definition
    for mt8192
  thermal/drivers/mediatek/lvts_thermal: Add suspend and resume
  thermal/drivers/mediatek/lvts_thermal: Add mt8192 support
  arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones
  thermal/drivers/mediatek/lvts_thermal: Update calibration data
    documentation

 arch/arm64/boot/dts/mediatek/mt8192.dtsi      | 454 ++++++++++++++++++
 drivers/thermal/mediatek/lvts_thermal.c       | 160 +++++-
 .../thermal/mediatek,lvts-thermal.h           |  19 +
 3 files changed, 631 insertions(+), 2 deletions(-)

base-commit: 6a3d37b4d885129561e1cef361216f00472f7d2e
-- 
2.41.0.rc2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2022-06-12  7:44   ` Teng Long
  0 siblings, 0 replies; 40+ messages in thread
From: Teng Long @ 2022-06-12  7:44 UTC (permalink / raw)
  To: dyroneteng; +Cc: avarab, derrickstolee, git, gitster, me, tenglong.tl

Sorry for the late reply (in emergency project).

I reread the replies in patch v2 and fixed/optimized
in patch v3 in respective, I hope I haven't missed
anything.

Thanks.

Teng Long (5):
  pack-bitmap.c: continue looping when first MIDX bitmap is found
  pack-bitmap.c: rename "idx_name" to "bitmap_name"
  pack-bitmap.c: make warnings support i18N when opening bitmap
  pack-bitmap.c: using error() instead of silently returning -1
  bitmap: add trace2 outputs during open "bitmap" file

 pack-bitmap.c   | 58 +++++++++++++++++++++++++++++++------------------
 repo-settings.c |  1 +
 2 files changed, 38 insertions(+), 21 deletions(-)

Range-diff against v2:
1:  1bfd2fb6ab ! 1:  589e3f4075 pack-bitmap.c: continue looping when first MIDX bitmap is found
    @@ Commit message
         the first one has been found, then will break out by a "return"
         directly.
     
    -    But actually, it's better to don't stop the loop until we have visited
    +    But actually, it's better to continue the loop until we have visited
         both the MIDX in our repository, as well as any alternates (along with
         _their_ alternates, recursively).
     
    +    The reason for this is, there may exist more than one MIDX file in
    +    a repo. The "multi_pack_index" struct is actually designed as a singly
    +    linked list, and if a MIDX file has been already opened successfully,
    +    then the other MIDX files will be skipped and left with a warning
    +    "ignoring extra bitmap file." to the output.
    +
         The discussion link of community:
     
           https://public-inbox.org/git/YjzCTLLDCby+kJrZ@nand.local/
2:  1fff3b3ca7 ! 2:  b6b30047fc pack-bitmap.c: rename "idx_name" to "bitmap_name"
    @@ Commit message
     
         There may bring some confusion in this "idx_name" naming, which
         might lead us to think of ".idx "or" multi-pack-index" files,    -    although bitmap is essentially can be understood as a kind of index
    -    , let's define this name a little more accurate here.
    +    although bitmap is essentially can be understood as a kind of index,
    +    let's define this name a little more accurate here.
     
         Signed-off-by: Teng Long <dyroneteng@gmail.com>
     
3:  5a8f5afccf ! 3:  d8dfe53dd4 pack-bitmap.c: make warnings more detailed when opening bitmap
    @@ Metadata
     Author: Teng Long <dyroneteng@gmail.com>
     
      ## Commit message ##
    -    pack-bitmap.c: make warnings more detailed when opening bitmap
    +    pack-bitmap.c: make warnings support i18N when opening bitmap
     
         When calling the "open_midx_bitmap_1()" or "open_pack_bitmap_1()", there
         will be a warning if a normal bitmap or MIDX bitmap already has been
    -    opened, then let's make the warning information more detailed. For
    -    example, it makes the error clearer in case of an accidental
    -    regression where we start looking for single-pack bitmaps after
    -    successfully opening a multi-pack one.
    -
    -    At the same time, we made the previous and new warning texts support
    -    translation.
    +    opened, then let's make the warning text supporting for translation.
     
         Discussion in community:
     
    @@ pack-bitmap.c: static int open_midx_bitmap_1(struct bitmap_index *bitmap_git,
      		get_midx_filename(&buf, midx->object_dir);
      		/* ignore extra bitmap file; we can only handle one */
     -		warning("ignoring extra bitmap file: %s", buf.buf);
    -+		warning(_("a normal or midx bitmap already has been opened"));
     +		warning(_("ignoring extra bitmap file: %s"), buf.buf);
      		close(fd);
      		strbuf_release(&buf);
    @@ pack-bitmap.c: static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, st
      	if (bitmap_git->pack || bitmap_git->midx) {
      		/* ignore extra bitmap file; we can only handle one */
     -		warning("ignoring extra bitmap file: %s", packfile->pack_name);
    -+		warning(_("a normal or midx bitmap already has been opened "));
     +		warning(_("ignoring extra bitmap file: %s"), packfile->pack_name);
      		close(fd);
      		return -1;
      	}
    -
    - ## t/t5310-pack-bitmaps.sh ##
    -@@ t/t5310-pack-bitmaps.sh: test_expect_success 'complains about multiple pack bitmaps' '
    - 		test_line_count = 2 bitmaps &&
    - 
    - 		git rev-list --use-bitmap-index HEAD 2>err &&
    -+		grep "a bitmap has been opened" err &&
    - 		grep "ignoring extra bitmap file" err
    - 	)
    - '
5:  1a169d7b5e ! 4:  72da3b5844 pack-bitmap.c: using error() instead of silently returning -1
    @@ Commit message
     
      ## pack-bitmap.c ##
     @@ pack-bitmap.c: static int open_midx_bitmap_1(struct bitmap_index *bitmap_git,
    - 		trace2_data_string("midx", the_repository, "stat bitmap file",
    - 				   "failed");
    + 
    + 	if (fstat(fd, &st)) {
      		close(fd);
     -		return -1;
    -+		return error("cannot stat bitmap file");
    ++		return error(_("cannot stat bitmap file"));
      	}
      
      	if (bitmap_git->pack || bitmap_git->midx) {
    @@ pack-bitmap.c: static int open_midx_bitmap_1(struct bitmap_index *bitmap_git,
      
      static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, struct packed_git *packfile)
     @@ pack-bitmap.c: static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, struct packed_git
    - 		trace2_data_string("bitmap", the_repository, "stat bitmap file",
    - 				   "failed");
    + 
    + 	if (fstat(fd, &st)) {
      		close(fd);
     -		return -1;
    -+		return error("cannot stat bitmap file");
    ++		return error(_("cannot stat bitmap file"));
      	}
      
      	if (bitmap_git->pack || bitmap_git->midx) {
     @@ pack-bitmap.c: static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, struct packed_git
    + 
      	if (!is_pack_valid(packfile)) {
    - 		trace2_data_string("bitmap", the_repository, "packfile", "invalid");
      		close(fd);
     -		return -1;
    -+		return error("packfile is invalid");
    ++		return error(_("packfile is invalid"));
      	}
      
      	bitmap_git->pack = packfile;
    @@ pack-bitmap.c: static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, st
      		bitmap_git->map_pos = 0;
      		bitmap_git->pack = NULL;
     -		return -1;
    -+		return error("bitmap header is invalid");
    ++		return error(_("bitmap header is invalid"));
      	}
      
      	return 0;
4:  2016ef2e34 ! 5:  e118758d1d bitmap: add trace2 outputs during open "bitmap" file
    @@ Metadata
      ## Commit message ##
         bitmap: add trace2 outputs during open "bitmap" file
     
    -    It's supported for a Git repo to use bitmap in both normal bitmap way
    -    or a multi-pack-index bitmap.
    -
    -    Sometimes the debug path is not obvious, for example, when executing:
    +    It's supported for a repo to use bitmap in both "NORMAL" bitmap way
    +    or a MIDX (multi-pack-index) bitmap. Either of two bitmap kinds can
    +    exist in the repository, or both can be stored but let the config
    +    controls which kind of bitmap is used (like "core.multipackIndex",
    +    etc.). Because of this, sometimes the bitmap debug path is not
    +    obvious enough, for example, when executing:
     
          $git rev-list  --test-bitmap  HEAD
          fatal: failed to load bitmap indexes
     
    -    If we see the output like this, we are not sure about what's happened,
    -    because the cause should be :
    +    If we see the output like this, It's not sure for us to know
    +    what's happened concretely, because the cause should be :
     
    -      1. neither normal nor midx bitmap exists
    -      2. only midx bitmap exists but core.multipackIndex="false"
    -      3. core.multipackIndex="true" but midx bitmap file is currupt
    -      4. core.multipackIndex="true" and no midx bitmap exists but
    -         normal bitmap file is currupt
    +      1. Neither normal nor MIDX bitmap exists.
    +      2. Only MIDX bitmap exists but core.multipackIndex="false".
    +      3. Config core.multipackIndex set to "true" but MIDX  bitmap is
    +         corrupted.
    +      4. Config core.multipackIndex set to "true" and no MIDX bitmap
    +         exists but normal bitmap file is corrupted.
           ....
     
         These are some of the scenarios I briefly tested, but maybe there are
    -    others (some scenarios is produced manually like "currupt bitmap file",
    +    others (some scenarios is produced manually like "corrupted bitmap file",
         but it's not represent it's an existed bug.).
     
         Therefore, we added some TRACE2 code so that when we read the bitmap
         we can be more clear about the decision path, such as whether it is
    -    working on midx bitmap or normal bitmap, or is it simply because the
    -    related configuration is disabled. This may help with logging, user
    -    troubleshooting, and development debugging.
    -
    -    Here are some output examples when executing
    -    "$GIT_TRACE2_PERF=1 git rev-list --test-bitmap HEAD" under different
    -    situations:
    -
    -    1. _HAVE_ MIDX bitmap and NORMAL bitmap file, but the
    -    "core.multipackIndex" configures as "false":
    -
    -      19:38:43.007840 common-main.c:49             | d0 | main                     | version      |     |           |           |              | 2.35.1.582.g8e9092487a
    -      19:38:43.007874 common-main.c:50             | d0 | main                     | start        |     |  0.000305 |           |              | /opt/git/master/bin/git rev-list --test-bitmap HEAD
    -      19:38:43.007950 compat/linux/procinfo.c:170  | d0 | main                     | cmd_ancestry |     |           |           |              | ancestry:[bash sshd sshd sshd systemd]
    -      19:38:43.008091 git.c:460                    | d0 | main                     | cmd_name     |     |           |           |              | rev-list (rev-list)
    -      19:38:43.008284 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000720 |  0.000720 | config       | feature.manyfiles:false
    -      19:38:43.008297 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000734 |  0.000734 | config       | feature.experimental:false
    -      19:38:43.008305 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000742 |  0.000742 | config       | core.commitgraph:true
    -      19:38:43.008313 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000749 |  0.000749 | config       | commitgraph.readchangedpaths:true
    -      19:38:43.008320 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000756 |  0.000756 | config       | gc.writecommitgraph:true
    -      19:38:43.008327 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000764 |  0.000764 | config       | fetch.writecommitgraph:false
    -      19:38:43.008334 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000770 |  0.000770 | config       | pack.usesparse:true
    -      19:38:43.008341 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000777 |  0.000777 | config       | core.multipackindex:false
    -      19:38:43.008348 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000784 |  0.000784 | config       | index.sparse:false
    -      19:38:43.008724 pack-bitmap.c:536            | d0 | main                     | region_enter | r0  |  0.001160 |           | pack-bitmap  | label:open_bitmap
    -      19:38:43.008738 pack-bitmap.c:390            | d0 | main                     | data         | r0  |  0.001173 |  0.000013 | bitmap       | ..try to open bitmap:/home/tenglong.tl/test/dyrone/.git/objects/pack/pack-2d1b3f749fb859b874710e33263d0847ef009e03.bitmap
    -      19:38:43.008754 pack-bitmap.c:543            | d0 | main                     | region_leave | r0  |  0.001191 |  0.000031 | pack-bitmap  | label:open_bitmap
    -      Bitmap v1 test (8 entries loaded)
    -      Found bitmap for 0a7df7ae92f8d8ed879c240f8ae9cdd33d18085e. 64 bits / 1801edc6 checksum
    -      19:38:43.009099 progress.c:268               | d0 | main                     | region_enter | r0  |  0.001535 |           | progress     | label:Verifying bitmap entries
    -      Verifying bitmap entries: 100% (27/27), done.
    -      19:38:43.009294 progress.c:339               | d0 | main                     | data         | r0  |  0.001730 |  0.000195 | progress     | ..total_objects:27
    -      19:38:43.009302 progress.c:346               | d0 | main                     | region_leave | r0  |  0.001739 |  0.000204 | progress     | label:Verifying bitmap entries
    -      OK!
    -      19:38:43.009321 git.c:718                    | d0 | main                     | exit         |     |  0.001757 |           |              | code:0
    -      19:38:43.009329 trace2/tr2_tgt_perf.c:215    | d0 | main                     | atexit       |     |  0.001766 |           |              | code:0
    -
    -    2. _HAVE_ MIDX bitmap and NORMAL bitmap file, but the
    -    "core.multipackIndex" configures as "true":
    -
    -      (omit duplicate outputs)
    -      ...
    -      20:02:31.288797 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000811 |  0.000811 | config       | core.multipackindex:true
    -      20:02:31.288806 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000819 |  0.000819 | config       | index.sparse:false
    -      20:02:31.288836 midx.c:185                   | d0 | main                     | data         | r0  |  0.000849 |  0.000849 | midx         | load/num_packs:1
    -      20:02:31.288843 midx.c:186                   | d0 | main                     | data         | r0  |  0.000857 |  0.000857 | midx         | load/num_objects:27
    -      20:02:31.289217 pack-bitmap.c:536            | d0 | main                     | region_enter | r0  |  0.001229 |           | pack-bitmap  | label:open_bitmap
    -      20:02:31.289230 pack-bitmap.c:318            | d0 | main                     | data         | r0  |  0.001242 |  0.000013 | midx         | ..try to open bitmap:/home/tenglong.tl/test/dyrone/.git/objects/pack/multi-pack-index-b6b04fbe053bd500d9ca13354466d3249dc275ac.bitmap
    -      20:02:31.289252 pack-revindex.c:315          | d0 | main                     | data         | r0  |  0.001265 |  0.000036 | load_midx_re | ..source:midx
    -      20:02:31.289261 pack-bitmap.c:543            | d0 | main                     | region_leave | r0  |  0.001274 |  0.000045 | pack-bitmap  | label:open_bitmap
    -      Bitmap v1 test (8 entries loaded)
    -      Found bitmap for 0a7df7ae92f8d8ed879c240f8ae9cdd33d18085e. 64 bits / 1801edc6 checksum
    -      20:02:31.289594 progress.c:268               | d0 | main                     | region_enter | r0  |  0.001607 |           | progress     | label:Verifying bitmap entries
    -      Verifying bitmap entries: 100% (27/27), done.
    -      20:02:31.289810 progress.c:339               | d0 | main                     | data         | r0  |  0.001823 |  0.000216 | progress     | ..total_objects:27
    -      20:02:31.289824 progress.c:346               | d0 | main                     | region_leave | r0  |  0.001837 |  0.000230 | progress     | label:Verifying bitmap entries
    -      OK!
    -      20:02:31.289843 git.c:718                    | d0 | main                     | exit         |     |  0.001856 |           |              | code:0
    -      20:02:31.289860 trace2/tr2_tgt_perf.c:215    | d0 | main                     | atexit       |     |  0.001873 |           |              | code:0
    -
    -    3. _HAVE_ MIDX bitmap and a corrupt NORMAL bitmap file, but the
    -    "core.multipackIndex" configures as "false" :
    -
    -      (omit duplicate outputs)
    -      ...
    -      20:14:06.539305 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000794 |  0.000794 | config       | core.multipackindex:false
    -      20:14:06.539310 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000799 |  0.000799 | config       | index.sparse:false
    -      20:14:06.539658 pack-bitmap.c:536            | d0 | main                     | region_enter | r0  |  0.001146 |           | pack-bitmap  | label:open_bitmap
    -      20:14:06.539671 pack-bitmap.c:390            | d0 | main                     | data         | r0  |  0.001160 |  0.000014 | bitmap       | ..try to open bitmap:/home/tenglong.tl/test/dyrone/.git/objects/pack/pack-2d1b3f749fb859b874710e33263d0847ef009e03.bitmap
    -      20:14:06.539686 usage.c:79                   | d0 | main                     | error        |     |           |           |              | ..Corrupted bitmap index file (wrong header)
    -      error: Corrupted bitmap index file (wrong header)
    -      20:14:06.539696 pack-bitmap.c:426            | d0 | main                     | data         | r0  |  0.001185 |  0.000039 | bitmap       | ..load bitmap header:failed
    -      20:14:06.539709 usage.c:79                   | d0 | main                     | error        |     |           |           |              | ..bitmap header is invalid
    -      error: bitmap header is invalid
    -      20:14:06.539719 pack-bitmap.c:543            | d0 | main                     | region_leave | r0  |  0.001208 |  0.000062 | pack-bitmap  | label:open_bitmap
    -      20:14:06.539726 usage.c:60                   | d0 | main                     | error        |     |           |           |              | failed to load bitmap indexes
    -      fatal: failed to load bitmap indexes
    -      20:14:06.539735 usage.c:74                   | d0 | main                     | exit         |     |  0.001224 |           |              | code:128
    -      20:14:06.539744 trace2/tr2_tgt_perf.c:215    | d0 | main                     | atexit       |     |  0.001233 |           |              | code:128
    +    working on MIDX or NORMAL bitmap at present, or the related config is
    +    enabled or not. This may help with logging, user troubleshooting, and
    +    development debugging.
    +
    +    Here are some brief output examples on different scenarios when
    +    executing:
    +
    +      $GIT_TRACE2_PERF=1 git rev-list --test-bitmap HEAD
    +
    +    Scenario 1: core.multipackIndex [false], midx bitmap exists [Y],
    +    normal bitmap exists [N]
    +
    +           19:21:56.580349 repo-settings.c:11           | d0 | main                     | data         | r1  |  0.000827 |  0.000827 | config       | core.multipackindex:false
    +           19:21:56.580356 repo-settings.c:11           | d0 | main                     | data         | r1  |  0.000834 |  0.000834 | config       | index.sparse:false
    +           19:21:56.580706 pack-bitmap.c:525            | d0 | main                     | region_enter | r1  |  0.001183 |           | pack-bitmap  | label:open_bitmap
    +           19:21:56.580719 pack-bitmap.c:386            | d0 | main                     | data         | r1  |  0.001196 |  0.000013 | bitmap       | ..path:.git/objects/pack/pack-e9eb18e6a423057f4424a762069e13804a75d01e.bitmap
    +           19:21:56.580729 pack-bitmap.c:530            | d0 | main                     | region_leave | r1  |  0.001207 |  0.000024 | pack-bitmap  | label:open_bitmap
    +           19:21:56.580737 usage.c:60                   | d0 | main                     | error        |     |           |           |              | failed to load bitmap indexes
    +           fatal: failed to load bitmap indexes
    +           19:21:56.580746 usage.c:74                   | d0 | main                     | exit         |     |  0.001224 |           |              | code:128
    +           19:21:56.580754 trace2/tr2_tgt_perf.c:215    | d0 | main                     | atexit       |     |  0.001232 |           |              | code:128
    +
    +    Scenario 2: core.multipackIndex [false], midx bitmap exists [Y],
    +    normal bitmap exists [Y]
    +
    +            19:23:44.692384 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000765 |  0.000765 | config       | core.multipackindex:false
    +            19:23:44.692755 pack-bitmap.c:525            | d0 | main                     | region_enter | r0  |  0.001135 |           | pack-bitmap  | label:open_bitmap
    +            19:23:44.692768 pack-bitmap.c:386            | d0 | main                     | data         | r0  |  0.001149 |  0.000014 | bitmap       | ..path:/home/tenglong.tl/test/dyrone_bitmap/.git/objects/pack/pack-e9eb18e6a423057f4424a762069e13804a75d01e.bitmap
    +            19:23:44.692790 pack-bitmap.c:530            | d0 | main                     | region_leave | r0  |  0.001171 |  0.000036 | pack-bitmap  | label:open_bitmap
    +            Bitmap v1 test (1 entries loaded)
    +            Found bitmap for d864fefa87415d6cd289c72aa9ffd45b4a8ffd84. 64 bits / 11030517 checksum
    +            19:23:44.693119 progress.c:268               | d0 | main                     | region_enter | r0  |  0.001500 |           | progress     | label:Verifying bitmap entries
    +            Verifying bitmap entries: 100% (3/3), done.
    +            19:23:44.693208 progress.c:339               | d0 | main                     | data         | r0  |  0.001589 |  0.000089 | progress     | ..total_objects:3
    +            19:23:44.693216 progress.c:346               | d0 | main                     | region_leave | r0  |  0.001597 |  0.000097 | progress     | label:Verifying bitmap entries
    +            OK!
    +            19:23:44.693234 git.c:718                    | d0 | main                     | exit         |     |  0.001615 |           |              | code:0
    +            19:23:44.693244 trace2/tr2_tgt_perf.c:215    | d0 | main                     | atexit       |     |  0.001625 |           |              | code:0
    +
    +    Scenario 3: core.multipackIndex [true], midx bitmap exists [Y],
    +    normal bitmap exists [Y]
    +
    +            19:26:03.625055 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000760 |  0.000760 | config       | core.multipackindex:true
    +            19:26:03.625090 midx.c:185                   | d0 | main                     | data         | r0  |  0.000795 |  0.000795 | midx         | load/num_packs:1
    +            19:26:03.625097 midx.c:186                   | d0 | main                     | data         | r0  |  0.000803 |  0.000803 | midx         | load/num_objects:3
    +            19:26:03.625455 pack-bitmap.c:525            | d0 | main                     | region_enter | r0  |  0.001160 |           | pack-bitmap  | label:open_bitmap
    +            19:26:03.625470 pack-bitmap.c:318            | d0 | main                     | data         | r0  |  0.001175 |  0.000015 | midx         | ..path:/home/tenglong.tl/test/dyrone_bitmap/.git/objects/pack/multi-pack-index-fe8e96790bd34926423bdf3efd762dbbea9f3213.bitmap
    +            19:26:03.625489 pack-revindex.c:315          | d0 | main                     | data         | r0  |  0.001194 |  0.000034 | load_midx_re | ..source:midx
    +            19:26:03.625496 pack-bitmap.c:530            | d0 | main                     | region_leave | r0  |  0.001202 |  0.000042 | pack-bitmap  | label:open_bitmap
    +            Bitmap v1 test (1 entries loaded)
    +            Found bitmap for d864fefa87415d6cd289c72aa9ffd45b4a8ffd84. 64 bits / 11030517 checksum
    +            19:26:03.625818 progress.c:268               | d0 | main                     | region_enter | r0  |  0.001523 |           | progress     | label:Verifying bitmap entries
    +            Verifying bitmap entries: 100% (3/3), done.
    +            19:26:03.625916 progress.c:339               | d0 | main                     | data         | r0  |  0.001622 |  0.000099 | progress     | ..total_objects:3
    +            19:26:03.625925 progress.c:346               | d0 | main                     | region_leave | r0  |  0.001630 |  0.000107 | progress     | label:Verifying bitmap entries
    +            OK!
    +            19:26:03.625943 git.c:718                    | d0 | main                     | exit         |     |  0.001648 |           |              | code:0
    +            19:26:03.625952 trace2/tr2_tgt_perf.c:215    | d0 | main                     | atexit       |     |  0.001658 |           |              | code:0
    +
    +    Situation 4: core.multipackIndex [false], midx bitmap exists [N],
    +    normal bitmap exists [Y].
    +
    +            19:27:15.383037 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000746 |  0.000746 | config       | core.multipackindex:true
    +            19:27:15.383397 pack-bitmap.c:525            | d0 | main                     | region_enter | r0  |  0.001105 |           | pack-bitmap  | label:open_bitmap
    +            19:27:15.383408 pack-bitmap.c:386            | d0 | main                     | data         | r0  |  0.001116 |  0.000011 | bitmap       | ..path:/home/tenglong.tl/test/dyrone_bitmap/.git/objects/pack/pack-e9eb18e6a423057f4424a762069e13804a75d01e.bitmap
    +            19:27:15.383419 pack-bitmap.c:530            | d0 | main                     | region_leave | r0  |  0.001128 |  0.000023 | pack-bitmap  | label:open_bitmap
    +            Bitmap v1 test (1 entries loaded)
    +            Found bitmap for d864fefa87415d6cd289c72aa9ffd45b4a8ffd84. 64 bits / 11030517 checksum
    +            19:27:15.383730 progress.c:268               | d0 | main                     | region_enter | r0  |  0.001439 |           | progress     | label:Verifying bitmap entries
    +            Verifying bitmap entries: 100% (3/3), done.
    +            19:27:15.383822 progress.c:339               | d0 | main                     | data         | r0  |  0.001531 |  0.000092 | progress     | ..total_objects:3
    +            19:27:15.383830 progress.c:346               | d0 | main                     | region_leave | r0  |  0.001539 |  0.000100 | progress     | label:Verifying bitmap entries
    +            OK!
    +            19:27:15.383848 git.c:718                    | d0 | main                     | exit         |     |  0.001557 |           |              | code:0
    +            19:27:15.383867 trace2/tr2_tgt_perf.c:215    | d0 | main                     | atexit       |     |  0.001576 |           |              | code:0
    +
    +    Scenario 5: core.multipackIndex [true], midx bitmap exists [Y] but corrupted,
    +    normal bitmap exists [Y]
    +
    +            19:29:25.888233 repo-settings.c:11           | d0 | main                     | data         | r0  |  0.000794 |  0.000794 | config       | core.multipackindex:true
    +            19:29:25.888591 pack-bitmap.c:525            | d0 | main                     | region_enter | r0  |  0.001152 |           | pack-bitmap  | label:open_bitmap
    +            19:29:25.888603 pack-bitmap.c:386            | d0 | main                     | data         | r0  |  0.001163 |  0.000011 | bitmap       | ..path:/home/tenglong.tl/test/dyrone_bitmap/.git/objects/pack/pack-e9eb18e6a423057f4424a762069e13804a75d01e.bitmap
    +            19:29:25.888622 usage.c:79                   | d0 | main                     | error        |     |           |           |              | ..Corrupted bitmap index file (wrong header)
    +            error: Corrupted bitmap index file (wrong header)
    +            19:29:25.888638 usage.c:79                   | d0 | main                     | error        |     |           |           |              | ..bitmap header is invalid
    +            error: bitmap header is invalid
    +            19:29:25.888650 pack-bitmap.c:530            | d0 | main                     | region_leave | r0  |  0.001211 |  0.000059 | pack-bitmap  | label:open_bitmap
    +            19:29:25.888659 usage.c:60                   | d0 | main                     | error        |     |           |           |              | failed to load bitmap indexes
    +            fatal: failed to load bitmap indexes
    +            19:29:25.888670 usage.c:74                   | d0 | main                     | exit         |     |  0.001231 |           |              | code:128
    +            19:29:25.888680 trace2/tr2_tgt_perf.c:215    | d0 | main                     | atexit       |     |  0.001241 |           |              | code:128
     
         Signed-off-by: Teng Long <dyroneteng@gmail.com>
     
    @@ pack-bitmap.c: char *pack_bitmap_filename(struct packed_git *p)
      	struct stat st;
      	char *bitmap_name = midx_bitmap_filename(midx);
     -	int fd = git_open(bitmap_name);
    -+	trace2_data_string("midx", the_repository, "try to open bitmap",
    -+			   bitmap_name);
    ++	trace2_data_string("midx", the_repository, "path", bitmap_name);
     +	fd = git_open(bitmap_name);
      
      	free(bitmap_name);
      
    -@@ pack-bitmap.c: static int open_midx_bitmap_1(struct bitmap_index *bitmap_git,
    - 		return -1;
    - 
    - 	if (fstat(fd, &st)) {
    -+		trace2_data_string("midx", the_repository, "stat bitmap file",
    -+				   "failed");
    - 		close(fd);
    - 		return -1;
    - 	}
     @@ pack-bitmap.c: static int open_midx_bitmap_1(struct bitmap_index *bitmap_git,
      				MAP_PRIVATE, fd, 0);
      	close(fd);
    @@ pack-bitmap.c: static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, st
      		return -1;
      
      	bitmap_name = pack_bitmap_filename(packfile);
    -+	trace2_data_string("bitmap", the_repository, "try to open bitmap",
    -+			   bitmap_name);
    ++	trace2_data_string("bitmap", the_repository, "path", bitmap_name);
      	fd = git_open(bitmap_name);
      	free(bitmap_name);
      
    -@@ pack-bitmap.c: static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, struct packed_git
    - 		return -1;
    - 
    - 	if (fstat(fd, &st)) {
    -+		trace2_data_string("bitmap", the_repository, "stat bitmap file",
    -+				   "failed");
    - 		close(fd);
    - 		return -1;
    - 	}
    -@@ pack-bitmap.c: static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, struct packed_git
    - 	}
    - 
    - 	if (!is_pack_valid(packfile)) {
    -+		trace2_data_string("bitmap", the_repository, "packfile", "invalid");
    - 		close(fd);
    - 		return -1;
    - 	}
    -@@ pack-bitmap.c: static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, struct packed_git
    - 	close(fd);
    - 
    - 	if (load_bitmap_header(bitmap_git) < 0) {
    -+		trace2_data_string("bitmap", the_repository,
    -+				   "load bitmap header", "failed");
    - 		munmap(bitmap_git->map, bitmap_git->map_size);
    - 		bitmap_git->map = NULL;
    - 		bitmap_git->map_size = 0;
     @@ pack-bitmap.c: static int open_midx_bitmap(struct repository *r,
      static int open_bitmap(struct repository *r,
      		       struct bitmap_index *bitmap_git)
      {
     -	assert(!bitmap_git->map);
    -+	int ret = -1;
    ++	int ret = 0;
      
    --	if (!open_midx_bitmap(r, bitmap_git))
    --		return 0;
    --	return open_pack_bitmap(r, bitmap_git);
     +	assert(!bitmap_git->map);
     +	trace2_region_enter("pack-bitmap", "open_bitmap", r);
    -+	if (!open_midx_bitmap(r, bitmap_git)) {
    -+		ret = 0;
    + 	if (!open_midx_bitmap(r, bitmap_git))
    +-		return 0;
    +-	return open_pack_bitmap(r, bitmap_git);
     +		goto done;
    -+	}
     +	ret = open_pack_bitmap(r, bitmap_git);
     +done:
     +	trace2_region_leave("pack-bitmap", "open_bitmap", r);
    @@ repo-settings.c: static void repo_cfg_bool(struct repository *r, const char *key
      }
      
      void prepare_repo_settings(struct repository *r)
    -
    - ## t/t5310-pack-bitmaps.sh ##
    -@@ t/t5310-pack-bitmaps.sh: test_expect_success 'complains about multiple pack bitmaps' '
    - 		test_line_count = 2 bitmaps &&
    - 
    - 		git rev-list --use-bitmap-index HEAD 2>err &&
    --		grep "a bitmap has been opened" err &&
    --		grep "ignoring extra bitmap file" err
    -+		grep "warning: a normal or midx bitmap already has been opened" err &&
    -+		grep "warning: ignoring extra bitmap file" err
    - 	)
    - '
    - 
-- 
2.35.1.582.g320e881567


^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 0/5]
  2021-12-19 23:46   ` Florian Fainelli
@ 2021-12-20  8:59     ` Marc Zyngier
  0 siblings, 0 replies; 40+ messages in thread
From: Marc Zyngier @ 2021-12-20  8:59 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: linux-arm-kernel, Chris Healy, Will Deacon, Stefan Wahren,
	vincent.weaver, Mark Rutland

Hi Florian,

On Sun, 19 Dec 2021 23:46:32 +0000,
Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
> Hi Will, Marc,

+Mark

> 
> On 5/21/2018 11:19 AM, Will Deacon wrote:
> > Hi Marc,
> > 
> > Thanks for this.
> > 
> > On Fri, May 18, 2018 at 03:39:08PM +0100, Marc Zyngier wrote:
> >> PMUv3 has been introduced with ARMv8 and, while it has only been used
> >> on 64bit systems so far, it would definitely be useful for 32bit
> >> guests running under KVM/arm64, for example.
> >> 
> >> There is also the case of people natively running 32bit kernels on
> >> 64bit HW and trying to upstream unspeakable hacks, hoping that the
> >> stars will align and that they'll win the lottery (see [1]).
> >> 
> >> So let's try again, and make the PMUv3 driver usable for everyone.
> >> 
> >> This is done in three steps:
> >> (1) Move the driver from arch/arm64 to drivers/perf
> >> (2) Add a handful of system register accessors so that we can reuse
> >>      the driver on 32bit
> >> (3) Provide the same accessors on 32bit, enable compilation, and
> >>      make it the default selection for mach-virt.
> >> 
> >> Tested on a Seattle box with 32bit guests.
> > 
> > I think we should go ahead with something like this, but I don't think
> > we're quite there with these patches. If we're going to move the arch code
> > out into drivers, let's do that for the perf_event* files under arch/arm/
> > as well. Then we could have a structure along the lines of:
> > 
> > 
> >    drivers/perf/arm_pmu.c			- As it is today
> >    drivers/perf/arm_cpu/xscale_pmu.c		- Only builds for 32-bit
> >    drivers/perf/arm_cpu/armv6_pmu.c		- Only builds for 32-bit
> >    drivers/perf/arm_cpu/arch_pmu.c		- Works for v7/v8 on
> >                                                    both 32-bit and 64-bit
> 
> There has been a recent renewed interest in this patch series from my
> side as well as other users, and I have picked up where Marc left and
> started moving the Xscale and ARMv6 PMU drivers as Will had asked the
> current result can be seen here:
> 
> https://github.com/ffainelli/linux/commits/arm-pmuv3

Blast from the past!

> 
> It is not entirely clear to me what you had in mind when you want to
> have a common driver for v7 and v8 under
> drivers/perf/arm_cpu/arch_pmu.c. How much sharing or consolidation
> would you expect to be done there?

The v7/v8 models are very similar (they share most of the registers,
and there is only a few bits and pieces that differ between PMUv3 and
its ancestors). It should be possible to build a single driver

However, the 32bit PMU code is bundled together with the
Krait/Scorpion code that isn't quite the same. Maybe this should be
spun as a different driver if this can be disentangled neatly enough?

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 0/5]
  2018-05-21 18:19   ` Will Deacon
  (?)
@ 2021-12-19 23:46   ` Florian Fainelli
  2021-12-20  8:59     ` Marc Zyngier
  -1 siblings, 1 reply; 40+ messages in thread
From: Florian Fainelli @ 2021-12-19 23:46 UTC (permalink / raw)
  To: linux-arm-kernel, Marc Zyngier, Chris Healy, Will Deacon,
	Stefan Wahren, vincent.weaver

Hi Will, Marc,

On 5/21/2018 11:19 AM, Will Deacon wrote:
> Hi Marc,
> 
> Thanks for this.
> 
> On Fri, May 18, 2018 at 03:39:08PM +0100, Marc Zyngier wrote:
>> PMUv3 has been introduced with ARMv8 and, while it has only been used
>> on 64bit systems so far, it would definitely be useful for 32bit
>> guests running under KVM/arm64, for example.
>>
>> There is also the case of people natively running 32bit kernels on
>> 64bit HW and trying to upstream unspeakable hacks, hoping that the
>> stars will align and that they'll win the lottery (see [1]).
>>
>> So let's try again, and make the PMUv3 driver usable for everyone.
>>
>> This is done in three steps:
>> (1) Move the driver from arch/arm64 to drivers/perf
>> (2) Add a handful of system register accessors so that we can reuse
>>      the driver on 32bit
>> (3) Provide the same accessors on 32bit, enable compilation, and
>>      make it the default selection for mach-virt.
>>
>> Tested on a Seattle box with 32bit guests.
> 
> I think we should go ahead with something like this, but I don't think
> we're quite there with these patches. If we're going to move the arch code
> out into drivers, let's do that for the perf_event* files under arch/arm/
> as well. Then we could have a structure along the lines of:
> 
> 
>    drivers/perf/arm_pmu.c			- As it is today
>    drivers/perf/arm_cpu/xscale_pmu.c		- Only builds for 32-bit
>    drivers/perf/arm_cpu/armv6_pmu.c		- Only builds for 32-bit
>    drivers/perf/arm_cpu/arch_pmu.c		- Works for v7/v8 on
>                                                    both 32-bit and 64-bit

There has been a recent renewed interest in this patch series from my 
side as well as other users, and I have picked up where Marc left and 
started moving the Xscale and ARMv6 PMU drivers as Will had asked the 
current result can be seen here:

https://github.com/ffainelli/linux/commits/arm-pmuv3

It is not entirely clear to me what you had in mind when you want to 
have a common driver for v7 and v8 under 
drivers/perf/arm_cpu/arch_pmu.c. How much sharing or consolidation would 
you expect to be done there?

Thanks!
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 0/5]
  2019-02-08 16:11 ` Federico Vaga
  (?)
@ 2019-02-09 21:41 ` Andrew Lunn
  -1 siblings, 0 replies; 40+ messages in thread
From: Andrew Lunn @ 2019-02-09 21:41 UTC (permalink / raw)
  To: Federico Vaga; +Cc: Peter Korsgaard, linux-i2c, linux-kernel

On Fri, Feb 08, 2019 at 05:11:56PM +0100, Federico Vaga wrote:
> This patch set provides improvements to the i2c-ocore driver.

Hi Federico

Please could you fixup the SPDX patch, add my review/tested by tags,
and i think we are good to go.

Thanks
	Andrew

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2019-02-08 16:11 ` Federico Vaga
  0 siblings, 0 replies; 40+ messages in thread
From: Federico Vaga @ 2019-02-08 16:11 UTC (permalink / raw)
  To: Peter Korsgaard, Andrew Lunn; +Cc: linux-i2c, linux-kernel

This patch set provides improvements to the i2c-ocore driver.

[V2 -> V3]
- fix error condition on platform_get_irq(). Copied from
  https://patchwork.ozlabs.org/patch/1038409/

[V1 -> V2]
- replaced usleep_range() with udelay() so that the polling version can be
  used in atomic context.
- added dedicated patch for minor style issues
- fixed delay computation
- use spin_lock_irqsave(), instead of spin_trylock_irqsave(). IACK is always
  necessary and a trylock would generate an extra interrupt for nothing
- make the driver ready for an eventual master_xfer_irqless()


^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2019-02-08 16:11 ` Federico Vaga
  0 siblings, 0 replies; 40+ messages in thread
From: Federico Vaga @ 2019-02-08 16:11 UTC (permalink / raw)
  To: Peter Korsgaard, Andrew Lunn; +Cc: linux-i2c, linux-kernel

This patch set provides improvements to the i2c-ocore driver.

[V2 -> V3]
- fix error condition on platform_get_irq(). Copied from
  https://patchwork.ozlabs.org/patch/1038409/

[V1 -> V2]
- replaced usleep_range() with udelay() so that the polling version can be
  used in atomic context.
- added dedicated patch for minor style issues
- fixed delay computation
- use spin_lock_irqsave(), instead of spin_trylock_irqsave(). IACK is always
  necessary and a trylock would generate an extra interrupt for nothing
- make the driver ready for an eventual master_xfer_irqless()

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 0/5]
  2018-05-18 14:39 ` Marc Zyngier
@ 2018-05-21 18:19   ` Will Deacon
  -1 siblings, 0 replies; 40+ messages in thread
From: Will Deacon @ 2018-05-21 18:19 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: linux-arm-kernel, linux-kernel, Mark Rutland, Russell King,
	Vladimir Murzin, Vince Weaver, Peter Zijlstra, Stefan Wahren,
	Eric Anholt, Florian Fainelli

Hi Marc,

Thanks for this.

On Fri, May 18, 2018 at 03:39:08PM +0100, Marc Zyngier wrote:
> PMUv3 has been introduced with ARMv8 and, while it has only been used
> on 64bit systems so far, it would definitely be useful for 32bit
> guests running under KVM/arm64, for example.
> 
> There is also the case of people natively running 32bit kernels on
> 64bit HW and trying to upstream unspeakable hacks, hoping that the
> stars will align and that they'll win the lottery (see [1]).
> 
> So let's try again, and make the PMUv3 driver usable for everyone.
> 
> This is done in three steps:
> (1) Move the driver from arch/arm64 to drivers/perf
> (2) Add a handful of system register accessors so that we can reuse
>     the driver on 32bit
> (3) Provide the same accessors on 32bit, enable compilation, and
>     make it the default selection for mach-virt.
> 
> Tested on a Seattle box with 32bit guests.

I think we should go ahead with something like this, but I don't think
we're quite there with these patches. If we're going to move the arch code
out into drivers, let's do that for the perf_event* files under arch/arm/
as well. Then we could have a structure along the lines of:


  drivers/perf/arm_pmu.c			- As it is today
  drivers/perf/arm_cpu/xscale_pmu.c		- Only builds for 32-bit
  drivers/perf/arm_cpu/armv6_pmu.c		- Only builds for 32-bit
  drivers/perf/arm_cpu/arch_pmu.c		- Works for v7/v8 on
                                                  both 32-bit and 64-bit

The latter can then pull in whatever accessors it needs from the arch
code headers.

I know it's more of an invasive change, but this way we always end up
running the same code on the two architectures and it will be much easier
to maintain.

Will

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2018-05-21 18:19   ` Will Deacon
  0 siblings, 0 replies; 40+ messages in thread
From: Will Deacon @ 2018-05-21 18:19 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Marc,

Thanks for this.

On Fri, May 18, 2018 at 03:39:08PM +0100, Marc Zyngier wrote:
> PMUv3 has been introduced with ARMv8 and, while it has only been used
> on 64bit systems so far, it would definitely be useful for 32bit
> guests running under KVM/arm64, for example.
> 
> There is also the case of people natively running 32bit kernels on
> 64bit HW and trying to upstream unspeakable hacks, hoping that the
> stars will align and that they'll win the lottery (see [1]).
> 
> So let's try again, and make the PMUv3 driver usable for everyone.
> 
> This is done in three steps:
> (1) Move the driver from arch/arm64 to drivers/perf
> (2) Add a handful of system register accessors so that we can reuse
>     the driver on 32bit
> (3) Provide the same accessors on 32bit, enable compilation, and
>     make it the default selection for mach-virt.
> 
> Tested on a Seattle box with 32bit guests.

I think we should go ahead with something like this, but I don't think
we're quite there with these patches. If we're going to move the arch code
out into drivers, let's do that for the perf_event* files under arch/arm/
as well. Then we could have a structure along the lines of:


  drivers/perf/arm_pmu.c			- As it is today
  drivers/perf/arm_cpu/xscale_pmu.c		- Only builds for 32-bit
  drivers/perf/arm_cpu/armv6_pmu.c		- Only builds for 32-bit
  drivers/perf/arm_cpu/arch_pmu.c		- Works for v7/v8 on
                                                  both 32-bit and 64-bit

The latter can then pull in whatever accessors it needs from the arch
code headers.

I know it's more of an invasive change, but this way we always end up
running the same code on the two architectures and it will be much easier
to maintain.

Will

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 0/5]
  2018-05-18 16:41     ` Marc Zyngier
@ 2018-05-18 17:39       ` Stefan Wahren
  -1 siblings, 0 replies; 40+ messages in thread
From: Stefan Wahren @ 2018-05-18 17:39 UTC (permalink / raw)
  To: Marc Zyngier, Vince Weaver
  Cc: Peter Zijlstra, Florian Fainelli, Vladimir Murzin, Eric Anholt,
	Mark Rutland, Russell King, Will Deacon, linux-kernel,
	linux-arm-kernel

> Marc Zyngier <marc.zyngier@arm.com> hat am 18. Mai 2018 um 18:41 geschrieben:
> 
> 
> [/me beats himself for not writing a subject line...]
> 
> On 18/05/18 17:29, Vince Weaver wrote:
> > On Fri, 18 May 2018, Marc Zyngier wrote:
> > 
> >> There is also the case of people natively running 32bit kernels on
> >> 64bit HW and trying to upstream unspeakable hacks, hoping that the
> >> stars will align and that they'll win the lottery (see [1]).
> > 
> > I've tested these patches on a Raspberry Pi 3B running a 32-bit upstream 
> > (4.17-rc5-git) kernel and they work.
> > 
> > [    0.472906] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
> > 
> > I only needed to add this to the devicetree
> > 
> > 	arm-pmu {
> > 		compatible = "arm,cortex-a53-pmu";
> > 		interrupt-parent = <&local_intc>;
> > 		interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
> > 	};
> 
> That's definitely the sensible thing to have on such hardware. Why isn't
> it in the upstream DT already, irrespective of the state of the kernel
> support?

I remember that Vince point out the absence. He asked about how to implement it and i wasn't sure about it. At this time we hadn't IRQ polarity support. So we wanted to get this puzzle piece before. In march i put it on my TODO list, but then RPI 3 B+ support had higher prio to get into 4.18.

In general we have the problem that most of the users take the downstream kernel and don't know about the differences. Luckily more distributions switch to the upstream kernel, which increases the feedback.

> 
> > Tested-by: Vince Weaver <vincent.weaver@maine.edu>

Thanks again
Stefan

> 
> Thanks a lot for testing.
> 
> 	M.
> -- 
> Jazz is not dead. It just smells funny...

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2018-05-18 17:39       ` Stefan Wahren
  0 siblings, 0 replies; 40+ messages in thread
From: Stefan Wahren @ 2018-05-18 17:39 UTC (permalink / raw)
  To: linux-arm-kernel

> Marc Zyngier <marc.zyngier@arm.com> hat am 18. Mai 2018 um 18:41 geschrieben:
> 
> 
> [/me beats himself for not writing a subject line...]
> 
> On 18/05/18 17:29, Vince Weaver wrote:
> > On Fri, 18 May 2018, Marc Zyngier wrote:
> > 
> >> There is also the case of people natively running 32bit kernels on
> >> 64bit HW and trying to upstream unspeakable hacks, hoping that the
> >> stars will align and that they'll win the lottery (see [1]).
> > 
> > I've tested these patches on a Raspberry Pi 3B running a 32-bit upstream 
> > (4.17-rc5-git) kernel and they work.
> > 
> > [    0.472906] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
> > 
> > I only needed to add this to the devicetree
> > 
> > 	arm-pmu {
> > 		compatible = "arm,cortex-a53-pmu";
> > 		interrupt-parent = <&local_intc>;
> > 		interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
> > 	};
> 
> That's definitely the sensible thing to have on such hardware. Why isn't
> it in the upstream DT already, irrespective of the state of the kernel
> support?

I remember that Vince point out the absence. He asked about how to implement it and i wasn't sure about it. At this time we hadn't IRQ polarity support. So we wanted to get this puzzle piece before. In march i put it on my TODO list, but then RPI 3 B+ support had higher prio to get into 4.18.

In general we have the problem that most of the users take the downstream kernel and don't know about the differences. Luckily more distributions switch to the upstream kernel, which increases the feedback.

> 
> > Tested-by: Vince Weaver <vincent.weaver@maine.edu>

Thanks again
Stefan

> 
> Thanks a lot for testing.
> 
> 	M.
> -- 
> Jazz is not dead. It just smells funny...

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 0/5]
  2018-05-18 16:29   ` Vince Weaver
@ 2018-05-18 16:41     ` Marc Zyngier
  -1 siblings, 0 replies; 40+ messages in thread
From: Marc Zyngier @ 2018-05-18 16:41 UTC (permalink / raw)
  To: Vince Weaver
  Cc: linux-arm-kernel, linux-kernel, Will Deacon, Mark Rutland,
	Russell King, Vladimir Murzin, Peter Zijlstra, Stefan Wahren,
	Eric Anholt, Florian Fainelli

[/me beats himself for not writing a subject line...]

On 18/05/18 17:29, Vince Weaver wrote:
> On Fri, 18 May 2018, Marc Zyngier wrote:
> 
>> There is also the case of people natively running 32bit kernels on
>> 64bit HW and trying to upstream unspeakable hacks, hoping that the
>> stars will align and that they'll win the lottery (see [1]).
> 
> I've tested these patches on a Raspberry Pi 3B running a 32-bit upstream 
> (4.17-rc5-git) kernel and they work.
> 
> [    0.472906] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
> 
> I only needed to add this to the devicetree
> 
> 	arm-pmu {
> 		compatible = "arm,cortex-a53-pmu";
> 		interrupt-parent = <&local_intc>;
> 		interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
> 	};

That's definitely the sensible thing to have on such hardware. Why isn't
it in the upstream DT already, irrespective of the state of the kernel
support?

> Tested-by: Vince Weaver <vincent.weaver@maine.edu>

Thanks a lot for testing.

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2018-05-18 16:41     ` Marc Zyngier
  0 siblings, 0 replies; 40+ messages in thread
From: Marc Zyngier @ 2018-05-18 16:41 UTC (permalink / raw)
  To: linux-arm-kernel

[/me beats himself for not writing a subject line...]

On 18/05/18 17:29, Vince Weaver wrote:
> On Fri, 18 May 2018, Marc Zyngier wrote:
> 
>> There is also the case of people natively running 32bit kernels on
>> 64bit HW and trying to upstream unspeakable hacks, hoping that the
>> stars will align and that they'll win the lottery (see [1]).
> 
> I've tested these patches on a Raspberry Pi 3B running a 32-bit upstream 
> (4.17-rc5-git) kernel and they work.
> 
> [    0.472906] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
> 
> I only needed to add this to the devicetree
> 
> 	arm-pmu {
> 		compatible = "arm,cortex-a53-pmu";
> 		interrupt-parent = <&local_intc>;
> 		interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
> 	};

That's definitely the sensible thing to have on such hardware. Why isn't
it in the upstream DT already, irrespective of the state of the kernel
support?

> Tested-by: Vince Weaver <vincent.weaver@maine.edu>

Thanks a lot for testing.

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH v3 0/5]
  2018-05-18 14:39 ` Marc Zyngier
@ 2018-05-18 16:29   ` Vince Weaver
  -1 siblings, 0 replies; 40+ messages in thread
From: Vince Weaver @ 2018-05-18 16:29 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: linux-arm-kernel, linux-kernel, Will Deacon, Mark Rutland,
	Russell King, Vladimir Murzin, Vince Weaver, Peter Zijlstra,
	Stefan Wahren, Eric Anholt, Florian Fainelli

On Fri, 18 May 2018, Marc Zyngier wrote:

> There is also the case of people natively running 32bit kernels on
> 64bit HW and trying to upstream unspeakable hacks, hoping that the
> stars will align and that they'll win the lottery (see [1]).

I've tested these patches on a Raspberry Pi 3B running a 32-bit upstream 
(4.17-rc5-git) kernel and they work.

[    0.472906] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available

I only needed to add this to the devicetree

	arm-pmu {
		compatible = "arm,cortex-a53-pmu";
		interrupt-parent = <&local_intc>;
		interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
	};


Tested-by: Vince Weaver <vincent.weaver@maine.edu>

Vince

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2018-05-18 16:29   ` Vince Weaver
  0 siblings, 0 replies; 40+ messages in thread
From: Vince Weaver @ 2018-05-18 16:29 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 18 May 2018, Marc Zyngier wrote:

> There is also the case of people natively running 32bit kernels on
> 64bit HW and trying to upstream unspeakable hacks, hoping that the
> stars will align and that they'll win the lottery (see [1]).

I've tested these patches on a Raspberry Pi 3B running a 32-bit upstream 
(4.17-rc5-git) kernel and they work.

[    0.472906] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available

I only needed to add this to the devicetree

	arm-pmu {
		compatible = "arm,cortex-a53-pmu";
		interrupt-parent = <&local_intc>;
		interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
	};


Tested-by: Vince Weaver <vincent.weaver@maine.edu>

Vince

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2018-05-18 14:39 ` Marc Zyngier
  0 siblings, 0 replies; 40+ messages in thread
From: Marc Zyngier @ 2018-05-18 14:39 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel
  Cc: Will Deacon, Mark Rutland, Russell King, Vladimir Murzin,
	Vince Weaver, Peter Zijlstra, Stefan Wahren, Eric Anholt,
	Florian Fainelli

PMUv3 has been introduced with ARMv8 and, while it has only been used
on 64bit systems so far, it would definitely be useful for 32bit
guests running under KVM/arm64, for example.

There is also the case of people natively running 32bit kernels on
64bit HW and trying to upstream unspeakable hacks, hoping that the
stars will align and that they'll win the lottery (see [1]).

So let's try again, and make the PMUv3 driver usable for everyone.

This is done in three steps:
(1) Move the driver from arch/arm64 to drivers/perf
(2) Add a handful of system register accessors so that we can reuse
    the driver on 32bit
(3) Provide the same accessors on 32bit, enable compilation, and
    make it the default selection for mach-virt.

Tested on a Seattle box with 32bit guests.

* From v1:
  - Fixed encodings for some CP15 accessors
  - Added a terse note saying that CPU_V7 also covers ARMv8
  - Rebased on v4.12-rc5

* From v2:
  - SPDX tags on new and moved files. Yeah!
  - Annual rebase on 4.17-rc5

[1] https://patchwork.kernel.org/patch/10406793/

Marc Zyngier (5):
  arm64: perf: Move PMUv3 driver to drivers/perf
  arm64: perf: Abstract system register accesses away
  ARM: Make CONFIG_CPU_V7 valid for 32bit ARMv8 implementations
  ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM
  ARM: mach-virt: Select PMUv3 driver by default

 arch/arm/Kconfig                                   |   1 +
 arch/arm/include/asm/arm_pmuv3.h                   | 125 +++++++++++++++++++++
 arch/arm/mm/Kconfig                                |   2 +-
 arch/arm64/include/asm/arm_pmuv3.h                 | 111 ++++++++++++++++++
 arch/arm64/include/asm/perf_event.h                |  55 ---------
 arch/arm64/kernel/Makefile                         |   1 -
 drivers/perf/Kconfig                               |   8 ++
 drivers/perf/Makefile                              |   1 +
 .../perf_event.c => drivers/perf/arm_pmuv3.c       |  42 ++++---
 include/kvm/arm_pmu.h                              |   2 +-
 include/linux/perf/arm_pmuv3.h                     |  78 +++++++++++++
 11 files changed, 346 insertions(+), 80 deletions(-)
 create mode 100644 arch/arm/include/asm/arm_pmuv3.h
 create mode 100644 arch/arm64/include/asm/arm_pmuv3.h
 rename arch/arm64/kernel/perf_event.c => drivers/perf/arm_pmuv3.c (97%)
 create mode 100644 include/linux/perf/arm_pmuv3.h

-- 
2.14.2

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2018-05-18 14:39 ` Marc Zyngier
  0 siblings, 0 replies; 40+ messages in thread
From: Marc Zyngier @ 2018-05-18 14:39 UTC (permalink / raw)
  To: linux-arm-kernel

PMUv3 has been introduced with ARMv8 and, while it has only been used
on 64bit systems so far, it would definitely be useful for 32bit
guests running under KVM/arm64, for example.

There is also the case of people natively running 32bit kernels on
64bit HW and trying to upstream unspeakable hacks, hoping that the
stars will align and that they'll win the lottery (see [1]).

So let's try again, and make the PMUv3 driver usable for everyone.

This is done in three steps:
(1) Move the driver from arch/arm64 to drivers/perf
(2) Add a handful of system register accessors so that we can reuse
    the driver on 32bit
(3) Provide the same accessors on 32bit, enable compilation, and
    make it the default selection for mach-virt.

Tested on a Seattle box with 32bit guests.

* From v1:
  - Fixed encodings for some CP15 accessors
  - Added a terse note saying that CPU_V7 also covers ARMv8
  - Rebased on v4.12-rc5

* From v2:
  - SPDX tags on new and moved files. Yeah!
  - Annual rebase on 4.17-rc5

[1] https://patchwork.kernel.org/patch/10406793/

Marc Zyngier (5):
  arm64: perf: Move PMUv3 driver to drivers/perf
  arm64: perf: Abstract system register accesses away
  ARM: Make CONFIG_CPU_V7 valid for 32bit ARMv8 implementations
  ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM
  ARM: mach-virt: Select PMUv3 driver by default

 arch/arm/Kconfig                                   |   1 +
 arch/arm/include/asm/arm_pmuv3.h                   | 125 +++++++++++++++++++++
 arch/arm/mm/Kconfig                                |   2 +-
 arch/arm64/include/asm/arm_pmuv3.h                 | 111 ++++++++++++++++++
 arch/arm64/include/asm/perf_event.h                |  55 ---------
 arch/arm64/kernel/Makefile                         |   1 -
 drivers/perf/Kconfig                               |   8 ++
 drivers/perf/Makefile                              |   1 +
 .../perf_event.c => drivers/perf/arm_pmuv3.c       |  42 ++++---
 include/kvm/arm_pmu.h                              |   2 +-
 include/linux/perf/arm_pmuv3.h                     |  78 +++++++++++++
 11 files changed, 346 insertions(+), 80 deletions(-)
 create mode 100644 arch/arm/include/asm/arm_pmuv3.h
 create mode 100644 arch/arm64/include/asm/arm_pmuv3.h
 rename arch/arm64/kernel/perf_event.c => drivers/perf/arm_pmuv3.c (97%)
 create mode 100644 include/linux/perf/arm_pmuv3.h

-- 
2.14.2

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2015-07-12  5:10 Taeung Song
  0 siblings, 0 replies; 40+ messages in thread
From: Taeung Song @ 2015-07-12  5:10 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: linux-kernel, jolsa, namhyung, Ingo Molnar, Taeung Song

Changes in v3:
	- builtin-config.c: Add a config variable ’kmem.default’ with a default value into ‘struct default_configset’
	which has default config variables and values.
	- cmd_config(): Add a option ‘—global’ and ‘—local’ to enable  config file location to  be selected

Changes in v2:
	- Renaming variables a more suitable name
	  1. ’—list-all' instead of '--all'
	  2. ’name' instead of 'subkey'
	  3. 'section, name, value' instead of 'given_section,subkey,value'
	- Documentation/perf-config.txt: Correct small infelicities or typing errors in a perf-config documention.
	- Documentation/perf-config.txt: Remove a part description of report.children because it was duplicated
	in Documentation/callchain-overhead-calculation.txt
	- builtin-config.c: Use a variable ’int actions’ instead of struct params which has ‘bool list_action’,
	‘bool get_action’ and etc. , to simplify a branching statement for perf-config options 
	- builtin-config.c: Declaration a global variable ‘static struct default_configsets’ has config variables
	with default values instead of using a 'util/PERFCONFIG-DEFAULT' file and remove functions merge()
	and perse_key() to get perf config default values.
	- normalize_value(): Add a function to normalize a value and check data type of it.
	- cmd_config(): Simplify parsing arguments as arguments is just divided by '=' and then in front of '.' is a section,
	between '.' and '=' is a name, and behind '=' is a value.
	- show_all_config(): Print config variables ‘struct default_configsets’ haven't 
	- cmd_config(): Make a command ’perf config' without a option work as with a option ’—list’ instead of ‘—list-all’.

Taeung Song (5):
  perf tools: Add 'perf-config' command
  perf config: Add functions which can get or set perf config variables.
  perf config: Add a option 'list-all' to perf-config.
  perf config: Add a option 'remove' to perf-config.
  perf config: Add ‘—system’ and ‘—global’ options to be able to select
    which config file to be used.

 tools/perf/Build                            |   1 +
 tools/perf/Documentation/perf-config.txt    | 401 ++++++++++++++++
 tools/perf/Documentation/perfconfig.example |  70 ++-
 tools/perf/builtin-config.c                 | 708 ++++++++++++++++++++++++++++
 tools/perf/builtin.h                        |   1 +
 tools/perf/command-list.txt                 |   1 +
 tools/perf/perf.c                           |   1 +
 tools/perf/util/cache.h                     |  20 +
 tools/perf/util/config.c                    |  84 +++-
 9 files changed, 1251 insertions(+), 36 deletions(-)
 create mode 100644 tools/perf/Documentation/perf-config.txt
 create mode 100644 tools/perf/builtin-config.c

-- 
1.9.1


^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
  2014-06-05 13:25 Maxime Ripard
@ 2014-06-09 13:56 ` Linus Walleij
  0 siblings, 0 replies; 40+ messages in thread
From: Linus Walleij @ 2014-06-09 13:56 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jun 5, 2014 at 3:25 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:

> This is an attempt at making the external interrupts on the A31 and
> the A23 working.

I've applied these 5 patches to my devel branch, but you won't
see this on linux-next until after the merge window is closed.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2014-06-05 13:25 Maxime Ripard
  2014-06-09 13:56 ` Linus Walleij
  0 siblings, 1 reply; 40+ messages in thread
From: Maxime Ripard @ 2014-06-05 13:25 UTC (permalink / raw)
  To: linux-arm-kernel

Hi everyone,

This is an attempt at making the external interrupts on the A31 and
the A23 working.

The main difference with the previous code is that there's now several
banks and several parent interrupts, instead of a single bank with a
single parent interrupt in the older SoCs.

Most of the diffstat is to register the new irq pin functions. The
real code additions are those in the core pinctrl driver.

Maxime

Changes from v2:
   - Fixed the bogus the irq_cfg_reg function that was not taking into
     account the fact that we have several registers for this one.
   - Remove the SUNXI_IRQ_NUMBER, since it was not really a good name
     anymore, and replaced it for IRQ_PER_BANK.
   - Removed meaningless and broken sunxi_irq_cfg_reg_from_bank function.

Changes from v1:
   - Bail out of the interrupt handler in case of a spurious interrupt
   - Fix the wrong register offset in sunxi_irq_*_reg functions.

Maxime Ripard (5):
  pinctrl: sunxi: Remove irq_mask_ack and use irq_ack instead
  pinctrl: sunxi: Add macro definition for pinctrl with more than one
    interrupt
  pinctrl: sunxi: Declare the number of interrupt banks in the
    descriptor
  pinctrl: sunxi: Declare the interrupt function for the A31
  pinctrl: sunxi: Implement multiple interrupt banks support

 drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c   |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun5i-a10s.c  |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun5i-a13.c   |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c   | 217 +++++++++++++++++++---------
 drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c   |   1 +
 drivers/pinctrl/sunxi/pinctrl-sunxi.c       |  81 +++++++----
 drivers/pinctrl/sunxi/pinctrl-sunxi.h       |  44 ++++--
 8 files changed, 238 insertions(+), 109 deletions(-)

-- 
2.0.0

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2009-11-10 22:36 ` Alex Chiang
  0 siblings, 0 replies; 40+ messages in thread
From: Alex Chiang @ 2009-11-10 22:36 UTC (permalink / raw)
  To: akpm; +Cc: linux-mm, linux-kernel, rientjes

This is v3 of the series.

I based it off of Linus's latest tree. 

I did not include David Rientjes's "mm: slab allocate memory section nodemask
for large systems" patch in my series, since it's not necessarily related.

Please consider for inclusion for the next merge window (v2.6.33).

Thanks,
/ac

v2 -> v3:
	- rebased to Linus's latest tree (799dd75b)
	- Added David Rientjes's Acked-by: flags
	- dropped S390 cc's, since they are unaffected by this series

v1 -> v2: http://thread.gmane.org/gmane.linux.kernel.mm/40084/
        Address David Rientjes's comments
        - check return value of sysfs_create_link in register_cpu_under_node
        - do /not/ convert [un]register_cpu_under_node to return void, since
          sparse starts whinging if you ignore sysfs_create_link()'s return
          value and working around sparse makes the code ugly
        - adjust documentation

        Added S390 maintainers to cc: for patch [1/5] as per Kame-san's
        suggestion. S390 may map a memory section to more than one node,
        causing this series to break.


---

Alex Chiang (5):
      mm: add numa node symlink for memory section in sysfs
      mm: refactor register_cpu_under_node()
      mm: refactor unregister_cpu_under_node()
      mm: add numa node symlink for cpu devices in sysfs
      Documentation: ABI: /sys/devices/system/cpu/cpu#/node


 Documentation/ABI/testing/sysfs-devices-memory     |   14 ++++-
 Documentation/ABI/testing/sysfs-devices-system-cpu |   14 +++++
 Documentation/memory-hotplug.txt                   |   11 ++--
 drivers/base/node.c                                |   58 ++++++++++++++------
 4 files changed, 76 insertions(+), 21 deletions(-)


^ permalink raw reply	[flat|nested] 40+ messages in thread

* [PATCH v3 0/5]
@ 2009-11-10 22:36 ` Alex Chiang
  0 siblings, 0 replies; 40+ messages in thread
From: Alex Chiang @ 2009-11-10 22:36 UTC (permalink / raw)
  To: akpm; +Cc: linux-mm, linux-kernel, rientjes

This is v3 of the series.

I based it off of Linus's latest tree. 

I did not include David Rientjes's "mm: slab allocate memory section nodemask
for large systems" patch in my series, since it's not necessarily related.

Please consider for inclusion for the next merge window (v2.6.33).

Thanks,
/ac

v2 -> v3:
	- rebased to Linus's latest tree (799dd75b)
	- Added David Rientjes's Acked-by: flags
	- dropped S390 cc's, since they are unaffected by this series

v1 -> v2: http://thread.gmane.org/gmane.linux.kernel.mm/40084/
        Address David Rientjes's comments
        - check return value of sysfs_create_link in register_cpu_under_node
        - do /not/ convert [un]register_cpu_under_node to return void, since
          sparse starts whinging if you ignore sysfs_create_link()'s return
          value and working around sparse makes the code ugly
        - adjust documentation

        Added S390 maintainers to cc: for patch [1/5] as per Kame-san's
        suggestion. S390 may map a memory section to more than one node,
        causing this series to break.


---

Alex Chiang (5):
      mm: add numa node symlink for memory section in sysfs
      mm: refactor register_cpu_under_node()
      mm: refactor unregister_cpu_under_node()
      mm: add numa node symlink for cpu devices in sysfs
      Documentation: ABI: /sys/devices/system/cpu/cpu#/node


 Documentation/ABI/testing/sysfs-devices-memory     |   14 ++++-
 Documentation/ABI/testing/sysfs-devices-system-cpu |   14 +++++
 Documentation/memory-hotplug.txt                   |   11 ++--
 drivers/base/node.c                                |   58 ++++++++++++++------
 4 files changed, 76 insertions(+), 21 deletions(-)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 40+ messages in thread

end of thread, other threads:[~2023-05-29 16:45 UTC | newest]

Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-08  9:46 [PATCH v3 0/5] Yunzhi Li
2014-12-08  9:46 ` Yunzhi Li
2014-12-08  9:46 ` [PATCH v3 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY Yunzhi Li
2014-12-08  9:46   ` Yunzhi Li
2014-12-08  9:57   ` Kishon Vijay Abraham I
2014-12-08  9:57     ` Kishon Vijay Abraham I
2014-12-08  9:57     ` Kishon Vijay Abraham I
2014-12-08 11:04     ` Yunzhi Li
2014-12-08 11:04       ` Yunzhi Li
2014-12-08  9:46 ` [PATCH v3 2/5] Documentation: bindings: add doc for the Rockchip usb PHY Yunzhi Li
2014-12-08  9:46   ` Yunzhi Li
2014-12-08  9:46 ` [PATCH v3 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver Yunzhi Li
2014-12-08 20:55   ` Paul Zimmerman
2014-12-08  9:46 ` [PATCH v3 4/5] ARM: dts: add rk3288 usb PHY Yunzhi Li
2014-12-08  9:46   ` Yunzhi Li
  -- strict thread matches above, loose matches on Subject: below --
2023-05-29 15:35 [PATCH v3 0/5] Bernhard Rosenkränzer
2023-05-29 15:35 ` Bernhard Rosenkränzer
2023-05-29 16:30 ` Matthias Brugger
2023-05-29 16:30   ` Matthias Brugger
2022-04-21 13:26 [PATCH v2 0/5] trace2 output for bitmap decision path Teng Long
2022-06-12  7:44 ` [PATCH v3 0/5] Teng Long
2022-06-12  7:44   ` Teng Long
2019-02-08 16:11 Federico Vaga
2019-02-08 16:11 ` Federico Vaga
2019-02-09 21:41 ` Andrew Lunn
2018-05-18 14:39 Marc Zyngier
2018-05-18 14:39 ` Marc Zyngier
2018-05-18 16:29 ` Vince Weaver
2018-05-18 16:29   ` Vince Weaver
2018-05-18 16:41   ` Marc Zyngier
2018-05-18 16:41     ` Marc Zyngier
2018-05-18 17:39     ` Stefan Wahren
2018-05-18 17:39       ` Stefan Wahren
2018-05-21 18:19 ` Will Deacon
2018-05-21 18:19   ` Will Deacon
2021-12-19 23:46   ` Florian Fainelli
2021-12-20  8:59     ` Marc Zyngier
2015-07-12  5:10 Taeung Song
2014-06-05 13:25 Maxime Ripard
2014-06-09 13:56 ` Linus Walleij
2009-11-10 22:36 Alex Chiang
2009-11-10 22:36 ` Alex Chiang

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.