* [PATCH v6 02/10] mfd: omap-usb-host: Get clocks based on hardware revision
From: Roger Quadros @ 2014-01-20 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390227091-4523-1-git-send-email-rogerq@ti.com>
Not all revisions have all the clocks so get the necessary clocks
based on hardware revision.
This should avoid un-necessary clk_get failure messages that were
observed earlier.
Be more strict and always fail on clk_get() error.
CC: Lee Jones <lee.jones@linaro.org>
CC: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/mfd/omap-usb-host.c | 92 +++++++++++++++++++++++++++++++--------------
1 file changed, 64 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 1c9bca2..eaafd2e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -665,22 +665,41 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- need_logic_fck = false;
+ /* Set all clocks as invalid to begin with */
+ omap->ehci_logic_fck = omap->init_60m_fclk = ERR_PTR(-ENODEV);
+ omap->utmi_p1_gfclk = omap->utmi_p2_gfclk = ERR_PTR(-ENODEV);
+ omap->xclk60mhsp1_ck = omap->xclk60mhsp2_ck = ERR_PTR(-ENODEV);
+
for (i = 0; i < omap->nports; i++) {
- if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
- is_ehci_hsic_mode(i))
- need_logic_fck |= true;
+ omap->utmi_clk[i] = ERR_PTR(-ENODEV);
+ omap->hsic480m_clk[i] = ERR_PTR(-ENODEV);
+ omap->hsic60m_clk[i] = ERR_PTR(-ENODEV);
}
- omap->ehci_logic_fck = ERR_PTR(-EINVAL);
- if (need_logic_fck) {
- omap->ehci_logic_fck = devm_clk_get(dev, "ehci_logic_fck");
- if (IS_ERR(omap->ehci_logic_fck)) {
- ret = PTR_ERR(omap->ehci_logic_fck);
- dev_dbg(dev, "ehci_logic_fck failed:%d\n", ret);
+ /* for OMAP3 i.e. USBHS REV1 */
+ if (omap->usbhs_rev == OMAP_USBHS_REV1) {
+ need_logic_fck = false;
+ for (i = 0; i < omap->nports; i++) {
+ if (is_ehci_phy_mode(pdata->port_mode[i]) ||
+ is_ehci_tll_mode(pdata->port_mode[i]) ||
+ is_ehci_hsic_mode(pdata->port_mode[i]))
+
+ need_logic_fck |= true;
+ }
+
+ if (need_logic_fck) {
+ omap->ehci_logic_fck = clk_get(dev, "usbhost_120m_fck");
+ if (IS_ERR(omap->ehci_logic_fck)) {
+ ret = PTR_ERR(omap->ehci_logic_fck);
+ dev_err(dev, "usbhost_120m_fck failed:%d\n",
+ ret);
+ goto err_mem;
+ }
}
+ goto initialize;
}
+ /* for OMAP4+ i.e. USBHS REV2+ */
omap->utmi_p1_gfclk = devm_clk_get(dev, "utmi_p1_gfclk");
if (IS_ERR(omap->utmi_p1_gfclk)) {
ret = PTR_ERR(omap->utmi_p1_gfclk);
@@ -728,54 +747,71 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* them
*/
omap->utmi_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap->utmi_clk[i]))
- dev_dbg(dev, "Failed to get clock : %s : %ld\n",
- clkname, PTR_ERR(omap->utmi_clk[i]));
+ if (IS_ERR(omap->utmi_clk[i])) {
+ ret = PTR_ERR(omap->utmi_clk[i]);
+ dev_err(dev, "Failed to get clock : %s : %d\n",
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic480m_p%d_clk", i + 1);
omap->hsic480m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap->hsic480m_clk[i]))
- dev_dbg(dev, "Failed to get clock : %s : %ld\n",
- clkname, PTR_ERR(omap->hsic480m_clk[i]));
+ if (IS_ERR(omap->hsic480m_clk[i])) {
+ ret = PTR_ERR(omap->hsic480m_clk[i]);
+ dev_err(dev, "Failed to get clock : %s : %d\n",
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic60m_p%d_clk", i + 1);
omap->hsic60m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap->hsic60m_clk[i]))
- dev_dbg(dev, "Failed to get clock : %s : %ld\n",
- clkname, PTR_ERR(omap->hsic60m_clk[i]));
+ if (IS_ERR(omap->hsic60m_clk[i])) {
+ ret = PTR_ERR(omap->hsic60m_clk[i]);
+ dev_err(dev, "Failed to get clock : %s : %d\n",
+ clkname, ret);
+ goto err_mem;
+ }
}
if (is_ehci_phy_mode(pdata->port_mode[0])) {
- /* for OMAP3, clk_set_parent fails */
ret = clk_set_parent(omap->utmi_p1_gfclk,
omap->xclk60mhsp1_ck);
- if (ret != 0)
- dev_dbg(dev, "xclk60mhsp1_ck set parent failed: %d\n",
+ if (ret != 0) {
+ dev_err(dev, "xclk60mhsp1_ck set parent failed: %d\n",
ret);
+ goto err_mem;
+ }
} else if (is_ehci_tll_mode(pdata->port_mode[0])) {
ret = clk_set_parent(omap->utmi_p1_gfclk,
omap->init_60m_fclk);
- if (ret != 0)
- dev_dbg(dev, "P0 init_60m_fclk set parent failed: %d\n",
+ if (ret != 0) {
+ dev_err(dev, "P0 init_60m_fclk set parent failed: %d\n",
ret);
+ goto err_mem;
+ }
}
if (is_ehci_phy_mode(pdata->port_mode[1])) {
ret = clk_set_parent(omap->utmi_p2_gfclk,
omap->xclk60mhsp2_ck);
- if (ret != 0)
- dev_dbg(dev, "xclk60mhsp2_ck set parent failed: %d\n",
+ if (ret != 0) {
+ dev_err(dev, "xclk60mhsp2_ck set parent failed: %d\n",
ret);
+ goto err_mem;
+ }
} else if (is_ehci_tll_mode(pdata->port_mode[1])) {
ret = clk_set_parent(omap->utmi_p2_gfclk,
omap->init_60m_fclk);
- if (ret != 0)
- dev_dbg(dev, "P1 init_60m_fclk set parent failed: %d\n",
+ if (ret != 0) {
+ dev_err(dev, "P1 init_60m_fclk set parent failed: %d\n",
ret);
+ goto err_mem;
+ }
}
+initialize:
omap_usbhs_init(dev);
if (dev->of_node) {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v6 03/10] mfd: omap-usb-host: Use clock names as per function for reference clocks
From: Roger Quadros @ 2014-01-20 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390227091-4523-1-git-send-email-rogerq@ti.com>
Use a meaningful name for the reference clocks so that it indicates the function.
CC: Lee Jones <lee.jones@linaro.org>
CC: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/mfd/omap-usb-host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index eaafd2e..d6fab3e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
+ omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1");
if (IS_ERR(omap->xclk60mhsp1_ck)) {
ret = PTR_ERR(omap->xclk60mhsp1_ck);
dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
goto err_mem;
}
- omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck");
+ omap->xclk60mhsp2_ck = devm_clk_get(dev, "refclk_60m_ext_p2");
if (IS_ERR(omap->xclk60mhsp2_ck)) {
ret = PTR_ERR(omap->xclk60mhsp2_ck);
dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
goto err_mem;
}
- omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk");
+ omap->init_60m_fclk = devm_clk_get(dev, "refclk_60m_int");
if (IS_ERR(omap->init_60m_fclk)) {
ret = PTR_ERR(omap->init_60m_fclk);
dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
--
1.8.3.2
^ permalink raw reply related
* [PATCH v6 04/10] mfd: omap-usb-host: Update DT clock binding information
From: Roger Quadros @ 2014-01-20 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390227091-4523-1-git-send-email-rogerq@ti.com>
The omap-usb-host driver expects certained named clocks.
Add this information to the DT binding document.
CC: Lee Jones <lee.jones@linaro.org>
CC: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
index b381fa6..4721b2d 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -32,6 +32,29 @@ Optional properties:
- single-ulpi-bypass: Must be present if the controller contains a single
ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
+- clocks: a list of phandles and clock-specifier pairs, one for each entry in
+ clock-names.
+
+- clock-names: should include:
+ For OMAP3
+ * "usbhost_120m_fck" - 120MHz Functional clock.
+
+ For OMAP4+
+ * "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux
+ * "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux.
+ * "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux
+ * "utmi_p1_gfclk" - Port 1 UTMI clock mux.
+ * "utmi_p2_gfclk" - Port 2 UTMI clock mux.
+ * "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate.
+ * "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate.
+ * "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate.
+ * "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate.
+ * "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate.
+ * "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate.
+ * "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate.
+ * "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate.
+ * "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate.
+
Required properties if child node exists:
- #address-cells: Must be 1
--
1.8.3.2
^ permalink raw reply related
* [PATCH v6 05/10] mfd: omap-usb-tll: Update DT clock binding information
From: Roger Quadros @ 2014-01-20 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390227091-4523-1-git-send-email-rogerq@ti.com>
The omap-usb-tll driver needs one clock for each TLL channel.
Add this information to the DT binding document.
CC: Lee Jones <lee.jones@linaro.org>
CC: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Documentation/devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
index 62fe697..c58d704 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -7,6 +7,16 @@ Required properties:
- interrupts : should contain the TLL module's interrupt
- ti,hwmod : must contain "usb_tll_hs"
+Optional properties:
+
+- clocks: a list of phandles and clock-specifier pairs, one for each entry in
+ clock-names.
+
+- clock-names: should include:
+ * "usb_tll_hs_usb_ch0_clk" - USB TLL channel 0 clock
+ * "usb_tll_hs_usb_ch1_clk" - USB TLL channel 1 clock
+ * "usb_tll_hs_usb_ch2_clk" - USB TLL channel 2 clock
+
Example:
usbhstll: usbhstll at 4a062000 {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v6 06/10] ARM: dts: omap4: Update omap-usb-host node
From: Roger Quadros @ 2014-01-20 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390227091-4523-1-git-send-email-rogerq@ti.com>
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..39a05ce 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -697,6 +697,12 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ clocks = <&init_60m_fclk>,
+ <&xclk60mhsp1_ck>,
+ <&xclk60mhsp2_ck>;
+ clock-names = "refclk_60m_int",
+ "refclk_60m_ext_p1",
+ "refclk_60m_ext_p2";
usbhsohci: ohci at 4a064800 {
compatible = "ti,ohci-omap3", "usb-ohci";
--
1.8.3.2
^ permalink raw reply related
* [PATCH v6 07/10] ARM: dts: omap5: Update omap-usb-host node
From: Roger Quadros @ 2014-01-20 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390227091-4523-1-git-send-email-rogerq@ti.com>
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 2f12a47..0f82ecf 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -765,6 +765,12 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ clocks = <&l3init_60m_fclk>,
+ <&xclk60mhsp1_ck>,
+ <&xclk60mhsp2_ck>;
+ clock-names = "refclk_60m_int",
+ "refclk_60m_ext_p1",
+ "refclk_60m_ext_p2";
usbhsohci: ohci at 4a064800 {
compatible = "ti,ohci-omap3", "usb-ohci";
--
1.8.3.2
^ permalink raw reply related
* [PATCH v6 08/10] ARM: dts: omap4-panda: Provide USB PHY clock
From: Roger Quadros @ 2014-01-20 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390227091-4523-1-git-send-email-rogerq@ti.com>
The USB PHY gets its clock from AUXCLK3. Provide this
information.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..50b72966 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -83,12 +83,8 @@
compatible = "usb-nop-xceiv";
reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>; /* gpio_62 */
vcc-supply = <&hsusb1_power>;
- /**
- * FIXME:
- * put the right clock phandle here when available
- * clocks = <&auxclk3>;
- * clock-names = "main_clk";
- */
+ clocks = <&auxclk3_ck>;
+ clock-names = "main_clk";
clock-frequency = <19200000>;
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v6 09/10] ARM: dts: omap5-uevm: Provide USB PHY clock
From: Roger Quadros @ 2014-01-20 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390227091-4523-1-git-send-email-rogerq@ti.com>
The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/omap5-uevm.dts | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 002fa70..3b99ec2 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,12 +31,8 @@
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
reset-gpios = <&gpio3 16 GPIO_ACTIVE_LOW>; /* gpio3_80 HUB_NRESET */
- /**
- * FIXME
- * Put the right clock phandle here when available
- * clocks = <&auxclk1>;
- * clock-names = "main_clk";
- */
+ clocks = <&auxclk1_ck>;
+ clock-names = "main_clk";
clock-frequency = <19200000>;
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v6 10/10] ARM: OMAP2+: Remove legacy_init_ehci_clk()
From: Roger Quadros @ 2014-01-20 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390227091-4523-1-git-send-email-rogerq@ti.com>
The necessary clock phandle for the EHCI clock is now provided
via device tree so we no longer need this legacy method.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/mach-omap2/pdata-quirks.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 39f020c..6a4e2d1 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -26,20 +26,6 @@ struct pdata_init {
void (*fn)(void);
};
-/*
- * Create alias for USB host PHY clock.
- * Remove this when clock phandle can be provided via DT
- */
-static void __init __used legacy_init_ehci_clk(char *clkname)
-{
- int ret;
-
- ret = clk_add_alias("main_clk", NULL, clkname, NULL);
- if (ret)
- pr_err("%s:Failed to add main_clk alias to %s :%d\n",
- __func__, clkname, ret);
-}
-
#if IS_ENABLED(CONFIG_WL12XX)
static struct wl12xx_platform_data wl12xx __initdata;
@@ -105,7 +91,6 @@ static void __init omap4_sdp_legacy_init(void)
static void __init omap4_panda_legacy_init(void)
{
omap4_panda_display_init_of();
- legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
#endif
@@ -113,7 +98,6 @@ static void __init omap4_panda_legacy_init(void)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_uevm_legacy_init(void)
{
- legacy_init_ehci_clk("auxclk1_ck");
}
#endif
--
1.8.3.2
^ permalink raw reply related
* [PATCH 06/20] ARM64 / ACPI: Introduce some PCI functions when PCI is enabled
From: Hanjun Guo @ 2014-01-20 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4387274.ri38HmFxAV@wuerfel>
On 2014?01?20? 16:20, Arnd Bergmann wrote:
> On Monday 20 January 2014 16:08:01 Hanjun Guo wrote:
>>>> diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
>>>> index 3c8521d..1835b21 100644
>>>> --- a/drivers/acpi/plat/arm-core.c
>>>> +++ b/drivers/acpi/plat/arm-core.c
>>>> @@ -100,6 +100,25 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
>>>> }
>>>> EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
>>>>
>>>> +int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
>>>> +{
>>>> + return -1;
>>>> +}
>>>> +
>>>> +int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base)
>>>> +{
>>>> + /* TBD */
>>>> + return -EINVAL;
>>>> +}
>>>> +EXPORT_SYMBOL(acpi_register_ioapic);
>>>> +
>>>> +int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base)
>>>> +{
>>>> + /* TBD */
>>>> + return -EINVAL;
>>>> +}
>>>> +EXPORT_SYMBOL(acpi_unregister_ioapic);
>>>> +
>>> My feeling is that these are better handled in the ACPI code by not
>>> calling them on architectures that have no ISA or no IOAPIC support.
>>>
>>> We have configuration symbols for both, so you don't have to make
>>> it depend on CONFIG_ARM64 or CONFIG_X86.
>> Do you mean introduce a stub function when there is no ISA support?
> Do you anticipate ISA devices on ARM64? I hope not ;-)
me too :)
>
> My guess is that whatever code calls this function should be disabled
> in reduced hw mode.
ok, that would be make sense, will update it in next version.
>
>> acpi_register_ioapic()/acpi_unregister_ioapic() will be used for IOAPIC
>> hotplug and GIC distributor is something like IOAPIC on x86, so I think
>> these two functions can be reserved for future use.
> But GIC is not hotplugged, is it? It still sounds x86 specific to me.
Well, if we want to do physical CPU hotplug on ARM/ARM64 (maybe years
later?),
then GIC add/remove is needed because we have to remove GIC
on the SoC too when we remove the physical CPU.
Thanks
Hanjun
^ permalink raw reply
* [PATCH] dt-bindings: add rockchip vendor prefix
From: Heiko Stübner @ 2014-01-20 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201312201626.48119.heiko@sntech.de>
Am Freitag, 20. Dezember 2013, 16:26:47 schrieb Heiko St?bner:
> It seems I forgot to add the vendor prefix for rockchip to the vendor-prefix
> list. Therefore add it now.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
not sure, where this should go through
arm-soc? or is there a special dt-tree around?
Thanks
Heiko
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt index
> ca2c190..2dc3b75 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -65,6 +65,7 @@ ralink Mediatek/Ralink Technology Corp.
> ramtron Ramtron International
> realtek Realtek Semiconductor Corp.
> renesas Renesas Electronics Corporation
> +rockchip Fuzhou Rockchip Electronics Co., Ltd
> samsung Samsung Semiconductor
> sbs Smart Battery System
> schindler Schindler
^ permalink raw reply
* [PATCHv10 2/2] dma: Add Freescale eDMA engine driver support
From: Jingchang Lu @ 2014-01-20 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120102007.GC26823@intel.com>
________________________________________
From: Vinod Koul <vinod.koul@intel.com>
Sent: Monday, January 20, 2014 6:20 PM
To: Lu Jingchang-B35083
Cc: dan.j.williams at intel.com; arnd at arndb.de; shawn.guo at linaro.org; pawel.moll at arm.com; mark.rutland at arm.com; swarren at wwwdotorg.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; Wang Huan-B18965
Subject: Re: [PATCHv10 2/2] dma: Add Freescale eDMA engine driver support
On Mon, Jan 20, 2014 at 11:05:03AM +0000, Jingchang Lu wrote:
>> > > > > + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
>> > > > > + struct dma_slave_config *cfg = (void *)arg;
>> > > > > + unsigned long flags;
>> > > > > + LIST_HEAD(head);
>> > > > > +
>> > > > > + switch (cmd) {
>> > > > > + case DMA_TERMINATE_ALL:
>> > > > > + spin_lock_irqsave(&fsl_chan->vchan.lock, flags);
>> > > > > + fsl_edma_disable_request(fsl_chan);
>> > > > > + fsl_chan->edesc = NULL;
>> > > > > + vchan_get_all_descriptors(&fsl_chan->vchan, &head);
>> > > > > + spin_unlock_irqrestore(&fsl_chan->vchan.lock, flags);
>> > > > > + vchan_dma_desc_free_list(&fsl_chan->vchan, &head);
>> > > > > + return 0;
> >> > > well what happens to the current ongoing transactions, i don't see
> >> those
> >> > > getting
> >> > > terminated?
> >> > The fsl_edma_disable_request(fsl_chan) would end the channel's ongoing
> >> transaction, then
> >> > the eDMA would not response to device dma request, and the
> >> vchan_dma_desc_free_list()
> >> > will release all associate memory. Thanks.
> >> Can you explain a bit more how terminate will happen, given taht you are
> >> using
> >> same thing for pause?
>> It works just like an interrupt controller on irq enable and disable. It has a register called
>> set/clear enable request register(SERQ/CERQ) to enable or disable the DMA request for a given
>> channel. It won't transfer data any more with the enable request register cleared. So for the
>> pause and terminate the pause is the same. And there is no other way to stop the channels.
>well then it is not pause! If you jave no way to stop the channel, you cant
>claim to support pause and resume!
>>Also, for terminate this will be problematic. Assuming you are doing transfers
>and terminate is invoked. Then you will disable irq. The transfers may get stuck
>and periphral clock may go away after transfer so current transaction never gets
>completed, how do we recovery from this?
The clear enable request would isolate the dma request from the eDMA engine,
and the eDMA engine could not receive any dma request from the device any more,
so the transmission is stopped, all the channel parameters will not be changed any more, and the
eDMA engine will not do any transmission for that channel until the request is enabled
by set enable request. And the channel parameters could be changed when the enable request
cleared.
We have tested the eDMA drive with the SAI audio driver which uses the cyclic dma tranfer, and it
work well.
Thanks.
>Alstly, have you looked at edma driver already existing, any similarties in teh
>controller with that?
Yes, I have notice the TI's edma driver, but they are not the same. So we implement this driver.
Best Regards,
Jingchang
^ permalink raw reply
* [PATCH v5 4/4] [media] exynos-scaler: Add DT bindings for SCALER driver
From: Shaik Ameer Basha @ 2014-01-20 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2542868.mVreZlxTcT@amdc1032>
Hi Bartlomiej,
Thanks for the review.
Yes you are right. I didn't add the users for this driver.
Once the driver gets merged, I will send more patches with the users.
Already this driver merge is pending on DT maintainers ack and I
don't want to complex it more by adding DT patches :)
Definitely, I will send the users patches once the driver gets merged.
And I will address all your comments in next version of patch series.
Regards,
Shaik Ameer Basha
On Thu, Jan 9, 2014 at 6:20 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
>
> Hi,
>
> On Thursday, January 09, 2014 08:58:14 AM Shaik Ameer Basha wrote:
>> This patch adds the DT binding documentation for the
>> Exynos5420/5410 based SCALER device driver.
>>
>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> ---
>> .../devicetree/bindings/media/exynos5-scaler.txt | 22 ++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
>> new file mode 100644
>> index 0000000..9328e7d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
>> @@ -0,0 +1,22 @@
>> +* Samsung Exynos5 SCALER device
>> +
>> +SCALER is used for scaling, blending, color fill and color space
>> +conversion on EXYNOS[5420/5410] SoCs.
>> +
>> +Required properties:
>> +- compatible: should be "samsung,exynos5420-scaler" or
>> + "samsung,exynos5410-scaler"
>> +- reg: should contain SCALER physical address location and length
>> +- interrupts: should contain SCALER interrupt number
>> +- clocks: should contain the SCALER clock specifier, from the
>> + common clock bindings
>> +- clock-names: should be "scaler"
>> +
>> +Example:
>> + scaler_0: scaler at 12800000 {
>> + compatible = "samsung,exynos5420-scaler";
>> + reg = <0x12800000 0x1000>;
>> + interrupts = <0 220 0>;
>> + clocks = <&clock 381>;
>> + clock-names = "scaler";
>> + };
>
> Your patchset adds support for EXYNOS5 SCALER but doesn't add any real
> users of it yet. Could you please explain why?
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC part2 PATCH 8/9] ACPI / ARM64: Update acpi_register_gsi to register with the core IRQ subsystem
From: Grant Likely @ 2014-01-20 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201312110623.04341.arnd@arndb.de>
On Wed, 11 Dec 2013 06:23:04 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 10 December 2013, Grant Likely wrote:
> > > --- a/drivers/acpi/plat/arm-core.c
> > > +++ b/drivers/acpi/plat/arm-core.c
> > > @@ -90,7 +90,7 @@ enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
> > >
> > > static unsigned int gsi_to_irq(unsigned int gsi)
> > > {
> > > - int irq = irq_create_mapping(NULL, gsi);
> > > + int irq = irq_find_mapping(NULL, gsi);
> >
> > I suspect this will break FDT users that depend on the old behaviour.
>
> I think not, given this is only in drivers/acpi and gets added in one
> of the prior patches of the same series.
Ah, okay.
g.
^ permalink raw reply
* [PATCH] arch_timer: Move delay timer to drivers clocksource
From: Daniel Lezcano @ 2014-01-20 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D932B5.7020909@nvidia.com>
On 01/17/2014 02:40 PM, Prashant Gaikwad wrote:
> On Friday 17 January 2014 05:38 PM, Daniel Lezcano wrote:
>> On 01/17/2014 12:37 PM, Prashant Gaikwad wrote:
>>> On Friday 17 January 2014 03:45 PM, Daniel Lezcano wrote:
>>>> On 01/17/2014 11:11 AM, Prashant Gaikwad wrote:
>>>>> On Friday 17 January 2014 02:42 PM, Daniel Lezcano wrote:
>>>>>> On 01/17/2014 10:07 AM, Antti Miettinen wrote:
>>>>>>> Will Deacon <will.deacon@arm.com> writes:
>>>>>>>> Why can't you use the C3STOP feature so that the arch-timer isn't
>>>>>>>> used when
>>>>>>>> you go idle?
>>>>>>> That would mean falling back to broadcast timer, right? That's not
>>>>>>> necessarily on the local CPU so wakeups would often wake two CPUs.
>>>>>> You can prevent that if the hardware supports it with the
>>>>>> CLOCK_EVT_DYNIRQ flag on the broadcast timer.
>>>>> Instead of falling back on broadcast timer, is it possible to fall
>>>>> back
>>>>> on other per-CPU timer which is preserved across idle state?
>>>> Is it what you are looking for ?
>>>>
>>>> http://lwn.net/Articles/580568/
>>>>
>>> If I understand correctly these patches enables us to use per-CPU timers
>>> as broadcast timers. I do not want to use broadcast timer.
>> Why ?
>>
>
> For some idle states it may be required to change the timer when
> entering idle state to adjust the exit latency.
>
> It can be done for broadcast timer too but following scenario will not work
>
> 1. CPU1 enters in idle state:
> Broadcast timer next event is in 2ms, CPU latency is 50us. So
> we change the broadcast timer to send event after (2ms - 50us).
>
> 2. After 1ms CPU2 enters in idle state:
> Next event is 5ms. Broadcast timer is already programmed to <
> (5ms -50us) so we do nothing.
>
> 3. CPU1 exits from idle state because of timer interrupt
>
> 4. Broadcast event handler:
> - Timer event is handled and CPU1 is switched back to local timer.
> - Next CPU is CPU2 and next event for it is 4ms. So brodcast timer
> is programmed to 4ms.
>
> We can not change brodcast timer here to adjust delay caused by CPU exit
> latency.
Thanks for the detailed explanation. IIUC, this not only related to your
hardware only but with how is implemented the broadcast timer, no ?
I think there is a similar need with the scheduler when it needs to know
what is the idlest cpu. One thing the scheduler wants to know is the
wakeup latency in order to choose the cpu in the shallowest state.
> CPU idle governors does help to solve the latency issue. I was thinking
> this from sub-states perspective which are not exposed to CPU idle
> governor.
Could you elaborate what you mean by these sub-states ? Is it related to
the cpuidle backend drivers choosing an intermediate state different
from the one the governor choose ?
> Solution for this could be to expose those states to CPU idle governor
> but just wanted to know if we can use timers this way
IMO, that should be studied in a larger scope including the scheduler.
> Another requirement:
>
> We have 3 timers T1, T2, T3 used as wake events for 3 idle states C1,
> C2, C3 respectively.
>
> Rating of T2 is better than T3. If I register T2 and T3 both as
> broadcast timers then T3 will not be used. But ...
> - T2 is not preserved in C3 idle state.
> - T3 resolution is very poor (ms) and can not be used as wake event
> for C2.
>
> Possible solution, register only T3 as broadcast device and use T2 as
> per-CPU fallback timer.
>
>>> If I have 2 per-CPU timers T1 and T2, T1 is not preserved across idle
>>> state and T2 is preserved. And I want to use T1 as scheduler timer.
>>> Can I do following for idle state?
>>>
>>> Idle entry:
>>> clockevents_shutdown(T1);
>>> clockevents_set_mode(T2, ONESHOT);
>>> clockevents_program_event(T2, next_event);
>>>
>>> Idle exit:
>>> clockevents_shutdown(T2);
>>> clockevents_set_mode(T1, ONESHOT);
See answer to Stephen.
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH] arch_timer: Move delay timer to drivers clocksource
From: Daniel Lezcano @ 2014-01-20 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D97831.6030700@codeaurora.org>
On 01/17/2014 07:36 PM, Stephen Boyd wrote:
> On 01/17/14 05:40, Prashant Gaikwad wrote:
>>
>> Another requirement:
>>
>> We have 3 timers T1, T2, T3 used as wake events for 3 idle states C1,
>> C2, C3 respectively.
>>
>> Rating of T2 is better than T3. If I register T2 and T3 both as
>> broadcast timers then T3 will not be used. But ...
>> - T2 is not preserved in C3 idle state.
>> - T3 resolution is very poor (ms) and can not be used as wake
>> event for C2.
>>
>> Possible solution, register only T3 as broadcast device and use T2 as
>> per-CPU fallback timer.
>
> We have the same situation on MSM. I've been thinking about proposing we
> allow multiple broadcast timers to exist in the system and then have the
> clockevents_notify() caller indicate which C state is being entered. The
> broadcast timers would need to indicate which C state they don't work in
> though.
IMO, there are different solutions:
1. extend the C3STOP to C1STOP, C2STOP, etc ... and pass the idle state
to the time framework where these flags are checked against. I don't
like this approach but it is feasible.
2. use the generic power domain. When the power domain is shutdown via
the cpuidle backend driver, it switches the timer.
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH v5 0/4] Fix i2c bus hang on A0 version of the Armada XP SoCs
From: Jason Cooper @ 2014-01-20 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD0688.1080802@free-electrons.com>
On Mon, Jan 20, 2014 at 12:20:40PM +0100, Gregory CLEMENT wrote:
> On 14/01/2014 09:46, Gregory CLEMENT wrote:
> > On 14/01/2014 03:14, Jason Cooper wrote:
> >> Gregory,
> >>
> >> On Wed, Jan 08, 2014 at 04:06:25PM +0100, Gregory CLEMENT wrote:
> >>> Hi,
> >>>
> >>> Here come the 5th version of the series fixing the i2c bus hang on A0
> >>> version of the Armada XP SoCs. It occurred on the early release of the
> >>> OpenBlocks AX3-4 boards. Indeed the first variants of Armada XP SoCs
> >>> (A0 stepping) have issues related to the i2c controller which prevent
> >>> to use the offload mechanism and lead to a kernel hang during boot.
> >>>
> >>> The main change are the use of marvell,mv78230-a0-i2c and that the
> >>> function mvebu_get_soc_id() is now local to mach-mvebu.
> >>>
> >>> The first patch add a mean to detect the SoCs version at run-time and
> >>> the second one use this feature in the driver.
> >>>
> >>> The 3 first patches should be applied on 3.13-rc and on stable kernel
> >>> 3.12 as it fixes a regression introduce by the commit 930ab3d403ae
> >>> "i2c: mv64xxx: Add I2C Transaction Generator support".
> >>
> >> Ok, I've pulled this in by cherrypicking the commits. I needed to add
> >> the 'Fixes: ...' and 'Cc: stable ...' language, so the commit ids were
> >> going to change anyhow. I also added the note to the binding as we
> >> discussed. I've also based this against v3.13-rc1 as there doesn't
> >> appear to be any need to drag in everything up to -rc6.
> >>
> >> I've pushed this to mvebu/fixes. Please take a look. If it all looks
> >> good I'll send the pull request off tomorrow.
> > Hi Jason,
> >
> > Everything looks perfect!
> >
> > Thanks for having improved it,
> >
> > Gregory
> >
>
> Hi Jason,
>
> Eventually we didn't finish with it!
> Ezequiel found an issue when we try to access pci_base if it have
> not been properly mapped, in this case the kernel hang. Indeed the check
> of the return of of_iomap was wrong.
>
> The fix would be something like:
>
> -o<---o<---o<---o<---o<---o<---o<---o<---o<---o<---o<--
> --- a/arch/arm/mach-mvebu/mvebu-soc-id.c
> +++ b/arch/arm/mach-mvebu/mvebu-soc-id.c
> @@ -88,7 +88,7 @@ static int __init mvebu_soc_id_init(void)
> }
>
> pci_base = of_iomap(child, 0);
> - if (IS_ERR(pci_base)) {
> + if (pci_base == NULL) {
> pr_err("cannot map registers\n");
> ret = -ENOMEM;
> goto res_ioremap;
> -o<---o<---o<---o<---o<---o<---o<---o<---o<---o<---o<--
>
> How do you want we handle it?
>
> Do you want a proper patch to amend?
> A new series?
> Something else?
>
submit a patch, please. We'll push it as a fix.
thx,
Jason.
^ permalink raw reply
* [PATCH] dt-bindings: add rockchip vendor prefix
From: Rob Herring @ 2014-01-20 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2229282.4AAJ7iLdU7@phil>
On Mon, Jan 20, 2014 at 8:23 AM, Heiko St?bner <heiko@sntech.de> wrote:
> Am Freitag, 20. Dezember 2013, 16:26:47 schrieb Heiko St?bner:
>> It seems I forgot to add the vendor prefix for rockchip to the vendor-prefix
>> list. Therefore add it now.
>>
>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>
> not sure, where this should go through
> arm-soc? or is there a special dt-tree around?
Sorry, missed this one. I'll apply for 3.14.
Rob
>
>
> Thanks
> Heiko
>
>> ---
>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt index
>> ca2c190..2dc3b75 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -65,6 +65,7 @@ ralink Mediatek/Ralink Technology Corp.
>> ramtron Ramtron International
>> realtek Realtek Semiconductor Corp.
>> renesas Renesas Electronics Corporation
>> +rockchip Fuzhou Rockchip Electronics Co., Ltd
>> samsung Samsung Semiconductor
>> sbs Smart Battery System
>> schindler Schindler
>
^ permalink raw reply
* [PATCH] arch_timer: Move delay timer to drivers clocksource
From: Lorenzo Pieralisi @ 2014-01-20 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD35C2.3070809@linaro.org>
On Mon, Jan 20, 2014 at 02:42:10PM +0000, Daniel Lezcano wrote:
> On 01/17/2014 07:36 PM, Stephen Boyd wrote:
> > On 01/17/14 05:40, Prashant Gaikwad wrote:
> >>
> >> Another requirement:
> >>
> >> We have 3 timers T1, T2, T3 used as wake events for 3 idle states C1,
> >> C2, C3 respectively.
> >>
> >> Rating of T2 is better than T3. If I register T2 and T3 both as
> >> broadcast timers then T3 will not be used. But ...
> >> - T2 is not preserved in C3 idle state.
> >> - T3 resolution is very poor (ms) and can not be used as wake
> >> event for C2.
> >>
> >> Possible solution, register only T3 as broadcast device and use T2 as
> >> per-CPU fallback timer.
> >
> > We have the same situation on MSM. I've been thinking about proposing we
> > allow multiple broadcast timers to exist in the system and then have the
> > clockevents_notify() caller indicate which C state is being entered. The
> > broadcast timers would need to indicate which C state they don't work in
> > though.
>
> IMO, there are different solutions:
>
> 1. extend the C3STOP to C1STOP, C2STOP, etc ... and pass the idle state
> to the time framework where these flags are checked against. I don't
> like this approach but it is feasible.
>
> 2. use the generic power domain. When the power domain is shutdown via
> the cpuidle backend driver, it switches the timer.
IMO, 2 is the way forward. It is the only solution that links resources to
the reason they need maintainance (ie power management). I am writing
v2 of C-state proposal where power domains are explicitly associated with
devices (eg arch timers), and 2 fits well with this approach.
Lorenzo
^ permalink raw reply
* [PATCH v3 3/7] net: moxa: connect to PHY
From: Rob Herring @ 2014-01-20 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390216399-27028-3-git-send-email-jonas.jensen@gmail.com>
On Mon, Jan 20, 2014 at 5:13 AM, Jonas Jensen <jonas.jensen@gmail.com> wrote:
> The kernel now has a MDIO bus driver and a phy_driver (RTL8201CP),
> connect to this PHY using OF.
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
> ---
>
> Notes:
> Applies to next-20140120
>
> .../devicetree/bindings/net/moxa,moxart-mac.txt | 47 ++++++++++-
> drivers/net/ethernet/moxa/moxart_ether.c | 92 +++++++++++++++++++++-
> drivers/net/ethernet/moxa/moxart_ether.h | 2 +
> 3 files changed, 138 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
> index 583418b..94c1f3b 100644
> --- a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
> +++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
> @@ -1,21 +1,64 @@
> MOXA ART Ethernet Controller
>
> +Integrated MDIO bus node:
> +
> +- compatible: "moxa,moxart-mdio"
> +- Inherits from MDIO bus node binding[1]
> +
> +[1] Documentation/devicetree/bindings/net/phy.txt
> +
> +
> +Ethernet node:
> +
> Required properties:
>
> - compatible : Must be "moxa,moxart-mac"
> - reg : Should contain register location and length
> - interrupts : Should contain the mac interrupt number
>
> +Optional Properties:
> +
> +- phy-handle : the phandle to a PHY node
> +
> +
> Example:
>
> + mdio0: mdio at 90900090 {
> + compatible = "moxa,moxart-mdio";
> + reg = <0x90900090 0x8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy at 1 {
> + device_type = "ethernet-phy";
Drop this. device_type is only for real OpenFirmware.
> + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> + };
> +
> + mdio1: mdio at 92000090 {
> + compatible = "moxa,moxart-mdio";
> + reg = <0x92000090 0x8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy1: ethernet-phy at 1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> + };
> +
> mac0: mac at 90900000 {
Not part of this patch, but this should really be ethernet at ...
> compatible = "moxa,moxart-mac";
> - reg = <0x90900000 0x100>;
> + reg = <0x90900000 0x90>;
> interrupts = <25 0>;
> + phy-handle = <ðphy0>;
> };
>
> mac1: mac at 92000000 {
> compatible = "moxa,moxart-mac";
> - reg = <0x92000000 0x100>;
> + reg = <0x92000000 0x90>;
> interrupts = <27 0>;
> + phy-handle = <ðphy1>;
> };
^ permalink raw reply
* [PATCH] ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed
From: Gregory CLEMENT @ 2014-01-20 14:59 UTC (permalink / raw)
To: linux-arm-kernel
When pci_base is accessed whereas it has not been properly mapped by
of_iomap() the kernel hang. The check of this pointer made an improper
use of IS_ERR() instead of comparing to NULL. This patch fix this
issue.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reported-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
Jason,
As this is a fix on a fix which should be ported to the stable branch, I
don't know how to handle the cc:stable flag
arch/arm/mach-mvebu/mvebu-soc-id.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/mvebu-soc-id.c b/arch/arm/mach-mvebu/mvebu-soc-id.c
index fe4fc1cbdfaf..f3b325f6cbd4 100644
--- a/arch/arm/mach-mvebu/mvebu-soc-id.c
+++ b/arch/arm/mach-mvebu/mvebu-soc-id.c
@@ -88,7 +88,7 @@ static int __init mvebu_soc_id_init(void)
}
pci_base = of_iomap(child, 0);
- if (IS_ERR(pci_base)) {
+ if (pci_base == NULL) {
pr_err("cannot map registers\n");
ret = -ENOMEM;
goto res_ioremap;
--
1.8.1.2
^ permalink raw reply related
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Russell King - ARM Linux @ 2014-01-20 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120150902.207b9d66@ipc1.ka-ro>
On Mon, Jan 20, 2014 at 03:09:02PM +0100, Lothar Wa?mann wrote:
> Hi,
>
> Russell King - ARM Linux wrote:
> > On Mon, Jan 20, 2014 at 12:36:27PM +0100, Lothar Wa?mann wrote:
> > > In case user space firmware loading support (CONFIG_FW_LOADER) is
> > > enabled, this message may still be inadequate, since the firmware may
> > > very well be loaded lateron.
> >
> > I haven't worked out whether that's actually possible - I saw no way to
> > re-trigger the firmware request, and once the firmware request expires,
> > there seems to be no way for userspace to say "okay, the firmware is now
> > available, please load it".
> >
> I can confirm that it does work, since I'm using it.
> I have the following in my /etc/init.d/mdev.sh script:
> | [ "$VERBOSE" = no ] || echo -n "Triggering firmware load"
> | for dir in $(find /sys/class/firmware/ -type l);do
> | echo add > "$dir/uevent"
> | done
I can't check on iMX6 at the moment, but I did look in that directory
after the iMX6 SDMA reported that it hadn't found any firmware, and
it was empty apart from the "timeout" file.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] arch_timer: Move delay timer to drivers clocksource
From: Daniel Lezcano @ 2014-01-20 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120145633.GA2725@e102568-lin.cambridge.arm.com>
On 01/20/2014 03:56 PM, Lorenzo Pieralisi wrote:
> On Mon, Jan 20, 2014 at 02:42:10PM +0000, Daniel Lezcano wrote:
>> On 01/17/2014 07:36 PM, Stephen Boyd wrote:
>>> On 01/17/14 05:40, Prashant Gaikwad wrote:
>>>>
>>>> Another requirement:
>>>>
>>>> We have 3 timers T1, T2, T3 used as wake events for 3 idle states C1,
>>>> C2, C3 respectively.
>>>>
>>>> Rating of T2 is better than T3. If I register T2 and T3 both as
>>>> broadcast timers then T3 will not be used. But ...
>>>> - T2 is not preserved in C3 idle state.
>>>> - T3 resolution is very poor (ms) and can not be used as wake
>>>> event for C2.
>>>>
>>>> Possible solution, register only T3 as broadcast device and use T2 as
>>>> per-CPU fallback timer.
>>>
>>> We have the same situation on MSM. I've been thinking about proposing we
>>> allow multiple broadcast timers to exist in the system and then have the
>>> clockevents_notify() caller indicate which C state is being entered. The
>>> broadcast timers would need to indicate which C state they don't work in
>>> though.
>>
>> IMO, there are different solutions:
>>
>> 1. extend the C3STOP to C1STOP, C2STOP, etc ... and pass the idle state
>> to the time framework where these flags are checked against. I don't
>> like this approach but it is feasible.
>>
>> 2. use the generic power domain. When the power domain is shutdown via
>> the cpuidle backend driver, it switches the timer.
>
> IMO, 2 is the way forward. It is the only solution that links resources to
> the reason they need maintainance (ie power management). I am writing
> v2 of C-state proposal where power domains are explicitly associated with
> devices (eg arch timers), and 2 fits well with this approach.
Thanks Lorenzo for your feedback.
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Laurent Pinchart @ 2014-01-20 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD06CB.8050606@ti.com>
Hi Tomi,
On Monday 20 January 2014 13:21:47 Tomi Valkeinen wrote:
> On 2014-01-19 23:01, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > The lcdc driver can be compiled without meram support. This is handled by
> > conditional compilation in include/video/sh_mobile_meram.h that defines
> > the
> > meram functions as stubs when meram support isn't selected.
> >
> > The problem comes from the combination of FB_SH_MOBILE_MERAM=m and
> > FB_SH_MOBILE_LCDC=y. The former makes the meram function non-stubs, while
> > the later makes the LCDC driver fail to link, as meram support is then
> > compiled as a module.
> >
> > How do you usually handle this ?
>
> I guess the easiest option is to make FB_SH_MOBILE_MERAM a bool, instead
> of tristate.
That's easy, but it would prevent meram support from being compiled as a
module when lcdc support is compiled as a module as well.
--
Regards,
Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140120/5f7481fa/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
From: Stefano Stabellini @ 2014-01-20 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116193123.GB22105@mudshark.cambridge.arm.com>
On Thu, 16 Jan 2014, Will Deacon wrote:
> Hi Stefano,
>
> On Thu, Jan 16, 2014 at 04:27:55PM +0000, Stefano Stabellini wrote:
> > On Thu, 9 Jan 2014, Will Deacon wrote:
> > > Ok, thanks for the explanation. Looking at the patch, I wonder whether it's
> > > not cleaner just to implement xchg code separately for Xen? The Linux code
> > > isn't always sufficient (due to the GENERIC_ATOMIC64 stuff) and most of the
> > > churn coming out of this patch is an attempt to provide some small code
> > > reuse at the cost of code readability.
> > >
> > > What do others think?
> >
> > I am OK with that, in fact my first version of the patch did just that:
> >
> > http://marc.info/?l=linux-arm-kernel&m=138436406724990&w=2
> >
> > Is that what you had in mind?
>
> For the xchg part, yes, that looks a lot better. I don't like the #undef
> CONFIG_CPU_V6 though, can that be rewritten to use __LINUX_ARM_ARCH__?
The problem is that the 1 and 2 byte parameter size cases in __cmpxchg
are ifdef'ed CONFIG_CPU_V6 but drivers/xen/grant-table.c needs them.
So we can either undef CONFIG_CPU_V6 in grant-table.c or call a
different function.
If I switch from ifdef CONFIG_CPU_V6 to if __LINUX_ARM_ARCH__ > 6 in
__cmpxchg, we still have the problem that if __LINUX_ARM_ARCH__ == 6,
grant-table.c doesn't compile.
Maybe the approach taken by the other patch for cmpxchg is better, see
below.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1f1a7e..ae54ae0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1881,8 +1881,7 @@ config XEN_DOM0
config XEN
bool "Xen guest support on ARM (EXPERIMENTAL)"
depends on ARM && AEABI && OF
- depends on CPU_V7 && !CPU_V6
- depends on !GENERIC_ATOMIC64
+ depends on CPU_V7
select ARM_PSCI
select SWIOTLB_XEN
help
diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index df2fbba..cc8a4a2 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -133,6 +133,44 @@ extern void __bad_cmpxchg(volatile void *ptr, int size);
* cmpxchg only support 32-bits operands on ARMv6.
*/
+static inline unsigned long __cmpxchg8(volatile void *ptr, unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval, res;
+
+ do {
+ asm volatile("@ __cmpxchg1\n"
+ " ldrexb %1, [%2]\n"
+ " mov %0, #0\n"
+ " teq %1, %3\n"
+ " strexbeq %0, %4, [%2]\n"
+ : "=&r" (res), "=&r" (oldval)
+ : "r" (ptr), "Ir" (old), "r" (new)
+ : "memory", "cc");
+ } while (res);
+
+ return oldval;
+}
+
+static inline unsigned long __cmpxchg16(volatile void *ptr, unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval, res;
+
+ do {
+ asm volatile("@ __cmpxchg1\n"
+ " ldrexh %1, [%2]\n"
+ " mov %0, #0\n"
+ " teq %1, %3\n"
+ " strexheq %0, %4, [%2]\n"
+ : "=&r" (res), "=&r" (oldval)
+ : "r" (ptr), "Ir" (old), "r" (new)
+ : "memory", "cc");
+ } while (res);
+
+ return oldval;
+}
+
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long new, int size)
{
@@ -141,28 +179,10 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
switch (size) {
#ifndef CONFIG_CPU_V6 /* min ARCH >= ARMv6K */
case 1:
- do {
- asm volatile("@ __cmpxchg1\n"
- " ldrexb %1, [%2]\n"
- " mov %0, #0\n"
- " teq %1, %3\n"
- " strexbeq %0, %4, [%2]\n"
- : "=&r" (res), "=&r" (oldval)
- : "r" (ptr), "Ir" (old), "r" (new)
- : "memory", "cc");
- } while (res);
+ oldval = __cmpxchg8(ptr, old, new);
break;
case 2:
- do {
- asm volatile("@ __cmpxchg1\n"
- " ldrexh %1, [%2]\n"
- " mov %0, #0\n"
- " teq %1, %3\n"
- " strexheq %0, %4, [%2]\n"
- : "=&r" (res), "=&r" (oldval)
- : "r" (ptr), "Ir" (old), "r" (new)
- : "memory", "cc");
- } while (res);
+ oldval = __cmpxchg16(ptr, old, new);
break;
#endif
case 4:
diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
index 63479ee..942659a 100644
--- a/arch/arm/include/asm/sync_bitops.h
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -21,7 +21,29 @@
#define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p)
#define sync_test_and_change_bit(nr, p) _test_and_change_bit(nr, p)
#define sync_test_bit(nr, addr) test_bit(nr, addr)
-#define sync_cmpxchg cmpxchg
+static inline unsigned long sync_cmpxchg(volatile void *ptr,
+ unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval;
+ int size = sizeof(*(ptr));
+
+ smp_mb();
+ switch (size) {
+ case 1:
+ oldval = __cmpxchg8(ptr, old, new);
+ break;
+ case 2:
+ oldval = __cmpxchg16(ptr, old, new);
+ break;
+ default:
+ oldval = __cmpxchg(ptr, old, new, size);
+ break;
+ }
+ smp_mb();
+
+ return oldval;
+}
#endif
diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 8b1f37b..2032ee6 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -16,7 +16,37 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return raw_irqs_disabled_flags(regs->ARM_cpsr);
}
-#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((ptr), \
+#ifdef CONFIG_GENERIC_ATOMIC64
+/* if CONFIG_GENERIC_ATOMIC64 is defined we cannot use the generic
+ * atomic64_xchg function because it is implemented using spin locks.
+ * Here we need proper atomic instructions to read and write memory
+ * shared with the hypervisor.
+ */
+static inline u64 xen_atomic64_xchg(atomic64_t *ptr, u64 new)
+{
+ u64 result;
+ unsigned long tmp;
+
+ smp_mb();
+
+ __asm__ __volatile__("@ xen_atomic64_xchg\n"
+"1: ldrexd %0, %H0, [%3]\n"
+" strexd %1, %4, %H4, [%3]\n"
+" teq %1, #0\n"
+" bne 1b"
+ : "=&r" (result), "=&r" (tmp), "+Qo" (ptr->counter)
+ : "r" (&ptr->counter), "r" (new)
+ : "cc");
+
+ smp_mb();
+
+ return result;
+}
+#else
+#define xen_atomic64_xchg atomic64_xchg
+#endif
+
+#define xchg_xen_ulong(ptr, val) xen_atomic64_xchg(container_of((ptr), \
atomic64_t, \
counter), (val))
^ permalink raw reply related
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