* [PATCH 5/6] usb: phy: mxs: Add VF610 USB PHY support
From: Stefan Agner @ 2014-07-18 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1405702442.git.stefan@agner.ch>
This adds support for the USB PHY in Vybrid VF610. We assume that
the disconnection without VBUS is also needed for Vybrid. For all
other flags, the presumption of innocence applies.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/usb/phy/phy-mxs-usb.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index c42bdf0..207946b 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -125,10 +125,15 @@ static const struct mxs_phy_data imx6sl_phy_data = {
MXS_PHY_NEED_IP_FIX,
};
+static const struct mxs_phy_data vf610_phy_data = {
+ .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
+};
+
static const struct of_device_id mxs_phy_dt_ids[] = {
{ .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
{ .compatible = "fsl,imx6q-usbphy", .data = &imx6q_phy_data, },
{ .compatible = "fsl,imx23-usbphy", .data = &imx23_phy_data, },
+ { .compatible = "fsl,vf610-usbphy", .data = &vf610_phy_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
--
2.0.1
^ permalink raw reply related
* [PATCH 4/6] chipidea: usbmisc_imx: Add USB support for VF610 SoCs
From: Stefan Agner @ 2014-07-18 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1405702442.git.stefan@agner.ch>
This adds Vybrid VF610 SoC support. The IP is very similar to i.MX6,
however the non-core registers are spread in two different register
areas. Hence we support multiple registers which are addressed by
the index of usbmisc.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
I tried first to create two usbmisc nodes and hoped it would instanciate
the driver twice, however, the driver currently only supports one instance.
In an short attempt to add support for that, I realized that since the
data structure holding the information for each instance is within the
driver ci_hdrc_imx. For Vybrid two instances would make much more sense,
however, a i.MX6Q shares all the non-core registers in one register area,
hence only one driver can map this area. I ended up with this multiple
registers solution, altough for the Vybrid multiple instances would
probably make more sense. Any thoughts on this?
drivers/usb/chipidea/usbmisc_imx.c | 76 +++++++++++++++++++++++++++-----------
1 file changed, 54 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c b/drivers/usb/chipidea/usbmisc_imx.c
index 85293b8..61c2350 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -57,6 +57,10 @@
#define MX6_BM_OVER_CUR_DIS BIT(7)
+#define VF610_OVER_CUR_DIS BIT(7)
+
+#define MAX_BASE_ADDR 2
+
struct usbmisc_ops {
/* It's called once when probe a usb device */
int (*init)(struct imx_usbmisc_data *data);
@@ -65,7 +69,7 @@ struct usbmisc_ops {
};
struct imx_usbmisc {
- void __iomem *base;
+ void __iomem *base[MAX_BASE_ADDR];
spinlock_t lock;
struct clk *clk;
const struct usbmisc_ops *ops;
@@ -84,20 +88,20 @@ static int usbmisc_imx25_init(struct imx_usbmisc_data *data)
spin_lock_irqsave(&usbmisc->lock, flags);
switch (data->index) {
case 0:
- val = readl(usbmisc->base);
+ val = readl(usbmisc->base[0]);
val &= ~(MX25_OTG_SIC_MASK | MX25_OTG_PP_BIT);
val |= (MX25_EHCI_INTERFACE_DIFF_UNI & MX25_EHCI_INTERFACE_MASK) << MX25_OTG_SIC_SHIFT;
val |= (MX25_OTG_PM_BIT | MX25_OTG_OCPOL_BIT);
- writel(val, usbmisc->base);
+ writel(val, usbmisc->base[0]);
break;
case 1:
- val = readl(usbmisc->base);
+ val = readl(usbmisc->base[0]);
val &= ~(MX25_H1_SIC_MASK | MX25_H1_PP_BIT | MX25_H1_IPPUE_UP_BIT);
val |= (MX25_EHCI_INTERFACE_SINGLE_UNI & MX25_EHCI_INTERFACE_MASK) << MX25_H1_SIC_SHIFT;
val |= (MX25_H1_PM_BIT | MX25_H1_OCPOL_BIT | MX25_H1_TLL_BIT |
MX25_H1_USBTE_BIT | MX25_H1_IPPUE_DOWN_BIT);
- writel(val, usbmisc->base);
+ writel(val, usbmisc->base[0]);
break;
}
@@ -115,7 +119,7 @@ static int usbmisc_imx25_post(struct imx_usbmisc_data *data)
if (data->index > 2)
return -EINVAL;
- reg = usbmisc->base + MX25_USB_PHY_CTRL_OFFSET;
+ reg = usbmisc->base[0] + MX25_USB_PHY_CTRL_OFFSET;
if (data->evdo) {
spin_lock_irqsave(&usbmisc->lock, flags);
@@ -149,10 +153,10 @@ static int usbmisc_imx27_init(struct imx_usbmisc_data *data)
spin_lock_irqsave(&usbmisc->lock, flags);
if (data->disable_oc)
- val = readl(usbmisc->base) | val;
+ val = readl(usbmisc->base[0]) | val;
else
- val = readl(usbmisc->base) & ~val;
- writel(val, usbmisc->base);
+ val = readl(usbmisc->base[0]) & ~val;
+ writel(val, usbmisc->base[0]);
spin_unlock_irqrestore(&usbmisc->lock, flags);
return 0;
@@ -168,29 +172,29 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data *data)
return -EINVAL;
/* Select a 24 MHz reference clock for the PHY */
- reg = usbmisc->base + MX53_USB_OTG_PHY_CTRL_1_OFFSET;
+ reg = usbmisc->base[0] + MX53_USB_OTG_PHY_CTRL_1_OFFSET;
val = readl(reg);
val &= ~MX53_USB_PHYCTRL1_PLLDIV_MASK;
val |= MX53_USB_PLL_DIV_24_MHZ;
- writel(val, usbmisc->base + MX53_USB_OTG_PHY_CTRL_1_OFFSET);
+ writel(val, usbmisc->base[0] + MX53_USB_OTG_PHY_CTRL_1_OFFSET);
if (data->disable_oc) {
spin_lock_irqsave(&usbmisc->lock, flags);
switch (data->index) {
case 0:
- reg = usbmisc->base + MX53_USB_OTG_PHY_CTRL_0_OFFSET;
+ reg = usbmisc->base[0] + MX53_USB_OTG_PHY_CTRL_0_OFFSET;
val = readl(reg) | MX53_BM_OVER_CUR_DIS_OTG;
break;
case 1:
- reg = usbmisc->base + MX53_USB_OTG_PHY_CTRL_0_OFFSET;
+ reg = usbmisc->base[0] + MX53_USB_OTG_PHY_CTRL_0_OFFSET;
val = readl(reg) | MX53_BM_OVER_CUR_DIS_H1;
break;
case 2:
- reg = usbmisc->base + MX53_USB_UH2_CTRL_OFFSET;
+ reg = usbmisc->base[0] + MX53_USB_UH2_CTRL_OFFSET;
val = readl(reg) | MX53_BM_OVER_CUR_DIS_UHx;
break;
case 3:
- reg = usbmisc->base + MX53_USB_UH3_CTRL_OFFSET;
+ reg = usbmisc->base[0] + MX53_USB_UH3_CTRL_OFFSET;
val = readl(reg) | MX53_BM_OVER_CUR_DIS_UHx;
break;
}
@@ -212,15 +216,31 @@ static int usbmisc_imx6q_init(struct imx_usbmisc_data *data)
if (data->disable_oc) {
spin_lock_irqsave(&usbmisc->lock, flags);
- reg = readl(usbmisc->base + data->index * 4);
+ reg = readl(usbmisc->base[0] + data->index * 4);
writel(reg | MX6_BM_OVER_CUR_DIS,
- usbmisc->base + data->index * 4);
+ usbmisc->base[0] + data->index * 4);
spin_unlock_irqrestore(&usbmisc->lock, flags);
}
return 0;
}
+static int usbmisc_vf610_init(struct imx_usbmisc_data *data)
+{
+ u32 reg;
+
+ if (data->index >= 2)
+ return -EINVAL;
+
+ if (data->disable_oc) {
+ reg = readl(usbmisc->base[data->index]);
+ writel(reg | VF610_OVER_CUR_DIS,
+ usbmisc->base[data->index]);
+ }
+
+ return 0;
+}
+
static const struct usbmisc_ops imx25_usbmisc_ops = {
.init = usbmisc_imx25_init,
.post = usbmisc_imx25_post,
@@ -238,6 +258,10 @@ static const struct usbmisc_ops imx6q_usbmisc_ops = {
.init = usbmisc_imx6q_init,
};
+static const struct usbmisc_ops vf610_usbmisc_ops = {
+ .init = usbmisc_vf610_init,
+};
+
int imx_usbmisc_init(struct imx_usbmisc_data *data)
{
if (!usbmisc)
@@ -283,6 +307,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
.compatible = "fsl,imx6q-usbmisc",
.data = &imx6q_usbmisc_ops,
},
+ {
+ .compatible = "fsl,vf610-usbmisc",
+ .data = &vf610_usbmisc_ops,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, usbmisc_imx_dt_ids);
@@ -291,7 +319,7 @@ static int usbmisc_imx_probe(struct platform_device *pdev)
{
struct resource *res;
struct imx_usbmisc *data;
- int ret;
+ int ret, i;
struct of_device_id *tmp_dev;
if (usbmisc)
@@ -303,10 +331,14 @@ static int usbmisc_imx_probe(struct platform_device *pdev)
spin_lock_init(&data->lock);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- data->base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(data->base))
- return PTR_ERR(data->base);
+ for (i = 0; i < MAX_BASE_ADDR; i++) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ data->base[i] = devm_ioremap_resource(&pdev->dev, res);
+
+ /* First base address is mandatory */
+ if (IS_ERR(data->base) && !i)
+ return PTR_ERR(data->base);
+ }
data->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(data->clk)) {
--
2.0.1
^ permalink raw reply related
* [PATCH 3/6] ARM: dts: vf610: Add usbmisc for non-core registers
From: Stefan Agner @ 2014-07-18 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1405702442.git.stefan@agner.ch>
Add device tree node for usbmisc which controls the non-core USB
registers. This is required to use the property to disable the over-
current detection.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/vf610.dtsi | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index f6c3f02..b20ce4f 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -334,11 +334,19 @@
interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks VF610_CLK_USBC0>;
fsl,usbphy = <&usbphy0>;
+ fsl,usbmisc = <&usbmisc 0>;
dr_mode = "peripheral";
status = "disabled";
};
-
+ usbmisc: usb at 40034800 {
+ #index-cells = <1>;
+ compatible = "fsl,vf610-usbmisc";
+ reg = <0x40034800 0x200>,
+ <0x400b4800 0x200>;
+ clocks = <&clks VF610_CLK_USBC0>,
+ <&clks VF610_CLK_USBC1>;
+ };
};
aips1: aips-bus at 40080000 {
@@ -407,6 +415,7 @@
interrupts = <0 76 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks VF610_CLK_USBC1>;
fsl,usbphy = <&usbphy1>;
+ fsl,usbmisc = <&usbmisc 1>;
dr_mode = "host";
status = "disabled";
};
--
2.0.1
^ permalink raw reply related
* [PATCH 2/6] ARM: imx: clk-vf610: add USBPHY clocks
From: Stefan Agner @ 2014-07-18 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1405702442.git.stefan@agner.ch>
This commit adds PLL7 which is required for USBPHY1. It also adds
the USB PHY and USB Controller clocks and the gates to enable them.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
All the main PLLs are currently turned on by boot ROM or boot loader, within
the kernel we only set the fixed factor. Altough, the function imx_clk_pllv3
would provide enabling and rate calculation support.
Because PLL7 is _not_ enabled at boot up, we need enable support. With this,
we make use of the imx_clk_pllv3 function the first time in clk-vf610. In
order to be aligned, would it make sense to use the function for all the
main PLLs? I think support for all types of PLL available in Vybrid is
already there, altough this need to be verified first.
arch/arm/mach-imx/clk-vf610.c | 12 ++++++++++--
include/dt-bindings/clock/vf610-clock.h | 5 ++++-
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-imx/clk-vf610.c b/arch/arm/mach-imx/clk-vf610.c
index 22dc3ee..159c5c4 100644
--- a/arch/arm/mach-imx/clk-vf610.c
+++ b/arch/arm/mach-imx/clk-vf610.c
@@ -58,6 +58,8 @@
#define PFD_PLL1_BASE (anatop_base + 0x2b0)
#define PFD_PLL2_BASE (anatop_base + 0x100)
#define PFD_PLL3_BASE (anatop_base + 0xf0)
+#define PLL3_CTRL (anatop_base + 0x10)
+#define PLL7_CTRL (anatop_base + 0x20)
static void __iomem *anatop_base;
static void __iomem *ccm_base;
@@ -148,6 +150,9 @@ static void __init vf610_clocks_init(struct device_node *ccm_node)
clk[VF610_CLK_PLL5_MAIN] = imx_clk_fixed_factor("pll5_main", "fast_clk_sel", 125, 6);
/* pll6: default 960Mhz */
clk[VF610_CLK_PLL6_MAIN] = imx_clk_fixed_factor("pll6_main", "fast_clk_sel", 40, 1);
+ /* pll7: USB1 PLL at 480MHz */
+ clk[VF610_CLK_PLL7_MAIN] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7_main", "fast_clk_sel", PLL7_CTRL, 0x2);
+
clk[VF610_CLK_PLL1_PFD_SEL] = imx_clk_mux("pll1_pfd_sel", CCM_CCSR, 16, 3, pll1_sels, 5);
clk[VF610_CLK_PLL2_PFD_SEL] = imx_clk_mux("pll2_pfd_sel", CCM_CCSR, 19, 3, pll2_sels, 5);
clk[VF610_CLK_SYS_SEL] = imx_clk_mux("sys_sel", CCM_CCSR, 0, 3, sys_sels, ARRAY_SIZE(sys_sels));
@@ -160,8 +165,11 @@ static void __init vf610_clocks_init(struct device_node *ccm_node)
clk[VF610_CLK_PLL4_MAIN_DIV] = clk_register_divider_table(NULL, "pll4_main_div", "pll4_main", 0, CCM_CACRR, 6, 3, 0, pll4_main_div_table, &imx_ccm_lock);
clk[VF610_CLK_PLL6_MAIN_DIV] = imx_clk_divider("pll6_main_div", "pll6_main", CCM_CACRR, 21, 1);
- clk[VF610_CLK_USBC0] = imx_clk_gate2("usbc0", "pll3_main", CCM_CCGR1, CCM_CCGRx_CGn(4));
- clk[VF610_CLK_USBC1] = imx_clk_gate2("usbc1", "pll3_main", CCM_CCGR7, CCM_CCGRx_CGn(4));
+ clk[VF610_CLK_USBPHY0] = imx_clk_gate("usbphy0", "pll3_main", PLL3_CTRL, 6);
+ clk[VF610_CLK_USBPHY1] = imx_clk_gate("usbphy1", "pll7_main", PLL7_CTRL, 6);
+
+ clk[VF610_CLK_USBC0] = imx_clk_gate2("usbc0", "ipg_bus", CCM_CCGR1, CCM_CCGRx_CGn(4));
+ clk[VF610_CLK_USBC1] = imx_clk_gate2("usbc1", "ipg_bus", CCM_CCGR7, CCM_CCGRx_CGn(4));
clk[VF610_CLK_QSPI0_SEL] = imx_clk_mux("qspi0_sel", CCM_CSCMR1, 22, 2, qspi_sels, 4);
clk[VF610_CLK_QSPI0_EN] = imx_clk_gate("qspi0_en", "qspi0_sel", CCM_CSCDR3, 4);
diff --git a/include/dt-bindings/clock/vf610-clock.h b/include/dt-bindings/clock/vf610-clock.h
index a916029..6593757 100644
--- a/include/dt-bindings/clock/vf610-clock.h
+++ b/include/dt-bindings/clock/vf610-clock.h
@@ -164,6 +164,9 @@
#define VF610_CLK_DMAMUX1 151
#define VF610_CLK_DMAMUX2 152
#define VF610_CLK_DMAMUX3 153
-#define VF610_CLK_END 154
+#define VF610_CLK_PLL7_MAIN 154
+#define VF610_CLK_USBPHY0 155
+#define VF610_CLK_USBPHY1 156
+#define VF610_CLK_END 157
#endif /* __DT_BINDINGS_CLOCK_VF610_H */
--
2.0.1
^ permalink raw reply related
* [PATCH 1/6] ARM: dts: vf610: add USB PHY and controller
From: Stefan Agner @ 2014-07-18 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1405702442.git.stefan@agner.ch>
This adds USB PHY and USB controller nodes. Vybrid SoCs have two
independent USB cores which each supports DR (dual role). However,
real OTG is not supported since the OTG ID pin is not available.
The PHYs are located within the anadig register range, hence we need
to change the length of the anadig registers.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/vf610.dtsi | 46 +++++++++++++++++++++++++++++++++++++++++---
1 file changed, 43 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 6a6190c..f6c3f02 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -25,6 +25,8 @@
gpio2 = &gpio3;
gpio3 = &gpio4;
gpio4 = &gpio5;
+ usbphy0 = &usbphy0;
+ usbphy1 = &usbphy1;
};
cpus {
@@ -285,9 +287,25 @@
gpio-ranges = <&iomuxc 0 128 7>;
};
- anatop at 40050000 {
- compatible = "fsl,vf610-anatop";
- reg = <0x40050000 0x1000>;
+ anatop: anatop at 40050000 {
+ compatible = "fsl,vf610-anatop", "syscon";
+ reg = <0x40050000 0x400>;
+ };
+
+ usbphy0: usbphy at 40050800 {
+ compatible = "fsl,vf610-usbphy", "fsl,imx23-usbphy";
+ reg = <0x40050800 0x400>;
+ interrupts = <0 50 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_USBPHY0>;
+ fsl,anatop = <&anatop>;
+ };
+
+ usbphy1: usbphy at 40050c00 {
+ compatible = "fsl,vf610-usbphy", "fsl,imx23-usbphy";
+ reg = <0x40050c00 0x400>;
+ interrupts = <0 51 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_USBPHY1>;
+ fsl,anatop = <&anatop>;
};
i2c0: i2c at 40066000 {
@@ -309,6 +327,18 @@
reg = <0x4006b000 0x1000>;
#clock-cells = <1>;
};
+
+ usbdev0: usb at 40034000 {
+ compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+ reg = <0x40034000 0x800>;
+ interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_USBC0>;
+ fsl,usbphy = <&usbphy0>;
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+
};
aips1: aips-bus at 40080000 {
@@ -371,6 +401,16 @@
status = "disabled";
};
+ usbh1: usb at 400b4000 {
+ compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+ reg = <0x400b4000 0x800>;
+ interrupts = <0 76 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_USBC1>;
+ fsl,usbphy = <&usbphy1>;
+ dr_mode = "host";
+ status = "disabled";
+ };
+
ftm: ftm at 400b8000 {
compatible = "fsl,ftm-timer";
reg = <0x400b8000 0x1000 0x400b9000 0x1000>;
--
2.0.1
^ permalink raw reply related
* [PATCH 0/6] vf610: Add USB support
From: Stefan Agner @ 2014-07-18 17:01 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds USB support for Vybrid VF610 SoC. It extends the
clock framework to support the USB PHY cocks, extends the device
tree files and adds support for the non-core registers in the
usbmisc_imx driver.
This patchset needs the eSDHC length fix available in Shawn's
for-next branch.
The whole patchset proved to be working on a Colibri VF61. The
first USB controller runs in peripheral mode. I could successfully
use RNDIS, however with some stability issues: Suddenly the other
side was not reachable anymore and the interface needed to brought
down and back up again. I'm still investigating this.
The second USB controller, running in USB host mode, showed no
issues so far.
Stefan Agner (6):
ARM: dts: vf610: add USB PHY and controller
ARM: imx: clk-vf610: add USBPHY clocks
ARM: dts: vf610: Add usbmisc for non-core registers
chipidea: usbmisc_imx: Add USB support for VF610 SoCs
usb: phy: mxs: Add VF610 USB PHY support
ARM: dts: vf610-colibri: add USB support
arch/arm/boot/dts/vf610-colibri.dts | 10 +++++
arch/arm/boot/dts/vf610.dtsi | 55 ++++++++++++++++++++++--
arch/arm/mach-imx/clk-vf610.c | 12 +++++-
drivers/usb/chipidea/usbmisc_imx.c | 76 +++++++++++++++++++++++----------
drivers/usb/phy/phy-mxs-usb.c | 5 +++
include/dt-bindings/clock/vf610-clock.h | 5 ++-
6 files changed, 135 insertions(+), 28 deletions(-)
--
2.0.1
^ permalink raw reply
* [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
From: Suman Anna @ 2014-07-18 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405680597-10012-1-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 07/18/2014 05:49 AM, Laurent Pinchart wrote:
> Hello,
>
> The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that is has
> been ported to the DMA API, remove the unused virtual memory manager.
>
> The removal is split in three patches to ease upstream merge. The first patch
> removes the omap-iovmm driver, the second patch removes setting of now unused
> platform data fields from arch code, and the last patch cleans up the platform
> data structure.
Thanks for the revised series, it looks good. I have also tested the
series on OMAP3, OMAP4 and OMAP5.
For the changes in the entire series,
Acked-by: Suman Anna <s-anna@ti.com>
regards
Suman
>
> I'd like to get at least the first patch merged in v3.17. To avoid splitting
> the series across three kernel versions, it would be nice to also merge at
> least the second patch for v3.17. If there's no risk of conflict everything
> could be merged in one go through the ARM SoC tree. Otherwise a stable branch
> with patch 1/3 will be needed to base the arch change on.
>
> Joerg, Tony, how would you like to proceed ?
>
> Changes compared to v1:
>
> - Fix OMAP_IOMMU_DEBUG dependency on OMAP_IOMMU
> - Remove omap_iommu da_start and da_end fields
> - Added patches 2/3 and 3/3
>
> Laurent Pinchart (3):
> iommu/omap: Remove virtual memory manager
> ARM: omap: Don't set iommu pdata da_start and da_end fields
> iommu/omap: Remove platform data da_start and da_end fields
>
> arch/arm/mach-omap2/omap-iommu.c | 2 -
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 -
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 -
> drivers/iommu/Kconfig | 10 +-
> drivers/iommu/Makefile | 1 -
> drivers/iommu/omap-iommu-debug.c | 114 -----
> drivers/iommu/omap-iommu.c | 13 -
> drivers/iommu/omap-iommu.h | 8 +-
> drivers/iommu/omap-iovmm.c | 791 -----------------------------
> include/linux/omap-iommu.h | 37 +-
> include/linux/platform_data/iommu-omap.h | 6 -
> 11 files changed, 8 insertions(+), 982 deletions(-)
> delete mode 100644 drivers/iommu/omap-iovmm.c
>
^ permalink raw reply
* [PATCH 0/9] usb: musb: several bugfixes for the musb driver
From: Felipe Balbi @ 2014-07-18 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718161636.GA18460@arch.cereza>
Hi,
On Fri, Jul 18, 2014 at 01:16:36PM -0300, Ezequiel Garcia wrote:
> Hi Lothar,
>
> On 18 Jul 11:31 AM, Lothar Wa?mann wrote:
> > The first three patches do some source code cleanup in the files that
> > are modified in the subsequent patches.
> >
>
> I've applied patches 4 and 9 on a recent -next, after fixing a conflict
> due to patch 3 ("usb: musb_am335x: source cleanup"):
>
> > Patch 4 carries the proper fix reported in commit:
> > 7adb5c876e9c ("usb: musb: Fix panic upon musb_am335x module removal")
> >
> > Patch 9 reinstates module unloading support for the musb_am335x driver
> > which was disabled due to a false failure analysis
> >
>
> For these two patches, Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
>
> Tested on a beaglebone with a mass storage USB device, module load/unload
> works without issues. The module_get/put in the phy is now preventing the
> musb_am335x driver unload, which seems to be the real cause of the issue
> I reported. Thanks for providing a proper fix!
I don't that's a good fix. The problem is that even after am335x
removing all its child, someone else tried to release the PHY. That
ordering is the one that needs to be fixed. Doing a module_get on the
parent device looks like a hack to me.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140718/7dd6352f/attachment.sig>
^ permalink raw reply
* [PATCHv6 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
From: Chanwoo Choi @ 2014-07-18 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10264770.8SXiIS8qhq@wuerfel>
On Sat, Jul 19, 2014 at 1:31 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 19 July 2014 01:11:53 Chanwoo Choi wrote:
>>
>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>> - 'adc' clock: bus clock for ADC
>>
>> Exynos3250 has additional 'sclk_adc' clock as following:
>> - 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
>
> The bus clock is often named "apb_pclk", but it's too late to change
> that now, and it's not clear if the device is actually on APB.
>
> The problem with "sclk_adc" is that it's very close to the name used
> in the clock provider, with is CLK_SCLK_TSADC. Please try to avoid
> the ambiguity here and make it clear that they are not referring
> to the same thing. "internal" or "special" might be good if you want
> to avoid "sclk".
OK, thanks for your feedback.
I'll try to find proper name.
Chanwoo Choi
^ permalink raw reply
* [PATCH v1] ARM: rockchip: Add cpu hotplug support for RK3XXX SoCs
From: Romain Perier @ 2014-07-18 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718082921.GB21766@n2100.arm.linux.org.uk>
Le 18/07/2014 10:29, Russell King - ARM Linux a ?crit :
> On Fri, Jul 18, 2014 at 08:16:02AM +0200, Romain Perier wrote:
>> you're probably talking about __cpu_die at
>> http://lxr.free-electrons.com/source/arch/arm/kernel/smp.c#L223 . The
>> problem being that the thread below which executes cpu_die completes the
>> completion before executing smp_ops.cpu_die. So smp_ops.cpu_kill might
>> be executed before smp_ops.cpu_die (in some cases cache coherency would
>> not be turned off). Note that almost all SoCs do the same thing.
> Look at what's happening:
>
> CPU0 CPU1
> wait_for_completion_timeout()
> idle_task_exit()
> flush_cache_louis()
> complete(&cpu_died);
>
> At this point, it is safe for CPU1 to be powered down.
>
> smp_ops.cpu_kill(cpu);
> flush_cache_louis();
> smp_ops.cpu_die(cpu);
>
> If we include your code at that point, then the sequence in totality
> becomes:
>
> wait_for_completion_timeout()
> idle_task_exit()
> flush_cache_louis()
> complete(&cpu_died);
> --- rockchip_cpu_kill ---
> wait_for_completion_timeout()
> flush_cache_louis();
> --- rockchip_cpu_die ---
> complete(&cpu_died);
> pmu_set_power_domain(0 + cpu, false);
> flush_cache_louis();
> v7_exit_coherency_flush(louis);
> while(1)
> cpu_do_idle();
>
> So, I repeat my question. What is the point of your additional wait
> in rockchip_cpu_kill() and complete in rockchip_cpu_die()?
>
Mhhh... you're right... my bad ! So either smp_ops.cpu_kill(cpu) is
executed before smp_ops.cpu_die and in this case it is safe to power
down the cpu. or smp_ops.cpu_die(cpu) is executed before
smp_ops.cpu_kill(due) and it is safe too.
I will send a new patch (v2)
Romain
^ permalink raw reply
* [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs
From: Mark Rutland @ 2014-07-18 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA8YvPeOEvn+-3mHzCwDv_2_mi=EPw0sFeAKrFk_0ZgBAw@mail.gmail.com>
On Fri, Jul 18, 2014 at 05:18:27PM +0100, Peter Maydell wrote:
> On 18 July 2014 16:58, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Jul 18, 2014 at 04:52:37PM +0100, Peter Maydell wrote:
> >> Comments in the kernel sources aren't going to guide
> >> anybody except kernel developers.
> >
> > That's not entirely true, some people skim the kernel sources to figure
> > out how they're meant to use syscalls and such (though admitedly this
> > isn't all that common).
>
> Every time anybody has to do that it means you've failed to document
> something...
...and in this case, the thing to document is the hwcaps.
> >> I was expecting from this commit message that you were going to emit
> >> actual comments in /proc/cpuinfo...
> >
> > I don't think that's a good idea, and I can only see that reading when I
> > squint quite hard. ;)
>
> You have to admit it would put the documentation right where
> the people looking at cpuinfo can find it :-)
Sure :)
> How about a patch to Documentation/filesystems/proc.txt ?
Currently there seems to be a single relevant line, and it doesn't seem
to be up-to-date for SMP:
cpuinfo Info about the CPU
It might make sense to have something under Documentation/arm64, but I
don't know what precisely.
Cheers,
Mark.
^ permalink raw reply
* [PATCHv6 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
From: Arnd Bergmann @ 2014-07-18 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGTfZH3cH-QFMbfTWJJfTPTRT-Bij2TW=6CH_Yy-GaZqZvn-Xg@mail.gmail.com>
On Saturday 19 July 2014 01:23:15 Chanwoo Choi wrote:
> If don't add new compatible including specific exynos version,
> I would add new 'adc-needs-sclk' property with existing 'exynos-adc-v2'
> compatible name.
>
>
> Dear Naveen, Tomasz,
>
> If existing exynos-adc driver add just one property for 'sclk_adc'
> as following, exynos-adc could not include the exynos version
> in compatible name.
>
> I need your opinion about it.
>
> adc: adc at 126C0000 {
> compatible = "samsung,exynos-adc-v2";
> reg = <0x126C0000 0x100>, <0x10020718 0x4>;
> interrupts = <0 137 0>;
> clock-names = "adc", "sclk_adc";
> clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
> + adc-needs-sclk;
> #io-channel-cells = <1>;
> io-channel-ranges;
> }
How about just making it an optional clock? That would be much
easier because then you can simply see if the clock itself is
there and use it, or otherwise ignore it.
Arnd
^ permalink raw reply
* [PATCHv6 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
From: Arnd Bergmann @ 2014-07-18 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGTfZH3vz9MLN+1fPM22zKE64oMNDgcib3is0nfzZhhLkmdNvw@mail.gmail.com>
On Saturday 19 July 2014 01:11:53 Chanwoo Choi wrote:
>
> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
> - 'adc' clock: bus clock for ADC
>
> Exynos3250 has additional 'sclk_adc' clock as following:
> - 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
The bus clock is often named "apb_pclk", but it's too late to change
that now, and it's not clear if the device is actually on APB.
The problem with "sclk_adc" is that it's very close to the name used
in the clock provider, with is CLK_SCLK_TSADC. Please try to avoid
the ambiguity here and make it clear that they are not referring
to the same thing. "internal" or "special" might be good if you want
to avoid "sclk".
Arnd
^ permalink raw reply
* [PATCHv6 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
From: Chanwoo Choi @ 2014-07-18 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6104032.PNRl85V92G@wuerfel>
On Fri, Jul 18, 2014 at 6:50 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 18 July 2014 14:59:45 Chanwoo Choi wrote:
>> Must be "samsung,exynos-adc-v2" for
>> future controllers.
>
> It would be good to change 'future controllers' to something else now.
> Presumably that word was used before the actual products were announced,
> but now they are publically known.
>
>> + Must be "samsung,exynos3250-adc-v2" for
>> + controllers compatible with ADC of Exynos3250.
>
> Doesn't this version have a specific name as well? The ADC block
> seems to use version numbers, so better put those in here to avoid
> confusion when another Exynos7890 comes out that uses the same
> ADC as exynos3250.
If don't add new compatible including specific exynos version,
I would add new 'adc-needs-sclk' property with existing 'exynos-adc-v2'
compatible name.
Dear Naveen, Tomasz,
If existing exynos-adc driver add just one property for 'sclk_adc'
as following, exynos-adc could not include the exynos version
in compatible name.
I need your opinion about it.
adc: adc at 126C0000 {
compatible = "samsung,exynos-adc-v2";
reg = <0x126C0000 0x100>, <0x10020718 0x4>;
interrupts = <0 137 0>;
clock-names = "adc", "sclk_adc";
clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
+ adc-needs-sclk;
#io-channel-cells = <1>;
io-channel-ranges;
}
Thanks,
Chanwoo Choi
^ permalink raw reply
* [PATCH 0/2] ARM: minor sigpage enhancements
From: Nathan Lynch @ 2014-07-18 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jJiJw3yk5SKGUk8BTHEd2jTwOKtHFDA2CppzXSy8CGUbg@mail.gmail.com>
On 07/14/2014 01:57 PM, Kees Cook wrote:
> On Mon, Jul 14, 2014 at 8:46 AM, Nathan Lynch <nathan_lynch@mentor.com> wrote:
>> Russell,
>>
>> Would you consider taking these for 3.17? I've been carrying the
>> sigpage placement randomization as part of the VDSO patch set but it
>> seems worthwhile on its own. Using _install_special_mapping for the
>> VDSO and similar VMAs was recently suggested by Andy Lutomirski.
>>
>> Nathan Lynch (2):
>> ARM: use _install_special_mapping for sigpage
>> ARM: place sigpage at a random offset above stack
>>
>> arch/arm/kernel/process.c | 60 ++++++++++++++++++++++++++++++++++++++++-------
>> 1 file changed, 51 insertions(+), 9 deletions(-)
>
> Cool! Thanks for this.
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
Russell, okay to add these to your patch tracker?
^ permalink raw reply
* [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs
From: Peter Maydell @ 2014-07-18 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718155852.GB16376@leverpostej>
On 18 July 2014 16:58, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Jul 18, 2014 at 04:52:37PM +0100, Peter Maydell wrote:
>> Comments in the kernel sources aren't going to guide
>> anybody except kernel developers.
>
> That's not entirely true, some people skim the kernel sources to figure
> out how they're meant to use syscalls and such (though admitedly this
> isn't all that common).
Every time anybody has to do that it means you've failed to document
something...
>> I was expecting from this commit message that you were going to emit
>> actual comments in /proc/cpuinfo...
>
> I don't think that's a good idea, and I can only see that reading when I
> squint quite hard. ;)
You have to admit it would put the documentation right where
the people looking at cpuinfo can find it :-)
How about a patch to Documentation/filesystems/proc.txt ?
thanks
-- PMM
^ permalink raw reply
* [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs
From: Mark Rutland @ 2014-07-18 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1863399.9O2S91ZvEO@amdc1032>
On Fri, Jul 18, 2014 at 05:00:02PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Recent patch by Tomasz Figa ("irqchip: gic: Fix core ID calculation
> when topology is read from DT") fixed GIC driver to filter cluster ID
> from values returned by cpu_logical_map() for SoCs having registers
> mapped without per-CPU banking making it is possible to add CPU nodes
> for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also
> required by future changes adding initialization of cpuidle states in
> Exynos cpuidle driver through DT.
>
> Tested on Origen board (Exynos4210 SoC) and Trats2 (Exynos4412 SoC).
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> Based on next-20140717 branch of linux-next tree +
> - [PATCH 2/6] ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg32811.html
> - [PATCH] irqchip: gic: Fix core ID calculation when topology is read from DT
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34277.html
>
> arch/arm/boot/dts/exynos4210.dtsi | 17 +++++++++++++++++
> arch/arm/boot/dts/exynos4212.dtsi | 17 +++++++++++++++++
> arch/arm/boot/dts/exynos4412.dtsi | 29 +++++++++++++++++++++++++++++
> 3 files changed, 63 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> index ee3001f..b99fc83 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -31,6 +31,23 @@
> pinctrl2 = &pinctrl_2;
> };
>
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0x900>;
> + };
Please match the unit-address with the reg (e.g. this should be
cpu at 900).
Please do this for all the other CPU nodes.
Thanks,
Mark.
> +
> + cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0x901>;
> + };
> + };
> +
> sysram at 02020000 {
> compatible = "mmio-sram";
> reg = <0x02020000 0x20000>;
> diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
> index 3c00e6e..484a2da 100644
> --- a/arch/arm/boot/dts/exynos4212.dtsi
> +++ b/arch/arm/boot/dts/exynos4212.dtsi
> @@ -22,6 +22,23 @@
> / {
> compatible = "samsung,exynos4212", "samsung,exynos4";
>
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0xA00>;
> + };
> +
> + cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0xA01>;
> + };
> + };
> +
> combiner: interrupt-controller at 10440000 {
> samsung,combiner-nr = <18>;
> };
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
> index c42a3e1..89f4743 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -22,6 +22,35 @@
> / {
> compatible = "samsung,exynos4412", "samsung,exynos4";
>
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0xA00>;
> + };
> +
> + cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0xA01>;
> + };
> +
> + cpu at 2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0xA02>;
> + };
> +
> + cpu at 3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0xA03>;
> + };
> + };
> +
> combiner: interrupt-controller at 10440000 {
> samsung,combiner-nr = <20>;
> };
> --
> 1.8.2.3
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 0/9] usb: musb: several bugfixes for the musb driver
From: Ezequiel Garcia @ 2014-07-18 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675890-8802-1-git-send-email-LW@KARO-electronics.de>
Hi Lothar,
On 18 Jul 11:31 AM, Lothar Wa?mann wrote:
> The first three patches do some source code cleanup in the files that
> are modified in the subsequent patches.
>
I've applied patches 4 and 9 on a recent -next, after fixing a conflict
due to patch 3 ("usb: musb_am335x: source cleanup"):
> Patch 4 carries the proper fix reported in commit:
> 7adb5c876e9c ("usb: musb: Fix panic upon musb_am335x module removal")
>
> Patch 9 reinstates module unloading support for the musb_am335x driver
> which was disabled due to a false failure analysis
>
For these two patches, Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested on a beaglebone with a mass storage USB device, module load/unload
works without issues. The module_get/put in the phy is now preventing the
musb_am335x driver unload, which seems to be the real cause of the issue
I reported. Thanks for providing a proper fix!
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply
* [PATCH v2 0/4] Support for Qualcomm QPNP PMIC's
From: Stanimir Varbanov @ 2014-07-18 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C857DE.7030507@codeaurora.org>
On 07/18/2014 02:10 AM, Stephen Boyd wrote:
> On 07/17/14 09:17, Stanimir Varbanov wrote:
>> Hello everyone,
>>
>> Here is the continuation of patch sets sent recently about Qualcomm
>> QPNP SPMI PMICs.
>>
>> The previous version of the patch set can be found at [1].
>>
>> Changes since v1:
>> - removed completely custom *of* parser
>> - renamed the mfd driver from qpnp-spmi to pm8xxx-spmi
>> - now MFD_PM8XXX_SPMI Kconfig option depends on SPMI
>>
>> Removing of the custom *of* parser leads to that that the *reg* devicetree
>> property cannot exist and therefore cannot be parsed to get PMIC peripheral
>> resources. I took this step aside because no one from mfd drivers does this
>> parsing. This will lead to inconvenience in the peripheral drivers to define
>> internally the SPMI base addresses depending on the compatible property
>> i.e. PMIC version.
>
> We should teach the of platform layer to translate reg properties up
> until the point that they can't be translated anymore. If they can't be
> translated all the way back to cpu addresses we can make the resource
> have IORESOURCE_REG instead of IORESOURCE_MEM and then said pmic
> platform drivers can use platform_get_resource() with IORESOURCE_REG
> instead of IORESOURCE_MEM to get the addresses.
>
I considered this as an option, if it is acceptable by OF maintainers it
will be awesome.
Rob, Grant, is that feasible?
--
regards,
Stan
^ permalink raw reply
* [PATCHv6 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
From: Chanwoo Choi @ 2014-07-18 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <32226622.5gSmvBRKvZ@wuerfel>
On Sat, Jul 19, 2014 at 12:23 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 19 July 2014 00:15:35 Chanwoo Choi wrote:
>> On Fri, Jul 18, 2014 at 8:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday 18 July 2014 19:00:48 Chanwoo Choi wrote:
>> >> On 07/18/2014 06:47 PM, Arnd Bergmann wrote:
>> >> >
>> >> > Further, why is it called "sclk_adc" rather than just "sclk"?
>> >>
>> >> The sclk means 'special clock' in Exynos TRM. Exynos SoC has varisou sclk clocks.
>> >> 'sclk_adc' is only used for ADC IP.
>> >
>> > But that sounds like sclk_adc is the name of the global name
>> > of the clock signal coming out of the clock controller.
>> >
>> > I still think it would be best to name it 'sclk' as the input
>> > for the adc. It shouldn't rely on a particular name of the
>> > clock controller.
>>
>> I think 'sclk' is too common name. 'sclk' don't include specific device name.
>> As I know, usual clock name includes the name of IP or includes the
>> specific meaning for each IP.
>
> No, normally it does not include the name of the IP, that's my whole point.
> Including the name of the IP is completely pointless because that is
> implied by the fact that it's being used by that particular IP.
>
> Ideally you would find the data sheet for the ADC IP block and figure
> out what this clock is used for, then find the right name for that.
I mentioned the meaning of clocks ('adc', 'sclk_adc') as following in
patch description.
But, you think that need the more proper name instead of 'sclk_adc' to mean the
correct operation of 'sclk_adc'. I'll check once again the meaning of
'sclk_adc' in data sheet
and renaming it.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_adc' clock as following:
- 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
> In a lot of cases, we are actually better off not naming the clocks
> at all but simply enumerating them if nobody knows what they are good
> for. In that case, you would simply have the first clock and the second
> clock of the ADC part and enable them both.
Thanks for your review.
Chanwoo Choi
^ permalink raw reply
* [PATCH v5 7/8] drivers: cpuidle: initialize Exynos driver through DT
From: Bartlomiej Zolnierkiewicz @ 2014-07-18 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANuQgHEPocfO8wDPDTJUkBNGEfw6FoLEYAJK-zPPA7kd_L-34Q@mail.gmail.com>
Hi,
On Friday, July 18, 2014 02:15:01 PM Chander Kashyap wrote:
> Hi Lorenzo,
>
>
> On 17 July 2014 19:50, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> > On Wed, Jun 25, 2014 at 04:23:38PM +0100, Bartlomiej Zolnierkiewicz wrote:
> >>
> >> Hi,
> >>
> >> On Wednesday, June 25, 2014 03:10:20 PM Lorenzo Pieralisi wrote:
> >> > With the introduction of DT based idle states, CPUidle drivers for
> >> > ARM can now initialize idle states data through properties in the device
> >> > tree.
> >> >
> >> > This patch adds code to the Exynos CPUidle driver to dynamically
> >> > initialize idle states data through the updated device tree source
> >> > files.
> >> >
> >> > Cc: Kukjin Kim <kgene.kim@samsung.com>
> >> > Cc: Tomasz Figa <t.figa@samsung.com>
> >> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> > ---
> >> > Compile tested, I am not sure I patched the right dts files, please check.
> >>
> >> cpuidle-exynos driver is currently working properly in deeper cpuidle
> >> mode (AFTR) on Exynos4210 and Exynos5250 (please also see the following
> >> patch from Tomasz Figa: [1]). There is ongoing work to AFTR mode work
> >> also on Exynos4x12 and Exynos3250 but it is not complete yet. Exynos5410
> >> OTOH should probably use the generic big little cpuidle driver (this SoC
> >> is similar to Exynos5420 one for which Chander Kashyap has developed
> >> cpuidle-big_little support [2]).
> >>
> >> Making long story short, I think that your patch should depend on patch
> >> [1] and update only exynos4210.dtsi and exynos5250.dtsi. Also for your
> >> patch #6 there needs to be some coordination with merging of Chander's
> >> patchset ([2]).
> >>
> >> [1] http://www.spinics.net/lists/arm-kernel/msg341023.html
> >> [2] https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg664470.html
> >
> >
> > exynos4210.dtsi does not even have cpu nodes in it. Should I add them or
> > this might trigger regression (ie cpu_logical_map()) ?
>
> Yes that can cause regression.
Yes, two patches from Tomasz Figa are needed to fix it:
- [PATCH 2/6] ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg32811.html
- [PATCH] irqchip: gic: Fix core ID calculation when topology is read from DT
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34277.html
> > I will post a new version soon, should I just patch 5250 for now ?
I posted patch adding CPU nodes for Exynos4 SoCs to DT:
- [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34378.html
Please make your series depend on it and add Exynos4210 support.
> > I would need help to test this patch thanks.
>
> I can test the patch for 5250.
I can do testing on Exynos4210 if needed.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> >
> > Lorenzo
> >
> >> > .../devicetree/bindings/arm/exynos/idle-states.txt | 27 ++++++++++++++++++++
> >> > arch/arm/boot/dts/exynos3250.dtsi | 16 ++++++++++++
> >> > arch/arm/boot/dts/exynos5250.dtsi | 15 +++++++++++
> >> > arch/arm/boot/dts/exynos5410.dtsi | 17 +++++++++++++
> >> > drivers/cpuidle/Kconfig.arm | 1 +
> >> > drivers/cpuidle/cpuidle-exynos.c | 29 +++++++++++++---------
> >> > 6 files changed, 93 insertions(+), 12 deletions(-)
> >> > create mode 100644 Documentation/devicetree/bindings/arm/exynos/idle-states.txt
^ permalink raw reply
* [PATCH 4/5] tty: serial: 8250 core: add runtime pm
From: Felipe Balbi @ 2014-07-18 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C942F1.2000408@hurleysoftware.com>
On Fri, Jul 18, 2014 at 11:53:21AM -0400, Peter Hurley wrote:
> On 07/18/2014 11:31 AM, Felipe Balbi wrote:
> >On Fri, Jul 18, 2014 at 10:35:10AM +0200, Sebastian Andrzej Siewior wrote:
> >>>On 07/17/2014 06:18 PM, Felipe Balbi wrote:
> >>>
> >>>>> >>No, this is okay. If you look, it checks for "up->ier &
> >>>>> >>UART_IER_THRI". On the second invocation it will see that this
> >>>>> >>bit is already set and therefore won't call get_sync() for the
> >>>>> >>second time. That bit is removed in the _stop_tx() path.
> >>>> >
> >>>> >oh, right. But that's actually unnecessary. Calling
> >>>> >pm_runtime_get() multiple times will just increment the usage
> >>>> >counter multiple times, which means you can call __stop_tx()
> >>>> >multiple times too and everything gets balanced, right ?
> >>>
> >>>No. start_tx() will be called multiple times but only the first
> >>>invocation invoke pm_runtime_get(). Now I noticed that I forgot to
> >right, but that's unnecessary. You can pm_runtime_get() every time
> >start_tx() is called. Just make sure to put everytime stop_tx() is
> >called too.
>
> The interface is asymmetric.
>
> start_tx() may be invoked multiple times for which only 1 interrupt
> will occur, and thus only invoke __stop_tx() once.
alright, thanks for the info.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140718/d89a0b78/attachment.sig>
^ permalink raw reply
* [PATCH v5 01/14] clk: composite: support determine_rate using rate_ops->round_rate + mux_ops->set_parent
From: Heiko Stübner @ 2014-07-18 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG374jCyHu1qfu7BWXYGMEdN93Uep9bnZqFk5aNZvnLMLpPCOg@mail.gmail.com>
Am Freitag, 18. Juli 2014, 15:55:55 schrieb Gabriel Fernandez:
> Hi Heiko,
> Sorry for the delay...
>
> I have tested your patch with below cases.
>
> -----
>
> CH0 -----------+--| | ----- CLK1
>
> | | MUX |-------| DIV |-----
>
> CH1 ----+---------| | -----
>
> | | -----
> | |
> | | -----
> |
> | +--| | ----- CLK2
> |
> | | | MUX |-------| DIV |-----
>
> +---------| | -----
>
> | | -----
> | |
> | | -----
> |
> | +--| | ----- CLK3
> |
> | | MUX |-------| DIV |-----
>
> +---------| | -----
>
> -----
>
> CH0 = 297000000 Hz
> CH1 = 148352000 Hz
>
> i set:
> CLK1 -> 297000000
> CLK2 -> 148352000
> CLK3 -> 148352000/2
>
> I was a little confused first time because CLK1,CLK2,CL3 had the
> clk_flags set to CLK_SET_RATE_PARENT.
>
> result
> set rate CLK1 -> 297000000
> ---> CLK1 = 297000000 (parent CH0)
>
> set rate CLK2 -> 148352000
> ---> CLK1 = 297000000 (parent CH0)
> ---> CLK2 = 148352000 (parent CH1)
>
> set rate CLK3 -> 148352000/2
> ---> CLK1 = 148352000/2 (parent CH0)
> ---> CLK2 = 148352000 (parent CH1)
> ---> CLK3 = 148352000/2 (parent CH0)
>
> We try to find the best parent but without considering the DIV...
> For me output clocks are not at all predictable in this case.
> what is your feeling about that ? is it a true probleme or a bad use case ?
>
>
> If clk_flags NOT set to CLK_SET_RATE_PARENT it's ok for me
>
> result
> set rate CLK1 -> 297000000
> ---> CLK1 = 297000000 (parent CH0)
>
> set rate CLK2 -> 148352000
> ---> CLK1 = 297000000 (parent CH0)
> ---> CLK2 = 148352000 (parent CH1)
>
> set rate CLK3 -> 148352000/2
> ---> CLK1 = 297000000 (parent CH0)
> ---> CLK2 = 148352000 (parent CH1)
> ---> CLK3 = 148352000/2 (parent CH0)
ok, so when CLK_SET_RATE_PARENT is set, the clock framework essentially sets
the CHx frequency to something new while without it it just uses the mux and
divider so create a suitable frequency.
I guess, the rate_ops->round_rate is modifying the parent rate, as the CHx
sources support changing them. But I'm wondering if the clock framework
shouldn't prevent the parent clock from being lowered.
Also I'm not even sure if a traditional setup of mux + divider clocks wouldn't
produce a similar result in the example above. Because when looking at
__clk_mux_determine_rate it looks very similar [__clk_round_is used for the
CLK_SET_RATE_PARENT case] and thus might even produce the same result.
Heiko
>
> On 3 July 2014 01:56, Heiko St?bner <heiko@sntech.de> wrote:
> > From: Boris BREZILLON <b.brezillon@overkiz.com>
> >
> > In case the rate_hw does not implement determine_rate, but only round_rate
> > we fallback to best_parent selection if mux_hw is present and support
> > reparenting.
> >
> > Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> >
> > This also fixes a rate calculation problem when using the standard div and
> > mux ops, as in this case currently only the mux->determine_rate is used
> > in the composite rate calculation.
> > So when for example the composite clock has two parents at 600 and 800MHz,
> > the requested rate is 75MHz, which the divider could provide, without this
> > change the rate would be set 600MHz ignoring the divider completely.
> > This may be way out of spec for the component.
> >
> > [fixed the output to actually return a rate instead of the diff]
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > Acked-By: Max Schwarz <max.schwarz@online.de>
> > Tested-By: Max Schwarz <max.schwarz@online.de>
> >
> > on a stih416 board
> > Tested-by: Gabriel Fernandez <gabriel.fernandez@linaro.org>
> > ---
> > Gabriel, I hope it is ok that I converted test-success to a Tested-by-Tag
> > :-)>
> > drivers/clk/clk-composite.c | 48
> > ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 47
> > insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> > index 57a078e..9548bfc 100644
> > --- a/drivers/clk/clk-composite.c
> > +++ b/drivers/clk/clk-composite.c
> > @@ -64,11 +64,56 @@ static long clk_composite_determine_rate(struct clk_hw
> > *hw, unsigned long rate,>
> > const struct clk_ops *mux_ops = composite->mux_ops;
> > struct clk_hw *rate_hw = composite->rate_hw;
> > struct clk_hw *mux_hw = composite->mux_hw;
> >
> > + struct clk *parent;
> > + unsigned long parent_rate;
> > + long tmp_rate, best_rate = 0;
> > + unsigned long rate_diff;
> > + unsigned long best_rate_diff = ULONG_MAX;
> > + int i;
> >
> > if (rate_hw && rate_ops && rate_ops->determine_rate) {
> >
> > rate_hw->clk = hw->clk;
> > return rate_ops->determine_rate(rate_hw, rate,
> > best_parent_rate,
> >
> > best_parent_p);
> >
> > + } else if (rate_hw && rate_ops && rate_ops->round_rate &&
> > + mux_hw && mux_ops && mux_ops->set_parent) {
> > + *best_parent_p = NULL;
> > +
> > + if (__clk_get_flags(hw->clk) & CLK_SET_RATE_NO_REPARENT) {
> > + *best_parent_p = clk_get_parent(mux_hw->clk);
> > + *best_parent_rate =
> > __clk_get_rate(*best_parent_p);
> > +
> > + return rate_ops->round_rate(rate_hw, rate,
> > + best_parent_rate);
> > + }
> > +
> > + for (i = 0; i < __clk_get_num_parents(mux_hw->clk); i++) {
> > + parent = clk_get_parent_by_index(mux_hw->clk, i);
> > + if (!parent)
> > + continue;
> > +
> > + parent_rate = __clk_get_rate(parent);
> > +
> > + tmp_rate = rate_ops->round_rate(rate_hw, rate,
> > + &parent_rate);
> > + if (tmp_rate < 0)
> > + continue;
> > +
> > + rate_diff = abs(rate - tmp_rate);
> > +
> > + if (!rate_diff || !*best_parent_p
> > + || best_rate_diff > rate_diff) {
> > + *best_parent_p = parent;
> > + *best_parent_rate = parent_rate;
> > + best_rate_diff = rate_diff;
> > + best_rate = tmp_rate;
> > + }
> > +
> > + if (!rate_diff)
> > + return rate;
> > + }
> > +
> > + return best_rate;
> >
> > } else if (mux_hw && mux_ops && mux_ops->determine_rate) {
> >
> > mux_hw->clk = hw->clk;
> > return mux_ops->determine_rate(mux_hw, rate,
> > best_parent_rate,
> >
> > @@ -196,7 +241,8 @@ struct clk *clk_register_composite(struct device *dev,
> > const char *name,>
> > composite->rate_hw = rate_hw;
> > composite->rate_ops = rate_ops;
> > clk_composite_ops->recalc_rate =
> > clk_composite_recalc_rate;
> >
> > - if (rate_ops->determine_rate)
> > + if (rate_ops->determine_rate ||
> > + (rate_ops->round_rate &&
> > clk_composite_ops->set_parent))>
> > clk_composite_ops->determine_rate =
> > clk_composite_determine_rate;
> >
> > }
> >
> > --
> > 1.9.0
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs
From: Bartlomiej Zolnierkiewicz @ 2014-07-18 16:00 UTC (permalink / raw)
To: linux-arm-kernel
Recent patch by Tomasz Figa ("irqchip: gic: Fix core ID calculation
when topology is read from DT") fixed GIC driver to filter cluster ID
from values returned by cpu_logical_map() for SoCs having registers
mapped without per-CPU banking making it is possible to add CPU nodes
for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also
required by future changes adding initialization of cpuidle states in
Exynos cpuidle driver through DT.
Tested on Origen board (Exynos4210 SoC) and Trats2 (Exynos4412 SoC).
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
Based on next-20140717 branch of linux-next tree +
- [PATCH 2/6] ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg32811.html
- [PATCH] irqchip: gic: Fix core ID calculation when topology is read from DT
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34277.html
arch/arm/boot/dts/exynos4210.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/exynos4212.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/exynos4412.dtsi | 29 +++++++++++++++++++++++++++++
3 files changed, 63 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index ee3001f..b99fc83 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,23 @@
pinctrl2 = &pinctrl_2;
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0x900>;
+ };
+
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0x901>;
+ };
+ };
+
sysram at 02020000 {
compatible = "mmio-sram";
reg = <0x02020000 0x20000>;
diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
index 3c00e6e..484a2da 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -22,6 +22,23 @@
/ {
compatible = "samsung,exynos4212", "samsung,exynos4";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0xA00>;
+ };
+
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0xA01>;
+ };
+ };
+
combiner: interrupt-controller at 10440000 {
samsung,combiner-nr = <18>;
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index c42a3e1..89f4743 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -22,6 +22,35 @@
/ {
compatible = "samsung,exynos4412", "samsung,exynos4";
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0xA00>;
+ };
+
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0xA01>;
+ };
+
+ cpu at 2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0xA02>;
+ };
+
+ cpu at 3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0xA03>;
+ };
+ };
+
combiner: interrupt-controller at 10440000 {
samsung,combiner-nr = <20>;
};
--
1.8.2.3
^ permalink raw reply related
* [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs
From: Mark Rutland @ 2014-07-18 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA-jdVxgUY03j12HDWzKwtVaxsmL-AarD5QyNb1jmYEa2g@mail.gmail.com>
On Fri, Jul 18, 2014 at 04:52:37PM +0100, Peter Maydell wrote:
> On 18 July 2014 14:57, Mark Rutland <mark.rutland@arm.com> wrote:
> > Comments are added to guide userspace developers in the right direction
> > (using the hwcaps provided in auxval). Hopefully where userspace
> > applications parse /proc/cpuinfo rather than using the readily available
> > hwcaps, they limit themselves to reading said first line.
>
> Comments in the kernel sources aren't going to guide
> anybody except kernel developers.
That's not entirely true, some people skim the kernel sources to figure
out how they're meant to use syscalls and such (though admitedly this
isn't all that common).
> I was expecting from this commit message that you were going to emit
> actual comments in /proc/cpuinfo...
I don't think that's a good idea, and I can only see that reading when I
squint quite hard. ;)
Thanks,
Mark
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox