* [PATCH RESEND] ARM: EXYNOS: dts: Set up power domain for MFC and G-scaler
From: Prasanna Kumar @ 2013-01-29 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <05b901cdfde0$a373a860$ea5af920$@samsung.com>
This patch adds device tree nodes for MFC and G-scaler power
domains of exynos5250.It binds these power-domain nodes to repsective
device tree nodes
It also adds support to enable PM generic domains for exynos5250.
Signed-off-by: Prasanna Kumar <prasanna.ps@samsung.com>
---
arch/arm/boot/dts/exynos5250.dtsi | 15 +++++++++++++++
arch/arm/mach-exynos/Kconfig | 1 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 30485de..6d0e87c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -85,6 +85,7 @@
compatible = "samsung,mfc-v6";
reg = <0x11000000 0x10000>;
interrupts = <0 96 0>;
+ samsung,power-domain = <&pd_mfc>;
};
rtc {
@@ -554,28 +555,42 @@
};
};
+ pd_gsc: gsc-power-domain at 0x10044000 {
+ compatible = "samsung,exynos4210-pd";
+ reg = <0x10044000 0x20>;
+ };
+
+ pd_mfc: mfc-power-domain at 0x10044040 {
+ compatible = "samsung,exynos4210-pd";
+ reg = <0x10044040 0x20>;
+ };
+
gsc_0: gsc at 0x13e00000 {
compatible = "samsung,exynos5-gsc";
reg = <0x13e00000 0x1000>;
interrupts = <0 85 0>;
+ samsung,power-domain = <&pd_gsc>;
};
gsc_1: gsc at 0x13e10000 {
compatible = "samsung,exynos5-gsc";
reg = <0x13e10000 0x1000>;
interrupts = <0 86 0>;
+ samsung,power-domain = <&pd_gsc>;
};
gsc_2: gsc at 0x13e20000 {
compatible = "samsung,exynos5-gsc";
reg = <0x13e20000 0x1000>;
interrupts = <0 87 0>;
+ samsung,power-domain = <&pd_gsc>;
};
gsc_3: gsc at 0x13e30000 {
compatible = "samsung,exynos5-gsc";
reg = <0x13e30000 0x1000>;
interrupts = <0 88 0>;
+ samsung,power-domain = <&pd_gsc>;
};
hdmi {
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index e103c29..96f4a9f 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -61,6 +61,7 @@ config SOC_EXYNOS5250
bool "SAMSUNG EXYNOS5250"
default y
depends on ARCH_EXYNOS5
+ select PM_GENERIC_DOMAINS if PM
select S5P_PM if PM
select S5P_SLEEP if PM
select S5P_DEV_MFC
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] clk: tegra: adapt tegra periph clk to mux table/mask
From: Peter De Schrijver @ 2013-01-29 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5106AC31.1040207@wwwdotorg.org>
On Mon, Jan 28, 2013 at 05:49:53PM +0100, Stephen Warren wrote:
> On 01/28/2013 08:54 AM, Peter De Schrijver wrote:
> > The tegra peripheral clock type uses struct clk_mux directly, so it needs to
> > be updated to handle the new mask and table fields. Also the macros need
> > to be updated
>
> Just a quick note on patch dependencies here:
>
> Patch 1/2 can presumably be taken through the clk tree whenever Mike is
> OK with it.
>
> Patch 2/2 depends on patches in the Tegra tree for 3.9. Since patch 2/2
> is useful mostly for the Tegra114 clock driver, and I don't imagine that
> will get posted/merged in time for 3.9, it's probably easiest to just
> take patch 2/2 for 3.10 along with the Tegra114 clock driver. Also, I
> imagine there won't be any more clk/Tegra tree dependencies in 3.10, so
> patch 2/2 and the Tegra114 clk driver patches can likely go through the
> clk tree itself for 3.10.
No. Because 1/2 changes struct clk_mux and the tegra peripheral clock type
uses struct clk_mux directly, 2/2 needs to be applied together with 1/2, even
if the new functionality is not yet used.
Cheers,
Peter.
^ permalink raw reply
* [PATCH v3 10/30] USB: ehci-omap: Use PHY APIs to get the PHY device and put it out of suspend
From: Roger Quadros @ 2013-01-29 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-11-git-send-email-rogerq@ti.com>
For each port that is in PHY mode we obtain a PHY device using the USB PHY
library and put it out of suspend.
It is up to platform code to associate the PHY to the controller's
port and it is upto the PHY driver to manage the PHY's resources.
Also remove wired spacing around declarations we come across.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/usb/host/ehci-omap.c | 76 ++++++++++++++++++++++++++++++++++--------
1 files changed, 62 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index fd2f5450..ddc31fb 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -4,10 +4,11 @@
* Bus Glue for the EHCI controllers in OMAP3/4
* Tested on several OMAP3 boards, and OMAP4 Pandaboard
*
- * Copyright (C) 2007-2011 Texas Instruments, Inc.
+ * Copyright (C) 2007-2013 Texas Instruments, Inc.
* Author: Vikram Pandita <vikram.pandita@ti.com>
* Author: Anand Gadiyar <gadiyar@ti.com>
* Author: Keshava Munegowda <keshava_mgowda@ti.com>
+ * Author: Roger Quadros <rogerq@ti.com>
*
* Copyright (C) 2009 Nokia Corporation
* Contact: Felipe Balbi <felipe.balbi@nokia.com>
@@ -70,6 +71,10 @@ static const char hcd_name[] = "ehci-omap";
/*-------------------------------------------------------------------------*/
+struct omap_hcd {
+ struct usb_phy *phy[OMAP3_HS_USB_PORTS]; /* one PHY for each port */
+ int nports;
+};
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
{
@@ -178,7 +183,8 @@ static void disable_put_regulator(
static struct hc_driver __read_mostly ehci_omap_hc_driver;
static const struct ehci_driver_overrides ehci_omap_overrides __initdata = {
- .reset = omap_ehci_init,
+ .reset = omap_ehci_init,
+ .extra_priv_size = sizeof(struct omap_hcd),
};
/**
@@ -190,15 +196,16 @@ static const struct ehci_driver_overrides ehci_omap_overrides __initdata = {
*/
static int ehci_hcd_omap_probe(struct platform_device *pdev)
{
- struct device *dev = &pdev->dev;
- struct usbhs_omap_platform_data *pdata = dev->platform_data;
- struct resource *res;
- struct usb_hcd *hcd;
- void __iomem *regs;
- int ret = -ENODEV;
- int irq;
- int i;
- char supply[7];
+ struct device *dev = &pdev->dev;
+ struct usbhs_omap_platform_data *pdata = dev->platform_data;
+ struct resource *res;
+ struct usb_hcd *hcd;
+ void __iomem *regs;
+ int ret = -ENODEV;
+ int irq;
+ int i;
+ char supply[7];
+ struct omap_hcd *omap;
if (usb_disabled())
return -ENODEV;
@@ -233,6 +240,33 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
hcd->rsrc_len = resource_size(res);
hcd->regs = regs;
+ omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
+ omap->nports = pdata->nports;
+
+ platform_set_drvdata(pdev, hcd);
+
+ /* get the PHY devices if needed */
+ for (i = 0 ; i < omap->nports ; i++) {
+ struct usb_phy *phy;
+
+ if (pdata->port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
+ continue;
+
+ /* get the PHY device */
+ phy = devm_usb_get_phy_dev(dev, i);
+ if (IS_ERR(phy) || !phy) {
+ ret = IS_ERR(phy) ? PTR_ERR(phy) : -ENODEV;
+ dev_err(dev, "Can't get PHY device for port %d: %d\n",
+ i, ret);
+ goto err_phy;
+ }
+
+ omap->phy[i] = phy;
+ usb_phy_init(omap->phy[i]);
+ /* bring PHY out of suspend */
+ usb_phy_set_suspend(omap->phy[i], 0);
+ }
+
/* get ehci regulator and enable */
for (i = 0 ; i < OMAP3_HS_USB_PORTS ; i++) {
if (pdata->port_mode[i] != OMAP_EHCI_PORT_MODE_PHY) {
@@ -277,6 +311,13 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
err_pm_runtime:
disable_put_regulator(pdata);
pm_runtime_put_sync(dev);
+
+err_phy:
+ for (i = 0; i < omap->nports; i++) {
+ if (omap->phy[i])
+ usb_phy_shutdown(omap->phy[i]);
+ }
+
usb_put_hcd(hcd);
return ret;
@@ -293,13 +334,20 @@ err_pm_runtime:
*/
static int ehci_hcd_omap_remove(struct platform_device *pdev)
{
- struct device *dev = &pdev->dev;
- struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct device *dev = &pdev->dev;
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
+ int i;
usb_remove_hcd(hcd);
disable_put_regulator(dev->platform_data);
- usb_put_hcd(hcd);
+ for (i = 0; i < omap->nports; i++) {
+ if (omap->phy[i])
+ usb_phy_shutdown(omap->phy[i]);
+ }
+
+ usb_put_hcd(hcd);
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN
From: Jan Lübbe @ 2013-01-29 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359403945-28585-3-git-send-email-mugunthanvnm@ti.com>
On Tue, 2013-01-29 at 01:42 +0530, Mugunthan V N wrote:
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -24,6 +24,8 @@ Required properties:
> Optional properties:
> - ti,hwmods : Must be "cpgmac0"
> - no_bd_ram : Must be 0 or 1
> +- default_vlan : Specifies Default VLAN for non tagged packets
> + ALE processing
This does not seem to be a property of the hardware. Could there be a
reasonable default for it?
Regards,
Jan
--
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 1/4] ARM: OMAP2+: dpll: round rate to closest value
From: Mohammed, Afzal @ 2013-01-29 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA9388C@DBDE01.ent.ti.com>
Hi Paul,
On Fri, Jan 25, 2013 at 17:48:22, Mohammed, Afzal wrote:
> On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
> > like MPU CPUFreq. I'd suggest reverting
> > 241d3a8dca239610d3d991bf58d4fe38c2d86fd5 or using a similar approach.
> As you prefer reverting the above commit, I will proceed so, hmm.. got
This patch or reverting the above mentioned commit is not required for
lcdc to be usable on am335x, instead please consider for inclusion
patches 3 & 4 of this series,
"ARM: OMAP2+: clock: DEFINE_STRUCT_CLK_FLAGS helper" and
"ARM: AM33XX: clock: SET_RATE_PARENT in lcd path"
Patches 3 & 4 are required to have a functional frame buffer driver
on am335x, also it may help drm driver for the lcdc ip in am335x to
be a platform independent one.
Regards
Afzal
^ permalink raw reply
* [RESEND PATCH v5 4/7] usb: chipidea: consolidate ci_role_driver's API for both roles
From: Alexander Shishkin @ 2013-01-29 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128052158.GA8066@nchen-desktop>
Peter Chen <peter.chen@freescale.com> writes:
> On Fri, Jan 25, 2013 at 02:12:20PM +0200, Alexander Shishkin wrote:
>> Peter Chen <peter.chen@freescale.com> writes:
>>
>> > On Thu, Jan 24, 2013 at 04:35:30PM +0200, Alexander Shishkin wrote:
>> >> Peter Chen <peter.chen@freescale.com> writes:
>> >>
>> >> > - Create init/destroy API for probe and remove
>> >> > - start/stop API are only used otg id switch process
>> >> > - Create the gadget at ci_hdrc_probe if the gadget is supported
>> >> > at that port, the main purpose for this is to avoid gadget module
>> >> > load fail at init.rc
>> >>
>> @@ -402,6 +402,12 @@ static ssize_t store_role(struct device *dev, struct device_attribute *attr,
>> if (ret)
>> return ret;
>>
>> + /*
>> + * there won't be an interrupt in case of manual switching,
>> + * so we need to check vbus session manually
>> + */
>> + ci_handle_vbus_change(ci);
>> +
> It may not be used as there will be a vbus interrupt.
Not if you write gadget to "role" file.
>> return count;
>> }
>>
>> }
>> dbg_remove_files(&ci->gadget.dev);
>> device_unregister(&ci->gadget.dev);
>> - /* my kobject is dynamic, I swear! */
>> - memset(&ci->gadget, 0, sizeof(ci->gadget));
> Any reason to delete it, another fix?
It is currently like this because start and stop functions are called
multiple times during the devices lifetime. This patch converts the
driver to only call start at driver's probe() and stop at driver's
remove().
>> }
>>
>> /**
>> @@ -1842,13 +1839,11 @@ int ci_hdrc_gadget_init(struct ci13xxx *ci)
>> if (!rdrv)
>> return -ENOMEM;
>>
>> - rdrv->init = udc_start;
>> rdrv->start = udc_id_switch_for_device;
>> rdrv->stop = udc_id_switch_for_host;
>> - rdrv->destroy = udc_stop;
> Where we call udc_start and udc_stop? And the udc_start should only be called
> one time.
ci_hdrc_gadget_init() and ci_hdrc_gadget_destroy(). Look closer at the
patch.
>>
>> Which is shorter (32 insertions(+), 53 deletions(-)) and makes the main
>> probe easier on the eyes. What do you think?
> OK, not matter how to change it, it needs to cover below things:
> (Covers last email)
> - Gadget needs to be only initialized one time.
Yes, that's what we agreed on and that's what I'm suggesting in the
above patch.
> - Host/device function should be OK when the device on it or
> the usb cable connects to host during the boots up.
Should still work.
> - When the OTG port is at host mode, it should not call any
> register writing operations at gadget's API.
Furthermore, there shouldn't be any calls to the gadget api.
Regards,
--
Alex
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-29 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129092006.GA16377@avionic-0098.mockup.avionic-design.de>
Dear Thierry Reding,
On Tue, 29 Jan 2013 10:20:06 +0100, Thierry Reding wrote:
> Does this patch perhaps fix this crash?
>
> http://patchwork.ozlabs.org/patch/210870/
I'll test it, thanks for the notice!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thierry Reding @ 2013-01-29 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129094143.1aad9377@skate>
On Tue, Jan 29, 2013 at 09:41:43AM +0100, Thomas Petazzoni wrote:
> On Mon, 28 Jan 2013 15:21:45 -0700, Stephen Warren wrote:
[...]
> > > +static int mvebu_pcie_init(void)
> > > +{
> > > + return platform_driver_probe(&mvebu_pcie_driver,
> > > + mvebu_pcie_probe);
> > > +}
> > > +
> > > +subsys_initcall(mvebu_pcie_init);
> >
> > Why isn't that just platform_driver_register()?
>
> I didn't test recently, but with my first version of the patch set,
> having an initialization as late as module_init() was too late. Some
> PCI fixup code was being executed *before* we get the opportunity of
> initializing the PCI driver, and it was crashing the kernel. I can
> provide more details if you want.
Does this patch perhaps fix this crash?
http://patchwork.ozlabs.org/patch/210870/
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/579b43da/attachment.sig>
^ permalink raw reply
* backport patches to 2.6.34 to remove __ARCH_WANT_INTERRUPTS_ON_CTXSW?
From: Li Zefan @ 2013-01-29 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51077966.1060703@huawei.com>
On 2013/1/29 15:25, Li Zefan wrote:
> Hi Catalin,
>
> We got system crashes, and then we managed to trigger the bug within minutes,
> and we found this in upstream, which also backported to 2.6.34 stable:
>
> commit cb297a3e433dbdcf7ad81e0564e7b804c941ff0d
> Author: Chanho Min <chanho0207@gmail.com>
> Date: Thu Jan 5 20:00:19 2012 +0900
>
> sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW
>
> The bug described in this commit resembles to ours. Unfortunately After applying
> the fix, we still get crash in hours. We tried to bind each real-time task to a
> single cpu to make sure no cpu migration will happen, and it ran without any
> problem for ~20 hours.
>
> We're still investigating this issue. One thing I'm doing is backporting patches
> that removes __ARCH_WANT_INTERRUPTS_ON_CTXSW. With those patches, I can boot
> the kernel, but it hung up when the system automatically start nfs and later
> soft-lockup was reported. Things are fine if I disable nfs startup and start it
> manually.
>
I've confirmed it's the 1st patch that causes this lockup.
> So did I miss something when backporting, or is it infeasible to backport them
> to 2.6.34? We're using ARMv7. I've attached the patches I backported.
>
^ permalink raw reply
* [PATCH v2 3/4] watchdog: add support for ux500_wdt watchdog
From: Fabio Baltieri @ 2013-01-29 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128211222.GA3338@spo001.leaseweb.com>
This patch adds support for the ux500_wdt watchdog that is found in
ST-Ericsson Ux500 platform. The driver is based on PRCMU APIs.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Fabio Baltieri <fabio.baltieri@linaro.org>
---
Changes from v1:
- changed timeout as unsigned in both module parameter and pdata
- changed nowayout to bool
- added Linus Walleij's Ack
drivers/watchdog/Kconfig | 12 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/ux500_wdt.c | 171 ++++++++++++++++++++++++++++++++
include/linux/platform_data/ux500_wdt.h | 19 ++++
4 files changed, 203 insertions(+)
create mode 100644 drivers/watchdog/ux500_wdt.c
create mode 100644 include/linux/platform_data/ux500_wdt.h
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7f809fd..26e1fdb 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -364,6 +364,18 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config UX500_WATCHDOG
+ tristate "ST-Ericsson Ux500 watchdog"
+ depends on MFD_DB8500_PRCMU
+ select WATCHDOG_CORE
+ default y
+ help
+ Say Y here to include Watchdog timer support for the watchdog
+ existing in the prcmu of ST-Ericsson Ux500 series platforms.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ux500_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 97bbdb3a..bec86ee 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_STMP3XXX_WATCHDOG) += stmp3xxx_wdt.o
obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/ux500_wdt.c b/drivers/watchdog/ux500_wdt.c
new file mode 100644
index 0000000..a614d84
--- /dev/null
+++ b/drivers/watchdog/ux500_wdt.c
@@ -0,0 +1,171 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011-2013
+ *
+ * License Terms: GNU General Public License v2
+ *
+ * Author: Mathieu Poirier <mathieu.poirier@linaro.org> for ST-Ericsson
+ * Author: Jonas Aaberg <jonas.aberg@stericsson.com> for ST-Ericsson
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/moduleparam.h>
+#include <linux/miscdevice.h>
+#include <linux/err.h>
+#include <linux/uaccess.h>
+#include <linux/watchdog.h>
+#include <linux/platform_device.h>
+#include <linux/platform_data/ux500_wdt.h>
+
+#include <linux/mfd/dbx500-prcmu.h>
+
+#define WATCHDOG_TIMEOUT 600 /* 10 minutes */
+
+#define WATCHDOG_MIN 0
+#define WATCHDOG_MAX28 268435 /* 28 bit resolution in ms == 268435.455 s */
+#define WATCHDOG_MAX32 4294967 /* 32 bit resolution in ms == 4294967.295 s */
+
+static unsigned int timeout = WATCHDOG_TIMEOUT;
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout,
+ "Watchdog timeout in seconds. default="
+ __MODULE_STRING(WATCHDOG_TIMEOUT) ".");
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+ "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static int ux500_wdt_start(struct watchdog_device *wdd)
+{
+ return prcmu_enable_a9wdog(PRCMU_WDOG_ALL);
+}
+
+static int ux500_wdt_stop(struct watchdog_device *wdd)
+{
+ return prcmu_disable_a9wdog(PRCMU_WDOG_ALL);
+}
+
+static int ux500_wdt_keepalive(struct watchdog_device *wdd)
+{
+ return prcmu_kick_a9wdog(PRCMU_WDOG_ALL);
+}
+
+static int ux500_wdt_set_timeout(struct watchdog_device *wdd,
+ unsigned int timeout)
+{
+ ux500_wdt_stop(wdd);
+ prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
+ ux500_wdt_start(wdd);
+
+ return 0;
+}
+
+static const struct watchdog_info ux500_wdt_info = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+ .identity = "Ux500 WDT",
+ .firmware_version = 1,
+};
+
+static const struct watchdog_ops ux500_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = ux500_wdt_start,
+ .stop = ux500_wdt_stop,
+ .ping = ux500_wdt_keepalive,
+ .set_timeout = ux500_wdt_set_timeout,
+};
+
+static struct watchdog_device ux500_wdt = {
+ .info = &ux500_wdt_info,
+ .ops = &ux500_wdt_ops,
+ .min_timeout = WATCHDOG_MIN,
+ .max_timeout = WATCHDOG_MAX32,
+};
+
+static int ux500_wdt_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct ux500_wdt_data *pdata = pdev->dev.platform_data;
+
+ if (pdata) {
+ if (pdata->timeout > 0)
+ timeout = pdata->timeout;
+ if (pdata->has_28_bits_resolution)
+ ux500_wdt.max_timeout = WATCHDOG_MAX28;
+ }
+
+ watchdog_set_nowayout(&ux500_wdt, nowayout);
+
+ /* disable auto off on sleep */
+ prcmu_config_a9wdog(PRCMU_WDOG_CPU1, false);
+
+ /* set HW initial value */
+ prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
+
+ ret = watchdog_register_device(&ux500_wdt);
+ if (ret)
+ return ret;
+
+ dev_info(&pdev->dev, "initialized\n");
+
+ return 0;
+}
+
+static int ux500_wdt_remove(struct platform_device *dev)
+{
+ watchdog_unregister_device(&ux500_wdt);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int ux500_wdt_suspend(struct platform_device *pdev,
+ pm_message_t state)
+{
+ if (watchdog_active(&ux500_wdt)) {
+ ux500_wdt_stop(&ux500_wdt);
+ prcmu_config_a9wdog(PRCMU_WDOG_CPU1, true);
+
+ prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
+ ux500_wdt_start(&ux500_wdt);
+ }
+ return 0;
+}
+
+static int ux500_wdt_resume(struct platform_device *pdev)
+{
+ if (watchdog_active(&ux500_wdt)) {
+ ux500_wdt_stop(&ux500_wdt);
+ prcmu_config_a9wdog(PRCMU_WDOG_CPU1, false);
+
+ prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
+ ux500_wdt_start(&ux500_wdt);
+ }
+ return 0;
+}
+#else
+#define ux500_wdt_suspend NULL
+#define ux500_wdt_resume NULL
+#endif
+
+static struct platform_driver ux500_wdt_driver = {
+ .probe = ux500_wdt_probe,
+ .remove = ux500_wdt_remove,
+ .suspend = ux500_wdt_suspend,
+ .resume = ux500_wdt_resume,
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = "ux500_wdt",
+ },
+};
+
+module_platform_driver(ux500_wdt_driver);
+
+MODULE_AUTHOR("Jonas Aaberg <jonas.aberg@stericsson.com>");
+MODULE_DESCRIPTION("Ux500 Watchdog Driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
+MODULE_ALIAS("platform:ux500_wdt");
diff --git a/include/linux/platform_data/ux500_wdt.h b/include/linux/platform_data/ux500_wdt.h
new file mode 100644
index 0000000..1689ff4
--- /dev/null
+++ b/include/linux/platform_data/ux500_wdt.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) ST Ericsson SA 2011
+ *
+ * License Terms: GNU General Public License v2
+ *
+ * STE Ux500 Watchdog platform data
+ */
+#ifndef __UX500_WDT_H
+#define __UX500_WDT_H
+
+/**
+ * struct ux500_wdt_data
+ */
+struct ux500_wdt_data {
+ unsigned int timeout;
+ bool has_28_bits_resolution;
+};
+
+#endif /* __UX500_WDT_H */
--
1.7.12.1
^ permalink raw reply related
* [PATCH 3/4] watchdog: add support for ux500_wdt watchdog
From: Fabio Baltieri @ 2013-01-29 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128211222.GA3338@spo001.leaseweb.com>
Hello Wim,
thanks for the review!
On Mon, Jan 28, 2013 at 10:12:22PM +0100, Wim Van Sebroeck wrote:
> > +static int timeout = WATCHDOG_TIMEOUT;
> > +module_param(timeout, int, 0);
> > +MODULE_PARM_DESC(timeout,
> > + "Watchdog timeout in seconds. default="
> > + __MODULE_STRING(WATCHDOG_TIMEOUT) ".");
>
> We should go for unsigned int timeout values...
You're right! This ends up in an unsigned on the rest of the code
anyway and I see other drivers using it as unsigned so I'll change it in
v2 (here and in ux500_wdt_data).
>
> > +static int nowayout = WATCHDOG_NOWAYOUT;
> > +module_param(nowayout, int, 0);
> > +MODULE_PARM_DESC(nowayout,
> > + "Watchdog cannot be stopped once started (default="
> > + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
>
> nowayout is a boolean value so please change this to
> static bool nowayout = WATCHDOG_NOWAYOUT;
Right.
> The rest is OK by me. So if bowayout get's fixed then you have my acked-by.
Ok, I'll send a v2 of this patch soon with both parameters fixed for you
to ack.
Thanks!
Fabio
--
Fabio Baltieri
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-29 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5106F9F9.3010905@wwwdotorg.org>
Dear Stephen Warren,
On Mon, 28 Jan 2013 15:21:45 -0700, Stephen Warren wrote:
> > +Mandatory properties:
> > +- compatible: must be "marvell,armada-370-xp-pcie"
> > +- status: either "disabled" or "okay"
>
> status is a standard DT property; I certainly wouldn't expect its
> presence to be mandatory (there's a defined default), nor would I expect
> each device's binding to redefine this property.
Ok.
> > +- marvell,pcie-port: the physical PCIe port number
>
> Should the standardized cell-index property be used here instead? Or,
> perhaps that property is deprecated/discouraged...
The problem is that I need two identifiers, the pcie-port and
pcie-lane, and it would be strange to have one referenced as
cell-index, and the other one as marvell,pcie-lane, no? Unless of
course we can put two numbers in the cell-index property, but a quick
grep in Documentation/devicetree/bindings/ seems to indicate that all
users of cell-index use it with a single identifier.
Just tell me what to do here, I don't have a strong opinion on this.
> > diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>
> > +obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> > +ccflags-$(CONFIG_PCI_MVEBU) += \
> > + -I$(srctree)/arch/arm/plat-orion/include \
> > + -I$(srctree)/arch/arm/mach-mvebu/include
>
> That seems a little dangerous w.r.t. multi-platform zImage. Can the
> required headers be moved out to somewhere more public to avoid this?
Why is this dangerous for multi-platform zImage? For this specific
driver only, some SoC-specific headers are used. I don't think it
prevents another PCI driver (such as the Tegra one) from being built
into the same kernel image, no?
Also, this is kind of a temporary solution, because I can't fix all the
problems in just the PCI patch series without making it horribly large.
The reason why we need those include paths at the moment are:
* For plat-orion/include, because of pcie.h that provides functions
common to all Marvell SoCs regarding PCI. Ultimately, all the
Marvell SoCs that use this common code should be migrated over to
the DT-capable PCI driver that is submitted through this patch
series. This will take a bit of time, and is too complex to do in
one shot, together with the introduction of the driver itself. So
ultimately, all the code in plat-orion/pcie.c will migrate into
drivers/pci/host/pci-mvebu.c, and this
plat-orion/include/plat/pcie.h file should disappear, removing the
need for this special header path.
* For mach-mvebu/include, because of the addr-map.h header that
provides functions related to address decoding windows. This is also
likely to evolve quite significantly when we'll make the PCI driver
being used by the other Marvell SoC families (Kirkwood, Dove,
Orion5x), and when this work is done, we can think of having a
public header in include/linux that exposes the address decoding
APIs, once it has stabilized a bit across the different Marvell SoC
families.
So, the bottom line is: yes I know those include paths are not nice,
but I don't think they prevent multiplatform builds, and they are a
temporary solution until we convert more Marvell SoC families to this
new PCI driver.
> > +/*
> > + * Those are the product IDs used for the emulated PCI Host bridge and
> > + * emulated PCI-to-PCI bridges. They are temporary until we get
> > + * official IDs assigned.
> > + */
> > +#define MARVELL_EMULATED_HOST_BRIDGE_ID 4141
> > +#define MARVELL_EMULATED_PCI_PCI_BRIDGE_ID 4242
>
> I assume that means we can't merge this driver yet. The cover letter
> mentioned a desire to merge this for 3.9; there's not much time to get
> official IDs assigned, then.
I am working on getting real IDs assigned. For now, I'd like to work on
getting all other issues fixed, and have this only problem remaining.
>
> > +static int mvebu_pcie_init(void)
> > +{
> > + return platform_driver_probe(&mvebu_pcie_driver,
> > + mvebu_pcie_probe);
> > +}
> > +
> > +subsys_initcall(mvebu_pcie_init);
>
> Why isn't that just platform_driver_register()?
I didn't test recently, but with my first version of the patch set,
having an initialization as late as module_init() was too late. Some
PCI fixup code was being executed *before* we get the opportunity of
initializing the PCI driver, and it was crashing the kernel. I can
provide more details if you want.
> > +MODULE_LICENSE("GPL");
>
> "GPL v2".
Sure.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 18/27] arm: plat-orion: add more flexible PCI configuration space read/write functions
From: Thomas Petazzoni @ 2013-01-29 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128195111.GC17722@obsidianresearch.com>
Dear Jason Gunthorpe,
On Mon, 28 Jan 2013 12:51:11 -0700, Jason Gunthorpe wrote:
> On Mon, Jan 28, 2013 at 07:56:27PM +0100, Thomas Petazzoni wrote:
>
> > However, with the usage of the emulated PCI host bridge and emulated
> > PCI-to-PCI bridges, this is not the case: bus number 0 is the emulated
> > bus on which the emulated PCI-to-PCI bridges sit, so from the Linux
> > point of view, the real busses start at bus 1, but from a hardware
> > point of view, they start at bus 0.
>
> Hum.. This is a bit funny sounding, can you confirm..
Might be yes, but IIRC, when I try to enumerate the devices in the PCIe
interface 0 (from a hardware point of view), passing a bus number of 1
in the PCI configuration space access registers, then it simply doesn't
work.
> The bus number programmed into all the end points must match the Linux
> number. Ie the PCI-E Link Description register of end point devices
What is this PCI-E Link Description register ? Where is it located ?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC] arm: use built-in byte swap function
From: Borislav Petkov @ 2013-01-29 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128193033.8a0b0a871150c99247f05a95@freescale.com>
On Mon, Jan 28, 2013 at 07:30:33PM -0600, Kim Phillips wrote:
> Enable the compiler intrinsic for byte swapping on arch ARM. This
> allows the compiler to detect and be able to optimize out byte
> swappings, e.g. in big endian to big endian moves.
>
> AFAICT, arm gcc got __builtin_bswap{32,64} support in 4.6,
> and for the 16-bit version in 4.8.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> akin to: http://comments.gmane.org/gmane.linux.kernel.cross-arch/16016
>
> based on linux-next. Depends on commit "compiler-gcc{3,4}.h: Use
> GCC_VERSION macro" by Daniel Santos <daniel.santos@pobox.com>,
> currently in the akpm branch.
>
> RFC because of unfamiliarity with arch ARM, and that at91sam9rl,
> at91rm9200, and lpd270 (so far, at least) builds fail with:
>
> include/uapi/linux/swab.h:60: undefined reference to `__bswapsi2'
>
> I'm using eldk-5.2.1/armv7a's arm-linux-gnueabi-gcc (GCC) 4.6.4
> 20120303 (prerelease)
>
> arch/arm/Kconfig | 1 +
> include/linux/compiler-gcc4.h | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index eda8711..437d11a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -3,6 +3,7 @@ config ARM
> default y
> select ARCH_BINFMT_ELF_RANDOMIZE_PIE
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> + select ARCH_USE_BUILTIN_BSWAP
> select ARCH_HAVE_CUSTOM_GPIO_H
> select ARCH_WANT_IPC_PARSE_VERSION
> select BUILDTIME_EXTABLE_SORT if MMU
> diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
> index 68b162d..da5f728 100644
> --- a/include/linux/compiler-gcc4.h
> +++ b/include/linux/compiler-gcc4.h
> @@ -67,7 +67,8 @@
>
>
> #ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
> -#if GCC_VERSION >= 40400
> +#if (!defined(__arm__) && GCC_VERSION >= 40400) || \
> + (defined(__arm__) && GCC_VERSION >= 40600)
There should be no arch-specific stuff in a generic header. I guess
you probably need to select ARCH_USE_BUILTIN_BSWAP in an arm-specific
compiler.h header after checking compiler version...
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply
* [GIT PULL] ARM: OMAP: Audio support via omap-twl4030 and pwm support
From: Peter Ujfalusi @ 2013-01-29 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE64DC.2030808@ti.com>
Hi Tony,
On 01/22/2013 11:07 AM, Peter Ujfalusi wrote:
> Hi Tony,
>
> The content of this pull:
>
> update for audio support via omap-twl4030 and pwm updates in board level:
> http://www.spinics.net/lists/linux-omap/msg85085.html
>
> and zoom-peripherals update to not request the TWL GPIO7:
> http://www.spinics.net/lists/linux-omap/msg85187.html
>
> All is on top of mainline v3.8-rc4 tag.
Have you already pulled this one? I can not find the patches in linux-next.
Regards,
P?ter
>
> Regards,
> P?ter
>
> ---
> The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
>
> Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
>
> are available in the git repository at:
>
> git://gitorious.org/omap-audio/linux-audio.git peter/for-tony
>
> for you to fetch changes up to e4f4e8bfa47431b91fbb21dd9b86d9bc2c15cbd7:
>
> ARM: board-zoom: Do not request LCD panel enable GPIO from twl4030 (2013-01-22 10:35:16 +0100)
>
> ----------------------------------------------------------------
> Peter Ujfalusi (9):
> ARM: OMAP: 3430sdp: Enable extmute functionality for audio
> ARM: OMAP: zoom: Zoom2 does not have extmute functionality
> ARM: OMAP2+: twl-common: Add default twl4030 audio configuration
> ARM: OMAP2+: twl-common: Allow boards to customize the twl4030 audio setup
> ARM: OMAP: zoom: Audio support via the common omap-twl4030 machine driver
> ARM: OMAP: sdp3430: Audio support via the common omap-twl4030 machine driver
> ARM: OMAP: board-4430sdp: Proper support for TWL6030 PWM LED/Backlight
> ARM: OMAP: omap3beagle: Use the pwm_leds driver to control the PMU_STAT led
> ARM: board-zoom: Do not request LCD panel enable GPIO from twl4030
>
> arch/arm/mach-omap2/board-3430sdp.c | 20 ++++++++++++++++++++
> arch/arm/mach-omap2/board-4430sdp.c | 30 +++++++++++++++++++++++++++++-
> arch/arm/mach-omap2/board-cm-t35.c | 2 +-
> arch/arm/mach-omap2/board-devkit8000.c | 2 +-
> arch/arm/mach-omap2/board-igep0020.c | 2 +-
> arch/arm/mach-omap2/board-omap3beagle.c | 41 ++++++++++++++++++++++++++++++++---------
> arch/arm/mach-omap2/board-omap3evm.c | 2 +-
> arch/arm/mach-omap2/board-overo.c | 2 +-
> arch/arm/mach-omap2/board-zoom-peripherals.c | 39 +++++++++++++++++++++------------------
> arch/arm/mach-omap2/twl-common.c | 17 +++++++++++------
> arch/arm/mach-omap2/twl-common.h | 3 ++-
> 11 files changed, 120 insertions(+), 40 deletions(-)
>
> _______________________________________________
> 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 V1 RESEND] ARM: gic: add irq_set_affinity to gic_arch_extn
From: Chao Xie @ 2013-01-29 8:25 UTC (permalink / raw)
To: linux-arm-kernel
gic_arch_extn is used for ARCH specific interrupt controller.
It has added the callbacks for irq_mask/irq_unamsk and so, but
irq_set_affinity is not used.
For SMP architecure, when both cores are powered off, the GIC may
be powered off too. An external interrupt controller can be used
as a logic to detect the interrupt and acknowledge power managment
unitto wake up core.
Because the irqs may be bound to different cors, when set irq
affinity, the external interrupt controller should be set too. Then
it can acknowledge the power managment unit to wake up correct core.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
arch/arm/common/gic.c | 27 ++++++++++++++++++---------
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 36ae03a..49920a0 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -82,12 +82,15 @@ static u8 gic_cpu_map[NR_GIC_CPU_IF] __read_mostly;
* Default make them NULL.
*/
struct irq_chip gic_arch_extn = {
- .irq_eoi = NULL,
- .irq_mask = NULL,
- .irq_unmask = NULL,
- .irq_retrigger = NULL,
- .irq_set_type = NULL,
- .irq_set_wake = NULL,
+ .irq_eoi = NULL,
+ .irq_mask = NULL,
+ .irq_unmask = NULL,
+ .irq_retrigger = NULL,
+ .irq_set_type = NULL,
+#ifdef CONFIG_SMP
+ .irq_set_affinity = NULL,
+#endif
+ .irq_set_wake = NULL,
};
#ifndef MAX_GIC_NR
@@ -245,6 +248,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
unsigned int shift = (gic_irq(d) % 4) * 8;
unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
u32 val, mask, bit;
+ int ret = IRQ_SET_MASK_OK;
if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids)
return -EINVAL;
@@ -253,11 +257,16 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
bit = gic_cpu_map[cpu] << shift;
raw_spin_lock(&irq_controller_lock);
- val = readl_relaxed(reg) & ~mask;
- writel_relaxed(val | bit, reg);
+ if (gic_arch_extn.irq_set_affinity)
+ ret = gic_arch_extn.irq_set_affinity(d, mask_val, force);
+
+ if (ret == IRQ_SET_MASK_OK) {
+ val = readl_relaxed(reg) & ~mask;
+ writel_relaxed(val | bit, reg);
+ }
raw_spin_unlock(&irq_controller_lock);
- return IRQ_SET_MASK_OK;
+ return ret;
}
#endif
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 0/9] ARM: OMAP2+: AM33XX: Misc fixes/updates
From: Peter Korsgaard @ 2013-01-29 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-1-git-send-email-vaibhav.bedia@ti.com>
>>>>> "Vaibhav" == Vaibhav Bedia <vaibhav.bedia@ti.com> writes:
Vaibhav> Hi,
Vaibhav> The following patches were earlier posted as part the AM33XX
Vaibhav> suspend-resume support series [1]. Based on the suggestion
Vaibhav> from Santosh Shilimkar <santosh.shilimkar@ti.com> i have split
Vaibhav> out the changes which update the various data files related
Vaibhav> to AM33XX support. This version addresses the comments
Vaibhav> received from Sergei Shtylyov and Peter Korsgaard on the earlier
Vaibhav> patchset [2].
Vaibhav> These patches apply on top of v3.8-rc5
Besides the dt compatible property names in patch 8, this series looks
good to me:
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH v2 8/9] ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3
From: Peter Korsgaard @ 2013-01-29 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-9-git-send-email-vaibhav.bedia@ti.com>
>>>>> "Vaibhav" == Vaibhav Bedia <vaibhav.bedia@ti.com> writes:
Vaibhav> Since AM33XX supports only DT-boot, this is needed
Vaibhav> for the appropriate device nodes to be created.
Vaibhav> Note: OCMC RAM is part of the PER power domain and supports
Vaibhav> retention. The assembly code for low power entry/exit will
Vaibhav> run from OCMC RAM. To ensure that the OMAP PM code does not
Vaibhav> attempt to disable the clock to OCMC RAM as part of the
Vaibhav> suspend process add the no_idle_on_suspend flag.
Vaibhav> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Vaibhav> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Vaibhav> ---
Vaibhav> v2: Add reg property
Vaibhav> arch/arm/boot/dts/am33xx.dtsi | 14 +++++++++++++
Vaibhav> 1 file changed, 14 insertions(+)
Vaibhav> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
Vaibhav> index c2f14e8..423f898 100644
Vaibhav> --- a/arch/arm/boot/dts/am33xx.dtsi
Vaibhav> +++ b/arch/arm/boot/dts/am33xx.dtsi
Vaibhav> @@ -385,5 +385,19 @@
Vaibhav> mac-address = [ 00 00 00 00 00 00 ];
Vaibhav> };
Vaibhav> };
Vaibhav> +
Vaibhav> + ocmcram: ocmcram at 40300000 {
Vaibhav> + compatible = "ti,ocmcram";
Vaibhav> + reg = <0x40300000 0x10000>;
Vaibhav> + ti,hwmods = "ocmcram";
Vaibhav> + ti,no_idle_on_suspend;
Vaibhav> + };
Vaibhav> +
Vaibhav> + wkup_m3: wkup_m3 at 44d00000 {
Vaibhav> + compatible = "ti,wkup_m3";
Both of these compatible properties should probably use less generic
names, like:
ti,am3352-ocmcram
ti,am3352-wkup-m3 ('-' instead of '_')
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH v3 3/3] leds: leds-pwm: Defer led_pwm_set() if PWM can sleep
From: Peter Ujfalusi @ 2013-01-29 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359381659-24454-4-git-send-email-florian.vaussard@epfl.ch>
On 01/28/2013 03:00 PM, Florian Vaussard wrote:
> Call to led_pwm_set() can happen inside atomic context, like triggers.
> If the PWM call can sleep, defer using a worker.
>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> drivers/leds/leds-pwm.c | 50 +++++++++++++++++++++++++++++++++++++++-------
> 1 files changed, 42 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index a1ea5f6..faf52c0 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -23,12 +23,16 @@
> #include <linux/pwm.h>
> #include <linux/leds_pwm.h>
> #include <linux/slab.h>
> +#include <linux/workqueue.h>
>
> struct led_pwm_data {
> struct led_classdev cdev;
> struct pwm_device *pwm;
> + struct work_struct work;
> unsigned int active_low;
> unsigned int period;
> + int duty;
> + bool can_sleep;
> };
>
> struct led_pwm_priv {
> @@ -36,6 +40,26 @@ struct led_pwm_priv {
> struct led_pwm_data leds[0];
> };
>
> +static void __led_pwm_set(struct led_pwm_data *led_dat)
> +{
> + int new_duty = led_dat->duty;
> +
> + pwm_config(led_dat->pwm, new_duty, led_dat->period);
> +
> + if (new_duty == 0)
> + pwm_disable(led_dat->pwm);
> + else
> + pwm_enable(led_dat->pwm);
> +}
> +
> +static void led_pwm_work(struct work_struct *work)
> +{
> + struct led_pwm_data *led_dat =
> + container_of(work, struct led_pwm_data, work);
> +
> + __led_pwm_set(led_dat);
> +}
> +
> static void led_pwm_set(struct led_classdev *led_cdev,
> enum led_brightness brightness)
> {
> @@ -44,13 +68,12 @@ static void led_pwm_set(struct led_classdev *led_cdev,
> unsigned int max = led_dat->cdev.max_brightness;
> unsigned int period = led_dat->period;
>
> - if (brightness == 0) {
> - pwm_config(led_dat->pwm, 0, period);
> - pwm_disable(led_dat->pwm);
> - } else {
> - pwm_config(led_dat->pwm, brightness * period / max, period);
> - pwm_enable(led_dat->pwm);
> - }
> + led_dat->duty = brightness * period / max;
> +
> + if (led_dat->can_sleep)
> + schedule_work(&led_dat->work);
> + else
> + __led_pwm_set(led_dat);
> }
>
> static inline size_t sizeof_pwm_leds_priv(int num_leds)
> @@ -100,6 +123,10 @@ static struct led_pwm_priv *led_pwm_create_of(struct platform_device *pdev)
> led_dat->cdev.brightness = LED_OFF;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>
> + led_dat->can_sleep = pwm_can_sleep(led_dat->pwm);
> + if (led_dat->can_sleep)
> + INIT_WORK(&led_dat->work, led_pwm_work);
> +
> ret = led_classdev_register(&pdev->dev, &led_dat->cdev);
> if (ret < 0) {
> dev_err(&pdev->dev, "failed to register for %s\n",
> @@ -153,6 +180,10 @@ static int led_pwm_probe(struct platform_device *pdev)
> led_dat->cdev.max_brightness = cur_led->max_brightness;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>
> + led_dat->can_sleep = pwm_can_sleep(led_dat->pwm);
> + if (led_dat->can_sleep)
> + INIT_WORK(&led_dat->work, led_pwm_work);
> +
> ret = led_classdev_register(&pdev->dev, &led_dat->cdev);
> if (ret < 0)
> goto err;
> @@ -180,8 +211,11 @@ static int led_pwm_remove(struct platform_device *pdev)
> struct led_pwm_priv *priv = platform_get_drvdata(pdev);
> int i;
>
> - for (i = 0; i < priv->num_leds; i++)
> + for (i = 0; i < priv->num_leds; i++) {
> led_classdev_unregister(&priv->leds[i].cdev);
> + if (priv->leds[i].can_sleep)
> + cancel_work_sync(&priv->leds[i].work);
> + }
>
> return 0;
> }
>
--
P?ter
^ permalink raw reply
* [PATCH v3 1/3] pwm: Add pwm_can_sleep() as exported API to users
From: Peter Ujfalusi @ 2013-01-29 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359381659-24454-2-git-send-email-florian.vaussard@epfl.ch>
On 01/28/2013 03:00 PM, Florian Vaussard wrote:
> Calls to some external PWM chips can sleep. To help users,
> add pwm_can_sleep() API.
>
> Cc: Thierry Reding <thierry.reding@avionic-design.de>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> drivers/pwm/core.c | 12 ++++++++++++
> include/linux/pwm.h | 10 ++++++++++
> 2 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 4a13da4..41c0b0c 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -763,6 +763,18 @@ void devm_pwm_put(struct device *dev, struct pwm_device *pwm)
> }
> EXPORT_SYMBOL_GPL(devm_pwm_put);
>
> +/**
> + * pwm_can_sleep() - report whether PWM access will sleep
> + * @pwm: PWM device
> + *
> + * It returns true if accessing the PWM can sleep, false otherwise.
> + */
> +bool pwm_can_sleep(struct pwm_device *pwm)
> +{
> + return pwm->chip->can_sleep;
> +}
> +EXPORT_SYMBOL_GPL(pwm_can_sleep);
> +
> #ifdef CONFIG_DEBUG_FS
> static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
> {
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 70655a2..747c657 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -146,6 +146,8 @@ struct pwm_ops {
> * @base: number of first PWM controlled by this chip
> * @npwm: number of PWMs controlled by this chip
> * @pwms: array of PWM devices allocated by the framework
> + * @can_sleep: flag must be set iff config()/enable()/disable() methods sleep,
> + * as they must while accessing PWM chips over I2C or SPI
> */
> struct pwm_chip {
> struct device *dev;
> @@ -159,6 +161,7 @@ struct pwm_chip {
> struct pwm_device * (*of_xlate)(struct pwm_chip *pc,
> const struct of_phandle_args *args);
> unsigned int of_pwm_n_cells;
> + bool can_sleep;
> };
>
> #if IS_ENABLED(CONFIG_PWM)
> @@ -182,6 +185,8 @@ struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id);
> struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
> const char *con_id);
> void devm_pwm_put(struct device *dev, struct pwm_device *pwm);
> +
> +bool pwm_can_sleep(struct pwm_device *pwm);
> #else
> static inline int pwm_set_chip_data(struct pwm_device *pwm, void *data)
> {
> @@ -242,6 +247,11 @@ static inline struct pwm_device *devm_of_pwm_get(struct device *dev,
> static inline void devm_pwm_put(struct device *dev, struct pwm_device *pwm)
> {
> }
> +
> +static inline bool pwm_can_sleep(struct pwm_device *pwm)
> +{
> + return false;
> +}
> #endif
>
> struct pwm_lookup {
>
--
P?ter
^ permalink raw reply
* [PATCH 4/5] ata: arasan: remove the need for platform_data
From: Viresh Kumar @ 2013-01-29 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359410300-26113-5-git-send-email-arnd@arndb.de>
On 29 January 2013 03:28, Arnd Bergmann <arnd@arndb.de> wrote:
> This adds a complete DT binding for the arasan device driver. There is
> currently only one user, which is the spear13xx platform, so we don't
> actually have to parse all the properties until another user comes in,
> but this does use the generic DMA binding to find the DMA channel.
>
> The patch is untested so far and is part of a series to convert
> the spear platform over to use the generic DMA binding, so it
> should stay with the rest of the series.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH] ARM: gic: add irq_set_affinity to gic_arch_extn
From: Chao Xie @ 2013-01-29 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359436629-19873-1-git-send-email-chao.xie@marvell.com>
On Tue, Jan 29, 2013 at 1:17 PM, Chao Xie <chao.xie@marvell.com> wrote:
> gic_arch_extn is used for ARCH specific interrupt controller.
> It has added the callbacks for irq_mask/irq_unamsk and so, but
> irq_set_affinity is not used.
> For SMP architecure, when both cores are powered off, the GIC may
> be powered off too. An external interrupt controller can be used
> as a logic to detect the interrupt and acknowledge power managment
> unitto wake up core.
> Because the irqs may be bound to different cors, when set irq
> affinity, the external interrupt controller should be set too. Then
> it can acknowledge the power managment unit to wake up correct core.
>
> Signed-off-by: Chao Xie <chao.xie@marvell.com>
> ---
> arch/arm/common/gic.c | 17 +++++++++++------
> 1 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index 36ae03a..8e4bc8a 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -82,12 +82,15 @@ static u8 gic_cpu_map[NR_GIC_CPU_IF] __read_mostly;
> * Default make them NULL.
> */
> struct irq_chip gic_arch_extn = {
> - .irq_eoi = NULL,
> - .irq_mask = NULL,
> - .irq_unmask = NULL,
> - .irq_retrigger = NULL,
> - .irq_set_type = NULL,
> - .irq_set_wake = NULL,
> + .irq_eoi = NULL,
> + .irq_mask = NULL,
> + .irq_unmask = NULL,
> + .irq_retrigger = NULL,
> + .irq_set_type = NULL,
> +#ifdef CONFIG_SMP
> + .irq_set_affinity = NULL,
> +#endif
> + .irq_set_wake = NULL,
> };
>
> #ifndef MAX_GIC_NR
> @@ -253,6 +256,8 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
> bit = gic_cpu_map[cpu] << shift;
>
> raw_spin_lock(&irq_controller_lock);
> + if (gic_arch_extn.irq_set_affinity)
> + return gic_arch_extn.irq_set_affinity(d, mask_val, force);
> val = readl_relaxed(reg) & ~mask;
> writel_relaxed(val | bit, reg);
> raw_spin_unlock(&irq_controller_lock);
> --
> 1.7.4.1
>
I send the wrong patch, please ignore it, and i will send new one.
^ permalink raw reply
* [PATCH v2] ARM: mxs: gpio-mxs: Add IRQ_TYPE_EDGE_BOTH support
From: Gwenhael Goavec-Merou @ 2013-01-29 8:16 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for IRQ_TYPE_EDGE_BOTH needed for some driver
(gpio-keys).
Inspired from gpio-mxc.c
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
---
Changes since v1 (as advised by Shawn Guo):
* fix some typos
* use GPIO_INT_xxx_EDGE instead of GPIO_INT_xxx_LEV
* suppress useless variables
drivers/gpio/gpio-mxs.c | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
index fa2a63c..859b6fa 100644
--- a/drivers/gpio/gpio-mxs.c
+++ b/drivers/gpio/gpio-mxs.c
@@ -65,6 +65,7 @@ struct mxs_gpio_port {
struct irq_domain *domain;
struct bgpio_chip bgc;
enum mxs_gpio_id devid;
+ u32 both_edges;
};
static inline int is_imx23_gpio(struct mxs_gpio_port *port)
@@ -81,13 +82,23 @@ static inline int is_imx28_gpio(struct mxs_gpio_port *port)
static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
{
+ u32 val;
u32 pin_mask = 1 << d->hwirq;
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct mxs_gpio_port *port = gc->private;
void __iomem *pin_addr;
int edge;
+ port->both_edges &= ~pin_mask;
switch (type) {
+ case IRQ_TYPE_EDGE_BOTH:
+ val = gpio_get_value(port->bgc.gc.base + d->hwirq);
+ if (val)
+ edge = GPIO_INT_FALL_EDGE;
+ else
+ edge = GPIO_INT_RISE_EDGE;
+ port->both_edges |= pin_mask;
+ break;
case IRQ_TYPE_EDGE_RISING:
edge = GPIO_INT_RISE_EDGE;
break;
@@ -124,6 +135,23 @@ static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
return 0;
}
+static void mxs_flip_edge(struct mxs_gpio_port *port, u32 gpio)
+{
+ u32 bit, val, edge;
+ void __iomem *pin_addr;
+
+ bit = 1 << gpio;
+
+ pin_addr = port->base + PINCTRL_IRQPOL(port);
+ val = readl(pin_addr);
+ edge = val & bit;
+
+ if (edge)
+ writel(bit, pin_addr + MXS_CLR);
+ else
+ writel(bit, pin_addr + MXS_SET);
+}
+
/* MXS has one interrupt *per* gpio port */
static void mxs_gpio_irq_handler(u32 irq, struct irq_desc *desc)
{
@@ -137,6 +165,9 @@ static void mxs_gpio_irq_handler(u32 irq, struct irq_desc *desc)
while (irq_stat != 0) {
int irqoffset = fls(irq_stat) - 1;
+ if (port->both_edges & (1 << irqoffset))
+ mxs_flip_edge(port, irqoffset);
+
generic_handle_irq(irq_find_mapping(port->domain, irqoffset));
irq_stat &= ~(1 << irqoffset);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH 5/5] ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT
From: Viresh Kumar @ 2013-01-29 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359410300-26113-6-git-send-email-arnd@arndb.de>
You forgot spear-devel for this series.
On 29 January 2013 03:28, Arnd Bergmann <arnd@arndb.de> wrote:
> This replaces an earlier patch from Viresh Kumar to move
> the spear platform over to the generic DMA binding. This
> version is now based on the merged multiplatform capable
> spear platform, rather than the separate spear13xx/3xx/6xx
> directories.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Vinod Koul <vinod.koul@linux.intel.com>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> ---
> arch/arm/boot/dts/spear1340.dtsi | 3 +
> arch/arm/boot/dts/spear13xx.dtsi | 25 +++++-
> arch/arm/mach-spear/generic.h | 6 --
> arch/arm/mach-spear/include/mach/spear.h | 2 -
> arch/arm/mach-spear/spear1310.c | 30 +-------
> arch/arm/mach-spear/spear1340.c | 32 +-------
> arch/arm/mach-spear/spear13xx-dma.h | 128 -------------------------------
> arch/arm/mach-spear/spear13xx.c | 58 --------------
> 8 files changed, 29 insertions(+), 255 deletions(-)
> delete mode 100644 arch/arm/mach-spear/spear13xx-dma.h
>
> diff --git a/arch/arm/boot/dts/spear1340.dtsi b/arch/arm/boot/dts/spear1340.dtsi
> index 34da11a..e1786a0 100644
> --- a/arch/arm/boot/dts/spear1340.dtsi
> +++ b/arch/arm/boot/dts/spear1340.dtsi
> @@ -113,6 +113,9 @@
> reg = <0xb4100000 0x1000>;
> interrupts = <0 105 0x4>;
> status = "disabled";
> + dmas = <&dwdma0 0x600 0 0 1>, /* 0xC << 11 */
> + <&dwdma0 0x680 0 1 0>; /* 0xD << 7 */
> + dma-names = "tx", "rx";
> };
>
> thermal at e07008c4 {
> diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
> index b4ca60f..45597fd 100644
> --- a/arch/arm/boot/dts/spear13xx.dtsi
> +++ b/arch/arm/boot/dts/spear13xx.dtsi
> @@ -98,13 +98,24 @@
> reg = <0xb2800000 0x1000>;
> interrupts = <0 29 0x4>;
> status = "disabled";
> + dmas = <&dwdma0 0 0 0 0>;
> + dma-names = "data";
> };
>
> - dma at ea800000 {
> + dwdma0: dma at ea800000 {
> compatible = "snps,dma-spear1340";
> reg = <0xea800000 0x1000>;
> interrupts = <0 19 0x4>;
> status = "disabled";
> +
> + dma-channels = <8>;
> + #dma-cells = <3>;
4?
^ permalink raw reply
* [PATCH 2/2] ARM: davinci: da850: configure CS2(aemif) for norflash
From: Heiko Schocher @ 2013-01-29 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359436796-25135-3-git-send-email-anilkumar.v@ti.com>
Hello Kumar,
On 29.01.2013 06:19, Kumar, Anil wrote:
> Configure 16 bit data bus width for CS2(aemif) to use the norflash on
> DA850.
>
> Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
> ---
> :100644 100644 37c27af... 540e284... M arch/arm/mach-davinci/da8xx-dt.c
> arch/arm/mach-davinci/da8xx-dt.c | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index 37c27af..540e284 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -38,12 +38,29 @@ static void __init da8xx_init_irq(void)
> }
>
> #ifdef CONFIG_ARCH_DAVINCI_DA850
> +#define DA8XX_AEMIF_CE2CFG_OFFSET 0x10
> +#define DA8XX_AEMIF_ASIZE_16BIT 0x1
Hmm... I am not really happy with such defines, because different
boards need maybe different settings, and this should be catched
by the device tree ... Couldn't we add this infos in the
device tree? I tried such an approach here:
First post and some discussion:
https://lists.ozlabs.org/pipermail/devicetree-discuss/2011-December/010030.html
Nori suggested here
https://lists.ozlabs.org/pipermail/devicetree-discuss/2011-December/011330.html
to move such an driver out of arch/arm and IIRC it was
suggested to move it into the mfd framework. I currently
not know, if there was such a sort of patches, to get this
in the mfd subsystem, but I think, this CS settings should be
done like the pinmux settings ...
My last posted version of this patch:
https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-March/013036.html
Maybe it is worth to discuss this again?
> +
> +static void __init da8xx_init_nor(void)
> +{
> + void __iomem *aemif_addr;
> +
> + aemif_addr = ioremap(DA8XX_AEMIF_CTL_BASE, SZ_32K);
> +
> + /* Configure data bus width of CS2 to 16 bit */
> + writel(readl(aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET) |
> + DA8XX_AEMIF_ASIZE_16BIT,
> + aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET);
I vote for avoiding such board specific code in a generic
approach ...
> +
> + iounmap(aemif_addr);
> +}
>
> static void __init da850_init_machine(void)
> {
> of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>
> da8xx_uart_clk_enable();
> + da8xx_init_nor();
> }
>
> static const char *da850_boards_compat[] __initdata = {
>
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ 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