* [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 01/10] mfd: omap-usb-host: Use resource managed clk_get()
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 devm_clk_get() instead of clk_get().
CC: Lee Jones <lee.jones@linaro.org>
CC: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/omap-usb-host.c | 81 +++++++++------------------------------------
1 file changed, 16 insertions(+), 65 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 142650f..1c9bca2 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -674,46 +674,46 @@ static int usbhs_omap_probe(struct platform_device *pdev)
omap->ehci_logic_fck = ERR_PTR(-EINVAL);
if (need_logic_fck) {
- omap->ehci_logic_fck = clk_get(dev, "ehci_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);
}
}
- omap->utmi_p1_gfclk = clk_get(dev, "utmi_p1_gfclk");
+ 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);
dev_err(dev, "utmi_p1_gfclk failed error:%d\n", ret);
- goto err_p1_gfclk;
+ goto err_mem;
}
- omap->utmi_p2_gfclk = clk_get(dev, "utmi_p2_gfclk");
+ omap->utmi_p2_gfclk = devm_clk_get(dev, "utmi_p2_gfclk");
if (IS_ERR(omap->utmi_p2_gfclk)) {
ret = PTR_ERR(omap->utmi_p2_gfclk);
dev_err(dev, "utmi_p2_gfclk failed error:%d\n", ret);
- goto err_p2_gfclk;
+ goto err_mem;
}
- omap->xclk60mhsp1_ck = clk_get(dev, "xclk60mhsp1_ck");
+ omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
if (IS_ERR(omap->xclk60mhsp1_ck)) {
ret = PTR_ERR(omap->xclk60mhsp1_ck);
dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
- goto err_xclk60mhsp1;
+ goto err_mem;
}
- omap->xclk60mhsp2_ck = clk_get(dev, "xclk60mhsp2_ck");
+ omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck");
if (IS_ERR(omap->xclk60mhsp2_ck)) {
ret = PTR_ERR(omap->xclk60mhsp2_ck);
dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
- goto err_xclk60mhsp2;
+ goto err_mem;
}
- omap->init_60m_fclk = clk_get(dev, "init_60m_fclk");
+ omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk");
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);
- goto err_init60m;
+ goto err_mem;
}
for (i = 0; i < omap->nports; i++) {
@@ -727,21 +727,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* platforms have all clocks and we can function without
* them
*/
- omap->utmi_clk[i] = clk_get(dev, clkname);
+ 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]));
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic480m_p%d_clk", i + 1);
- omap->hsic480m_clk[i] = clk_get(dev, clkname);
+ 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]));
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic60m_p%d_clk", i + 1);
- omap->hsic60m_clk[i] = clk_get(dev, clkname);
+ 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]));
@@ -784,7 +784,7 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, "Failed to create DT children: %d\n", ret);
- goto err_alloc;
+ goto err_mem;
}
} else {
@@ -792,40 +792,12 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, "omap_usbhs_alloc_children failed: %d\n",
ret);
- goto err_alloc;
+ goto err_mem;
}
}
return 0;
-err_alloc:
- for (i = 0; i < omap->nports; i++) {
- if (!IS_ERR(omap->utmi_clk[i]))
- clk_put(omap->utmi_clk[i]);
- if (!IS_ERR(omap->hsic60m_clk[i]))
- clk_put(omap->hsic60m_clk[i]);
- if (!IS_ERR(omap->hsic480m_clk[i]))
- clk_put(omap->hsic480m_clk[i]);
- }
-
- clk_put(omap->init_60m_fclk);
-
-err_init60m:
- clk_put(omap->xclk60mhsp2_ck);
-
-err_xclk60mhsp2:
- clk_put(omap->xclk60mhsp1_ck);
-
-err_xclk60mhsp1:
- clk_put(omap->utmi_p2_gfclk);
-
-err_p2_gfclk:
- clk_put(omap->utmi_p1_gfclk);
-
-err_p1_gfclk:
- if (!IS_ERR(omap->ehci_logic_fck))
- clk_put(omap->ehci_logic_fck);
-
err_mem:
pm_runtime_disable(dev);
@@ -847,27 +819,6 @@ static int usbhs_omap_remove_child(struct device *dev, void *data)
*/
static int usbhs_omap_remove(struct platform_device *pdev)
{
- struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
- int i;
-
- for (i = 0; i < omap->nports; i++) {
- if (!IS_ERR(omap->utmi_clk[i]))
- clk_put(omap->utmi_clk[i]);
- if (!IS_ERR(omap->hsic60m_clk[i]))
- clk_put(omap->hsic60m_clk[i]);
- if (!IS_ERR(omap->hsic480m_clk[i]))
- clk_put(omap->hsic480m_clk[i]);
- }
-
- clk_put(omap->init_60m_fclk);
- clk_put(omap->utmi_p1_gfclk);
- clk_put(omap->utmi_p2_gfclk);
- clk_put(omap->xclk60mhsp2_ck);
- clk_put(omap->xclk60mhsp1_ck);
-
- if (!IS_ERR(omap->ehci_logic_fck))
- clk_put(omap->ehci_logic_fck);
-
pm_runtime_disable(&pdev->dev);
/* remove children */
--
1.8.3.2
^ permalink raw reply related
* [PATCH v6 00/10] USB Host support for OMAP5 uEVM (for 3.14)
From: Roger Quadros @ 2014-01-20 14:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi Benoit & Tony,
This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board.
It depends on the TI Clock DT conversion patches [1] and is based
on 3.13
[1] - http://article.gmane.org/gmane.linux.ports.arm.kernel/293147
Tested on:
- OMAP5 uEVM
- Pandaboard ES Rev. B1
- Beagleboard-XM Rev C2
- Beagleboard Rev C4.
cheers,
-roger
Changelog:
v6:
- Initialized clocks to -ENODEV and split patch 3.
v5:
- Expose all clocks in the DT binding document for mfd:omap-usb-host
and mfd:omap-usb-tll
v4:
- Updated DT binding document for clock binding
v3:
- Rebased on top of 3.13-rc7
cheers,
-roger
Roger Quadros (10):
mfd: omap-usb-host: Use resource managed clk_get()
mfd: omap-usb-host: Get clocks based on hardware revision
mfd: omap-usb-host: Use clock names as per function for reference
clocks
mfd: omap-usb-host: Update DT clock binding information
mfd: omap-usb-tll: Update DT clock binding information
ARM: dts: omap4: Update omap-usb-host node
ARM: dts: omap5: Update omap-usb-host node
ARM: dts: omap4-panda: Provide USB PHY clock
ARM: dts: omap5-uevm: Provide USB PHY clock
ARM: OMAP2+: Remove legacy_init_ehci_clk()
.../devicetree/bindings/mfd/omap-usb-host.txt | 23 +++
.../devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++
arch/arm/boot/dts/omap4-panda-common.dtsi | 8 +-
arch/arm/boot/dts/omap4.dtsi | 6 +
arch/arm/boot/dts/omap5-uevm.dts | 8 +-
arch/arm/boot/dts/omap5.dtsi | 6 +
arch/arm/mach-omap2/pdata-quirks.c | 16 --
drivers/mfd/omap-usb-host.c | 171 ++++++++++-----------
8 files changed, 128 insertions(+), 120 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH v3 1/2] i2c: qup: Add device tree bindings information
From: Rob Herring @ 2014-01-20 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389999819-10648-2-git-send-email-bjorn.andersson@sonymobile.com>
On Fri, Jan 17, 2014 at 5:03 PM, Bjorn Andersson
<bjorn.andersson@sonymobile.com> wrote:
> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
>
> The Qualcomm Universal Peripherial (QUP) wraps I2C mini-core and
> provide input and output FIFO's for it. I2C controller can operate
> as master with supported bus speeds of 100Kbps and 400Kbps.
>
> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> [bjorn: reformulated part of binding description and cleaned up example]
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> ---
Patch history?
> .../devicetree/bindings/i2c/qcom,i2c-qup.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
> new file mode 100644
> index 0000000..a99711b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
> @@ -0,0 +1,41 @@
> +Qualcomm Universal Peripheral (QUP) I2C controller
> +
> +Required properties:
> + - compatible: Should be "qcom,i2c-qup".
Seems a bit generic. All versions of the IP are exactly the same?
"qcom,<chip>-i2c-qup" would be better.
> + - reg: Should contain QUP register address and length.
> + - interrupts: Should contain I2C interrupt.
> +
> + - clocks: Should contain the core clock and the AHB clock.
> + - clock-names: Should be "core" for the core clock and "iface" for the
> + AHB clock.
> +
> + - #address-cells: Should be <1> Address cells for i2c device address
> + - #size-cells: Should be <0> as i2c addresses have no size component
> +
> +Optional properties:
> + - clock-frequency: Should specify the desired i2c bus clock frequency in Hz,
> + default is 100kHz if omitted.
> +
> +Child nodes should conform to i2c bus binding.
> +
> +Example:
> +
> + i2c2: i2c at f9924000 {
> + compatible = "qcom,i2c-qup";
> + reg = <0xf9924000 0x1000>;
> + interrupts = <0 96 0>;
> +
> + clocks = <&gcc_blsp1_qup2_i2c_apps_clk>, <&gcc_blsp1_ahb_clk>;
> + clock-names = "core", "iface";
> +
> + clock-frequency = <355000>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dummy at 60 {
> + compatible = "dummy";
> + reg = <0x60>;
> + };
> + };
> +
> --
> 1.8.2.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Lothar Waßmann @ 2014-01-20 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120123849.GC15937@n2100.arm.linux.org.uk>
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
Lothar
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH 1/3] ACPI / idle: Move idle_boot_override out of the arch directory
From: Hanjun Guo @ 2014-01-20 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5375666.26CZK1LlZA@vostro.rjw.lan>
On 2014?01?18? 21:47, Rafael J. Wysocki wrote:
> On Saturday, January 18, 2014 11:52:18 AM Hanjun Guo wrote:
>> On 2014-1-18 11:45, Hanjun Guo wrote:
>>> On 2014-1-17 20:06, Sudeep Holla wrote:
>>>> On 17/01/14 02:03, Hanjun Guo wrote:
>>>>> Move idle_boot_override out of the arch directory to be a single enum
>>>>> including both platforms values, this will make it rather easier to
>>>>> avoid ifdefs around which definitions are for which processor in
>>>>> generally used ACPI code.
>>>>>
>>>>> IDLE_FORCE_MWAIT for IA64 is not used anywhere, so romove it.
>>>>>
>>>>> No functional change in this patch.
>>>>>
>>>>> Suggested-by: Alan <gnomes@lxorguk.ukuu.org.uk>
>>>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>>>> ---
>> [...]
>>>>> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
>>>>> index 03e235ad..e324561 100644
>>>>> --- a/include/linux/cpu.h
>>>>> +++ b/include/linux/cpu.h
>>>>> @@ -220,6 +220,14 @@ void cpu_idle(void);
>>>>>
>>>>> void cpu_idle_poll_ctrl(bool enable);
>>>>>
>>>>> +enum idle_boot_override {
>>>>> + IDLE_NO_OVERRIDE = 0,
>>>>> + IDLE_HALT,
>>>>> + IDLE_NOMWAIT,
>>>>> + IDLE_POLL,
>>>>> + IDLE_POWERSAVE_OFF
>>>>> +};
>>>>> +
>>>> I do understand the idea behind this change, but IMO HALT and MWAIT are x86
>>>> specific and may not make sense for other architectures.
>>> yes, this is the strange part, the value is arch-dependent.
>>>
>>>> It will also require every architecture using ACPI to export
>>>> boot_option_idle_override which may not be really required.
>>> so, how about forget this patch and move boot_option_idle_override
>>> related code into arch directory such as arch/x86/acpi/boot.c for
>>> x86?
>> The general idea is that we can move all the arch-dependent codes
>> in ACPI driver to arch directory, then make codes in drivers/acpi/
>> arch independent.
> Well, MWAIT is arch-dependent, so I'm not sure how IDLE_NOMWAIT fits into
> include/linux/cpu.h?
So you will not happy with this patch and should find another solution?
Thanks
Hanjun
^ permalink raw reply
* [PATCH 10/20] ARM64 / ACPI: Enumerate possible/present CPU set and map logical cpu id to APIC id
From: Hanjun Guo @ 2014-01-20 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D96A61.9080505@arm.com>
On 2014?01?18? 01:37, Sudeep Holla wrote:
> On 17/01/14 12:25, Hanjun Guo wrote:
>> When boot the kernel with MADT, the cpu possible and present sets should
>> be enumerated for later smp initialization.
>>
>> The logic cpu id maps to APIC id (GIC id) is also implemented, it is
>> needed for acpi processor drivers.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/arm64/include/asm/acpi.h | 7 ++--
>> drivers/acpi/plat/arm-core.c | 83 +++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 87 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index c335c6d..7edd39e 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -76,9 +76,6 @@ static inline void acpi_disable_pci(void)
>> /* FIXME: this function should be moved to topology.h when it's ready */
>> void arch_fix_phys_package_id(int num, u32 slot);
>>
>> -/* temperally define -1 to make acpi core compilerable */
>> -#define cpu_physical_id(cpu) -1
>> -
>> /* Low-level suspend routine. */
>> extern int (*acpi_suspend_lowlevel)(void);
>> #define acpi_wakeup_address (0)
>> @@ -86,6 +83,10 @@ extern int (*acpi_suspend_lowlevel)(void);
>> #define MAX_GIC_CPU_INTERFACE 256
>> #define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
>>
>> +/* map logic cpu id to physical GIC id */
>> +extern int arm_cpu_to_apicid[NR_CPUS];
>> +#define cpu_physical_id(cpu) arm_cpu_to_apicid[cpu]
>> +
> You refer arm_cpu_to_apicid as a mapping from logical cpu id to GIC id,
> then why is it assigned to cpu_physical_id. cpu_physical_id must be same as
> cpu_logical_map which is from logical cpu id to MPIDRs.
>
> [...]
>
>> @@ -321,6 +401,9 @@ int __init early_acpi_boot_init(void)
>> if (acpi_disabled)
>> return -ENODEV;
>>
>> + /* Get the boot CPU's GIC cpu interface id before MADT parsing */
>> + boot_cpu_apic_id = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> +
> Code contradicts your comment. You need GIC cpu interface ID(referred as GIC ID
> in the MADT), but you are assigning the MPIDR(physical CPU ID on ARM) to
> boot_cpu_apic_id. I think you are assuming GIC ID and MPIDR to be same which is
> wrong.
>
> With ACPI5.0, IIUC the only possible way to manage mapping from GIC CPU
> interface to MPIDR is to assume(in a way enforce on ARM) ACPI Processor UID in
> MADT and CPU Device definition match MPIDR.
yes, agree with you. I mixed up the GIC Id and UID, as you said, UID can be
MPIDR, and then use as hardware id to map to the logical id, it is not the
same as x86 and ia64, will update this patch.
Thanks
Hanjun
^ permalink raw reply
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
From: Vivek Gautam @ 2014-01-20 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFp+6iGYapTX0tfTLaoiF02n+hNdXN2OEphOCkb3dAYvqA4N5g@mail.gmail.com>
Hi Kishon,
[...]
>>>>>>>>>>>> Right.
>>>>>>>>>>>>
>>>>>>>>>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0
>>>>>>>>>>>> block(UTMI+)
>>>>>>>>>>>> can be used for High speed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It should then come under *single IP muliple PHY* category similar
>>>>>>>>>>> to what
>>>>>>>>>>> Sylwester has done.
[...]
>>
>> The idea is to model the driver as close to the hardware though I understand
>> there won't be any advantages w.r.t power or performance. maybe in later
>> versions of the IP we'll have separate bits to control usb3 and usb2.
>
> Ok, i will prepare the next patchset for separating out the possible
> code based on
> the UTMI+ or PIPE3 phys. Though when experimenting with the PHY
> settings i can see
> there's little of such code :-)
>
>>
>> I think for power control we should have both usb3 and usb2 power-on callback
>> calling a single function that controls the power bit.
> Right. I will do that.
Have posted the next version of patch with functionality to support
multiple PHYs as suggested.
Please review the same.
Thanks !!
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply
* [RFC PATCH 2/3] arm64: KVM: trap VM system registers until MMU and caches are ON
From: Marc Zyngier @ 2014-01-20 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAhSdy1iwc2ZBoPO9KXJzzaEQz-SWpYXkkRvjyRjQPdPe31chQ@mail.gmail.com>
Hi Anup,
On 20/01/14 12:00, Anup Patel wrote:
> On Fri, Jan 17, 2014 at 8:33 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> In order to be able to detect the point where the guest enables
>> its MMU and caches, trap all the VM related system registers.
>>
>> Once we see the guest enabling both the MMU and the caches, we
>> can go back to a saner mode of operation, which is to leave these
>> registers in complete control of the guest.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>> arch/arm64/include/asm/kvm_arm.h | 3 ++-
>> arch/arm64/kvm/sys_regs.c | 58 ++++++++++++++++++++++++++++++++--------
>> 2 files changed, 49 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
>> index c98ef47..fd0a651 100644
>> --- a/arch/arm64/include/asm/kvm_arm.h
>> +++ b/arch/arm64/include/asm/kvm_arm.h
>> @@ -62,6 +62,7 @@
>> * RW: 64bit by default, can be overriden for 32bit VMs
>> * TAC: Trap ACTLR
>> * TSC: Trap SMC
>> + * TVM: Trap VM ops (until M+C set in SCTLR_EL1)
>> * TSW: Trap cache operations by set/way
>> * TWE: Trap WFE
>> * TWI: Trap WFI
>> @@ -74,7 +75,7 @@
>> * SWIO: Turn set/way invalidates into set/way clean+invalidate
>> */
>> #define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWE | HCR_TWI | HCR_VM | \
>> - HCR_BSU_IS | HCR_FB | HCR_TAC | \
>> + HCR_TVM | HCR_BSU_IS | HCR_FB | HCR_TAC | \
>> HCR_AMO | HCR_IMO | HCR_FMO | \
>> HCR_SWIO | HCR_TIDCP | HCR_RW)
>> #define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 02e9d09..5e92b9e 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -121,6 +121,42 @@ done:
>> }
>>
>> /*
>> + * Generic accessor for VM registers. Only called as long as HCR_TVM
>> + * is set.
>> + */
>> +static bool access_vm_reg(struct kvm_vcpu *vcpu,
>> + const struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + BUG_ON(!p->is_write);
>> +
>> + vcpu_sys_reg(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt);
>> + return true;
>> +}
>> +
>> +/*
>> + * SCTLR_EL1 accessor. Only called as long as HCR_TVM is set. If the
>> + * guest enables the MMU, we stop trapping the VM sys_regs and leave
>> + * it in complete control of the caches.
>> + */
>> +static bool access_sctlr_el1(struct kvm_vcpu *vcpu,
>> + const struct sys_reg_params *p,
>> + const struct sys_reg_desc *r)
>> +{
>> + unsigned long val;
>> +
>> + BUG_ON(!p->is_write);
>> +
>> + val = *vcpu_reg(vcpu, p->Rt);
>> + vcpu_sys_reg(vcpu, r->reg) = val;
>> +
>> + if ((val & (0b101)) == 0b101) /* MMU+Caches enabled? */
>> + vcpu->arch.hcr_el2 &= ~HCR_TVM;
>> +
>> + return true;
>> +}
>> +
>> +/*
>> * We could trap ID_DFR0 and tell the guest we don't support performance
>> * monitoring. Unfortunately the patch to make the kernel check ID_DFR0 was
>> * NAKed, so it will read the PMCR anyway.
>> @@ -185,32 +221,32 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>> NULL, reset_mpidr, MPIDR_EL1 },
>> /* SCTLR_EL1 */
>> { Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b000),
>> - NULL, reset_val, SCTLR_EL1, 0x00C50078 },
>> + access_sctlr_el1, reset_val, SCTLR_EL1, 0x00C50078 },
>
> This patch in its current form breaks Aarch32 VMs on Foundation v8 Model
> because encoding for Aarch64 VM registers we get Op0=0b11 and for Aarch32
> VM registers we get Op0=0b00 when trapped.
>
> Either its a Foundation v8 Model bug or we need to add more enteries in
> sys_reg_desc[] for Aarch32 VM registers with Op0=0b00.
That's a good point. But Op0 isn't defined for AArch32, the value is
simply hardcoded in kvm_handle_cp15_32/kvm_handle_cp15_64, which is
obviously horribly broken.
I'll work on a fix for that, thanks noticing it.
Does this series otherwise fix your L3 cache issue (assuming you stick
to 64bit guests)?
Cheers,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Srikanth Thokala @ 2014-01-20 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401201239.47665.arnd@arndb.de>
Hi Arnd,
Sorry for the duplication. Ccing others.
On Mon, Jan 20, 2014 at 5:09 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 20 January 2014, Srikanth Thokala wrote:
>> On Fri, Jan 17, 2014 at 9:43 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Thursday 16 January 2014, Srikanth Thokala wrote:
>> > I also assume that some of the properties should just go away:
>> >
>> > * xlnx,device-id should be the argument in the handle from the slave device
>>
>> We can have multiple instances of this VDMA IP configured in the FPGA and we
>> need a unique identifier for each VDMA device that is present in the FPGA.
>> This device-id dt parameter forms the filter mask for the slave devices. As an
>> example, this can be used to get a channel of specific VDMA device (assuming
>> multiple instances) using the API dma_request_channel(). Please note this
>> is an example of a slave device that doesnt have dt node.
>
> That is not a valid scenario: You should not try to support legacy
> slave devices (without DT) connected to a dma-engine that is initialized
> using DT. If you still in the progress of converting drivers to DT, you
> can use auxdata to attach additional information that can be used for
> those slave devices, but the code should be kept out of the mainline
> kernel, and I don't want to see it manifest in the bindings.
I see your point. Thank you for the clarification. I will fix this in my v2.
>
>> > * data width should be a property of the slave driver that is configured
>> > through dma_slave_config(), unless you can have dma engines that only
>> > support certain a width.
>>
>> Yes, this VDMA engine soft IP support only certain widths, which is
>> configurable during IP synthesis.
>
> But what is this property used for in that case? Surely you can't
> connect a slave device to a dmaengine if the bus width doesn't match.
> You probably have a point here, but I don't understand it yet.
There is a Data-Realignment Engine (DRE) in the IP which is only available for
data width setting of 64-bits and less. So, we use the data-width DT parameter
to verify this condition and we update alignment shift accordingly.
Srikanth
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] dma: fix vchan_cookie_complete() debug print
From: Russell King - ARM Linux @ 2014-01-20 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120120301.GE26823@intel.com>
On Mon, Jan 20, 2014 at 05:33:01PM +0530, Vinod Koul wrote:
> On Mon, Jan 20, 2014 at 11:28:22AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Jan 20, 2014 at 03:29:17PM +0530, Vinod Koul wrote:
> > > On Fri, Dec 06, 2013 at 04:42:09PM +0100, Jonas Jensen wrote:
> > > > vd->tx.cookie is set zero on dma_cookie_complete(),
> > > > save to local before printing it.
> > > >
> > > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
> > > > ---
> > > >
> > > > Notes:
> > > > dev_vdbg() could also be moved to happen earlier, what do you prefer?
> > > This would be preferred IMHO. Also pls cc dmaengine at vger on this
> >
> > I prefer this version - it means that the verbose debug printk doesn't
> > impact the completion timing when printk is expensive (eg, because its
> > outputting via a serial port.)
> But if you know your printk is costly, do you want to enable these?
dev_vdbg() is for verbose debugging - you only enable it if you really
need to. Even so, it should have _minimal_ impact where possible. That's
why I prefer the first patch, because we mark the cookie as being
complete _before_ we call the verbose debugging, which isn't going to add
milliseconds to that.
If you don't care about debugging, then getting rid of the dev_vdbg().
But really, I could pull rank and say that this is *my* file, I get to
choose how stuff should be done here - I'd prefer not to but...
--
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] ARM: shmobile: compile drivers/sh for CONFIG_ARCH_SHMOBILE_MULTI
From: Ben Dooks @ 2014-01-20 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120125436.GN17314@sirena.org.uk>
I've added linux-arm-kernel to the list to get a wider view from
people who actively use the clock subsystem.
On 20/01/14 12:54, Mark Brown wrote:
> On Mon, Jan 20, 2014 at 12:01:00PM +0000, Ben Dooks wrote:
>> On 20/01/14 11:47, Mark Brown wrote:
>
>>> I think that just makes things more complicated and isn't adding
>>> anything over pm_runtime_enable(), it's just boilerplate code. In
>>> theory essentially every driver running on platforms which don't have
>>> explicit management of core IP clocks ought to be calling this since
>>> potentially the IP might be deployed on another platform which does have
>>> clock management (this does actually happen with things like the
>>> DesignWare IPs) and it doesn't do anything like say which clocks are
>>> expected to be managed in this way which is another thing that can come
>>> up when moving devices between platforms.
>
>> That sounds like a real headache where you have two sets of code
>> looking at possibly the same clocks, and behaving differently between
>> different platforms.
>
> Yup, it's usually only one set of code on the client side but it's
> annoying that platform integrations aren't done consistently in hardware
> and that this flows through into software.
>
>>> I'm also struggling to see how it provides any sort of build time
>>> protection, it would allow the generation of a warning at runtime at
>>> best.
>
>> If you don't have the code it WILL NOT LINK. At the moment it is
>> entirely possible to link a kernel which will produce a set of confusing
>> errors as drivers fail to initialise at startup.
>
> How will this prevent the code linking? I would expect the "manage the
> clocks via runtime PM" call to be a bit of core code, I wouldn't expect
> it to be provided by a specific platform otherwise we're in for fail in
> a multiplatform environment. Besides, if it fails to link there's some
> missing Kconfig anyway since randconfig is supposed to work.
>
>> We've already had other people run into the issue where they do not
>> know why a driver is failing to work (rcar-thermal is one) as the code
>> that was managing the clock for it magically vanished during the
>> development cycle.
>
> I agree there's a usability problem here, I just don't think that this
> is the best fix for it, I think it's breaking abstractions.
>
>>> As far as I can tell the problem that Ben has seen here is that the
>>> platform really, really needs the code for its power domains running to
>>> be functional (this doesn't seem unreasonable and may not be related to
>>> clocks, this may be required to have the IPs powered up at all). I'd
>>> expect this is something for the platform to sort out rather than
>>> something for individual drivers to have to carry code for.
>
>> What's power domains got to do with this? You keep bringing this up
>> but the error is purely to do with clock management. The code happens
>> to be sitting in the drivers/base/pm directory, but could easily sit
>> elsewhere.
>
> What these platforms are saying is esssentially that the clocks are part
> of the power domain - they're a fundamental part of getting the IP
> available for use so there is no point in managing them separately.
> This is where I think the abstraction problem is coming, to me it seems
> like the platform isn't successfully ensuring that the code to manage
> the power domain is there. The fact that part of what's missing is the
> clocks shouldn't matter to the drivers, in doing things like this the
> platform is trying to abstract that detail away from the drivers.
>
>>> If it was going to be drivers carrying code for this I would expect it
>>> to be something like providing a list of clocks to be managed along with
>>> runtime PM - this would also make the code more widely applicable since
>>> it's quite common for the runtime PM callbacks to do nothing more than
>>> just enable and disable clocks.
>
>> If we are really saying that bus clocks should not be managed
>> by the drivers, then we should just enable this across the whole
>> kernel and remove the management from any extant drivers (or make
>> it so that any drivers that must manage their bus clocks have a
>> call to do so).
>
> Yes, I think that would be a useful way to go since it would factor out
> some common code patterns that keep cropping up (as I suggested to you
> previously). It may not just be the main IP clocks that the drivers are
> managing like this (some drivers end up managing other clocks at the
> same time even if they could be more flexible) so if it was something
> drivers could make use of themselves that'd be good.
At the moment, the code to actually use the support is sitting in
drivers/sh and gets initialised if it is built. This is the source
of the original confusions.
I think it would be ok if drivers could /opt out/ if the bus clock
handling was done like this for all platforms and we simply noted
that the pm code is doing it. At that point it would be nice just
to build the code in drivers/base/power unconditionally.
At the moment we could quite easily enable this code for all the
ARM platforms as the clk framework should deal nicely with properly
balanced clk_enable() and clk_disable() calls.
Enabling it across the board would also remove any issues with
changes in platform behaviour and find any bugs sooner rather than
later.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Sascha Hauer @ 2014-01-20 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120115919.GD26823@intel.com>
On Mon, Jan 20, 2014 at 05:29:20PM +0530, Vinod Koul wrote:
> On Mon, Jan 20, 2014 at 12:38:50PM +0000, 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".
> In that case why don't we use async version and wait till the userspace is
> availble and firmware is loaded.
>
> So request_firmware_nowait() seems to do the job, I have used in a device where
> I call it in probe() so that not to slow booting and make firmware bloc availble
> userpsace is availble.
>
> Sounds too good, did I miss anything obvious for this case here?
Been there, done that. This would make the RAM Firmware mandatory.
The Linux firmware loading mechanism is not very suitable for the SDMA
engine. The firmware loading mechanism expects that a driver cannot work
without a firmware. Normally this is true, but The SDMA engine can run
with the ROM firmware or a RAM firmware loaded during runtime. In fact
the firmware consists of Program code, so the SDMA engine could even run
with a combination of the ROM firmware and 0..n dynamically loaded
firmware modules.
Maybe using the firmware loading mechanism for the SDMA engine was the
wrong approach from the start.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Russell King - ARM Linux @ 2014-01-20 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120123627.1147f252@ipc1.ka-ro>
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".
--
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
* [RFC v3 05/13] ahci-platform: Pass ahci_host_priv ptr to ahci_platform_data init method
From: Tejun Heo @ 2014-01-20 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DC2DD9.7070403@redhat.com>
On Sun, Jan 19, 2014 at 08:56:09PM +0100, Hans de Goede wrote:
> Ok, asking the obvious here I guess, but you would accept a patch moving drivers/ata/ahci.h
> to include/linux as part of this patch-set ?
Wouldn't creating a minimal file which only contains the necessary
bits make more sense?
Thanks.
--
tejun
^ permalink raw reply
* [PATCH 04/20] ARM64 / ACPI: Introduce arm_core.c and its related head file
From: Hanjun Guo @ 2014-01-20 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D960D1.3090700@arm.com>
On 2014-1-18 0:56, Sudeep Holla wrote:
> On 17/01/14 12:24, Hanjun Guo wrote:
>> Introduce arm_core.c and its related head file, after this patch,
>> we can get ACPI tables from firmware on ARM64 now.
>>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/arm64/include/asm/acpi.h | 57 +++++++++++
>> arch/arm64/kernel/setup.c | 6 ++
>> drivers/acpi/Makefile | 2 +
>> drivers/acpi/plat/Makefile | 1 +
>> drivers/acpi/plat/arm-core.c | 209 +++++++++++++++++++++++++++++++++++++++++
>> 5 files changed, 275 insertions(+)
>> create mode 100644 drivers/acpi/plat/Makefile
>> create mode 100644 drivers/acpi/plat/arm-core.c
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index cf19dc6..908d71b 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -19,6 +19,43 @@
>> #ifndef _ASM_ARM64_ACPI_H
>> #define _ASM_ARM64_ACPI_H
>>
>> +#include <asm/cacheflush.h>
>> +
>> +#include <linux/init.h>
>> +
>> +#define COMPILER_DEPENDENT_INT64 s64
>> +#define COMPILER_DEPENDENT_UINT64 u64
>> +
>> +/*
>> + * Calling conventions:
>> + *
>> + * ACPI_SYSTEM_XFACE - Interfaces to host OS (handlers, threads)
>> + * ACPI_EXTERNAL_XFACE - External ACPI interfaces
>> + * ACPI_INTERNAL_XFACE - Internal ACPI interfaces
>> + * ACPI_INTERNAL_VAR_XFACE - Internal variable-parameter list interfaces
>> + */
>> +#define ACPI_SYSTEM_XFACE
>> +#define ACPI_EXTERNAL_XFACE
>> +#define ACPI_INTERNAL_XFACE
>> +#define ACPI_INTERNAL_VAR_XFACE
>> +
>> +/* Asm macros */
>> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
>> +
>> +/* Basic configuration for ACPI */
>> +#ifdef CONFIG_ACPI
>> +extern int acpi_disabled;
>> +extern int acpi_noirq;
>> +extern int acpi_pci_disabled;
>> +extern int acpi_strict;
>> +
>> +static inline void disable_acpi(void)
>> +{
>> + acpi_disabled = 1;
>> + acpi_pci_disabled = 1;
>> + acpi_noirq = 1;
>> +}
>> +
>> static inline bool arch_has_acpi_pdc(void)
>> {
>> return false; /* always false for now */
>> @@ -29,4 +66,24 @@ static inline void arch_acpi_set_pdc_bits(u32 *buf)
>> return;
>> }
>>
>> +static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
>> +static inline void acpi_disable_pci(void)
>> +{
>> + acpi_pci_disabled = 1;
>> + acpi_noirq_set();
>> +}
>> +
>> +/* FIXME: this function should be moved to topology.h when it's ready */
>> +void arch_fix_phys_package_id(int num, u32 slot);
>> +
>> +/* temperally define -1 to make acpi core compilerable */
>> +#define cpu_physical_id(cpu) -1
>> +
>
> I assume `cpu` here is logical cpu id in which case you can define it to be same
> as cpu_logical_map ?
Yes. it is about the hardware id of CPU and may refer to MPIDR in ARM/ARM64.
Thanks
Hanjun
^ permalink raw reply
* [RFC v3 03/13] ahci-platform: Fix clk enable/disable unbalance on suspend/resume
From: Tejun Heo @ 2014-01-20 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DC2CF5.5080109@redhat.com>
Hey,
On Sun, Jan 19, 2014 at 08:52:21PM +0100, Hans de Goede wrote:
> And having ahci_resume in ahci_platform.c still doing the clk and power enabling
> before calling into ahci_platform_resume, and drivers overriding the resume method
> need to do their own clk + regulator + whatever setup
> before calling into ahci_platform_resume_controller ?
If the use cases are significant enough, split the base function to
two parts? The thing which gets really messy down the road is when
common code and callbacks intertwine arbitrarily. A driver wants an
early exit after overriding a subpart, so if that callback exists,
it's an early exit. The next driver wants to override something at
slightly different point but still want to proceed with the rest of
the common code, so it adds a new callback which doesn't do early
exit, and so on. Pretty soon, when you're looking at a driver, it
becomes really difficult what it actually does. We *HAD* this problem
over and over again with ide and it was a nightmare.
Providing larger, logical overriding points while providing common lib
routines makes understanding what a given driver does a lot easier.
Also, it forces people to think about how the overall API looks and
whether a split of an existing library which require giving the splits
sensible names and semantics is justifiable or if the case at hand is
an one-off thing which can be better served by just open coding it.
> Will get exported from ahci_platform.c and drivers needing to override any of them
> will provide their own platform_driver struct, pointing either to their overrides,
> or for driver methods they don't need to override to the exported function from
> ahci_platform.c ?
Yeah, makes sense to me.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH v6] ARM: DTS: imx5* imx6*, use imx51-ssi
From: Markus Pargmann @ 2014-01-20 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140118083840.GD3430@S2101-09.ap.freescale.net>
imx51-ssi and imx21-ssi are different IPs. imx51-ssi supports online
reconfiguration and needs this for correct interaction with SDMA. This
patch adds imx51-ssi before each imx21-ssi for all imx5/imx6 SoCs.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
---
Hi Shawn,
Sorry for that last patch. I fixed it in this patch.
Thanks,
Markus
arch/arm/boot/dts/imx50.dtsi | 7 +++++--
arch/arm/boot/dts/imx53.dtsi | 10 +++++++---
arch/arm/boot/dts/imx6qdl.dtsi | 12 +++++++++---
arch/arm/boot/dts/imx6sl.dtsi | 12 +++++++++---
4 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index 01c0499..24df4f4f 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -140,7 +140,9 @@
};
ssi2: ssi at 50014000 {
- compatible = "fsl,imx50-ssi", "fsl,imx21-ssi";
+ compatible = "fsl,imx50-ssi",
+ "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x50014000 0x4000>;
interrupts = <30>;
clocks = <&clks IMX5_CLK_SSI2_IPG_GATE>;
@@ -445,7 +447,8 @@
};
ssi1: ssi at 63fcc000 {
- compatible = "fsl,imx50-ssi", "fsl,imx21-ssi";
+ compatible = "fsl,imx50-ssi", "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x63fcc000 0x4000>;
interrupts = <29>;
clocks = <&clks IMX5_CLK_SSI1_IPG_GATE>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 4dbde25..73e103b 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -171,7 +171,9 @@
};
ssi2: ssi at 50014000 {
- compatible = "fsl,imx53-ssi", "fsl,imx21-ssi";
+ compatible = "fsl,imx53-ssi",
+ "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x50014000 0x4000>;
interrupts = <30>;
clocks = <&clks IMX5_CLK_SSI2_IPG_GATE>;
@@ -590,7 +592,8 @@
};
ssi1: ssi at 63fcc000 {
- compatible = "fsl,imx53-ssi", "fsl,imx21-ssi";
+ compatible = "fsl,imx53-ssi", "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x63fcc000 0x4000>;
interrupts = <29>;
clocks = <&clks IMX5_CLK_SSI1_IPG_GATE>;
@@ -617,7 +620,8 @@
};
ssi3: ssi at 63fe8000 {
- compatible = "fsl,imx53-ssi", "fsl,imx21-ssi";
+ compatible = "fsl,imx53-ssi", "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x63fe8000 0x4000>;
interrupts = <96>;
clocks = <&clks IMX5_CLK_SSI3_IPG_GATE>;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 8a86502..cf7956e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -247,7 +247,9 @@
};
ssi1: ssi at 02028000 {
- compatible = "fsl,imx6q-ssi","fsl,imx21-ssi";
+ compatible = "fsl,imx6q-ssi",
+ "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x02028000 0x4000>;
interrupts = <0 46 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks 178>;
@@ -260,7 +262,9 @@
};
ssi2: ssi at 0202c000 {
- compatible = "fsl,imx6q-ssi","fsl,imx21-ssi";
+ compatible = "fsl,imx6q-ssi",
+ "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x0202c000 0x4000>;
interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks 179>;
@@ -273,7 +277,9 @@
};
ssi3: ssi at 02030000 {
- compatible = "fsl,imx6q-ssi","fsl,imx21-ssi";
+ compatible = "fsl,imx6q-ssi",
+ "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x02030000 0x4000>;
interrupts = <0 48 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks 180>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index a449c4f..95bb37b 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -226,7 +226,9 @@
};
ssi1: ssi at 02028000 {
- compatible = "fsl,imx6sl-ssi","fsl,imx21-ssi";
+ compatible = "fsl,imx6sl-ssi",
+ "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x02028000 0x4000>;
interrupts = <0 46 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_SSI1>;
@@ -238,7 +240,9 @@
};
ssi2: ssi at 0202c000 {
- compatible = "fsl,imx6sl-ssi","fsl,imx21-ssi";
+ compatible = "fsl,imx6sl-ssi",
+ "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x0202c000 0x4000>;
interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_SSI2>;
@@ -250,7 +254,9 @@
};
ssi3: ssi at 02030000 {
- compatible = "fsl,imx6sl-ssi","fsl,imx21-ssi";
+ compatible = "fsl,imx6sl-ssi",
+ "fsl,imx51-ssi",
+ "fsl,imx21-ssi";
reg = <0x02030000 0x4000>;
interrupts = <0 48 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_SSI3>;
--
1.8.5.2
^ permalink raw reply related
* [PATCH 2/2] clk: exynos4: Fix spacing related checkpatch errors
From: Tomasz Figa @ 2014-01-20 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389780070-4959-2-git-send-email-sachin.kamat@linaro.org>
Hi Sachin,
On 15.01.2014 11:01, Sachin Kamat wrote:
> Silences the following type of checkpatch errors:
> ERROR: space prohibited after that open parenthesis '('
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/clk/samsung/clk-exynos4.c | 50 ++++++++++++++++++-------------------
> 1 file changed, 25 insertions(+), 25 deletions(-)
I believe this is a false warning. In this special case the spaces
greatly improve readability of static data in the driver, which I
believe is preferred over the strict rules of checkpatch.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH] dma: fix vchan_cookie_complete() debug print
From: Vinod Koul @ 2014-01-20 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120112822.GA15937@n2100.arm.linux.org.uk>
On Mon, Jan 20, 2014 at 11:28:22AM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 20, 2014 at 03:29:17PM +0530, Vinod Koul wrote:
> > On Fri, Dec 06, 2013 at 04:42:09PM +0100, Jonas Jensen wrote:
> > > vd->tx.cookie is set zero on dma_cookie_complete(),
> > > save to local before printing it.
> > >
> > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
> > > ---
> > >
> > > Notes:
> > > dev_vdbg() could also be moved to happen earlier, what do you prefer?
> > This would be preferred IMHO. Also pls cc dmaengine at vger on this
>
> I prefer this version - it means that the verbose debug printk doesn't
> impact the completion timing when printk is expensive (eg, because its
> outputting via a serial port.)
But if you know your printk is costly, do you want to enable these?
--
~Vinod
^ permalink raw reply
* [RFC PATCH 2/3] arm64: KVM: trap VM system registers until MMU and caches are ON
From: Anup Patel @ 2014-01-20 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389970993-19371-3-git-send-email-marc.zyngier@arm.com>
On Fri, Jan 17, 2014 at 8:33 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> In order to be able to detect the point where the guest enables
> its MMU and caches, trap all the VM related system registers.
>
> Once we see the guest enabling both the MMU and the caches, we
> can go back to a saner mode of operation, which is to leave these
> registers in complete control of the guest.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/include/asm/kvm_arm.h | 3 ++-
> arch/arm64/kvm/sys_regs.c | 58 ++++++++++++++++++++++++++++++++--------
> 2 files changed, 49 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index c98ef47..fd0a651 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -62,6 +62,7 @@
> * RW: 64bit by default, can be overriden for 32bit VMs
> * TAC: Trap ACTLR
> * TSC: Trap SMC
> + * TVM: Trap VM ops (until M+C set in SCTLR_EL1)
> * TSW: Trap cache operations by set/way
> * TWE: Trap WFE
> * TWI: Trap WFI
> @@ -74,7 +75,7 @@
> * SWIO: Turn set/way invalidates into set/way clean+invalidate
> */
> #define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWE | HCR_TWI | HCR_VM | \
> - HCR_BSU_IS | HCR_FB | HCR_TAC | \
> + HCR_TVM | HCR_BSU_IS | HCR_FB | HCR_TAC | \
> HCR_AMO | HCR_IMO | HCR_FMO | \
> HCR_SWIO | HCR_TIDCP | HCR_RW)
> #define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 02e9d09..5e92b9e 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -121,6 +121,42 @@ done:
> }
>
> /*
> + * Generic accessor for VM registers. Only called as long as HCR_TVM
> + * is set.
> + */
> +static bool access_vm_reg(struct kvm_vcpu *vcpu,
> + const struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + BUG_ON(!p->is_write);
> +
> + vcpu_sys_reg(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt);
> + return true;
> +}
> +
> +/*
> + * SCTLR_EL1 accessor. Only called as long as HCR_TVM is set. If the
> + * guest enables the MMU, we stop trapping the VM sys_regs and leave
> + * it in complete control of the caches.
> + */
> +static bool access_sctlr_el1(struct kvm_vcpu *vcpu,
> + const struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + unsigned long val;
> +
> + BUG_ON(!p->is_write);
> +
> + val = *vcpu_reg(vcpu, p->Rt);
> + vcpu_sys_reg(vcpu, r->reg) = val;
> +
> + if ((val & (0b101)) == 0b101) /* MMU+Caches enabled? */
> + vcpu->arch.hcr_el2 &= ~HCR_TVM;
> +
> + return true;
> +}
> +
> +/*
> * We could trap ID_DFR0 and tell the guest we don't support performance
> * monitoring. Unfortunately the patch to make the kernel check ID_DFR0 was
> * NAKed, so it will read the PMCR anyway.
> @@ -185,32 +221,32 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> NULL, reset_mpidr, MPIDR_EL1 },
> /* SCTLR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b000),
> - NULL, reset_val, SCTLR_EL1, 0x00C50078 },
> + access_sctlr_el1, reset_val, SCTLR_EL1, 0x00C50078 },
This patch in its current form breaks Aarch32 VMs on Foundation v8 Model
because encoding for Aarch64 VM registers we get Op0=0b11 and for Aarch32
VM registers we get Op0=0b00 when trapped.
Either its a Foundation v8 Model bug or we need to add more enteries in
sys_reg_desc[] for Aarch32 VM registers with Op0=0b00.
> /* CPACR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b010),
> NULL, reset_val, CPACR_EL1, 0 },
> /* TTBR0_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b000),
> - NULL, reset_unknown, TTBR0_EL1 },
> + access_vm_reg, reset_unknown, TTBR0_EL1 },
> /* TTBR1_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b001),
> - NULL, reset_unknown, TTBR1_EL1 },
> + access_vm_reg, reset_unknown, TTBR1_EL1 },
> /* TCR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b010),
> - NULL, reset_val, TCR_EL1, 0 },
> + access_vm_reg, reset_val, TCR_EL1, 0 },
>
> /* AFSR0_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0001), Op2(0b000),
> - NULL, reset_unknown, AFSR0_EL1 },
> + access_vm_reg, reset_unknown, AFSR0_EL1 },
> /* AFSR1_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0001), Op2(0b001),
> - NULL, reset_unknown, AFSR1_EL1 },
> + access_vm_reg, reset_unknown, AFSR1_EL1 },
> /* ESR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0010), Op2(0b000),
> - NULL, reset_unknown, ESR_EL1 },
> + access_vm_reg, reset_unknown, ESR_EL1 },
> /* FAR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b0110), CRm(0b0000), Op2(0b000),
> - NULL, reset_unknown, FAR_EL1 },
> + access_vm_reg, reset_unknown, FAR_EL1 },
> /* PAR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b0111), CRm(0b0100), Op2(0b000),
> NULL, reset_unknown, PAR_EL1 },
> @@ -224,17 +260,17 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>
> /* MAIR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
> - NULL, reset_unknown, MAIR_EL1 },
> + access_vm_reg, reset_unknown, MAIR_EL1 },
> /* AMAIR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0011), Op2(0b000),
> - NULL, reset_amair_el1, AMAIR_EL1 },
> + access_vm_reg, reset_amair_el1, AMAIR_EL1 },
>
> /* VBAR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b1100), CRm(0b0000), Op2(0b000),
> NULL, reset_val, VBAR_EL1, 0 },
> /* CONTEXTIDR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b1101), CRm(0b0000), Op2(0b001),
> - NULL, reset_val, CONTEXTIDR_EL1, 0 },
> + access_vm_reg, reset_val, CONTEXTIDR_EL1, 0 },
> /* TPIDR_EL1 */
> { Op0(0b11), Op1(0b000), CRn(0b1101), CRm(0b0000), Op2(0b100),
> NULL, reset_unknown, TPIDR_EL1 },
> --
> 1.8.3.4
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
Regards,
Anup
^ permalink raw reply
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Vinod Koul @ 2014-01-20 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120123849.GC15937@n2100.arm.linux.org.uk>
On Mon, Jan 20, 2014 at 12:38:50PM +0000, 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".
In that case why don't we use async version and wait till the userspace is
availble and firmware is loaded.
So request_firmware_nowait() seems to do the job, I have used in a device where
I call it in probe() so that not to slow booting and make firmware bloc availble
userpsace is availble.
Sounds too good, did I miss anything obvious for this case here?
--
~Vinod
^ permalink raw reply
* [PATCH 2/2] clk: ux500: Staticize ux500_twocell_get
From: Ulf Hansson @ 2014-01-20 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115073631.GD11820@lee--X1>
On 15 January 2014 08:36, Lee Jones <lee.jones@linaro.org> wrote:
>> ux500_twocell_get is a local symbol.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> ---
>> drivers/clk/ux500/u8500_of_clk.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Acked-by: Lee Jones <lee.jones@linaro.org>
>
Thanks! Pushed to my clk-next-ux500 branch.
Kind regards
Ulf Hansson
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
>
> _______________________________________________
> 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 v2] can: flexcan: fix flexcan driver build for big endian on ARM and little endian on PowerPc
From: Marc Kleine-Budde @ 2014-01-20 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD0A5E.6010303@pengutronix.de>
From: Arnd Bergmann <arnd@arndb.de>
There is no reason to disallow building the driver on big-endian ARM kernels.
Furthermore, the current behavior is actually broken on little-endian PowerPC
as well.
The choice of register accessor functions must purely depend on the CPU
architecture, not which endianess the CPU is running on. Note that we nowadays
allow both big-endian ARM and little-endian PowerPC kernels.
With this patch applied, we will do the right thing in all four combinations.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Lothar Wa?mann <LW@KARO-electronics.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Changes since v1:
* squash the revert of the original patch with the wrong fix
drivers/net/can/Kconfig | 2 +-
drivers/net/can/flexcan.c | 7 +++++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index d447b88..9e7d95d 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -104,7 +104,7 @@ config CAN_JANZ_ICAN3
config CAN_FLEXCAN
tristate "Support for Freescale FLEXCAN based chips"
- depends on (ARM && CPU_LITTLE_ENDIAN) || PPC
+ depends on ARM || PPC
---help---
Say Y here if you want to support for Freescale FlexCAN.
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index aaed97b..320bef2 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -235,9 +235,12 @@ static const struct can_bittiming_const flexcan_bittiming_const = {
};
/*
- * Abstract off the read/write for arm versus ppc.
+ * Abstract off the read/write for arm versus ppc. This
+ * assumes that PPC uses big-endian registers and everything
+ * else uses little-endian registers, independent of CPU
+ * endianess.
*/
-#if defined(__BIG_ENDIAN)
+#if defined(CONFIG_PPC)
static inline u32 flexcan_read(void __iomem *addr)
{
return in_be32(addr);
--
1.8.5.2
^ permalink raw reply related
* [PATCH] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Arnd Bergmann @ 2014-01-20 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+mB=1L0ZSC8f6eMEuO7MEk6nG5SDahE7AH2F_uUr1TgTCD=cw@mail.gmail.com>
On Monday 20 January 2014, Srikanth Thokala wrote:
> On Fri, Jan 17, 2014 at 9:43 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 16 January 2014, Srikanth Thokala wrote:
> > I also assume that some of the properties should just go away:
> >
> > * xlnx,device-id should be the argument in the handle from the slave device
>
> We can have multiple instances of this VDMA IP configured in the FPGA and we
> need a unique identifier for each VDMA device that is present in the FPGA.
> This device-id dt parameter forms the filter mask for the slave devices. As an
> example, this can be used to get a channel of specific VDMA device (assuming
> multiple instances) using the API dma_request_channel(). Please note this
> is an example of a slave device that doesnt have dt node.
That is not a valid scenario: You should not try to support legacy
slave devices (without DT) connected to a dma-engine that is initialized
using DT. If you still in the progress of converting drivers to DT, you
can use auxdata to attach additional information that can be used for
those slave devices, but the code should be kept out of the mainline
kernel, and I don't want to see it manifest in the bindings.
> > * data width should be a property of the slave driver that is configured
> > through dma_slave_config(), unless you can have dma engines that only
> > support certain a width.
>
> Yes, this VDMA engine soft IP support only certain widths, which is
> configurable during IP synthesis.
But what is this property used for in that case? Surely you can't
connect a slave device to a dmaengine if the bus width doesn't match.
You probably have a point here, but I don't understand it yet.
Arnd
^ 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