* [PATCH v3 01/11] clk: davinci - add main PLL clock driver
From: Sekhar Nori @ 2012-11-01 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50912BCE.5000401@ti.com>
On 10/31/2012 7:16 PM, Murali Karicheri wrote:
> On 10/31/2012 08:29 AM, Sekhar Nori wrote:
>>> + /*
>>> + * if fixed_multiplier is non zero, multiply pllm value by this
>>> + * value.
>>> + */
>>> + if (pll_data->fixed_multiplier)
>>> + mult = pll_data->fixed_multiplier *
>>> + (mult & pll_data->pllm_mask);
>>> + else
>>> + mult = (mult & pll_data->pllm_mask) + 1;
>> Hmm, this is interpreting the 'mult' register field differently in both
>> cases. In one case it is 'actual multiplier - 1' and in other case it is
>> the 'actual multiplier' itself. Can we be sure that the mult register
>> definition will change whenever there is a fixed multiplier in the PLL
>> block? I don't think any of the existing DaVinci devices have a fixed
>> multiplier. Is this on keystone?
> Read section 6.4.3 (PLL Mode) in DM365 documentation (SPRUFG5a.pdf) that
> states PLL multiplies the clock by 2x the value in the PLLM. In the old
> code this is handled by a if cpu_is_* macro that we can't use in the
> driver. So this is represented by a fixed_multiplier that can be set to
> 2 for DM365 and zero on other SoCs.
Thanks for the clarification.
Regards,
Sekhar
^ permalink raw reply
* [PATCH -next] CLK: clk-twl6040: fix return value check in twl6040_clk_probe()
From: Mike Turquette @ 2012-11-01 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPgLHd-LVhPkOHUWOwjmcsDA-4spfQMTxW9z2tB7fnEuS_5OOw@mail.gmail.com>
Quoting Wei Yongjun (2012-10-31 22:33:55)
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> In case of error, the function clk_register() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check
> should be replaced with IS_ERR().
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Thanks for the patch. Will take into clk-next.
Regards,
Mike
> ---
> drivers/clk/clk-twl6040.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk-twl6040.c b/drivers/clk/clk-twl6040.c
> index f4a3389..bc1e713 100644
> --- a/drivers/clk/clk-twl6040.c
> +++ b/drivers/clk/clk-twl6040.c
> @@ -92,8 +92,8 @@ static int __devinit twl6040_clk_probe(struct platform_device *pdev)
>
> clkdata->mcpdm_fclk.init = &wm831x_clkout_init;
> clkdata->clk = clk_register(&pdev->dev, &clkdata->mcpdm_fclk);
> - if (!clkdata->clk)
> - return -EINVAL;
> + if (IS_ERR(clkdata->clk))
> + return PTR_ERR(clkdata->clk);
>
> dev_set_drvdata(&pdev->dev, clkdata);
^ permalink raw reply
* [RFC PATCH] ARM: OMAP4: ID: Improve features detection and check
From: Santosh Shilimkar @ 2012-11-01 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351765401-12487-1-git-send-email-ivan.khoronzhuk@ti.com>
On Thursday 01 November 2012 03:53 PM, Ivan Khoronzhuk wrote:
> Replaces several flags bearing the same meaning. There is no need
> to set flags due to different omap types here, it can be checked
> in appropriate places as well.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-omap at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> ---
> arch/arm/mach-omap2/id.c | 25 +++++++------------------
> arch/arm/mach-omap2/soc.h | 8 ++------
> 2 files changed, 9 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index cf2362c..3c47a19 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -28,6 +28,9 @@
> #include "soc.h"
> #include "control.h"
>
> +#define OMAP4_SILICON_TYPE_STANDARD 0x01
> +#define OMAP4_SILICON_TYPE_PERFORMANCE 0x02
> +
> static unsigned int omap_revision;
> static const char *cpu_rev;
> u32 omap_features;
> @@ -273,25 +276,11 @@ void __init omap4xxx_check_features(void)
> {
> u32 si_type;
>
> - if (cpu_is_omap443x())
> - omap_features |= OMAP4_HAS_MPU_1GHZ;
> -
> + si_type =
> + (read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1) >> 16) & 0x03;
>
> - if (cpu_is_omap446x()) {
> - si_type =
> - read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
> - switch ((si_type & (3 << 16)) >> 16) {
> - case 2:
> - /* High performance device */
> - omap_features |= OMAP4_HAS_MPU_1_5GHZ;
> - break;
> - case 1:
> - default:
> - /* Standard device */
> - omap_features |= OMAP4_HAS_MPU_1_2GHZ;
> - break;
> - }
> - }
> + if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE)
> + omap_features = OMAP4_HAS_PERF_SILICON;
Well the detection isn't for performance/standard but there are some
features depend on it. For example 1 GHz doesn't DPLL DCC enable feature
where as 1.2 GHz, 1.5 GHz doesn't need. This is the main reason this
information is also effused. Have you considered this aspect while
creating this patch ?
Regards
Santosh
^ permalink raw reply
* Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Kevin Hilman @ 2012-11-01 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaBmg7wtX0WsaxMw=n1sKDN5YphK=y8tzAx_CF=JnUqvw@mail.gmail.com>
Linus Walleij <linus.walleij@linaro.org> writes:
> On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>
>> Linus Walleij <linus.walleij@linaro.org> writes:
>
>
>>
>> > piece of hardware, this would be the right thing to do,
>> > and I think the in-kernel examples are all "simple",
>> > e.g. arch/arm/mach-omap2/powerdomain* is all about
>> > power domains and nothing else,
>>
>> FYI... that code isn't the same as PM domain.
>
>
> This sort of points to a core problem here. Our terminologies are
> ambiguous that we cannot understand each others code. As long
> as <linux/pm_domain.h> begins:
>
> /*
> * pm_domain.h - Definitions and headers related to device power domains.
> *
>
> But arguably that should just be patched (I think there are a few
> remnants in the code still implying that these things are only about
> power).
Agreed. The terminology is confusing, and any situations like this in
the code/comments/docs should be patched.
When PM domains were introduced, I was the first to complain that we
shouldn't use the term power domain so as not to be confused with HW
concepts, so we settled on the term 'PM domain.' Ultimately, it's just
a configurable grouping of devices whose callbacks happen during PM
transitions.
>>
>> That code is for the
>> *hardware* powerdomains, not the software concept of "PM domain." In
>> OMAP, PM domain is implmented at the omap_device level. And omap_device
>> is the abstraction of an IP block that knows about all the PM related
>> register settings, clocks, HW powerdomain, voltage domain, PM related
>> pin-muxing etc. etc. All of these things are abstracted in an
>> omap_device, so that the PM domain implementation for OMAP looks rather
>> simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.)
>
>
> OK following now...
>
>>
>> > I think the lesser of two evils is the distributed approach,
>>
>> The pinctrl examples I've seen mentioned so far are all PM related
>>
>> (sleep, idle, wakeup, etc.) so to me I think they still belong in
>> PM domains (and that's how we handle the PM related pins in OMAP.)
>
>
> Well, the pinctrl grabbers in these drivers are using these states also
> for platforms that do not even select CONFIG_PM. For example
> mach-nomadik is quite happy that the PL011 driver is thusly
> muxing in its pins. And would require refactoring to use PM
> domains.
If CONFIG_PM is disabled, then is it safe to assume that the pins in
question are probably only done once at init time. I assume during
->probe(). ?
>
> So basically this requirement comes down to:
>
> - When dealing with a SoC IP block driver
>
> - That need to multiplex pins
>
> - Then your SoC must select CONFIG_PM and
> CONFIG_PM_RUNTIME andb
> CONFIG_PM_GENERIC_DOMAINS and implement
> proper domain handling hooks.
>
> Is this correct?
I would say yes. Currently, PM domains are the way to hook SoC-specific
integration details into PM transitions.
However, if what we want/need are only ways to introduce SoC-specific
integration details into non-PM transitions (e.g. probe/remove), maybe
bus notifiers would suffice here. e.g. you'd get a bus notifier when
the device is added/attached and any init-time pinctrl setup could be
done then. This still keeps drivers clean of SoC-specific integration
data/code, and also allows that to happen whether or not PM features are
enabled.
Kevin
^ permalink raw reply
* [PATCH] i2c: mxs: remove broken PIOQUEUE support
From: Wolfram Sang @ 2012-11-01 11:56 UTC (permalink / raw)
To: linux-arm-kernel
This I2C master can do DMA and PIOQUEUE (PIO with FIFO). Originally,
only PIOQEUE was supported, then DMA support was added. The original
intention was to keep PIOQUEUE since it has less overhead what is nice
for small transfers. However, runtime switching between PIOQEUE and DMA
depending on the transfer size never worked despite a lot of trying.
Since PIOQUEUE mode itself was flaky (polling at places where interrupts
failed to work) and the implementation also imposed a size limit for
transfers, it is best to remove the support altogether which makes the
driver a lot cleaner and more robust. If somebody really wants less
overhead, plain PIO mode could still be implemented with the addidtional
advantage that this mode is also available on MX23, too.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
---
drivers/i2c/busses/i2c-mxs.c | 186 ++++--------------------------------------
1 file changed, 14 insertions(+), 172 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index 1f58197..286ca19 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -1,7 +1,7 @@
/*
* Freescale MXS I2C bus driver
*
- * Copyright (C) 2011 Wolfram Sang, Pengutronix e.K.
+ * Copyright (C) 2011-2012 Wolfram Sang, Pengutronix e.K.
*
* based on a (non-working) driver which was:
*
@@ -35,10 +35,6 @@
#define DRIVER_NAME "mxs-i2c"
-static bool use_pioqueue;
-module_param(use_pioqueue, bool, 0);
-MODULE_PARM_DESC(use_pioqueue, "Use PIOQUEUE mode for transfer instead of DMA");
-
#define MXS_I2C_CTRL0 (0x00)
#define MXS_I2C_CTRL0_SET (0x04)
@@ -75,23 +71,6 @@ MODULE_PARM_DESC(use_pioqueue, "Use PIOQUEUE mode for transfer instead of DMA");
MXS_I2C_CTRL1_SLAVE_STOP_IRQ | \
MXS_I2C_CTRL1_SLAVE_IRQ)
-#define MXS_I2C_QUEUECTRL (0x60)
-#define MXS_I2C_QUEUECTRL_SET (0x64)
-#define MXS_I2C_QUEUECTRL_CLR (0x68)
-
-#define MXS_I2C_QUEUECTRL_QUEUE_RUN 0x20
-#define MXS_I2C_QUEUECTRL_PIO_QUEUE_MODE 0x04
-
-#define MXS_I2C_QUEUESTAT (0x70)
-#define MXS_I2C_QUEUESTAT_RD_QUEUE_EMPTY 0x00002000
-#define MXS_I2C_QUEUESTAT_WRITE_QUEUE_CNT_MASK 0x0000001F
-
-#define MXS_I2C_QUEUECMD (0x80)
-
-#define MXS_I2C_QUEUEDATA (0x90)
-
-#define MXS_I2C_DATA (0xa0)
-
#define MXS_CMD_I2C_SELECT (MXS_I2C_CTRL0_RETAIN_CLOCK | \
MXS_I2C_CTRL0_PRE_SEND_START | \
@@ -153,7 +132,6 @@ struct mxs_i2c_dev {
const struct mxs_i2c_speed_config *speed;
/* DMA support components */
- bool dma_mode;
int dma_channel;
struct dma_chan *dmach;
struct mxs_dma_data dma_data;
@@ -172,99 +150,6 @@ static void mxs_i2c_reset(struct mxs_i2c_dev *i2c)
writel(i2c->speed->timing2, i2c->regs + MXS_I2C_TIMING2);
writel(MXS_I2C_IRQ_MASK << 8, i2c->regs + MXS_I2C_CTRL1_SET);
- if (i2c->dma_mode)
- writel(MXS_I2C_QUEUECTRL_PIO_QUEUE_MODE,
- i2c->regs + MXS_I2C_QUEUECTRL_CLR);
- else
- writel(MXS_I2C_QUEUECTRL_PIO_QUEUE_MODE,
- i2c->regs + MXS_I2C_QUEUECTRL_SET);
-}
-
-static void mxs_i2c_pioq_setup_read(struct mxs_i2c_dev *i2c, u8 addr, int len,
- int flags)
-{
- u32 data;
-
- writel(MXS_CMD_I2C_SELECT, i2c->regs + MXS_I2C_QUEUECMD);
-
- data = (addr << 1) | I2C_SMBUS_READ;
- writel(data, i2c->regs + MXS_I2C_DATA);
-
- data = MXS_CMD_I2C_READ | MXS_I2C_CTRL0_XFER_COUNT(len) | flags;
- writel(data, i2c->regs + MXS_I2C_QUEUECMD);
-}
-
-static void mxs_i2c_pioq_setup_write(struct mxs_i2c_dev *i2c,
- u8 addr, u8 *buf, int len, int flags)
-{
- u32 data;
- int i, shifts_left;
-
- data = MXS_CMD_I2C_WRITE | MXS_I2C_CTRL0_XFER_COUNT(len + 1) | flags;
- writel(data, i2c->regs + MXS_I2C_QUEUECMD);
-
- /*
- * We have to copy the slave address (u8) and buffer (arbitrary number
- * of u8) into the data register (u32). To achieve that, the u8 are put
- * into the MSBs of 'data' which is then shifted for the next u8. When
- * appropriate, 'data' is written to MXS_I2C_DATA. So, the first u32
- * looks like this:
- *
- * 3 2 1 0
- * 10987654|32109876|54321098|76543210
- * --------+--------+--------+--------
- * buffer+2|buffer+1|buffer+0|slave_addr
- */
-
- data = ((addr << 1) | I2C_SMBUS_WRITE) << 24;
-
- for (i = 0; i < len; i++) {
- data >>= 8;
- data |= buf[i] << 24;
- if ((i & 3) == 2)
- writel(data, i2c->regs + MXS_I2C_DATA);
- }
-
- /* Write out the remaining bytes if any */
- shifts_left = 24 - (i & 3) * 8;
- if (shifts_left)
- writel(data >> shifts_left, i2c->regs + MXS_I2C_DATA);
-}
-
-/*
- * TODO: should be replaceable with a waitqueue and RD_QUEUE_IRQ (setting the
- * rd_threshold to 1). Couldn't get this to work, though.
- */
-static int mxs_i2c_wait_for_data(struct mxs_i2c_dev *i2c)
-{
- unsigned long timeout = jiffies + msecs_to_jiffies(1000);
-
- while (readl(i2c->regs + MXS_I2C_QUEUESTAT)
- & MXS_I2C_QUEUESTAT_RD_QUEUE_EMPTY) {
- if (time_after(jiffies, timeout))
- return -ETIMEDOUT;
- cond_resched();
- }
-
- return 0;
-}
-
-static int mxs_i2c_finish_read(struct mxs_i2c_dev *i2c, u8 *buf, int len)
-{
- u32 uninitialized_var(data);
- int i;
-
- for (i = 0; i < len; i++) {
- if ((i & 3) == 0) {
- if (mxs_i2c_wait_for_data(i2c))
- return -ETIMEDOUT;
- data = readl(i2c->regs + MXS_I2C_QUEUEDATA);
- }
- buf[i] = data & 0xff;
- data >>= 8;
- }
-
- return 0;
}
static void mxs_i2c_dma_finish(struct mxs_i2c_dev *i2c)
@@ -432,39 +317,17 @@ static int mxs_i2c_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg,
init_completion(&i2c->cmd_complete);
i2c->cmd_err = 0;
- if (i2c->dma_mode) {
- ret = mxs_i2c_dma_setup_xfer(adap, msg, flags);
- if (ret)
- return ret;
- } else {
- if (msg->flags & I2C_M_RD) {
- mxs_i2c_pioq_setup_read(i2c, msg->addr,
- msg->len, flags);
- } else {
- mxs_i2c_pioq_setup_write(i2c, msg->addr, msg->buf,
- msg->len, flags);
- }
-
- writel(MXS_I2C_QUEUECTRL_QUEUE_RUN,
- i2c->regs + MXS_I2C_QUEUECTRL_SET);
- }
+ ret = mxs_i2c_dma_setup_xfer(adap, msg, flags);
+ if (ret)
+ return ret;
ret = wait_for_completion_timeout(&i2c->cmd_complete,
msecs_to_jiffies(1000));
if (ret == 0)
goto timeout;
- if (!i2c->dma_mode && !i2c->cmd_err && (msg->flags & I2C_M_RD)) {
- ret = mxs_i2c_finish_read(i2c, msg->buf, msg->len);
- if (ret)
- goto timeout;
- }
-
if (i2c->cmd_err == -ENXIO)
mxs_i2c_reset(i2c);
- else
- writel(MXS_I2C_QUEUECTRL_QUEUE_RUN,
- i2c->regs + MXS_I2C_QUEUECTRL_CLR);
dev_dbg(i2c->dev, "Done with err=%d\n", i2c->cmd_err);
@@ -472,8 +335,7 @@ static int mxs_i2c_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg,
timeout:
dev_dbg(i2c->dev, "Timeout!\n");
- if (i2c->dma_mode)
- mxs_i2c_dma_finish(i2c);
+ mxs_i2c_dma_finish(i2c);
mxs_i2c_reset(i2c);
return -ETIMEDOUT;
}
@@ -502,7 +364,6 @@ static irqreturn_t mxs_i2c_isr(int this_irq, void *dev_id)
{
struct mxs_i2c_dev *i2c = dev_id;
u32 stat = readl(i2c->regs + MXS_I2C_CTRL1) & MXS_I2C_IRQ_MASK;
- bool is_last_cmd;
if (!stat)
return IRQ_NONE;
@@ -515,14 +376,6 @@ static irqreturn_t mxs_i2c_isr(int this_irq, void *dev_id)
/* MXS_I2C_CTRL1_OVERSIZE_XFER_TERM_IRQ is only for slaves */
i2c->cmd_err = -EIO;
- if (!i2c->dma_mode) {
- is_last_cmd = (readl(i2c->regs + MXS_I2C_QUEUESTAT) &
- MXS_I2C_QUEUESTAT_WRITE_QUEUE_CNT_MASK) == 0;
-
- if (is_last_cmd || i2c->cmd_err)
- complete(&i2c->cmd_complete);
- }
-
writel(stat, i2c->regs + MXS_I2C_CTRL1_CLR);
return IRQ_HANDLED;
@@ -556,23 +409,14 @@ static int mxs_i2c_get_ofdata(struct mxs_i2c_dev *i2c)
int ret;
/*
- * The MXS I2C DMA mode is prefered and enabled by default.
- * The PIO mode is still supported, but should be used only
- * for debuging purposes etc.
- */
- i2c->dma_mode = !use_pioqueue;
- if (!i2c->dma_mode)
- dev_info(dev, "Using PIOQUEUE mode for I2C transfers!\n");
-
- /*
* TODO: This is a temporary solution and should be changed
* to use generic DMA binding later when the helpers get in.
*/
ret = of_property_read_u32(node, "fsl,i2c-dma-channel",
&i2c->dma_channel);
if (ret) {
- dev_warn(dev, "Failed to get DMA channel, using PIOQUEUE!\n");
- i2c->dma_mode = 0;
+ dev_err(dev, "Failed to get DMA channel!\n");
+ return -ENODEV;
}
ret = of_property_read_u32(node, "clock-frequency", &speed);
@@ -634,15 +478,13 @@ static int __devinit mxs_i2c_probe(struct platform_device *pdev)
}
/* Setup the DMA */
- if (i2c->dma_mode) {
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
- i2c->dma_data.chan_irq = dmairq;
- i2c->dmach = dma_request_channel(mask, mxs_i2c_dma_filter, i2c);
- if (!i2c->dmach) {
- dev_err(dev, "Failed to request dma\n");
- return -ENODEV;
- }
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+ i2c->dma_data.chan_irq = dmairq;
+ i2c->dmach = dma_request_channel(mask, mxs_i2c_dma_filter, i2c);
+ if (!i2c->dmach) {
+ dev_err(dev, "Failed to request dma\n");
+ return -ENODEV;
}
platform_set_drvdata(pdev, i2c);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 05/13] ARM: OMAP2+: PRCM: create SoC-specific chip restart functions
From: Paul Walmsley @ 2012-11-01 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025232116.17558.47458.stgit@dusk.lan>
Here's an update of this one.
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Mon, 29 Oct 2012 20:56:07 -0600
Subject: [PATCH] ARM: OMAP2+: PRCM: create SoC-specific chip restart
functions
Split omap_prcm_restart() from mach-omap2/prcm.c into SoC-specific
variants. These functions need to be able to save the reboot reason
into the scratchpad RAM. This implies a dependency on both the PRM
and SCM IP blocks, so they've been moved into their own file. This
will eventually call functions in the PRM and SCM drivers, once those
are created.
Vaibhav Hiremath <hvaibhav@ti.com> identified an unused prototype in
the first version of this patch - now removed.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
---
arch/arm/mach-omap2/Makefile | 5 +++
arch/arm/mach-omap2/common.h | 24 +++++++++++++
arch/arm/mach-omap2/omap2-restart.c | 65 +++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/omap3-restart.c | 36 +++++++++++++++++++
arch/arm/mach-omap2/omap4-common.c | 16 +++++++++
5 files changed, 146 insertions(+)
create mode 100644 arch/arm/mach-omap2/omap2-restart.c
create mode 100644 arch/arm/mach-omap2/omap3-restart.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ae87a3e..1988810 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -50,6 +50,11 @@ AFLAGS_sram242x.o :=-Wa,-march=armv6
AFLAGS_sram243x.o :=-Wa,-march=armv6
AFLAGS_sram34xx.o :=-Wa,-march=armv7-a
+# Restart code (OMAP4/5 currently in omap4-common.c)
+obj-$(CONFIG_SOC_OMAP2420) += omap2-restart.o
+obj-$(CONFIG_SOC_OMAP2430) += omap2-restart.o
+obj-$(CONFIG_ARCH_OMAP3) += omap3-restart.o
+
# Pin multiplexing
obj-$(CONFIG_SOC_OMAP2420) += mux2420.o
obj-$(CONFIG_SOC_OMAP2430) += mux2430.o
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index b8f7710..3f5aa9d 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -121,6 +121,30 @@ void omap4430_init_late(void);
int omap2_common_pm_late_init(void);
void omap_prcm_restart(char, const char *);
+#if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
+void omap2xxx_restart(char mode, const char *cmd);
+#else
+static inline void omap2xxx_restart(char mode, const char *cmd)
+{
+}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP3
+void omap3xxx_restart(char mode, const char *cmd);
+#else
+static inline void omap3xxx_restart(char mode, const char *cmd)
+{
+}
+#endif
+
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
+void omap44xx_restart(char mode, const char *cmd);
+#else
+static inline void omap44xx_restart(char mode, const char *cmd)
+{
+}
+#endif
+
/* This gets called from mach-omap2/io.c, do not call this */
void __init omap2_set_globals_tap(u32 class, void __iomem *tap);
diff --git a/arch/arm/mach-omap2/omap2-restart.c b/arch/arm/mach-omap2/omap2-restart.c
new file mode 100644
index 0000000..be6bc89
--- /dev/null
+++ b/arch/arm/mach-omap2/omap2-restart.c
@@ -0,0 +1,65 @@
+/*
+ * omap2-restart.c - code common to all OMAP2xxx machines.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Paul Walmsley
+ *
+ * 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 <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+
+#include "common.h"
+#include "prm2xxx.h"
+
+/*
+ * reset_virt_prcm_set_ck, reset_sys_ck: pointers to the virt_prcm_set
+ * clock and the sys_ck. Used during the reset process
+ */
+static struct clk *reset_virt_prcm_set_ck, *reset_sys_ck;
+
+/* Reboot handling */
+
+/**
+ * omap2xxx_restart - Set DPLL to bypass mode for reboot to work
+ *
+ * Set the DPLL to bypass so that reboot completes successfully. No
+ * return value.
+ */
+void omap2xxx_restart(char mode, const char *cmd)
+{
+ u32 rate;
+
+ rate = clk_get_rate(reset_sys_ck);
+ clk_set_rate(reset_virt_prcm_set_ck, rate);
+
+ /* XXX Should save the cmd argument for use after the reboot */
+
+ omap2xxx_prm_dpll_reset(); /* never returns */
+ while (1);
+}
+
+/**
+ * omap2xxx_common_look_up_clks_for_reset - look up clocks needed for restart
+ *
+ * Some clocks need to be looked up in advance for the SoC restart
+ * operation to work - see omap2xxx_restart(). Returns -EINVAL upon
+ * error or 0 upon success.
+ */
+static int __init omap2xxx_common_look_up_clks_for_reset(void)
+{
+ reset_virt_prcm_set_ck = clk_get(NULL, "virt_prcm_set");
+ if (IS_ERR(reset_virt_prcm_set_ck))
+ return -EINVAL;
+
+ reset_sys_ck = clk_get(NULL, "sys_ck");
+ if (IS_ERR(reset_sys_ck))
+ return -EINVAL;
+
+ return 0;
+}
+core_initcall(omap2xxx_common_look_up_clks_for_reset);
diff --git a/arch/arm/mach-omap2/omap3-restart.c b/arch/arm/mach-omap2/omap3-restart.c
new file mode 100644
index 0000000..923c582
--- /dev/null
+++ b/arch/arm/mach-omap2/omap3-restart.c
@@ -0,0 +1,36 @@
+/*
+ * omap3-restart.c - Code common to all OMAP3xxx machines.
+ *
+ * Copyright (C) 2009, 2012 Texas Instruments
+ * Copyright (C) 2010 Nokia Corporation
+ * Tony Lindgren <tony@atomide.com>
+ * Santosh Shilimkar <santosh.shilimkar@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 <linux/kernel.h>
+#include <linux/init.h>
+
+#include "iomap.h"
+#include "common.h"
+#include "control.h"
+#include "prm3xxx.h"
+
+/* Global address base setup code */
+
+/**
+ * omap3xxx_restart - trigger a software restart of the SoC
+ * @mode: the "reboot mode", see arch/arm/kernel/{setup,process}.c
+ * @cmd: passed from the userspace program rebooting the system (if provided)
+ *
+ * Resets the SoC. For @cmd, see the 'reboot' syscall in
+ * kernel/sys.c. No return value.
+ */
+void omap3xxx_restart(char mode, const char *cmd)
+{
+ omap3_ctrl_write_boot_mode((cmd ? (u8)*cmd : 0));
+ omap3xxx_prm_dpll3_reset(); /* never returns */
+ while (1);
+}
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 6cd7e87..34bd16a 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -33,6 +33,7 @@
#include "common.h"
#include "mmc.h"
#include "hsmmc.h"
+#include "prminst44xx.h"
#include "omap4-sar-layout.h"
#include "omap-secure.h"
@@ -248,6 +249,21 @@ static int omap4_twl6030_hsmmc_late_init(struct device *dev)
return 0;
}
+/**
+ * omap44xx_restart - trigger a software restart of the SoC
+ * @mode: the "reboot mode", see arch/arm/kernel/{setup,process}.c
+ * @cmd: passed from the userspace program rebooting the system (if provided)
+ *
+ * Resets the SoC. For @cmd, see the 'reboot' syscall in
+ * kernel/sys.c. No return value.
+ */
+void omap44xx_restart(char mode, const char *cmd)
+{
+ /* XXX Should save 'cmd' into scratchpad for use after reboot */
+ omap4_prminst_global_warm_sw_reset(); /* never returns */
+ while (1);
+}
+
static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
{
struct omap_mmc_platform_data *pdata;
--
1.7.10.4
^ permalink raw reply related
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-11-01 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbCk9+HSBPtfT-1dO8paSRYJ5VXX_0SxiyxgrObnJEvmQ@mail.gmail.com>
On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote:
> Well, the pinctrl grabbers in these drivers are using these states also
> for platforms that do not even select CONFIG_PM. For example
> mach-nomadik is quite happy that the PL011 driver is thusly
> muxing in its pins. And would require refactoring to use PM
> domains.
> So basically this requirement comes down to:
> - When dealing with a SoC IP block driver
> - That need to multiplex pins
> - Then your SoC must select CONFIG_PM and
> CONFIG_PM_RUNTIME and
> CONFIG_PM_GENERIC_DOMAINS and implement
> proper domain handling hooks.
> Is this correct? And for Mark, Dmitry, does this correspond to
> your view?
For the pin hogging I'd actually been thinking separately that we should
just have the device core do a devm_pinctrl_get_set_default() prior to
probing the device and store the result in the struct device. That
would immediately remove almost all of the current pinctrl users, users
that do need to do things with the data or check the result can then
pick up the pinctrl pointer from the device struct.
> It's actually something that needs to be acknowledged by the
> ARM SoC maintainers, because they will be the ones telling
> all subarch maintainers to go implement full PM handling
> with these three frameworks whenever an SoC driver want
> to handle pins.
Well, they're going to have to implement it somewhere anyway - either in
the drivers or in the SoC stuff.
> And IIUC not only pins but also silicon block clocks?
> I can surely fix these for "my" systems, but it really needs
> to be enforced widely or it will be a mess.
We definitely need to decide if it's something that should be open coded
everywhere.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121101/872838fb/attachment-0001.sig>
^ permalink raw reply
* [GIT PULL] ARM: OMAP: second set of PRCM cleanups for 3.8
From: Paul Walmsley @ 2012-11-01 12:17 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony
The following changes since commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33:
Merge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcm (2012-10-26 13:32:22 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-b-for-3.8
for you to fetch changes up to f17d60d20eb8e679cdd1e9d507394237e58ce0d8:
ARM: OMAP2+: PRCM: remove obsolete prcm.[ch] (2012-11-01 04:48:18 -0600)
- ----------------------------------------------------------------
Second set of OMAP PRCM cleanups for 3.8.
These patches remove the use of omap_prcm_get_reset_sources() from the
OMAP watchdog driver, and remove mach-omap2/prcm.c and
plat-omap/include/plat/prcm.h.
Basic test logs for this branch on top of Tony's cleanup-prcm branch
at commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33 are here:
http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/
However, cleanup-prcm at 7fc54fd3 does not build for several
Kconfigs here and doesn't include some fixes that are needed for
a successful test. With several reverts, fixes, and workarounds
applied, the following test logs were obtained:
http://www.pwsan.com/omap/testlogs/TEST_prcm_cleanup_b_3.8/20121101045401/
which indicate that the series tests cleanly.
- ----------------------------------------------------------------
vmlinux object size
(delta in bytes from test_cleanup-prcm_7fc54fd_v3.7-rc (7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33)):
text data bss total kernel
-252 -56 0 -308 am33xx_only
+16 -56 0 -40 n800_multi_omap2xxx
+232 -24 0 +208 n800_only_a
+88 -24 0 +64 omap1_defconfig
0 0 0 0 omap1_defconfig_1510innovator_only
+132 -8 0 +124 omap1_defconfig_5912osk_only
+652 -224 0 +428 omap2plus_defconfig
+200 -24 0 +176 omap2plus_defconfig_2430sdp_only
+652 -232 0 +420 omap2plus_defconfig_cpupm
+708 -248 0 +460 omap2plus_defconfig_no_pm
+200 -136 0 +64 omap2plus_defconfig_omap2_4_only
+4316 -128 0 +4188 omap2plus_defconfig_omap3_4_only
+196 -56 0 +140 rmk_omap3430_ldp_oldconfig
+60 -56 0 +4 rmk_omap4430_sdp_oldconfig
Paul Walmsley (17):
ARM: OMAP1: CGRM: fix omap1_get_reset_sources() return type
ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr
ARM: OMAP2+: PRCM: remove omap_prcm_get_reset_sources()
ARM: OMAP2+: common: remove mach-omap2/common.c globals and map_common_io code
ARM: OMAP2/3: PRM: add SoC reset functions (using the CORE DPLL method)
ARM: OMAP2xxx: clock: remove global 'dclk' variable
ARM: OMAP2xxx: clock: move virt_prcm_set code into clkt2xxx_virt_prcm_set.c
ARM: OMAP2+: PRCM: create SoC-specific chip restart functions
ARM: OMAP2+: board files: use SoC-specific system restart functions
ARM: OMAP2xxx: APLL/CM: convert to use omap2_cm_wait_module_ready()
ARM: OMAP2+: CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM functions
ARM: OMAP2+: PRCM: remove omap2_cm_wait_idlest()
ARM: OMAP2+: PRCM: split and relocate the PRM/CM globals setup
ARM: OMAP2+: PRCM: consolidate PRCM-related timeout macros
ARM: OMAP2+: hwmod: call to _omap4_disable_module() should use the SoC-specific call
ARM: OMAP2+: PRCM: remove obsolete prcm.[ch]
arch/arm/mach-omap1/common.h | 2 +-
arch/arm/mach-omap1/devices.c | 21 ++-
arch/arm/mach-omap1/reset.c | 9 +-
arch/arm/mach-omap2/Makefile | 7 +-
arch/arm/mach-omap2/am33xx.h | 1 +
arch/arm/mach-omap2/board-2430sdp.c | 2 +-
arch/arm/mach-omap2/board-3430sdp.c | 2 +-
arch/arm/mach-omap2/board-3630sdp.c | 2 +-
arch/arm/mach-omap2/board-4430sdp.c | 2 +-
arch/arm/mach-omap2/board-am3517crane.c | 2 +-
arch/arm/mach-omap2/board-am3517evm.c | 2 +-
arch/arm/mach-omap2/board-apollon.c | 2 +-
arch/arm/mach-omap2/board-cm-t35.c | 18 +--
arch/arm/mach-omap2/board-cm-t3517.c | 2 +-
arch/arm/mach-omap2/board-devkit8000.c | 2 +-
arch/arm/mach-omap2/board-generic.c | 10 +-
arch/arm/mach-omap2/board-h4.c | 2 +-
arch/arm/mach-omap2/board-igep0020.c | 4 +-
arch/arm/mach-omap2/board-ldp.c | 2 +-
arch/arm/mach-omap2/board-n8x0.c | 6 +-
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
arch/arm/mach-omap2/board-omap3evm.c | 2 +-
arch/arm/mach-omap2/board-omap3logic.c | 4 +-
arch/arm/mach-omap2/board-omap3pandora.c | 2 +-
arch/arm/mach-omap2/board-omap3stalker.c | 2 +-
arch/arm/mach-omap2/board-omap3touchbook.c | 2 +-
arch/arm/mach-omap2/board-omap4panda.c | 2 +-
arch/arm/mach-omap2/board-overo.c | 2 +-
arch/arm/mach-omap2/board-rm680.c | 4 +-
arch/arm/mach-omap2/board-rx51.c | 2 +-
arch/arm/mach-omap2/board-ti8168evm.c | 4 +-
arch/arm/mach-omap2/board-zoom.c | 4 +-
arch/arm/mach-omap2/clkt2xxx_apll.c | 57 ++------
arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 36 ++++-
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 70 ++++++++--
arch/arm/mach-omap2/clkt_iclk.c | 1 -
arch/arm/mach-omap2/clock.c | 15 +-
arch/arm/mach-omap2/clock.h | 28 ----
arch/arm/mach-omap2/clock2420_data.c | 26 +---
arch/arm/mach-omap2/clock2430_data.c | 26 +---
arch/arm/mach-omap2/clock2xxx.c | 16 ---
arch/arm/mach-omap2/clock2xxx.h | 9 +-
arch/arm/mach-omap2/cm-regbits-24xx.h | 2 +
arch/arm/mach-omap2/cm.h | 20 ++-
arch/arm/mach-omap2/cm2xxx.c | 128 ++++++++++++++++-
arch/arm/mach-omap2/cm2xxx.h | 4 +
arch/arm/mach-omap2/cm2xxx_3xxx.h | 8 +-
arch/arm/mach-omap2/cm3xxx.c | 66 +++++++++
arch/arm/mach-omap2/cm3xxx.h | 5 +
arch/arm/mach-omap2/cm_common.c | 70 +++++++++-
arch/arm/mach-omap2/cminst44xx.h | 2 +
arch/arm/mach-omap2/common.c | 183 -------------------------
arch/arm/mach-omap2/common.h | 125 +++++------------
arch/arm/mach-omap2/control.c | 10 +-
arch/arm/mach-omap2/control.h | 2 +
arch/arm/mach-omap2/cpuidle34xx.c | 1 -
arch/arm/mach-omap2/devices.c | 26 ----
arch/arm/mach-omap2/display.c | 2 +-
arch/arm/mach-omap2/hdq1w.c | 4 +-
arch/arm/mach-omap2/i2c.c | 6 +-
arch/arm/mach-omap2/id.c | 7 +-
arch/arm/mach-omap2/io.c | 86 ++++++++++--
arch/arm/mach-omap2/mcbsp.c | 2 +-
arch/arm/mach-omap2/msdi.c | 4 +-
arch/arm/mach-omap2/omap2-restart.c | 65 +++++++++
arch/arm/mach-omap2/omap3-restart.c | 36 +++++
arch/arm/mach-omap2/omap4-common.c | 18 +++
arch/arm/mach-omap2/omap_hwmod.c | 8 +-
arch/arm/mach-omap2/pm34xx.c | 1 -
arch/arm/mach-omap2/powerdomain.c | 2 -
arch/arm/mach-omap2/prcm-common.h | 22 ---
arch/arm/mach-omap2/prcm.c | 189 --------------------------
arch/arm/mach-omap2/prcm_mpu44xx.c | 17 +++
arch/arm/mach-omap2/prcm_mpu44xx.h | 9 +-
arch/arm/mach-omap2/prm.h | 24 +++-
arch/arm/mach-omap2/prm2xxx.c | 15 +-
arch/arm/mach-omap2/prm2xxx.h | 2 +
arch/arm/mach-omap2/prm2xxx_3xxx.h | 7 -
arch/arm/mach-omap2/prm3xxx.c | 16 ++-
arch/arm/mach-omap2/prm3xxx.h | 2 +
arch/arm/mach-omap2/prm44xx.c | 1 -
arch/arm/mach-omap2/prm_common.c | 16 ++-
arch/arm/mach-omap2/prminst44xx.h | 2 +
arch/arm/mach-omap2/sdrc.c | 8 +-
arch/arm/mach-omap2/sdrc.h | 2 +
arch/arm/mach-omap2/ti81xx.h | 9 ++
arch/arm/mach-omap2/wd_timer.c | 40 +++++-
arch/arm/plat-omap/include/plat/prcm.h | 37 -----
drivers/watchdog/omap_wdt.c | 26 ++--
include/linux/platform_data/omap-wd-timer.h | 38 ++++++
90 files changed, 948 insertions(+), 843 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap2-restart.c
create mode 100644 arch/arm/mach-omap2/omap3-restart.c
delete mode 100644 arch/arm/mach-omap2/prcm.c
delete mode 100644 arch/arm/plat-omap/include/plat/prcm.h
create mode 100644 include/linux/platform_data/omap-wd-timer.h
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJQkmfKAAoJEMePsQ0LvSpLkskP/jNWB8Dt9r9V2g6wnvuym8YP
jj8Un5BwWdGdCV9wcd4A2jipJCEEEhuAF0sQlF/UV9+MgkPK5q000UTn3MFgY8/d
F2rpqeDKiYt0eS4pvdwvSj7Gx9ZLK/vNh5ILm2vpmfRhzbFuJFLQGUNg/M19XxHs
TWJdNGMAHhAlUefxUKhaeybzqUGx9WQ5pTIFJ+bKdZCtH61h8p3tJk24+m7gaBXr
034iu9imcpf4n2reHcFB3x79HnljHRxo00PlQh/2w6bKJ2rtU9EMdYudgWf36plS
7shziaokVNJ8zS2HpGm7yiEy/MaXuEjzzzTkPR2dhl0HvxhVfeQMZIJcPDACKIed
gbpGVQnXgliJ8bRQe72UdE++LLaQJfdCHtteBoQfKQi5o7qMSd0Wlq6htk6Dggdl
G6/jn2GRn0Vab6Ij9rrDNWoMqR7sS/Ujtq3AdF/Pd0QYs/Au88CDV0YOuIG55Tov
aYPzzOg0Fv1Z6ASvmOJYtaJK/P9EZ3NfdQyo2RWYCCm980B37VK/90YvyYoYKdFs
MBBm0B8ekDVRMvvQkoZhYY2QwUKsTO+mgV/qPanXZLp31rCPAC+Wg3A/RDZKfdWw
uvjjDko29Uxu8tncFW+6pfIQ5ib0Tt4fgGV9/65CD6R/0Q477xuh1XkJV7iI3Q3k
v4jtIO11lfToUr7W25lH
=eyog
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] lpc32xx: irq - Set the chain handlers after setting up the IRQ domain
From: Alban Bedel @ 2012-11-01 12:23 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de>
---
arch/arm/mach-lpc32xx/irq.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-lpc32xx/irq.c b/arch/arm/mach-lpc32xx/irq.c
index 3c63327..b92dc25 100644
--- a/arch/arm/mach-lpc32xx/irq.c
+++ b/arch/arm/mach-lpc32xx/irq.c
@@ -448,10 +448,6 @@ void __init lpc32xx_init_irq(void)
__raw_writel(0, LPC32XX_INTC_MASK(LPC32XX_SIC1_BASE));
__raw_writel(0, LPC32XX_INTC_MASK(LPC32XX_SIC2_BASE));
- /* MIC SUBIRQx interrupts will route handling to the chain handlers */
- irq_set_chained_handler(IRQ_LPC32XX_SUB1IRQ, lpc32xx_sic1_handler);
- irq_set_chained_handler(IRQ_LPC32XX_SUB2IRQ, lpc32xx_sic2_handler);
-
/* Initially disable all wake events */
__raw_writel(0, LPC32XX_CLKPWR_P01_ER);
__raw_writel(0, LPC32XX_CLKPWR_INT_ER);
@@ -485,6 +481,12 @@ void __init lpc32xx_init_irq(void)
irq_base, 0,
&irq_domain_simple_ops,
NULL);
- if (!lpc32xx_mic_domain)
+ if (!lpc32xx_mic_domain) {
panic("Unable to add MIC irq domain\n");
+ return;
+ }
+
+ /* MIC SUBIRQx interrupts will route handling to the chain handlers */
+ irq_set_chained_handler(IRQ_LPC32XX_SUB1IRQ, lpc32xx_sic1_handler);
+ irq_set_chained_handler(IRQ_LPC32XX_SUB2IRQ, lpc32xx_sic2_handler);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 01/15] ARM: clps711x: Load serial driver from boards
From: Russell King - ARM Linux @ 2012-11-01 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351762006-27368-1-git-send-email-shc_work@mail.ru>
BOn Thu, Nov 01, 2012 at 01:26:31PM +0400, Alexander Shiyan wrote:
> MACHINE_START(AUTCPU12, "autronix autcpu12")
> /* Maintainer: Thomas Gleixner */
> .atag_offset = 0x20000,
> - .init_machine = autcpu12_init,
> .map_io = autcpu12_map_io,
> + .init_machine = autcpu12_init,
> .init_irq = clps711x_init_irq,
> - .timer = &clps711x_timer,
> .restart = clps711x_restart,
> + .timer = &clps711x_timer,
> MACHINE_END
NAK. If you're going to sort them, arrange them in the same order as
in the structure declaration in mach/arch.h. That's the order in which
the functions will be called.
IOW, changing the order of .timer to be after .restart is wrong, .restart
should be the last. .timer should be immediately before .init_machine.
.init_irq should be immediately before .timer.
^ permalink raw reply
* [PATCH v3 03/11] clk: davinci - common clk utilities to init clk driver
From: Sekhar Nori @ 2012-11-01 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351181518-11882-4-git-send-email-m-karicheri2@ti.com>
On 10/25/2012 9:41 PM, Murali Karicheri wrote:
> This is the common clk driver initialization functions for DaVinci
> SoCs and other SoCs that uses similar hardware architecture.
> clock.h also defines struct types for clock definitions in a SoC
> and clock data type for configuring clk-mux. The initialization
> functions are used by clock initialization code in a specific
> platform/SoC.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> +struct clk *davinci_plldiv_clk(const char *name, const char *parent,
> + struct clk_plldiv_data *data)
> +{
> + /*
> + * This is a PLL divider clock with divider specified by
> + * div_reg in pll_div_data.
> + */
> + data->reg = ioremap(data->phys_div_reg, 4);
> + if (WARN_ON(!data->reg))
> + return NULL;
> +
> + return clk_register_davinci_plldiv(NULL, name, parent, data, &_lock);
This function does not exist at this point. Looks like you need to swap
3/11 with 4/11. Also, you should also add build infrastructure
(makefile, Kconfig) changes in the same patch that creates the file.
There is no point in adding those separately.
Thanks,
Sekhar
^ permalink raw reply
* Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-11-01 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874nl9tuqq.fsf@deeprootsystems.com>
On Thu, Nov 1, 2012 at 12:42 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> [Me]
>> Well, the pinctrl grabbers in these drivers are using these states also
>> for platforms that do not even select CONFIG_PM. For example
>> mach-nomadik is quite happy that the PL011 driver is thusly
>> muxing in its pins. And would require refactoring to use PM
>> domains.
>
> If CONFIG_PM is disabled, then is it safe to assume that the pins in
> question are probably only done once at init time. I assume during
> ->probe(). ?
Sadly no.
Consider drivers/tty/serial/amba-pl011.c
Many ARM platforms have several instances of PL011, and not all of
them have CONFIG_PM & friends, so it's a good example.
Here the driver will probe and currently fetch a pinctrl handle and
looks up two states: "default", which refers to the situation you
describe, and optionally "sleep" which will put pins into a
low-power state.
The driver will currently put the pins into the "sleep" state when
.shutdown() is called by something (userspace or in-kernel users).
So in the new suggested scheme using runtime PM, this
would have to be replaced by pm_runtime_get[_sync]()
and pm_runtime_put() hints and the current pin handling
deleted, and for each platform using this driver instead
implement a PM domain to do the same thing.
Else you loose this runtime power optimization.
This is what I refer to the all-or-nothing charcter of
runtime PM domains... but maybe it's a good thing,
I haven't quite made my mind up about it.
> (...) if what we want/need are only ways to introduce SoC-specific
> integration details into non-PM transitions (e.g. probe/remove), maybe
> bus notifiers would suffice here. e.g. you'd get a bus notifier when
> the device is added/attached and any init-time pinctrl setup could be
> done then. This still keeps drivers clean of SoC-specific integration
> data/code, and also allows that to happen whether or not PM features are
> enabled.
It doesn't cut it for any of our drivers as shown above,
but it would work for the patch in $SUBJECT.
It sounds like the way silicon clocks are handled on
SH am I right?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: Fix the "WFI" instruction opcode definition.
From: Fei Yang @ 2012-11-01 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5091D13B.6060106@gmail.com>
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.
^ permalink raw reply
* [PATCH v3] ARM: dts: AM33xx: Add SPI node
From: Benoit Cousson @ 2012-11-01 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351680669-20718-1-git-send-email-avinashphilip@ti.com>
Hi Avinash,
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
> Add McSPI data node to AM33XX device tree file. The McSPI module (and so
> as the driver) is reused from OMAP4.
>
> Signed-off-by: Philip, Avinash <avinashphilip@ti.com>
> Tested-by: Matt Porter <mporter@ti.com>
I've just realized the interrupt-parent was still there, so I removed both.
Please find below the updated version.
Regards,
Benoit
----
>From 9fd3c748aac9418cd377249ca463050783d2198f Mon Sep 17 00:00:00 2001
From: Philip, Avinash <avinashphilip@ti.com>
Date: Wed, 31 Oct 2012 16:21:09 +0530
Subject: [PATCH] ARM: dts: AM33XX: Add SPI node
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash <avinashphilip@ti.com>
Tested-by: Matt Porter <mporter@ti.com>
[b-cousson at ti.com: Remove interrupt-parent]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 97a7bd3..5dfd682 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -299,5 +299,27 @@
76>;
ti,hwmods = "rtc";
};
+
+ spi0: spi at 48030000 {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x48030000 0x400>;
+ interrupt = <65>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi0";
+ status = "disabled";
+ };
+
+ spi1: spi at 481a0000 {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x481a0000 0x400>;
+ interrupt = <125>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi1";
+ status = "disabled";
+ };
};
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
From: Ben Gardiner @ 2012-11-01 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351197357-23528-5-git-send-email-rtivy@ti.com>
Hi Rob,
On Thu, Oct 25, 2012 at 4:35 PM, Robert Tivy <rtivy@ti.com> wrote:
> [...]
> @@ -660,6 +667,99 @@ int __init da850_register_mmcsd1(struct davinci_mmc_config *config)
> }
> #endif
>
> +static struct platform_device *da8xx_dsp;
> +
> +#ifdef CONFIG_CMA
> +
> +/*
> + * The following address range was chosen because the XDC Platform for
> + * OMAP-L138 DSP has this range as its default code/data placement.
> + */
> +#define DA8XX_RPROC_CMA_BASE (0xc3000000)
> [...]
> +/*
> + * The following address range was chosen because the XDC Platform for
> + * OMAP-L138 DSP has this range as its default code/data placement.
> + *
> + * System integrators must ensure that Linux does not own this range.
> + */
> +#define DA_CONTIG_BASE (0xc3000000)
> +#define DA_CONTIG_SIZE (0x02000000)
I am concerned with the rigidity of the memory hole as its definition
is currently proposed.
As you noted DA_CONTIG_BASE and DA_CONTIG_SIZE must describe a range
that is not used by Linux. Ideally this hole would not be in the
middle of the usuable memory but instead at the top. For L138 boards
with larger DDR packages this would mean carrying a patch to this
file.
I think the same also applies to DA8XX_RPROC_CMA_BASE but I have no
hands-on experience yet with CMA.
Is there any other means by which the hole's location and size can be
specified which does not require patching this file? I imagine KConfig
would work, but is this an acceptable use of KConfig?
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-11-01 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121101120713.GA4413@opensource.wolfsonmicro.com>
On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote:
> For the pin hogging I'd actually been thinking separately that we should
> just have the device core do a devm_pinctrl_get_set_default() prior to
> probing the device and store the result in the struct device. That
> would immediately remove almost all of the current pinctrl users, users
> that do need to do things with the data or check the result can then
> pick up the pinctrl pointer from the device struct.
I never thought of that. This sounds like it would work.
And the good thing is that this is a clean cut so we
will centralized code without having to decide right now
how to handle the pm idle/sleep cases.
Talking here with Kevin Hilman on my left and Grant
Likely on my right (they're physically here) there is some
worry about stashing stuff into struct device.
What if I retrieve this in the pinctrl subsystem using
bus notifiers and then expose the struct pinctrl * to
the clients by using pinctrl_get() and when you get
such a handle in your probe() you know that the
pinctrl subsystem has already fetched the handle and
set it to "default" at that point?
I just worry whether there is a fringe case where the default
state is not be be default-selected in probe(), the API
semantics does not mandate that. But I think this is the case
for all in-kernel drivers so we wouldn't be breaking anything
by doing this right now. And platforms can just leave the
"default" state undefined in that case.
>> It's actually something that needs to be acknowledged by the
>> ARM SoC maintainers, because they will be the ones telling
>> all subarch maintainers to go implement full PM handling
>> with these three frameworks whenever an SoC driver want
>> to handle pins.
>
> Well, they're going to have to implement it somewhere anyway - either in
> the drivers or in the SoC stuff.
Sure I just worry about it being done is several different ways
and creating a mess so they need to be involved to block
other approaches.
>> I can surely fix these for "my" systems, but it really needs
>> to be enforced widely or it will be a mess.
>
> We definitely need to decide if it's something that should be open coded
> everywhere.
If I prepare a patch to move the fetch+set defaul to the pinctrl
core using notifiers, we centralize one piece and we get the
currently floating patches out of the way.
Then what to do with sleep and idle is a question we need
to handle next. Requiring PM domains for this is one
approach, albeit a bit controversial.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: stacktrace: Fix return_address() for CONFIG_FRAME_POINTER
From: Dave Martin @ 2012-11-01 14:01 UTC (permalink / raw)
To: linux-arm-kernel
return_address() currently relies on walk_stackframe() setting
frame->lr, but walk_stackframe() never sets this field.
Setting frame->lr from walk_stackframe() would require
walk_stackframe() to unwind one frame beyond the frame being
returned, and to track extra state in struct stackframe.
The value of this is debatable, so this patch modifies
caller_address() to unwind one extra level explicitly and reference
frame->pc instead of frame->lr.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
arch/arm/kernel/return_address.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index 8085417..0854b54 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -26,7 +26,7 @@ static int save_return_addr(struct stackframe *frame, void *d)
struct return_address_data *data = d;
if (!data->level) {
- data->addr = (void *)frame->lr;
+ data->addr = (void *)frame->pc;
return 1;
} else {
@@ -41,7 +41,7 @@ void *return_address(unsigned int level)
struct stackframe frame;
register unsigned long current_sp asm ("sp");
- data.level = level + 1;
+ data.level = level + 2;
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.sp = current_sp;
--
1.7.5.4
^ permalink raw reply related
* [GIT PULL] Next batch of ux500 related patches due for -next
From: Lee Jones @ 2012-11-01 14:17 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
Linux 3.7-rc3 (2012-10-28 12:24:48 -0700)
are available in the git repository at:
git://git.linaro.org/people/ljones/linux-3.0-ux500.git ste-dt-for-next
for you to fetch changes up to f44c5fd12d8152e45585905422d03427754e1907:
ARM: ux500: Convert DT_MACHINE_START to use SMP operations (2012-11-01 13:02:28 +0100)
----------------------------------------------------------------
Lee Jones (31):
ARM: ux500: Move regulator-name properties out to board DTS files
ARM: ux500: Fix initialisation order for UIBs
ARM: ux500: Elaborate on SDI device node names in Device Tree
ARM: ux500: Add SDI (MMC) support to the HREF Device Tree
ARM: ux500: Correct Snowball's external SD/MMC slot's bus width
ARM: ux500: Create a DTS hierarchy for ST-Ericsson's HREF boards
ARM: ux500: Create a Device Tree for early HREFs
ARM: ux500: Add support for gpio-keys and Proximity Sensor for HREF
ARM: ux500: Remove platform specific device registration when DT is enabled
ARM: ux500: Move all Device Tree booting into cpu-db8500
ARM: ux500: Strip out duplicate touch screen platform information
Documentation: Detail permitted DT properties for the BU21013 Touch Screen
ARM: ux500: Create a new Device Tree include file for boards supporting STUIBs
ARM: ux500: Stop calling the UIB init function when using Device Tree
ARM: ux500: Add all bu21013 touch screen components to supported Device Trees
ARM: ux500: Stop informing the regulator subsystem that we have full constraints
ARM: ux500: Apply a Device Tree node for the STMPE MFD
ARM: ux500: Supply the STMPE keypad Device Tree node to the STUIB DT
ARM: ux500: Remove unused board compatible string
ARM: ux500: Add skeleton DTS file for the u9540
ARM: ux500: Add support for ST-Ericsson's u9540 SoC
ARM: ux500: Add UART support to the u9540 Device Tree
ARM: ux500: Enable SDI4 port on the u9540 when booting with Device Tree
ARM: ux500: Enable all MMC devices on the u9540 when booting with DT
ARM: ux500: Rename references to the ccu9540 dev board accordingly
ARM: ux500: Remove duplicate DT_MACHINE_START - make u8500 for generic
ARM: ux500: List DT compatibility using platform names rather than by board
ARM: ux500: Add node for the MMC GPIO regulator
ARM: ux500: Change the type of interrupt to something compatible
ARM: ux500: CONFIG: Enable GPIO Regulators
ARM: ux500: Convert DT_MACHINE_START to use SMP operations
.../bindings/input/touchscreen/bu21013.txt | 28 ++
arch/arm/boot/dts/ccu9540.dts | 72 ++++++
arch/arm/boot/dts/dbx5x0.dtsi | 57 ++--
arch/arm/boot/dts/href.dtsi | 273 ++++++++++++++++++++
arch/arm/boot/dts/hrefprev60.dts | 41 +++
arch/arm/boot/dts/hrefv60plus.dts | 83 +-----
arch/arm/boot/dts/snowball.dts | 140 +++++++++-
arch/arm/boot/dts/stuib.dtsi | 78 ++++++
arch/arm/configs/u8500_defconfig | 1 +
arch/arm/mach-ux500/board-mop500-stuib.c | 22 +-
arch/arm/mach-ux500/board-mop500.c | 146 +----------
arch/arm/mach-ux500/board-mop500.h | 8 +-
arch/arm/mach-ux500/cpu-db8500.c | 108 +++++++-
arch/arm/mach-ux500/cpu.c | 3 +
14 files changed, 779 insertions(+), 281 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/bu21013.txt
create mode 100644 arch/arm/boot/dts/ccu9540.dts
create mode 100644 arch/arm/boot/dts/href.dtsi
create mode 100644 arch/arm/boot/dts/hrefprev60.dts
create mode 100644 arch/arm/boot/dts/stuib.dtsi
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-11-01 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdawAdbwackZeST4iDkFZx9-exhTVoUzAABaWr1G89tATg@mail.gmail.com>
On Thu, Nov 01, 2012 at 03:01:28PM +0100, Linus Walleij wrote:
> On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
>
> > For the pin hogging I'd actually been thinking separately that we should
> > just have the device core do a devm_pinctrl_get_set_default() prior to
> > probing the device and store the result in the struct device. That
> What if I retrieve this in the pinctrl subsystem using
> bus notifiers and then expose the struct pinctrl * to
> the clients by using pinctrl_get() and when you get
> such a handle in your probe() you know that the
> pinctrl subsystem has already fetched the handle and
> set it to "default" at that point?
I'm not sure I parse a problem from the above?
> I just worry whether there is a fringe case where the default
> state is not be be default-selected in probe(), the API
> semantics does not mandate that. But I think this is the case
> for all in-kernel drivers so we wouldn't be breaking anything
> by doing this right now. And platforms can just leave the
> "default" state undefined in that case.
Yes, that had been my thinking too though I'd really expect that the
platform ought to be able to think of something sensible to do by
default.
> Then what to do with sleep and idle is a question we need
> to handle next. Requiring PM domains for this is one
> approach, albeit a bit controversial.
Yup. Notifiers are another option again I guess. There's far fewer
drivers doing anything at all with that so it's a bit less urgent.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121101/9d6217f3/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] Input: nomadik-ske-keypad - clk fixups
From: Ulf Hansson @ 2012-11-01 14:20 UTC (permalink / raw)
To: linux-arm-kernel
From: Ulf Hansson <ulf.hansson@linaro.org>
Due to the convert to the common clk driver these changes for clks are needed.
Ulf Hansson (2):
Input: nomadik-ske-keypad - fixup use of clk
Input: nomadik-ske-keypad - start using the apb_pclk
drivers/input/keyboard/nomadik-ske-keypad.c | 34 +++++++++++++++++++++++----
1 file changed, 29 insertions(+), 5 deletions(-)
--
1.7.10
^ permalink raw reply
* [PATCH 1/2] Input: nomadik-ske-keypad - fixup use of clk
From: Ulf Hansson @ 2012-11-01 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351779602-13818-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
Do proper error handling for clk and make sure clocks are being
prepared|unprepared as well as enabled|disabled.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/input/keyboard/nomadik-ske-keypad.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/input/keyboard/nomadik-ske-keypad.c b/drivers/input/keyboard/nomadik-ske-keypad.c
index 49f5fa6..95dcc9b 100644
--- a/drivers/input/keyboard/nomadik-ske-keypad.c
+++ b/drivers/input/keyboard/nomadik-ske-keypad.c
@@ -287,14 +287,19 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
keypad->keymap, input);
if (error) {
dev_err(&pdev->dev, "Failed to build keymap\n");
- goto err_iounmap;
+ goto err_clk;
}
input_set_capability(input, EV_MSC, MSC_SCAN);
if (!plat->no_autorepeat)
__set_bit(EV_REP, input->evbit);
- clk_enable(keypad->clk);
+ error = clk_prepare_enable(keypad->clk);
+ if (error) {
+ dev_err(&pdev->dev, "Failed to prepare/enable clk\n");
+ goto err_clk;
+ }
+
/* go through board initialization helpers */
if (keypad->board->init)
@@ -330,7 +335,8 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
err_free_irq:
free_irq(keypad->irq, keypad);
err_clk_disable:
- clk_disable(keypad->clk);
+ clk_disable_unprepare(keypad->clk);
+err_clk:
clk_put(keypad->clk);
err_iounmap:
iounmap(keypad->reg_base);
@@ -351,7 +357,7 @@ static int __devexit ske_keypad_remove(struct platform_device *pdev)
input_unregister_device(keypad->input);
- clk_disable(keypad->clk);
+ clk_disable_unprepare(keypad->clk);
clk_put(keypad->clk);
if (keypad->board->exit)
--
1.7.10
^ permalink raw reply related
* [PATCH 2/2] Input: nomadik-ske-keypad - start using the apb_pclk
From: Ulf Hansson @ 2012-11-01 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351779602-13818-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
Previously this clock was handled internally by the clockdriver,
but now this is separate clk. So we need take care of it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/input/keyboard/nomadik-ske-keypad.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/nomadik-ske-keypad.c b/drivers/input/keyboard/nomadik-ske-keypad.c
index 95dcc9b..a1a9375 100644
--- a/drivers/input/keyboard/nomadik-ske-keypad.c
+++ b/drivers/input/keyboard/nomadik-ske-keypad.c
@@ -67,6 +67,7 @@ struct ske_keypad {
const struct ske_keypad_platform_data *board;
unsigned short keymap[SKE_KPD_NUM_ROWS * SKE_KPD_NUM_COLS];
struct clk *clk;
+ struct clk *pclk;
spinlock_t ske_keypad_lock;
};
@@ -271,11 +272,18 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
goto err_free_mem_region;
}
+ keypad->pclk = clk_get(&pdev->dev, "apb_pclk");
+ if (IS_ERR(keypad->pclk)) {
+ dev_err(&pdev->dev, "failed to get pclk\n");
+ error = PTR_ERR(keypad->pclk);
+ goto err_iounmap;
+ }
+
keypad->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(keypad->clk)) {
dev_err(&pdev->dev, "failed to get clk\n");
error = PTR_ERR(keypad->clk);
- goto err_iounmap;
+ goto err_pclk;
}
input->id.bustype = BUS_HOST;
@@ -294,10 +302,16 @@ static int __init ske_keypad_probe(struct platform_device *pdev)
if (!plat->no_autorepeat)
__set_bit(EV_REP, input->evbit);
+ error = clk_prepare_enable(keypad->pclk);
+ if (error) {
+ dev_err(&pdev->dev, "Failed to prepare/enable pclk\n");
+ goto err_clk;
+ }
+
error = clk_prepare_enable(keypad->clk);
if (error) {
dev_err(&pdev->dev, "Failed to prepare/enable clk\n");
- goto err_clk;
+ goto err_pclk_disable;
}
@@ -336,8 +350,12 @@ err_free_irq:
free_irq(keypad->irq, keypad);
err_clk_disable:
clk_disable_unprepare(keypad->clk);
+err_pclk_disable:
+ clk_disable_unprepare(keypad->pclk);
err_clk:
clk_put(keypad->clk);
+err_pclk:
+ clk_put(keypad->pclk);
err_iounmap:
iounmap(keypad->reg_base);
err_free_mem_region:
--
1.7.10
^ permalink raw reply related
* [PATCH] i2c: mxs: remove broken PIOQUEUE support
From: Marek Vasut @ 2012-11-01 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351771003-6071-1-git-send-email-w.sang@pengutronix.de>
Dear Wolfram Sang,
> This I2C master can do DMA and PIOQUEUE (PIO with FIFO). Originally,
> only PIOQEUE
PIOQUEUE ;-)
> was supported, then DMA support was added. The original
> intention was to keep PIOQUEUE since it has less overhead what is nice
> for small transfers. However, runtime switching between PIOQEUE and DMA
> depending on the transfer size never worked despite a lot of trying.
> Since PIOQUEUE mode itself was flaky (polling at places where interrupts
> failed to work) and the implementation also imposed a size limit for
> transfers, it is best to remove the support altogether which makes the
> driver a lot cleaner and more robust. If somebody really wants less
> overhead, plain PIO mode could still be implemented with the addidtional
> advantage that this mode is also available on MX23, too.
Yes, looks to be the way to go.
Reviewed-by: Marek Vasut <marex@denx.de>
Thanks
[...]
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 1/6] arch: Change defconfigs to point to g_mass_storage.
From: Alan Stern @ 2012-11-01 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <46dde680f525562e9fd19567deb5247f0bf26842.1351715302.git.mina86@mina86.com>
On Wed, 31 Oct 2012, Michal Nazarewicz wrote:
> From: Michal Nazarewicz <mina86@mina86.com>
>
> The File-backed Storage Gadget (g_file_storage) is being removed, since
> it has been replaced by Mass Storage Gadget (g_mass_storage). This commit
> changes defconfigs point to the new gadget.
...
> --- a/arch/arm/configs/qil-a9260_defconfig
> +++ b/arch/arm/configs/qil-a9260_defconfig
> @@ -108,7 +108,6 @@ CONFIG_ROOT_NFS=y
> CONFIG_NLS_CODEPAGE_437=y
> CONFIG_NLS_CODEPAGE_850=y
> CONFIG_NLS_ISO8859_1=y
> -CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_USER=y
> CONFIG_DEBUG_LL=y
> # CONFIG_CRYPTO_HW is not set
This seems to have crept in by mistake.
Alan Stern
^ permalink raw reply
* [Patch v2 3/4] ASoC: atmel-ssc-dai: register platform from DAIs
From: Mark Brown @ 2012-11-01 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351668420-18447-3-git-send-email-voice.shen@atmel.com>
On Wed, Oct 31, 2012 at 03:26:59PM +0800, Bo Shen wrote:
> +Required properties:
> + - compatible: "atmel,atmel-ssc-dai"
> + - atmel,dai-master: this dai base on which ssc controller
> +Example:
> +dai: dai {
> + compatible = "atmel,atmel-ssc-dai";
> + atmel,dai-master = <&ssc0>;
> +};
This seems to be a purely virtual device which remaps the SSC onto the
Linux audio subsystem? If that is the case then it shouldn't appear in
the device tree, the machine driver should just directly reference the
SSC and instantiate any devices required in Linux directly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121101/daf7cdde/attachment-0001.sig>
^ 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