* [PATCH V3 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
From: Benoit Cousson @ 2012-11-05 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352119972-13710-1-git-send-email-lokeshvutla@ti.com>
Hi Lokesh,
On 11/05/2012 01:52 PM, Lokesh Vutla wrote:
> This patch series adds Device tree data for the EMIF
> sdram controllers in OMAP5 and LPDDR2 memory devices
> in OMAP5-evm board.
>
> Testing:
> - Boot tested on OMAP5430 evm.
> - Built EMIF as a module.
>
> Changes from v2:
> * Rebased on top of
> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts
> * Addressed few other comments from Benoit.
Thanks for this quick update.
I've just applied your series in my for_3.8/dts_part2 branch.
Regards,
Benoit
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Rob Herring @ 2012-11-05 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105172624.GE2005@linaro.org>
On 11/05/2012 11:26 AM, Dave Martin wrote:
> On Mon, Nov 05, 2012 at 11:13:51AM -0500, Nicolas Pitre wrote:
>> On Mon, 5 Nov 2012, Russell King - ARM Linux wrote:
>>
>>> On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
>>>> Why not allow unaligned accesses in the decompressor, though, both
>>>> for v6 and v7?
>>>
>>> EXACTLY.
>>
>> I have no objections to that. In fact, I made a remark to this effect
>> in my initial review of this patch. Whether or not gcc does take
>> advantage of this hardware ability in the end is orthogonal.
>
> For the sake of argument, here's how it might look.
>
> Currently, I make no attempt to restore the original state of the U bit.
> The A bit if forced later by the kernel during boot, after a short window
> during which we should only run low-level arch code and therefore where
> no unaligned accesses should happen.
>
> Does anyone think these issues are likely to be important?
>
And here is my updated version that does v6 somewhat differently:
8<------------------------------------------------------------------
>From 76c2b7685397f13aa53f426822128430fc24b8a0 Mon Sep 17 00:00:00 2001
From: Rob Herring <rob.herring@calxeda.com>
Date: Mon, 5 Nov 2012 11:39:48 -0600
Subject: [PATCH v2] ARM: decompressor: clear SCTLR.A bit for v6 and v7 cores
With recent compilers and move to generic unaligned.h in commit d25c881
(ARM: 7493/1: use generic unaligned.h), unaligned accesses will be used
by the LZO decompressor on v7 cores. So we need to make sure unaligned
accesses are allowed by clearing the SCTLR A bit.
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. In case this changes and to align
with the kernel behavior, we clear the A bit and set the U bit.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
---
arch/arm/boot/compressed/head.S | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index bc67cbf..f14d7ec 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -629,6 +629,11 @@ __armv4_mmu_cache_on:
mcr p15, 0, r0, c7, c10, 4 @ drain write buffer
mcr p15, 0, r0, c8, c7, 0 @ flush I,D TLBs
mrc p15, 0, r0, c1, c0, 0 @ read control reg
+ mrc p15, 0, r11, c0, c0 @ get processor ID
+ and r11, r11, #0xf0000
+ tst r11, #0x70000 @ ARMv6
+ orreq r0, r0, #1 << 22 @ set SCTLR.U
+ biceq r0, r0, #1 << 1 @ clear SCTLR.A
orr r0, r0, #0x5000 @ I-cache enable, RR cache replacement
orr r0, r0, #0x0030
#ifdef CONFIG_CPU_ENDIAN_BE8
@@ -654,6 +659,7 @@ __armv7_mmu_cache_on:
#endif
mrc p15, 0, r0, c1, c0, 0 @ read control reg
bic r0, r0, #1 << 28 @ clear SCTLR.TRE
+ bic r0, r0, #1 << 1 @ clear SCTLR.A
orr r0, r0, #0x5000 @ I-cache enable, RR cache replacement
orr r0, r0, #0x003c @ write buffer
#ifdef CONFIG_MMU
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/6] ARM/dts: omap4-panda: Add pinmux configuration for HDMI
From: Benoit Cousson @ 2012-11-05 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121259-5836-2-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On 11/05/2012 02:14 PM, Tomi Valkeinen wrote:
> From: Ricardo Neri <ricardo.neri@ti.com>
>
> Add the pinmux configuration for HDMI and TPD12S015A. Configure the
> gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
>
> Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap4-panda-a4.dts | 17 +++++++++++++++++
> arch/arm/boot/dts/omap4-panda.dts | 18 ++++++++++++++++++
> arch/arm/boot/dts/omap4-pandaES.dts | 9 +++++++++
I've just renamed that file omap4-panda-es.dts for consistency, so you'd
better rebase this series on top on my for_3.8/dts branch that I've just
sent to Tony.
Otherwise, this looks good to me.
Regards,
Benoit
> 3 files changed, 44 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap4-panda-a4.dts
>
> diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts b/arch/arm/boot/dts/omap4-panda-a4.dts
> new file mode 100644
> index 0000000..75466d2
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4-panda-a4.dts
> @@ -0,0 +1,17 @@
> +/*
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/include/ "omap4-panda.dts"
> +
> +/* Pandaboard Rev A4+ have external pullups on SCL & SDA */
> +&dss_hdmi_pins {
> + pinctrl-single,pins = <
> + 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
> + 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
> + 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
> + >;
> +};
> diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
> index e8f927c..8060f5b 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -65,6 +65,8 @@
> &twl6040_pins
> &mcpdm_pins
> &mcbsp1_pins
> + &dss_hdmi_pins
> + &tpd12s015_pins
> >;
>
> twl6040_pins: pinmux_twl6040_pins {
> @@ -92,6 +94,22 @@
> 0xc4 0x100 /* abe_mcbsp1_fsx.abe_mcbsp1_fsx INPUT | MODE0 */
> >;
> };
> +
> + dss_hdmi_pins: pinmux_dss_hdmi_pins {
> + pinctrl-single,pins = <
> + 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
> + 0x5c 0x118 /* hdmi_scl.hdmi_scl INPUT PULLUP | MODE 0 */
> + 0x5e 0x118 /* hdmi_sda.hdmi_sda INPUT PULLUP | MODE 0 */
> + >;
> + };
> +
> + tpd12s015_pins: pinmux_tpd12s015_pins {
> + pinctrl-single,pins = <
> + 0x22 0x3 /* gpmc_a17.gpio_41 OUTPUT | MODE3 */
> + 0x48 0x3 /* gpmc_nbe1.gpio_60 OUTPUT | MODE3 */
> + 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */
> + >;
> + };
> };
>
> &i2c1 {
> diff --git a/arch/arm/boot/dts/omap4-pandaES.dts b/arch/arm/boot/dts/omap4-pandaES.dts
> index d4ba43a..73bc1a6 100644
> --- a/arch/arm/boot/dts/omap4-pandaES.dts
> +++ b/arch/arm/boot/dts/omap4-pandaES.dts
> @@ -22,3 +22,12 @@
> "AFML", "Line In",
> "AFMR", "Line In";
> };
> +
> +/* PandaboardES has external pullups on SCL & SDA */
> +&dss_hdmi_pins {
> + pinctrl-single,pins = <
> + 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
> + 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
> + 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
> + >;
> +};
>
^ permalink raw reply
* [PATCH 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
From: Kevin Hilman @ 2012-11-05 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351859566-24818-16-git-send-email-vaibhav.bedia@ti.com>
+Santosh (to help with EMIF questions/comments)
On 11/02/2012 12:32 PM, Vaibhav Bedia wrote:
> AM335x supports various low power modes as documented
> in section 8.1.4.3 of the AM335x TRM which is available
> @ http://www.ti.com/litv/pdf/spruh73f
>
> DeepSleep0 mode offers the lowest power mode with limited
> wakeup sources without a system reboot and is mapped as
> the suspend state in the kernel. In this state, MPU and
> PER domains are turned off with the internal RAM held in
> retention to facilitate resume process. As part of the boot
> process, the assembly code is copied over to OCMCRAM using
> the OMAP SRAM code.
>
> AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU
> in DeepSleep0 entry and exit. WKUP_M3 takes care of the
> clockdomain and powerdomain transitions based on the
> intended low power state. MPU needs to load the appropriate
> WKUP_M3 binary onto the WKUP_M3 memory space before it can
> leverage any of the PM features like DeepSleep.
>
> The IPC mechanism between MPU and WKUP_M3 uses a mailbox
> sub-module and 8 IPC registers in the Control module. MPU
> uses the assigned Mailbox for issuing an interrupt to
> WKUP_M3 which then goes and checks the IPC registers for
> the payload. WKUP_M3 has the ability to trigger on interrupt
> to MPU by executing the "sev" instruction.
>
> In the current implementation when the suspend process
> is initiated MPU interrupts the WKUP_M3 to let about the
> intent of entering DeepSleep0 and waits for an ACK. When
> the ACK is received, MPU continues with its suspend process
> to suspend all the drivers and then jumps to assembly in
> OCMC RAM to put the PLLs in bypass, put the external RAM in
> self-refresh mode and then finally execute the WFI instruction.
> The WFI instruction triggers another interrupt to the WKUP_M3
> which then continues wiht the power down sequence wherein the
> clockdomain and powerdomain transition takes place. As part of
> the sleep sequence, WKUP_M3 unmasks the interrupt lines for
> the wakeup sources. When WKUP_M3 executes WFI, the hardware
> disables the main oscillator.
>
> When a wakeup event occurs, WKUP_M3 starts the power-up
> sequence by switching on the power domains and finally
> enabling the clock to MPU. Since the MPU gets powered down
> as part of the sleep sequence, in the resume path ROM code
> starts executing. The ROM code detects a wakeup from sleep
> and then jumps to the resume location in OCMC which was
> populated in one of the IPC registers as part of the suspend
> sequence.
>
> The low level code in OCMC relocks the PLLs, enables access
> to external RAM and then jumps to the cpu_resume code of
> the kernel to finish the resume process.
>
> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Very well summarized. Thanks for the thorough changelog.
First, some general comments. This is a big patch and probably should
be broken up a bit. I suspect it could be broken up a bit, maybe into
at least:
- EMIF interface
- SCM interface, new APIs
- assembly/OCM code
- pm33xx.[ch]
- lastly, the late_init stuff that actually initizlizes
I have a handful of comments below. I wrote this up on the plane over
the weekend, and I see that Santosh has already made some similar
comments, but I'll send mine anyways.
[...]
> +static int am33xx_pm_suspend(void)
> +{
> + int status, ret = 0;
> +
> + struct omap_hwmod *gpmc_oh, *usb_oh;
> + struct omap_hwmod *tptc0_oh, *tptc1_oh, *tptc2_oh;
> +
> + /*
> + * By default the following IPs do not have MSTANDBY asserted
> + * which is necessary for PER domain transition. If the drivers
> + * are not compiled into the kernel HWMOD code will not change the
> + * state of the IPs if the IP was not never enabled
> + */
> + usb_oh = omap_hwmod_lookup("usb_otg_hs");
> + gpmc_oh = omap_hwmod_lookup("gpmc");
> + tptc0_oh = omap_hwmod_lookup("tptc0");
> + tptc1_oh = omap_hwmod_lookup("tptc1");
> + tptc2_oh = omap_hwmod_lookup("tptc2");
> +
> + omap_hwmod_enable(usb_oh);
> + omap_hwmod_enable(gpmc_oh);
> + omap_hwmod_enable(tptc0_oh);
> + omap_hwmod_enable(tptc1_oh);
> + omap_hwmod_enable(tptc2_oh);
> +
> + omap_hwmod_idle(usb_oh);
> + omap_hwmod_idle(gpmc_oh);
> + omap_hwmod_idle(tptc0_oh);
> + omap_hwmod_idle(tptc1_oh);
> + omap_hwmod_idle(tptc2_oh);
Doing this on every suspend looks a bit strange. Why not just have some
init function handle these devices once at boot. If this is really
needed on every suspend, it needs some more description, and probably
some basic stub drivers need to be created.
Also, if there are drivers for these devices, won't this interfere?
> + /* Put the GFX clockdomains to sleep */
> + clkdm_sleep(gfx_l3_clkdm);
> + clkdm_sleep(gfx_l4ls_clkdm);
> +
> + /* Try to put GFX to sleep */
> + pwrdm_set_next_pwrst(gfx_pwrdm, PWRDM_POWER_OFF);
ditto.
[...]
> +static int am33xx_pm_begin(suspend_state_t state)
> +{
> + int ret = 0;
> +
> + disable_hlt();
> +
> + /*
> + * Physical resume address to be used by ROM code
> + */
> + wkup_m3->resume_addr = (AM33XX_OCMC_END - am33xx_do_wfi_sz +
> + am33xx_resume_offset + 0x4);
Why does this need to be calculated every suspend/resume?
> + wkup_m3->sleep_mode = IPC_CMD_DS0;
> + wkup_m3->ipc_data1 = DS_IPC_DEFAULT;
> + wkup_m3->ipc_data2 = DS_IPC_DEFAULT;
> +
> + am33xx_ipc_cmd();
This IPC needs a cleaner interface/API. Also, since it involves
register writes to the SCM, it should be defined in control.c. (NOTE:
we're in the process of creating a real driver out of the SCM, so all
SCM register accesses need to be contained in control.c)
For example, you probably want an am33xx_m3_* API in control.c, with
some pre-baked commands for the M3.
> + wkup_m3->state = M3_STATE_MSG_FOR_LP;
>
> + omap_mbox_enable_irq(wkup_m3->mbox, IRQ_RX);
> +
> + ret = omap_mbox_msg_send(wkup_m3->mbox, 0xABCDABCD);
> + if (ret) {
> + pr_err("A8<->CM3 MSG for LP failed\n");
> + am33xx_m3_state_machine_reset();
> + ret = -1;
> + }
> +
> + if (!wait_for_completion_timeout(&wkup_m3_sync,
> + msecs_to_jiffies(500))) {
hmm, interesting. I know you're not implementing idle here, but I'm
rather curious how this sync w/M3 is going to work for idle.
> + pr_err("A8<->CM3 sync failure\n");
> + am33xx_m3_state_machine_reset();
> + ret = -1;
> + } else {
> + pr_debug("Message sent for entering DeepSleep mode\n");
> + omap_mbox_disable_irq(wkup_m3->mbox, IRQ_RX);
> + }
> +
> + return ret;
> +}
> +
[...]
> +static void am33xx_m3_state_machine_reset(void)
> +{
> + int ret = 0;
> +
> + wkup_m3->resume_addr = 0x0;
> + wkup_m3->sleep_mode = IPC_CMD_RESET;
> + wkup_m3->ipc_data1 = DS_IPC_DEFAULT;
> + wkup_m3->ipc_data2 = DS_IPC_DEFAULT;
> +
> + am33xx_ipc_cmd();
> +
> + wkup_m3->state = M3_STATE_MSG_FOR_RESET;
> +
> + ret = omap_mbox_msg_send(wkup_m3->mbox, 0xABCDABCD);
magic constant needs a #define
> + if (!ret) {
> + pr_debug("Message sent for resetting M3 state machine\n");
> + if (!wait_for_completion_timeout(&wkup_m3_sync,
> + msecs_to_jiffies(500)))
> + pr_err("A8<->CM3 sync failure\n");
> + } else {
> + pr_err("Could not reset M3 state machine!!!\n");
> + wkup_m3->state = M3_STATE_UNKNOWN;
> + }
> +}
> +#endif /* CONFIG_SUSPEND */
> +
> +/*
> + * Dummy notifier for the mailbox
> + */
> +int wkup_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
> +{
> + return 0;
> +}
> +
> +static struct notifier_block wkup_mbox_notifier = {
> + .notifier_call = wkup_mbox_msg,
> +};
Why do you need a dummy notifier? Looks like maybe plat-omap/mailbox.c
needs a few minor fixes to support not being passed a notifier instead?
> +static irqreturn_t wkup_m3_txev_handler(int irq, void *unused)
> +{
> + omap_ctrl_writel(0x1, AM33XX_CONTROL_M3_TXEV_EOI);
undocumented magic write (but presumably an IRQ ack?)
Note this also needs to be moved to control.c and given a useful API.
> + switch (wkup_m3->state) {
> + case M3_STATE_RESET:
> + wkup_m3->state = M3_STATE_INITED;
> + break;
> + case M3_STATE_MSG_FOR_RESET:
> + wkup_m3->state = M3_STATE_INITED;
> + omap_mbox_msg_rx_flush(wkup_m3->mbox);
> + complete(&wkup_m3_sync);
> + break;
> + case M3_STATE_MSG_FOR_LP:
> + omap_mbox_msg_rx_flush(wkup_m3->mbox);
> + complete(&wkup_m3_sync);
> + break;
> + case M3_STATE_UNKNOWN:
> + pr_err("IRQ %d with WKUP_M3 in unknown state\n", irq);
> + omap_mbox_msg_rx_flush(wkup_m3->mbox);
> + return IRQ_NONE;
> + }
> +
> + omap_ctrl_writel(0x0, AM33XX_CONTROL_M3_TXEV_EOI);
undoumented magic write?
> + return IRQ_HANDLED;
> +}
> +
[...]
> +static int wkup_m3_init(void)
> +{
> + int irq, ret = 0;
> + struct resource *mem;
> + struct platform_device *pdev = to_platform_device(wkup_m3->dev);
> +
> + omap_device_enable_hwmods(to_omap_device(pdev));
> +
> + /* Reserve the MBOX for sending messages to M3 */
> + wkup_m3->mbox = omap_mbox_get("wkup_m3", &wkup_mbox_notifier);
> + if (IS_ERR(wkup_m3->mbox)) {
> + pr_err("Could not reserve mailbox for A8->M3 IPC\n");
> + ret = -ENODEV;
> + goto exit;
> + }
> +
> + irq = platform_get_irq(pdev, 0);
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!mem)
> + dev_err(wkup_m3->dev, "no memory resource\n");
if !mem, this continues and still tries to ioremap NULL.
> + wkup_m3->code = devm_request_and_ioremap(wkup_m3->dev, mem);
> + ret = devm_request_irq(wkup_m3->dev, irq, wkup_m3_txev_handler,
> + IRQF_DISABLED, "wkup_m3_txev", NULL);
> + if (ret) {
> + dev_err(wkup_m3->dev, "request_irq failed\n");
> + goto err;
> + }
> +
> + pr_info("Trying to load am335x-pm-firmware.bin");
> +
> + /* We don't want to delay boot */
> + request_firmware_nowait(THIS_MODULE, 0, "am335x-pm-firmware.bin",
> + wkup_m3->dev, GFP_KERNEL, wkup_m3,
> + am33xx_pm_firmware_cb);
> + return 0;
> +
> +err:
> + omap_mbox_put(wkup_m3->mbox, &wkup_mbox_notifier);
> +exit:
> + return ret;
> +}
> +
[...]
> +extern void __iomem *am33xx_get_emif_base(void);
> +int wkup_mbox_msg(struct notifier_block *self, unsigned long len, void *msg);
> +#endif
> +
> +#define IPC_CMD_DS0 0x3
> +#define IPC_CMD_RESET 0xe
> +#define DS_IPC_DEFAULT 0xffffffff
> +
> +#define IPC_RESP_SHIFT 16
> +#define IPC_RESP_MASK (0xffff << 16)
> +
> +#define M3_STATE_UNKNOWN 0
> +#define M3_STATE_RESET 1
> +#define M3_STATE_INITED 2
> +#define M3_STATE_MSG_FOR_LP 3
> +#define M3_STATE_MSG_FOR_RESET 4
> +
> +#define AM33XX_OCMC_END 0x40310000
> +#define AM33XX_EMIF_BASE 0x4C000000
> +
> +/*
> + * This a subset of registers defined in drivers/memory/emif.h
> + * Move that to include/linux/?
> + */
I'd probably suggest just moving the register definitions you
need into <plat/emif_plat.h> so they can be shared with the driver.
Also, the EMIF stuff would benefit greatly from using symbolic defines
for the values being written. Probably having those in
<plat/emif_plat.h> would also help out here.
Or, maybe the EMIF driver can provide some self-contained stubs that can
be copied to OCP RAM for the functionality needed here?
Santosh, what do you think of that?
Another user of the EMIF virtual addr is emif_self_refresh_dis, but I
don't see that code actually used anywhere.
Looking closer, now I see the ddr_self_refresh macro is using
emif_virt_addr (that macro should be fixed to take the base address, for
readability.)
On a related note, just a quick glance at all the code running out of
OCM RAM makes me wonder if any that could be done before jumping to OCM
RAM. Ideally, we only want the absolute minimum running out of OCM RAM.
[...]
> diff --git a/arch/arm/mach-omap2/sleep33xx.S b\arch/arm/mach-omap2/sleep33xx.S
> new file mode 100644
> index 0000000..f7b34e5
> --- /dev/null
> +++ b/arch/arm/mach-omap2/sleep33xx.S
> @@ -0,0 +1,571 @@
> +/*
> + * Low level suspend code for AM33XX SoCs
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + * Vaibhav Bedia <vaibhav.bedia@ti.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/linkage.h>
> +#include <asm/memory.h>
> +#include <asm/assembler.h>
> +
> +#include "cm33xx.h"
> +#include "pm33xx.h"
> +#include "prm33xx.h"
> +#include "control.h"
> +
> +/* replicated define because linux/bitops.h cannot be included in assembly */
> +#define BIT(nr) (1 << (nr))
never used, just remove it. Using shifts as below is fine (but using
symbolic constants would be even better.)
In fact, there are lots of magic constants in this code that I'd like
to see #defined.
[...]
> + wfi
> + nop
> + nop
> + nop
> + nop
> + nop
> + nop
> + nop
> + nop
> + nop
> + nop
> + nop
> + nop
> + nop
Why all the nops? Some comments would be helpful there.
[...]
> +/* Values recommended by the HW team */
A little documentation of these values would be helpful here.
> +susp_io_pull_data:.
> + .word 0x3FF00003
> +susp_io_pull_cmd1:
> + .word 0xFFE0018B
> +susp_io_pull_cmd2:
> + .word 0xFFA0098B
> +resume_io_pull_data:
> + .word 0x18B
> +resume_io_pull_cmd:
> + .word 0x18B
> +susp_vtp_ctrl_val:
> + .word 0x10117
Kevin
^ permalink raw reply
* [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
From: Colin FoeParker @ 2012-11-05 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097ECAD.9010101@ti.com>
Hi Benoit,
"I don't know how it is connected at board level, but I'm not sure the binding is the proper one."
Here is a link to the Beaglebone schematic<http://beagleboard.org/static/beaglebone/latest/Docs/Hardware/BONE_SCH.pdf>. The PMIC_PWR_EN net is the one that you should be interested in following.
In the AM335x, this net is connected to the ALARM2 event in the RTC subsystem. If the ALARM2 event is triggered, and the PMIC_PWR_EN pin is configured correctly, the pin is driven low.
In the TPS65217 series PMIC, the PWR_EN I/O can be used to put the entire chip into a low power state. This disables all the power rails in the PMIC with an exception of the rail that powers the RTC power domain.
So when the ALARM2 event occurs, the PWR_EN I/O is pulled low and the entire system into a low power "off" state.
"It does not look super generic, and I'm wondering if we should not use instead some regulator binding to reflect the connection of the RTC to a regulator.
But without the board / soc spec it is hard to tell :-("
This is a good point. I know that there are other omap SOC RTC's that do not support the ALARM2 implementation. That being said, I would argue that there is more of a RTC connection with the implementation than a regulator.
Anil will probably have greater insight into the pro's/con's of the implementation.
-Colin
Colin Foe-Parker // Software Engineer II
Logic PD /// engineering design services
5 Clock Tower Place. Suite 400
Maynard, MA 01754
T // 978.243.2045
colin.foeparker at logicpd.com
www.logicpd.com
/ / / / / / / / / / / / / / / / / / / / / / / / /
This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, distribution, or other use of this message, or the taking of any action based on it, is strictly prohibited.
-----Original Message-----
From: Benoit Cousson [mailto:b-cousson at ti.com]
Sent: Monday, November 05, 2012 11:43 AM
To: AnilKumar Ch; Colin FoeParker
Cc: a.zummo at towertech.it; sameo at linux.intel.com; tony at atomide.com; grant.likely at secretlab.ca; rob.herring at calxeda.com; rtc-linux at googlegroups.com; linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; devicetree-discuss at lists.ozlabs.org
Subject: Re: [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
Hi Anil / Colin,
On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
> From: Colin Foe-Parker <colin.foeparker@logicpd.com>
>
> Add system power off control to rtc driver which is the in-charge of
> controlling the BeagleBone system power. The power_off routine can be
> hooked up to "pm_power_off" system call.
>
> System power off sequence:-
> * Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
> * Enable PMIC_POWER_EN in rtc module
> * Set rtc ALARM2 time
> * Enable ALARM2 interrupt
>
> Added while (1); after the above steps to make sure that no other
> process acquire cpu. Otherwise we might see an unexpected behaviour
> because we are shutting down all the power rails of SoC except RTC.
>
> Signed-off-by: Colin Foe-Parker <colin.foeparker at logicpd.com<mailto:colin.foeparker@logicpd.com>>
> [anilkumar at ti.com: move poweroff additions to rtc driver]
> Signed-off-by: AnilKumar Ch <anilkumar at ti.com<mailto:anilkumar@ti.com>>
> ---
> Documentation/devicetree/bindings/rtc/rtc-omap.txt | 5 ++
> drivers/rtc/rtc-omap.c | 79 +++++++++++++++++++-
> 2 files changed, 83 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> index b47aa41..8d9f4f9 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> @@ -6,6 +6,10 @@ Required properties:
> - interrupts: rtc timer, alarm interrupts in order
> - interrupt-parent: phandle for the interrupt controller
>
> +Optional properties:
> +- ti,system-power-controller: Telling whether or not rtc is
> +controlling
> + the system power.
I don't know how it is connected at board level, but I'm not sure the binding is the proper one.
It does not look super generic, and I'm wondering if we should not use instead some regulator binding to reflect the connection of the RTC to a regulator.
But without the board / soc spec it is hard to tell :-(
Regards,
Benoit
> +
> Example:
>
> rtc at 1c23000 {
> @@ -14,4 +18,5 @@ rtc at 1c23000 {
> interrupts = <19
> 19>;
> interrupt-parent = <&intc>;
> + ti,system-power-controller;
> };
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index
> 6009714..2d90170 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -72,6 +72,14 @@
> #define OMAP_RTC_KICK0_REG 0x6c
> #define OMAP_RTC_KICK1_REG 0x70
>
> +#define OMAP_RTC_ALARM2_SECONDS_REG 0x80
> +#define OMAP_RTC_ALARM2_MINUTES_REG 0x84
> +#define OMAP_RTC_ALARM2_HOURS_REG 0x88
> +#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
> +#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
> +#define OMAP_RTC_ALARM2_YEARS_REG 0x94
> +#define OMAP_RTC_PMIC_REG 0x98
> +
> /* OMAP_RTC_CTRL_REG bit fields: */
> #define OMAP_RTC_CTRL_SPLIT (1<<7)
> #define OMAP_RTC_CTRL_DISABLE (1<<6)
> @@ -93,15 +101,24 @@
> #define OMAP_RTC_STATUS_BUSY (1<<0)
>
> /* OMAP_RTC_INTERRUPTS_REG bit fields: */
> +#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (1<<4)
> #define OMAP_RTC_INTERRUPTS_IT_ALARM (1<<3)
> #define OMAP_RTC_INTERRUPTS_IT_TIMER (1<<2)
>
> +/* OMAP_RTC_PMIC_REG bit fields: */
> +#define OMAP_RTC_PMIC_POWER_EN_EN (1<<16)
> +
> /* OMAP_RTC_KICKER values */
> #define KICK0_VALUE 0x83e70b13
> #define KICK1_VALUE 0x95a4f1e0
>
> #define OMAP_RTC_HAS_KICKER 0x1
>
> +#define SHUTDOWN_TIME_SEC 2
> +#define SECS_IN_MIN 60
> +#define WAIT_AFTER (SECS_IN_MIN - SHUTDOWN_TIME_SEC)
> +#define WAIT_TIME_MS (SHUTDOWN_TIME_SEC * 1000)
> +
> static void __iomem *rtc_base;
>
> #define rtc_read(addr) readb(rtc_base + (addr))
> @@ -290,6 +307,58 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
> return 0;
> }
>
> +/*
> + * rtc_power_off: Set the pmic power off sequence. The RTC generates
> + * pmic_pwr_enable control, which can be used to control an external
> + * PMIC.
> + */
> +static void rtc_power_off(void)
> +{
> + u32 val;
> + struct rtc_time tm;
> + spinlock_t lock;
> + unsigned long flags;
> +
> + spin_lock_init(&lock);
> +
> + /* Set PMIC power enable */
> + val = readl(rtc_base + OMAP_RTC_PMIC_REG);
> + writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base +
> +OMAP_RTC_PMIC_REG);
> +
> + /* Wait few seconds instead of rollover */
> + do {
> + omap_rtc_read_time(NULL, &tm);
> + if (WAIT_AFTER <= tm.tm_sec)
> + mdelay(WAIT_TIME_MS);
> + } while (WAIT_AFTER <= tm.tm_sec);
> +
> + /* Add shutdown time to the current value */
> + tm.tm_sec += SHUTDOWN_TIME_SEC;
> +
> + if (tm2bcd(&tm) < 0)
> + return;
> +
> + pr_info("System will go to power_off state in approx. %d secs\n",
> + SHUTDOWN_TIME_SEC);
> +
> + /* Set the ALARM2 time */
> + rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
> + rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
> + rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
> + rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
> + rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
> + rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
> +
> + /* Enable alarm2 interrupt */
> + val = readl(rtc_base + OMAP_RTC_INTERRUPTS_REG);
> + writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
> + rtc_base + OMAP_RTC_INTERRUPTS_REG);
> +
> + /* Do not allow to execute any other task */
> + spin_lock_irqsave(&lock, flags);
> + while (1);
> +}
> +
> static struct rtc_class_ops omap_rtc_ops = {
> .read_time = omap_rtc_read_time,
> .set_time = omap_rtc_set_time,
> @@ -327,12 +396,16 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
> struct resource *res, *mem;
> struct rtc_device *rtc;
> u8 reg, new_ctrl;
> + bool pm_off = false;
> const struct platform_device_id *id_entry;
> const struct of_device_id *of_id;
>
> of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
> - if (of_id)
> + if (of_id) {
> pdev->id_entry = of_id->data;
> + pm_off = of_property_read_bool(pdev->dev.of_node,
> + "ti,system-power-controller");
> + }
>
> omap_rtc_timer = platform_get_irq(pdev, 0);
> if (omap_rtc_timer <= 0) {
> @@ -385,6 +458,10 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, rtc);
> dev_set_drvdata(&rtc->dev, mem);
>
> + /* RTC power off */
> + if (pm_off && !pm_power_off)
> + pm_power_off = rtc_power_off;
> +
> /* clear pending irqs, and set 1/second periodic,
> * which we'll use instead of update irqs
> */
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121105/fc8fde6e/attachment-0001.html>
^ permalink raw reply
* [PATCH V4 REPOST] ARM: implement debug_ll_io_init()
From: Olof Johansson @ 2012-11-05 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351718515-871-1-git-send-email-swarren@wwwdotorg.org>
On Wed, Oct 31, 2012 at 10:21 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> Arnd, Olof, could this patch be placed into a standalone topic branch in
> arm-soc branch; I'd like to make use of this patch for both Tegra and
> bcm2835 this cycle, and perhaps others might too. Thanks.
Done, applied to single-patch branch devel/debug_ll_init. I'll bring
that in at next/multiplatform as well.
-Olof
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Will Deacon @ 2012-11-05 17:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi guys,
I was playing around with !CONFIG_MMU today and to my dismay noticed that
you can't select ARCH_VEXPRESS without CONFIG_MMU=y! This is because
ARCH_VEXPRESS is only selectable via ARCH_MULTI_V7, which depends on
ARCH_MULTIPLATFORM which in turn depends on MMU.
I'm inclined to add a dummy VEXPRESS entry to arm/Kconfig which depends on
!ARCH_MULTIPLATFORM and just selects ARCH_VEXPRESS (with the if ARCH_MULTI_V7
dependency dropped) but I wondered if you'd got any better ideas?
Cheers,
Will
^ permalink raw reply
* [PATCH] ARM: Fix the "WFI" instruction opcode definition.
From: Dave Martin @ 2012-11-05 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKw8HL0ymmNRB=jgGcZn1+6k0s=FKA+qBV04y_wfeu7xMpUpkw@mail.gmail.com>
On Thu, Nov 01, 2012 at 09:40:10PM +0800, Fei Yang wrote:
> 2012/11/1 Rob Herring <robherring2@gmail.com>:
> > On 10/31/2012 08:24 PM, Yangfei (Felix) wrote:
> >> The current "WFI" opcode definiton causes CPU hot-plug feature fails to
> >> work
> >> if the kernel is built with CONFIG_THUMB2_KERNEL/CONFIG_CPU_ENDIAN_BE8
> >> being
> >> defined. An invalid instruction exception will be generated.
> >>
> >> Signed-off-by: yangfei.kernel at gmail.com
> >> ---
> >> arch/arm/mach-exynos/hotplug.c | 8 +++++++-
> >> arch/arm/mach-realview/hotplug.c | 8 +++++++-
> >> arch/arm/mach-shmobile/hotplug.c | 8 +++++++-
> >> 3 files changed, 21 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-exynos/hotplug.c
> >> b/arch/arm/mach-exynos/hotplug.c
> >> index f4d7dd2..823a0e4 100644
> >> --- a/arch/arm/mach-exynos/hotplug.c
> >> +++ b/arch/arm/mach-exynos/hotplug.c
> >> @@ -18,11 +18,17 @@
> >> #include <asm/cacheflush.h>
> >> #include <asm/cp15.h>
> >> #include <asm/smp_plat.h>
> >> +#include <asm/opcodes.h>
> >>
> >> #include <mach/regs-pmu.h>
> >>
> >> #include "common.h"
> >>
> >> +/*
> >> + * Define opcode of the WFI instruction.
> >> + */
> >> +#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
> >> +
> >> static inline void cpu_enter_lowpower(void)
> >> {
> >> unsigned int v;
> >> @@ -72,7 +78,7 @@ static inline void platform_do_lowpower(unsigned int
> >> cpu, int *spurious)
> >> /*
> >> * here's the WFI
> >> */
> >> - asm(".word 0xe320f003\n"
> >> + asm(__WFI
> >
> > Wouldn't using the actual wfi instruction fix this. There is a wfi()
> > macro.
> >
> > Or just call cpu_do_idle() which will do any other things needed before
> > wfi like a dsb instruction.
> >
> > Rob
> >> :
> >> :
> >> : "memory", "cc");
>
> <Cut>
>
> Hi Rob,
> Thanks for the reply. The way you suggested is more elegant. But
> here we worried about the version of the compiler toolchain used to
> build the kernel. The "WFI" assembler instruction may not be
> recognized if the toolchain is too old. Need the related ARM board
> maintainers to confirm this.
Maybe all the exynos platforms are new enough for this not to be a
problem?
I think mach-exynos is pretty new and v7-only anyway. If so, then it
may be better to put
CFLAGS_hotplug.o := -march=armv7-a
in arch/arm/mach-exynos/Makefile, and use the real "wfi" mnemonic
directly. People should _really_ not be building kernels containig
v7 board support with tools that are too old to support this.
Cheers
---Dave
^ permalink raw reply
* [PATCH] lpc32xx: irq - Set the chain handlers after setting up the IRQ domain
From: Roland Stigge @ 2012-11-05 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105180053.20090a3e@avionic-0020.adnet.avionic-design.de>
Hi!
On 05/11/12 18:00, Alban Bedel wrote:
>> I already posted basically the same change on 2012-10-28 already which
>> is part of my patch set for LPC32xx to be merged into arm-soc.git (will
>> do a pull request later). Fixing another irq bug in this platform/irq also.
>
> I checked arm-soc.git, linux-next.git, linux-arm-kernel@ and
> linux-kernel@, is there any other place I should check before
> submitting LPC32xx patches?
I usually prepare lpc32xx branches for merging into arm-soc.git at
git.antcom.de. Expect the posted patches there and a pull request during
the next days.
Thanks,
Roland
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Vasily Khoruzhick @ 2012-11-05 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVfi8Ko4SDDi92jRLjQ4bKtqHkhq4N7QtbiU1k7bPbWjig@mail.gmail.com>
On Sat, Nov 3, 2012 at 12:29 AM, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>>
>> I prefer to use pinctrl-single driver instead. I'm updating mmp
>> pinctrol driver to
>> pinctrl-single driver framework. You can find them in mailist. I'm submitting
>> a third round in these days.
>>
>> Regards
>> Haojian
>
> OK, one more question:
>
> On PXA2xx GPIO and PINMUX are not separate blocks. Each pin can be
> either input or output and have 4 modes (gpio + 3 alternate functions)
> == 8 states , so we have: gpio in, gpio out, 3 alt in, 3 alt out.
> To control pin mode one should write to GPDR (direction register) and
> GAFR (alternate function register). pxa-gpio driver controls both of
> those registers, so does pxa2xx-mfp.
>
> I'm not sure what to do in this case. Should I move code controlling
> GPDR and GAFR into some pinctrl-pxa2xx driver, and modify pxa-gpio
> driver to use it?
>
> Regards
> Vasily
Daniel, Haojian, any suggestion?
I'm stuck at the moment, and have no idea how to handle it...
pinmux/gpio are connected in hardware
and I don't see a way to handle them with 2 separate drivers (gpio and
pinmux) in software...
Regards
Vasily
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Dave Martin @ 2012-11-05 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211051111150.21033@xanadu.home>
On Mon, Nov 05, 2012 at 11:13:51AM -0500, Nicolas Pitre wrote:
> On Mon, 5 Nov 2012, Russell King - ARM Linux wrote:
>
> > On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
> > > Why not allow unaligned accesses in the decompressor, though, both
> > > for v6 and v7?
> >
> > EXACTLY.
>
> I have no objections to that. In fact, I made a remark to this effect
> in my initial review of this patch. Whether or not gcc does take
> advantage of this hardware ability in the end is orthogonal.
For the sake of argument, here's how it might look.
Currently, I make no attempt to restore the original state of the U bit.
The A bit if forced later by the kernel during boot, after a short window
during which we should only run low-level arch code and therefore where
no unaligned accesses should happen.
Does anyone think these issues are likely to be important?
Cheers
---Dave
>From 160a5576b53264951ff8164775146b2d4feddecb Mon Sep 17 00:00:00 2001
From: Dave Martin <dave.martin@linaro.org>
Date: Mon, 5 Nov 2012 16:34:57 +0000
Subject: [PATCH] ARM: decompressor: Enable unaligned memory access for v6 and above
Modern GCC can generate code which makes use of the CPU's native
unaligned memory access capabilities. This is useful for the C
decompressor implementations used for unpacking compressed kernels.
This patch disables the alignment faults and enabled the v6
unaligned access on CPUs which support these features (i.e., v6 and
later), allowing full unaligned access support for C code in the
decompressor.
The decompressor C code must not be built to assume that unaligned
access works if support for v5 or older platforms is included in
the kernel.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
Note: I have only build-tested this so far.
arch/arm/boot/compressed/head.S | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 90275f0..cfbb4c9 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -652,6 +652,15 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size
mov pc, lr
ENDPROC(__setup_mmu)
+@ Enable unaligned access on v6, to allow better code generation
+@ for the decompressor C code:
+__armv6_mmu_cache_on:
+ mrc p15, 0, r0, c1, c0, 0 @ read SCTLR
+ bic r0, r0, #2 @ A (no unaligned access fault)
+ orr r0, r0, #1 << 22 @ U (v6 unaligned access model)
+ mcr p15, 0, r0, c1, c0, 0 @ write SCTLR
+ b __armv4_mmu_cache_on
+
__arm926ejs_mmu_cache_on:
#ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
mov r0, #4 @ put dcache in WT mode
@@ -694,6 +703,7 @@ __armv7_mmu_cache_on:
bic r0, r0, #1 << 28 @ clear SCTLR.TRE
orr r0, r0, #0x5000 @ I-cache enable, RR cache replacement
orr r0, r0, #0x003c @ write buffer
+ bic r0, r0, #2 @ A (no unaligned access fault)
#ifdef CONFIG_MMU
#ifdef CONFIG_CPU_ENDIAN_BE8
orr r0, r0, #1 << 25 @ big-endian page tables
@@ -914,7 +924,7 @@ proc_types:
.word 0x0007b000 @ ARMv6
.word 0x000ff000
- W(b) __armv4_mmu_cache_on
+ W(b) __armv6_mmu_cache_on
W(b) __armv4_mmu_cache_off
W(b) __armv6_mmu_cache_flush
--
1.7.4.1
^ permalink raw reply related
* [PATCH] clocksource: arm_generic: use integer math helpers
From: Catalin Marinas @ 2012-11-05 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351520658-23028-1-git-send-email-linus.walleij@linaro.org>
On Mon, Oct 29, 2012 at 02:24:18PM +0000, Linus Walleij wrote:
> This will make the two crucial integer divisions in the generic
> ARM arch timer used for ARMv8 use the kernel DIV_ROUND_CLOSEST()
> helper inline from <linux/kernel.h> so they get more precise.
>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
BTW, would this go through John's tree? I'm happy to push it as well.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCHv3 8/8] i2c: omap: cleanup the sysc write
From: Cousson, Benoit @ 2012-11-05 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105142517.GG4815@arwen.pp.htv.fi>
On 11/5/2012 3:25 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Nov 05, 2012 at 07:53:45PM +0530, Shubhrajyoti wrote:
>> On Monday 05 November 2012 07:44 PM, Felipe Balbi wrote:
>>>> - dev->syscstate);
>>>>> - }
>>> not sure if this will work. What about the first time you call reset() ?
>>> won't SYSC just contain the reset values ?
>> No actually the hwmod sets the value.
>
> ahaaa, ok good. Let's get an Ack from Benoit, then.
Well, in fact, I'm a little bit surprised that we still have to hack the
SYSC directly without using an omap_device API. I know that we have to
do some weird stuff for reseting that IP, but didn't we already exposed
something to allow that?
Regards,
Benoit
^ permalink raw reply
* vexpress issues in next-20121029
From: Pawel Moll @ 2012-11-05 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211051647.19785.arnd@arndb.de>
On Mon, 2012-11-05 at 16:47 +0000, Arnd Bergmann wrote:
> I've just tried pulling in your branch again, but it appears unchanged:
> The patches are still based on 807e45b328, which is a different commit
> from bcd6f569e874 that is in Mike's tree. Please do as I asked you before
> and rebase on top of the commit that you sent him,
Ok, I think I got the idea now. Sorry about not catching up straight
away...
The following changes since commit bcd6f569e87471d7f104bd9497f0b516a3b12e32:
clk: Common clocks implementation for Versatile Express (2012-10-29 11:08:03 -0700)
are available in the git repository at:
git://git.linaro.org/people/pawelmoll/linux.git vexpress-clk-soc
for you to fetch changes up to 433683a66401adb0150792e725cc4f631c94de46:
ARM: vexpress: Remove motherboard dependencies in the DTS files (2012-11-05 17:09:52 +0000)
> and make sure that this is a commit that Mike never rebases.
Uh. Mike, is your clk-next subject to rebases?
Pawe?
^ permalink raw reply
* [PATCH for soc] socfpga: map uart into virtual address space so that early_printk() works
From: Olof Johansson @ 2012-11-05 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121103112614.GA27365@elf.ucw.cz>
On Sat, Nov 03, 2012 at 12:26:14PM +0100, Pavel Machek wrote:
> Hi!
>
> > Early printk code needs UART to be mapped early during
> > boot. early_printk() is left there during the start-up; it is useful
> > as our emulators are fairly slow.
> >
> > Signed-off-by: Pavel Machek <pavel@denx.de>
> > Acked-by: Dinh Nguyen <dinguyen@altera.com>
>
> Could we get this one applied? No comments for quite a while... and it
> is needed for machine not to crash with early_printk used...
> Pavel
Sorry, we've been delayed on applying patches due to Linaro Connect and travel.
I've applied this now with a minor edit to remove the extra added lines before
the struct.
Regards,
-Olof
^ permalink raw reply
* [PATCH] lpc32xx: irq - Set the chain handlers after setting up the IRQ domain
From: Alban Bedel @ 2012-11-05 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50938BFD.1000402@antcom.de>
On Fri, 02 Nov 2012 10:01:49 +0100
Roland Stigge <stigge@antcom.de> wrote:
> Thanks for your patch!
>
> I already posted basically the same change on 2012-10-28 already which
> is part of my patch set for LPC32xx to be merged into arm-soc.git (will
> do a pull request later). Fixing another irq bug in this platform/irq also.
I checked arm-soc.git, linux-next.git, linux-arm-kernel@ and
linux-kernel@, is there any other place I should check before
submitting LPC32xx patches?
> Please also note that panic() doesn't return, so I won't include the
> respective new return that you added.
OK
Alban
^ permalink raw reply
* [PATCH 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
From: Benoit Cousson @ 2012-11-05 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352108549-9341-2-git-send-email-anilkumar@ti.com>
+ Mark
On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
> From: Colin Foe-Parker <colin.foeparker@logicpd.com>
>
> Set tps65217 PMIC status to OFF if power enable toggle is
> supported. Also adds platform data flag, which should be
> passed from board init data.
>
> Signed-off-by: Colin Foe-Parker <colin.foeparker@logicpd.com>
> [anilkumar at ti.com: move the additions to tps65217 MFD driver]
> Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
> ---
> .../devicetree/bindings/regulator/tps65217.txt | 4 ++++
> drivers/mfd/tps65217.c | 12 ++++++++++++
> 2 files changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt b/Documentation/devicetree/bindings/regulator/tps65217.txt
> index d316fb8..4f05d20 100644
> --- a/Documentation/devicetree/bindings/regulator/tps65217.txt
> +++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
> @@ -11,6 +11,9 @@ Required properties:
> using the standard binding for regulators found at
> Documentation/devicetree/bindings/regulator/regulator.txt.
>
> +Optional properties:
> +- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
That sounds like a generic functionality to me. Don't we have some more
generic way to handle that?
If not, that should probably not be a TI only attribute.
It looks like a GPIO like kind of interface at PMIC level.
Regards,
Benoit
> +
> The valid names for regulators are:
> tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
>
> @@ -20,6 +23,7 @@ Example:
>
> tps: tps at 24 {
> compatible = "ti,tps65217";
> + ti,pmic-shutdown-controller;
>
> regulators {
> dcdc1_reg: dcdc1 {
> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index 3fb32e6..c7f17d8 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -160,6 +160,7 @@ static int __devinit tps65217_probe(struct i2c_client *client,
> unsigned int version;
> unsigned int chip_id = ids->driver_data;
> const struct of_device_id *match;
> + bool status_off = false;
> int ret;
>
> if (client->dev.of_node) {
> @@ -170,6 +171,8 @@ static int __devinit tps65217_probe(struct i2c_client *client,
> return -EINVAL;
> }
> chip_id = (unsigned int)match->data;
> + status_off = of_property_read_bool(client->dev.of_node,
> + "ti,pmic-shutdown-controller");
> }
>
> if (!chip_id) {
> @@ -207,6 +210,15 @@ static int __devinit tps65217_probe(struct i2c_client *client,
> return ret;
> }
>
> + /* Set the PMIC to shutdown on PWR_EN toggle */
> + if (status_off) {
> + ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
> + TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
> + TPS65217_PROTECT_NONE);
> + if (ret)
> + dev_warn(tps->dev, "unable to set the status OFF\n");
> + }
> +
> dev_info(tps->dev, "TPS65217 ID %#x version 1.%d\n",
> (version & TPS65217_CHIPID_CHIP_MASK) >> 4,
> version & TPS65217_CHIPID_REV_MASK);
>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Mark Jackson @ 2012-11-05 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB563F8@DBDE01.ent.ti.com>
On 31/10/12 13:57, Hiremath, Vaibhav wrote:
> On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote:
>> On 30/10/12 14:48, Vaibhav Hiremath wrote:
>>
>> Okay, so I'm now coming up against a brick wall regarding U-Boot.
>>
>> The Kernel boots fine (as per the tree + patch above) provided I build U-Boot using the
>> v2011.09_AM335xPSP_04.06.00.06 branch from git://arago-project.org/git/projects/u-boot-am33x.git
>>
>> If I try the latest mainline U-Boot (or the TI branch), I just get to "Starting kernel ..." and then
>> hangs.
>>
>> I'm going to raise this query on the U-Boot ML, but can you let me know which U-Boot image you're
>> using ?
>>
>
>
> I am using Mainline u-boot and it works for me. Can you paste u-boot boot
> log and environment variable here?
>
> Thanks,
> Vaibhav
So I've now spent several days trying to fix this problem, but still no joy.
Did my previous emails give any clue as to where I'm going wrong ?
Thanks for any help you can provide.
Mark J.
^ permalink raw reply
* [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
From: Joel A Fernandes @ 2012-11-05 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105081317.GC28886@opensource.wolfsonmicro.com>
Hi Mark,
On Mon, Nov 5, 2012 at 3:13 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Nov 03, 2012 at 02:32:59PM -0500, Joel A Fernandes wrote:
>
>> beaglebone_defconfig: Add dummy regulator to init tlv320aic3x
>> https://github.com/joelagnel/linux-kernel/commit/db5672dfe548d82625cf40ed688d05ba7cee5c93
>
> This should never be done in production, you should ensure that the
> appropriate supplies are provided by the board file or device tree.
Sure I just did this for debugging purpose,
Thanks,
Joel
^ permalink raw reply
* vexpress issues in next-20121029
From: Arnd Bergmann @ 2012-11-05 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352126598.10947.13.camel@hornet>
On Monday 05 November 2012, Pawel Moll wrote:
> On Mon, 2012-11-05 at 09:45 +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 05, 2012 at 09:35:32AM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Oct 30, 2012 at 04:16:59PM +0000, Pawel Moll wrote:
> > > > There was a glitch between clk-next and arm-soc - it should be fine
> > > > starting with next-20121030.
> > >
> > > The problem is still there - my builds of my tree plus arm-soc are
> > > continuing to fail with:
> > >
> > > arch/arm/mach-vexpress/built-in.o: In function `v2m_timer_init':
> > > reset.c:(.init.text+0xe0): undefined reference to `vexpress_clk_init'
> > > arch/arm/mach-vexpress/built-in.o: In function `v2m_dt_timer_init':
> > > reset.c:(.init.text+0x114): undefined reference to `vexpress_clk_of_init'
> > >
> > > My guess is you have a dependency between the clk-next tree and arm-soc
> > > which you haven't told the arm-soc people about.
> >
> > Oh, and the above seems to affect all my kautobuilds for any ARM Ltd
> > development platform - it's not just vexpress which is affected by this
> > anymore.
>
> I've just successfully built defconfigs for vexpress, versatile and
> realview with next-20121105 so I guess Arnd simply didn't have time last
> week (the Connect event) to sort out the arm-soc tree...
>
> Arnd, will you pull the vexpress-clk-soc (containing, as you suggested,
> the soc stuff rebased on top of the clk branch) or do you want me to do
> something else?
Sorry for not getting back to this earlier. It was indeed a very busy
week and I did not manage to pull in any branches.
I've just tried pulling in your branch again, but it appears unchanged:
The patches are still based on 807e45b328, which is a different commit
from bcd6f569e874 that is in Mike's tree. Please do as I asked you before
and rebase on top of the commit that you sent him, and make sure that
this is a commit that Mike never rebases.
Arnd
^ permalink raw reply
* [PATCH linux-next] ARM64: dma-mapping: support debug_dma_mapping_error
From: Catalin Marinas @ 2012-11-05 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351871933.2721.10.camel@lorien2>
On Fri, Nov 02, 2012 at 03:58:53PM +0000, Shuah Khan wrote:
> On Fri, 2012-10-26 at 09:23 -0600, Shuah Khan wrote:
> > Add support for debug_dma_mapping_error() call to avoid warning from
> > debug_dma_unmap() interface when it checks for mapping error checked
> > status. Without this patch, device driver failed to check map error
> > warning is generated.
> >
> > Signed-off-by: Shuah Khan <shuah.khan@hp.com>
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> Do you want this patch going through linux-next or the ARM64 tree? Let
> me know your preference.
I think it can go together with your other patches since I can't tell
when you'll push the debug_dma_mapping_error() implementation.
--
Catalin
^ permalink raw reply
* [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
From: Benoit Cousson @ 2012-11-05 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352108549-9341-3-git-send-email-anilkumar@ti.com>
Hi Anil / Colin,
On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
> From: Colin Foe-Parker <colin.foeparker@logicpd.com>
>
> Add system power off control to rtc driver which is the in-charge
> of controlling the BeagleBone system power. The power_off routine
> can be hooked up to "pm_power_off" system call.
>
> System power off sequence:-
> * Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
> * Enable PMIC_POWER_EN in rtc module
> * Set rtc ALARM2 time
> * Enable ALARM2 interrupt
>
> Added while (1); after the above steps to make sure that no other
> process acquire cpu. Otherwise we might see an unexpected behaviour
> because we are shutting down all the power rails of SoC except RTC.
>
> Signed-off-by: Colin Foe-Parker <colin.foeparker@logicpd.com>
> [anilkumar at ti.com: move poweroff additions to rtc driver]
> Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
> ---
> Documentation/devicetree/bindings/rtc/rtc-omap.txt | 5 ++
> drivers/rtc/rtc-omap.c | 79 +++++++++++++++++++-
> 2 files changed, 83 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> index b47aa41..8d9f4f9 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> @@ -6,6 +6,10 @@ Required properties:
> - interrupts: rtc timer, alarm interrupts in order
> - interrupt-parent: phandle for the interrupt controller
>
> +Optional properties:
> +- ti,system-power-controller: Telling whether or not rtc is controlling
> + the system power.
I don't know how it is connected at board level, but I'm not sure the
binding is the proper one.
It does not look super generic, and I'm wondering if we should not use
instead some regulator binding to reflect the connection of the RTC to a
regulator.
But without the board / soc spec it is hard to tell :-(
Regards,
Benoit
> +
> Example:
>
> rtc at 1c23000 {
> @@ -14,4 +18,5 @@ rtc at 1c23000 {
> interrupts = <19
> 19>;
> interrupt-parent = <&intc>;
> + ti,system-power-controller;
> };
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 6009714..2d90170 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -72,6 +72,14 @@
> #define OMAP_RTC_KICK0_REG 0x6c
> #define OMAP_RTC_KICK1_REG 0x70
>
> +#define OMAP_RTC_ALARM2_SECONDS_REG 0x80
> +#define OMAP_RTC_ALARM2_MINUTES_REG 0x84
> +#define OMAP_RTC_ALARM2_HOURS_REG 0x88
> +#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
> +#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
> +#define OMAP_RTC_ALARM2_YEARS_REG 0x94
> +#define OMAP_RTC_PMIC_REG 0x98
> +
> /* OMAP_RTC_CTRL_REG bit fields: */
> #define OMAP_RTC_CTRL_SPLIT (1<<7)
> #define OMAP_RTC_CTRL_DISABLE (1<<6)
> @@ -93,15 +101,24 @@
> #define OMAP_RTC_STATUS_BUSY (1<<0)
>
> /* OMAP_RTC_INTERRUPTS_REG bit fields: */
> +#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (1<<4)
> #define OMAP_RTC_INTERRUPTS_IT_ALARM (1<<3)
> #define OMAP_RTC_INTERRUPTS_IT_TIMER (1<<2)
>
> +/* OMAP_RTC_PMIC_REG bit fields: */
> +#define OMAP_RTC_PMIC_POWER_EN_EN (1<<16)
> +
> /* OMAP_RTC_KICKER values */
> #define KICK0_VALUE 0x83e70b13
> #define KICK1_VALUE 0x95a4f1e0
>
> #define OMAP_RTC_HAS_KICKER 0x1
>
> +#define SHUTDOWN_TIME_SEC 2
> +#define SECS_IN_MIN 60
> +#define WAIT_AFTER (SECS_IN_MIN - SHUTDOWN_TIME_SEC)
> +#define WAIT_TIME_MS (SHUTDOWN_TIME_SEC * 1000)
> +
> static void __iomem *rtc_base;
>
> #define rtc_read(addr) readb(rtc_base + (addr))
> @@ -290,6 +307,58 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
> return 0;
> }
>
> +/*
> + * rtc_power_off: Set the pmic power off sequence. The RTC generates
> + * pmic_pwr_enable control, which can be used to control an external
> + * PMIC.
> + */
> +static void rtc_power_off(void)
> +{
> + u32 val;
> + struct rtc_time tm;
> + spinlock_t lock;
> + unsigned long flags;
> +
> + spin_lock_init(&lock);
> +
> + /* Set PMIC power enable */
> + val = readl(rtc_base + OMAP_RTC_PMIC_REG);
> + writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base + OMAP_RTC_PMIC_REG);
> +
> + /* Wait few seconds instead of rollover */
> + do {
> + omap_rtc_read_time(NULL, &tm);
> + if (WAIT_AFTER <= tm.tm_sec)
> + mdelay(WAIT_TIME_MS);
> + } while (WAIT_AFTER <= tm.tm_sec);
> +
> + /* Add shutdown time to the current value */
> + tm.tm_sec += SHUTDOWN_TIME_SEC;
> +
> + if (tm2bcd(&tm) < 0)
> + return;
> +
> + pr_info("System will go to power_off state in approx. %d secs\n",
> + SHUTDOWN_TIME_SEC);
> +
> + /* Set the ALARM2 time */
> + rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
> + rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
> + rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
> + rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
> + rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
> + rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
> +
> + /* Enable alarm2 interrupt */
> + val = readl(rtc_base + OMAP_RTC_INTERRUPTS_REG);
> + writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
> + rtc_base + OMAP_RTC_INTERRUPTS_REG);
> +
> + /* Do not allow to execute any other task */
> + spin_lock_irqsave(&lock, flags);
> + while (1);
> +}
> +
> static struct rtc_class_ops omap_rtc_ops = {
> .read_time = omap_rtc_read_time,
> .set_time = omap_rtc_set_time,
> @@ -327,12 +396,16 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
> struct resource *res, *mem;
> struct rtc_device *rtc;
> u8 reg, new_ctrl;
> + bool pm_off = false;
> const struct platform_device_id *id_entry;
> const struct of_device_id *of_id;
>
> of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
> - if (of_id)
> + if (of_id) {
> pdev->id_entry = of_id->data;
> + pm_off = of_property_read_bool(pdev->dev.of_node,
> + "ti,system-power-controller");
> + }
>
> omap_rtc_timer = platform_get_irq(pdev, 0);
> if (omap_rtc_timer <= 0) {
> @@ -385,6 +458,10 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, rtc);
> dev_set_drvdata(&rtc->dev, mem);
>
> + /* RTC power off */
> + if (pm_off && !pm_power_off)
> + pm_power_off = rtc_power_off;
> +
> /* clear pending irqs, and set 1/second periodic,
> * which we'll use instead of update irqs
> */
>
^ permalink raw reply
* [PATCH 00/10] ARM: dts: AM33XX: Add device tree data
From: Benoit Cousson @ 2012-11-05 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <331ABD5ECB02734CA317220B2BBEABC13EA647CE@DBDE01.ent.ti.com>
Hi Anil,
On 11/05/2012 02:46 PM, AnilKumar, Chimata wrote:
> On Mon, Nov 05, 2012 at 16:15:40, AnilKumar, Chimata wrote:
>> Add device tree date for GPIO based various drivers matrix keypad,
>> volume keys, push buttons and use leds accross three AM33XX devices
>> viz EVM, BeagleBone and Starter Kit.
>>
>> To make it functional this series also adds pinctrl data for all
>> the GPIOs used by various drivers. In this series only default state
>> pinmux/conf settings are added because of sleep/idle state pinctrl
>> values are not available.
>>
>> These patches are based on linux-omap-dt:for_3.8/dts tree and these
>
> My bad, small correction in this statement, these patches apply cleanly
> on linux-omap-dt:for_3.8/dts tree with the below two patches.
> http://www.spinics.net/lists/arm-kernel/msg204872.html
> http://www.spinics.net/lists/arm-kernel/msg204873.html
Mmm, this 2 patches do have dependency on some driver changes that might
not be accepted for 3.8. And in fact I do have some comment on the RTC
one :-)
Don't you prefer to change the order to allow me to pull these ones first?
Thanks,
Benoit
^ permalink raw reply
* [PATCH 1/8] mfd: ab8500-core: Remove unused ab8500-gpio IRQ ranges
From: Lee Jones @ 2012-11-05 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211051616.24257.arnd@arndb.de>
On Mon, 05 Nov 2012, Arnd Bergmann wrote:
> On Monday 05 November 2012, Lee Jones wrote:
> > The IRQ ranges provided in ab8500-core to be passed on to the
> > ab8500-gpio driver are not only redundant, but they are also
> > causing a warning in the boot log. These IRQ ranges, like any
> > other MFD related IRQ resource are passed though MFD core for
> > automatic conversion to virtual IRQs; however, MFD core does
> > not support IRQ mapping of IRQ ranges. Let's just remove them.
> >
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Whoops, I missed Linus' Tested-by on this patch too, so:
Tested-by: Linus Walleij <linus.walleij@linaro.org>
I also forgot to to mention that this should really be going
for the -rcs rather than -next.
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] leds: leds-gpio: adopt pinctrl support
From: Tony Lindgren @ 2012-11-05 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY_db3ju4LVnoR=0Wq8TFUxa48jNFGhvGM-3uSrmGZVew@mail.gmail.com>
* Linus Walleij <linus.walleij@linaro.org> [121104 09:39]:
> On Tue, Oct 30, 2012 at 3:12 PM, AnilKumar, Chimata <anilkumar@ti.com> wrote:
> > I have two options now
> > - add only default states for now, I can add reset of
> > the state details once suspend/resume is supported.
> > - add same values in all the states, modify those once
> > suspend/resume is added for AM335x.
>
> The OMAP maintainer gets to choose how this is to be done,
> it's none of my business :-)
Either way is fine with me as long as the changes have been
tested and you don't have to redo things once you have
suspend and resume working.
Regards,
Tony
^ 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