* [PATCH 2/2] msm: clock: Migrate to clkdev
From: David Brown @ 2011-02-28 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298482662-27298-3-git-send-email-sboyd@codeaurora.org>
On Wed, Feb 23 2011, Stephen Boyd wrote:
> Migrating to clkdev has several advantages:
>
> * Less code in mach-msm/clock.c
>
> * A more robust clk_get() implementation
>
> * clk_add_alias() support
>
> * clk_get_sys() support
>
> In general, this will help board authors setup clock aliases and
> break the dependency on device pointers in the clock tables.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/mach-msm/board-msm7x30.c | 1 +
> arch/arm/mach-msm/board-msm8960.c | 1 +
> arch/arm/mach-msm/board-qsd8x50.c | 1 +
> arch/arm/mach-msm/board-trout.c | 1 +
> arch/arm/mach-msm/clock-7x30.h | 31 +++++++++++++-----------
> arch/arm/mach-msm/clock-pcom.h | 16 +++++++-----
> arch/arm/mach-msm/clock.c | 39 ++++++++-----------------------
> arch/arm/mach-msm/clock.h | 2 -
> arch/arm/mach-msm/devices-msm7x00.c | 32 ++++++++++++------------
> arch/arm/mach-msm/devices-msm7x30.c | 5 ++-
> arch/arm/mach-msm/devices-qsd8x50.c | 23 +++++++++--------
> arch/arm/mach-msm/devices.h | 8 ++++--
> arch/arm/mach-msm/include/mach/board.h | 4 +-
> arch/arm/mach-msm/include/mach/clkdev.h | 19 +++++++++++++++
> 15 files changed, 98 insertions(+), 86 deletions(-)
> create mode 100644 arch/arm/mach-msm/include/mach/clkdev.h
This doesn't seem to apply cleanly. Do you mind resending this against
the msm for/next branch.
Thanks,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 3/8] Add a mfd IPUv3 driver
From: Thomas Gleixner @ 2011-02-28 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298887229-7987-4-git-send-email-s.hauer@pengutronix.de>
On Mon, 28 Feb 2011, Sascha Hauer wrote:
> +
> +static int ipu_use_count;
> +
> +static struct ipu_channel channels[64];
> +
> +struct ipu_channel *ipu_idmac_get(unsigned num)
> +{
> + struct ipu_channel *channel;
> +
> + dev_dbg(ipu_dev, "%s %d\n", __func__, num);
> +
> + if (num > 63)
>= ARRAY_SIZE(channels) or a sensible define please
> + return ERR_PTR(-ENODEV);
> +
> + mutex_lock(&ipu_channel_lock);
> +
> + channel = &channels[num];
> +
> + if (channel->busy) {
> + channel = ERR_PTR(-EBUSY);
> + goto out;
> + }
> +
> + channel->busy = 1;
> + channel->num = num;
> +
> +out:
> + mutex_unlock(&ipu_channel_lock);
> +
> + return channel;
> +}
> +EXPORT_SYMBOL(ipu_idmac_get);
EXPORT_SYMBOL_GPL all over the place
> +void ipu_idmac_put(struct ipu_channel *channel)
> +{
> + dev_dbg(ipu_dev, "%s %d\n", __func__, channel->num);
Do we really need this debug stuff in all these functions ?
> + mutex_lock(&ipu_channel_lock);
> +
> + channel->busy = 0;
> +
> + mutex_unlock(&ipu_channel_lock);
> +}
> +EXPORT_SYMBOL(ipu_idmac_put);
> +
Also exported functions want a proper kerneldoc comment.
> +void ipu_idmac_set_double_buffer(struct ipu_channel *channel, bool doublebuffer)
> +static LIST_HEAD(ipu_irq_handlers);
> +
> +static void ipu_irq_update_irq_mask(void)
> +{
> + struct ipu_irq_handler *handler;
> + int i;
> +
> + DECLARE_IPU_IRQ_BITMAP(irqs);
Why the hell do we need this? It's a bog standard bitmap, right ?
> + bitmap_zero(irqs, IPU_IRQ_COUNT);
> +
> + list_for_each_entry(handler, &ipu_irq_handlers, list)
> + bitmap_or(irqs, irqs, handler->ipu_irqs, IPU_IRQ_COUNT);
> +
> + for (i = 0; i < BITS_TO_LONGS(IPU_IRQ_COUNT); i++)
> + ipu_cm_write(irqs[i], IPU_INT_CTRL(i + 1));
> +}
> +static void ipu_completion_handler(unsigned long *bitmask, void *context)
> +{
> + struct completion *completion = context;
> +
> + complete(completion);
> +}
> +
> +int ipu_wait_for_interrupt(int interrupt, int timeout_ms)
> +{
> + struct ipu_irq_handler handler;
> + DECLARE_COMPLETION_ONSTACK(completion);
> + int ret;
> +
> + bitmap_zero(handler.ipu_irqs, IPU_IRQ_COUNT);
> + bitmap_set(handler.ipu_irqs, interrupt, 1);
> +
> + ipu_cm_write(1 << (interrupt % 32), IPU_INT_STAT(interrupt / 32 + 1));
> +
> + handler.handler = ipu_completion_handler;
> + handler.context = &completion;
> + ipu_irq_add_handler(&handler);
> +
> + ret = wait_for_completion_timeout(&completion,
> + msecs_to_jiffies(timeout_ms));
> +
> + ipu_irq_remove_handler(&handler);
> +
> + if (ret > 0)
> + ret = 0;
> + else
> + ret = -ETIMEDOUT;
> +
> + return ret;
return ret > 0 ? 0 : -ETIMEDOUT;
perhaps ?
> +}
> +EXPORT_SYMBOL(ipu_wait_for_interrupt);
> +
> +static irqreturn_t ipu_irq_handler(int irq, void *desc)
> +{
> + DECLARE_IPU_IRQ_BITMAP(status);
> + struct ipu_irq_handler *handler;
> + int i;
> +
> + for (i = 0; i < BITS_TO_LONGS(IPU_IRQ_COUNT); i++) {
> + status[i] = ipu_cm_read(IPU_INT_STAT(i + 1));
> + ipu_cm_write(status[i], IPU_INT_STAT(i + 1));
> + }
> +
> + list_for_each_entry(handler, &ipu_irq_handlers, list) {
> + DECLARE_IPU_IRQ_BITMAP(tmp);
> + if (bitmap_and(tmp, status, handler->ipu_irqs, IPU_IRQ_COUNT))
> + handler->handler(tmp, handler->context);
> + }
And what protects the list walk? Just the fact that this is a UP
machine?
> +void ipu_put(void)
> +{
> + mutex_lock(&ipu_channel_lock);
> +
> + ipu_use_count--;
> +
> + if (ipu_use_count == 0)
> + clk_disable(ipu_clk);
> +
> + if (ipu_use_count < 0) {
> + dev_err(ipu_dev, "ipu use count < 0\n");
This wants to be a WARN_ON(ipu_use_count < 0) so you get some
information which code is calling this.
> + ipu_use_count = 0;
> + }
> +
> + mutex_unlock(&ipu_channel_lock);
> +}
> +static int __devinit ipu_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + unsigned long ipu_base;
> + int ret, irq1, irq2;
> +
> + /* There can be only one */
> + if (ipu_dev)
> + return -EBUSY;
> +
> + spin_lock_init(&ipu_lock);
> +
> + ipu_dev = &pdev->dev;
> +
> + irq1 = platform_get_irq(pdev, 0);
> + irq2 = platform_get_irq(pdev, 1);
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> + if (!res || irq1 < 0 || irq2 < 0)
> + return -ENODEV;
> +
> + ipu_base = res->start;
> +
> + ipu_cm_reg = ioremap(ipu_base + IPU_CM_REG_BASE, PAGE_SIZE);
> + if (!ipu_cm_reg) {
> + ret = -ENOMEM;
> + goto failed_ioremap1;
> + }
> +
> + ipu_idmac_reg = ioremap(ipu_base + IPU_IDMAC_REG_BASE, PAGE_SIZE);
> + if (!ipu_idmac_reg) {
> + ret = -ENOMEM;
> + goto failed_ioremap2;
> + }
> +
> + ipu_clk = clk_get(&pdev->dev, "ipu");
> + if (IS_ERR(ipu_clk)) {
> + ret = PTR_ERR(ipu_clk);
> + dev_err(&pdev->dev, "clk_get failed with %d", ret);
> + goto failed_clk_get;
> + }
> +
> + ipu_get();
> +
> + ret = request_irq(irq1, ipu_irq_handler, IRQF_DISABLED, pdev->name,
> + &pdev->dev);
s/IRQF_DISABLED/0/ We run all handlers with interrupts disabled
nowadays.
> + ret = ipu_submodules_init(pdev, ipu_base, ipu_clk);
> + if (ret)
> + goto failed_submodules_init;
> +
> + /* Set sync refresh channels as high priority */
> + ipu_idmac_write(0x18800000, IDMAC_CHA_PRI(0));
Hmm, this random prio setting here is odd.
> + ret = ipu_add_client_devices(pdev);
> + if (ret) {
> + dev_err(&pdev->dev, "adding client devices failed with %d\n", ret);
> + goto failed_add_clients;
> + }
White space damage.
> + ret = ipu_wait_for_interrupt(irq, 50);
> + if (ret)
> + return;
> +
> + /* Wait for DC triple buffer to empty */
> + if (dc_channels[dc_chan].di == 0)
> + while ((__raw_readl(DC_STAT) & 0x00000002)
> + != 0x00000002) {
> + msleep(2);
> + timeout -= 2;
> + if (timeout <= 0)
> + break;
So we poll stuff which is updated from some other function ?
> + }
> + else if (dc_channels[dc_chan].di == 1)
> + while ((__raw_readl(DC_STAT) & 0x00000020)
> + != 0x00000020) {
> + msleep(2);
> + timeout -= 2;
> + if (timeout <= 0)
> + break;
Ditto
> + }
Thanks,
tglx
^ permalink raw reply
* [PATCH v3 2/5] ARM: pm: add generic CPU suspend/resume support
From: Jean Pihet @ 2011-02-28 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3f574626437da8db9f7844d5bb031046@mail.gmail.com>
On Sat, Feb 12, 2011 at 4:09 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
>> Sent: Saturday, February 12, 2011 8:20 PM
>> To: Santosh Shilimkar
>> Cc: Colin Cross; Kukjin Kim; saeed bishara; linux-arm-
>> kernel at lists.infradead.org
>> Subject: Re: [PATCH v3 2/5] ARM: pm: add generic CPU suspend/resume
>> support
>>
>> On Fri, Feb 11, 2011 at 05:37:04PM +0530, Santosh Shilimkar wrote:
>> > There is a Monitor secure API, needs to be called from non-secure
>> > software to set this diagnostic registers in resume path.
>>
>> It would be an idea to get the OMAP sleep code up to date so that I
>> can
>> look at OMAPs requirements for this to be useful.
>>
>> As the current code stands, I don't see any reason why the sleep34xx
>> code
>> can't use this infrastructure, but I'm loathed to start modifying
>> that if there's outstanding code changes in that area.
>
> Yep. There are few issues out there with sleep34xx code.
> ? ? ? ?- Secure APIs
> ? ? ? ?- Current code needs to be cleaned up to remove
> ? ? ? ?unwanted registers save restore
> ? ? ? ?- Some part of the code on OMAP3 must be run from
> ? ? ? ?SRAM. It can't run from DDR
This is not the highest priority for now, I will have to come back
later on this.
> ? ? ? ?- AUXCTLR, Diagnostic registers aren't accessible
> ? ? ? ?in secure mode.
> ? ? ? ?- L2 cache needs to be handled with secure APIs.
> ? ? ? ?- Code sequence needs to handle errata's handling
> ? ? ? ?which accesses OMAP PM registers.
Also there is some on-going work to support Thumb-2, adding Dave.
>
> Few of the above are getting addressed for this merge window.
>
> So my plan was to take a look at generic suspend after the
> merge window. By that time your generic stuff and omap
> cleanup would have got merged hopefully.
Agree!
>
> Regards,
> Santosh
Regards,
Jean
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v3 2/5] ARM: pm: add generic CPU suspend/resume support
From: Santosh Shilimkar @ 2011-02-28 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3f574626437da8db9f7844d5bb031046@mail.gmail.com>
+ linux-omap on this thread.
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> Sent: Saturday, February 12, 2011 8:40 PM
> To: Russell King - ARM Linux
> Cc: Colin Cross; Kukjin Kim; saeed bishara; linux-arm-
> kernel at lists.infradead.org
> Subject: RE: [PATCH v3 2/5] ARM: pm: add generic CPU suspend/resume
> support
>
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Saturday, February 12, 2011 8:20 PM
> > To: Santosh Shilimkar
> > Cc: Colin Cross; Kukjin Kim; saeed bishara; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [PATCH v3 2/5] ARM: pm: add generic CPU
> suspend/resume
> > support
> >
> > On Fri, Feb 11, 2011 at 05:37:04PM +0530, Santosh Shilimkar wrote:
> > > There is a Monitor secure API, needs to be called from non-
> secure
> > > software to set this diagnostic registers in resume path.
> >
> > It would be an idea to get the OMAP sleep code up to date so that
> I
> > can
> > look at OMAPs requirements for this to be useful.
> >
> > As the current code stands, I don't see any reason why the
> sleep34xx
> > code
> > can't use this infrastructure, but I'm loathed to start modifying
> > that if there's outstanding code changes in that area.
>
> Yep. There are few issues out there with sleep34xx code.
> - Secure APIs
> - Current code needs to be cleaned up to remove
> unwanted registers save restore
> - Some part of the code on OMAP3 must be run from
> SRAM. It can't run from DDR
> - AUXCTLR, Diagnostic registers aren't accessible
> in secure mode.
> - L2 cache needs to be handled with secure APIs.
> - Code sequence needs to handle errata's handling
> which accesses OMAP PM registers.
>
> Few of the above are getting addressed for this merge window.
>
> So my plan was to take a look at generic suspend after the
> merge window. By that time your generic stuff and omap
> cleanup would have got merged hopefully.
>
> Regards,
> Santosh
^ permalink raw reply
* [patch 1/2] mc13892: reboot on wdi event
From: Mark Brown @ 2011-02-28 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k4gkyydi.fsf@lebrac.rtp-net.org>
On Mon, Feb 28, 2011 at 04:25:45PM +0100, Arnaud Patard wrote:
> afaik, mc13892 is used only on imx designs and the reset for imx is done
> only throught the watchdog. From this point of view, I don't see any
> valid reason for powering off instead of rebooting on watchdog event
Is there a separate way to do power off?
^ permalink raw reply
* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-28 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228140327.GA1937@n2100.arm.linux.org.uk>
Hi Russell,
> On Mon, Feb 28, 2011 at 01:33:42PM +0000, Will Deacon wrote:
> > The chained GPIO IRQ handler for the nomadik platform can be called
> > with the GIC as its host chip on the mach-ux500 machines.
> >
> > This patch updates the code to use ->irq_eoi when it is available.
> >
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm/plat-nomadik/gpio.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/plat-nomadik/gpio.c b/arch/arm/plat-nomadik/gpio.c
> > index 1e88ecb..51cc71b 100644
> > --- a/arch/arm/plat-nomadik/gpio.c
> > +++ b/arch/arm/plat-nomadik/gpio.c
> > @@ -538,6 +538,8 @@ static void nmk_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
> > }
> >
> > host_chip->irq_unmask(&desc->irq_data);
> > + if (host_chip->irq_eoi)
> > + host_chip->irq_eoi(&desc->irq_data);
>
> I notice in some you delete the irq_unmask, others you leave it. Shouldn't
> they all be similar?
It depends on whether or not the parent chip is always the GIC. In some cases
it can be a different IRQ chip, so we need to call the functions conditionally.
> Maybe we do something like:
>
> static inline void chained_irq_exit(struct irq_chip *chip, struct irq_desc *desc)
> {
> if (chip->irq_eoi)
> chip->irq_eoi(&desc->irq_data);
> else
> chip->irq_unmask(&desc->irq_data);
> }
>
> to cover these exit paths in a common way?
Yes, that is cleaner and potentially less confusing. We'll also need an entry
function which will do something like:
if (!chip->irq_eoi)
chip->irq_mask(&desc->irq_data);
which does look pretty odd, so factoring it out (with a comment) will
make it a little clearer.
I'll see if I get any feedback about nomadik and msm and then post a v3
with the entry/exit functions.
Will
^ permalink raw reply
* [PATCH 3/3] OMAP: use PM QOS for wake-up constraints from I2C
From: jean.pihet at newoldbits.com @ 2011-02-28 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298914884-16468-1-git-send-email-j-pihet@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Implements the PM QOS API for the wake-up constraints on the MPU.
Note: the caller shall allocate and store the PM QOS handle for future use
(update/removal of the constraint).
Based on the original patch from Vishwanath,
cf. https://patchwork.kernel.org/patch/327312/
Cc: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
---
arch/arm/plat-omap/i2c.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 3341ca4..207a320 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -117,10 +117,15 @@ static inline int omap1_i2c_add_bus(int bus_id)
* XXX This function is a temporary compatibility wrapper - only
* needed until the I2C driver can be converted to call
* omap_pm_set_max_dev_wakeup_lat() and handle a return code.
+ *
+ * The PM QOS handle is stored in the corresponding omap_device struct.
*/
static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
+ struct omap_device *od = to_omap_device(to_platform_device(dev));
+
+ if (od->pm_qos_request)
+ omap_pm_set_max_mpu_wakeup_lat(od->pm_qos_request, t);
}
static struct omap_device_pm_latency omap_i2c_latency[] = {
@@ -160,11 +165,26 @@ static inline int omap2_i2c_add_bus(int bus_id)
*/
if (cpu_is_omap34xx())
pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
+
od = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
omap_i2c_latency, ARRAY_SIZE(omap_i2c_latency), 0);
WARN(IS_ERR(od), "Could not build omap_device for %s\n", name);
+ /* Allocate the PM QOS handle and initialize it */
+ if ((!(IS_ERR(od))) && cpu_is_omap34xx()) {
+ od->pm_qos_request = kzalloc(sizeof(struct pm_qos_request_list),
+ GFP_KERNEL);
+ if (od->pm_qos_request) {
+ pm_qos_add_request(od->pm_qos_request,
+ PM_QOS_CPU_DMA_LATENCY,
+ PM_QOS_DEFAULT_VALUE);
+ } else {
+ WARN(1, "%s: could not reserve memory for "
+ "pm_qos_request\n", __func__);
+ }
+ }
+
return PTR_ERR(od);
}
#else
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] OMAP: implement MPU and DMA wake-up constraints using PM_QOS
From: jean.pihet at newoldbits.com @ 2011-02-28 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298914884-16468-1-git-send-email-j-pihet@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Implement the wake-up constraints using the PM QOS API.
Due to the nature of PM QOS only the MPU and DMA constraints
can be used.
Due to the implementation of cpuidle on OMAP34xx
(in arch/arm/mach-omap2/cpuidle34xx.c) only the global
C-states wakeup latencies are used to determine the next
state of the MPU and CORE power domains.
The PM QOS handle pointer is stored inside the omap_device structure
and so the patch only applies to OMAP devices.
To be replaced by a more generic solution which allows every
device to put a constraint, and which can control all power
domains in the system. This solution is currently under
investigation.
Based on the original patch from Vishwanath,
cf. https://patchwork.kernel.org/patch/327312/
Cc: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
---
arch/arm/plat-omap/include/plat/omap-pm.h | 96 ++++++++++++++-----------
arch/arm/plat-omap/include/plat/omap_device.h | 1 +
arch/arm/plat-omap/omap-pm-constraints.c | 80 +++++++++------------
arch/arm/plat-omap/omap-pm-noop.c | 70 +++++++++---------
4 files changed, 124 insertions(+), 123 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-omap/include/plat/omap-pm.h
index c0a7520..7180473 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -18,6 +18,7 @@
#include <linux/cpufreq.h>
#include <linux/clk.h>
#include <linux/opp.h>
+#include <linux/pm_qos_params.h>
/*
* agent_id values for use with omap_pm_set_min_bus_tput():
@@ -70,44 +71,6 @@ void omap_pm_if_exit(void);
* Device-driver-originated constraints (via board-*.c files, platform_data)
*/
-
-/**
- * omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
- * @dev: struct device * requesting the constraint
- * @t: maximum MPU wakeup latency in microseconds
- *
- * Request that the maximum interrupt latency for the MPU to be no
- * greater than @t microseconds. "Interrupt latency" in this case is
- * defined as the elapsed time from the occurrence of a hardware or
- * timer interrupt to the time when the device driver's interrupt
- * service routine has been entered by the MPU.
- *
- * It is intended that underlying PM code will use this information to
- * determine what power state to put the MPU powerdomain into, and
- * possibly the CORE powerdomain as well, since interrupt handling
- * code currently runs from SDRAM. Advanced PM or board*.c code may
- * also configure interrupt controller priorities, OCP bus priorities,
- * CPU speed(s), etc.
- *
- * This function will not affect device wakeup latency, e.g., time
- * elapsed from when a device driver enables a hardware device with
- * clk_enable(), to when the device is ready for register access or
- * other use. To control this device wakeup latency, use
- * omap_pm_set_max_dev_wakeup_lat()
- *
- * Multiple calls to omap_pm_set_max_mpu_wakeup_lat() will replace the
- * previous t value. To remove the latency target for the MPU, call
- * with t = -1.
- *
- * XXX This constraint will be deprecated soon in favor of the more
- * general omap_pm_set_max_dev_wakeup_lat()
- *
- * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
- * is not satisfiable, or 0 upon success.
- */
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
-
-
/**
* omap_pm_set_min_bus_tput - set minimum bus throughput needed by device
* @dev: struct device * requesting the constraint
@@ -139,7 +102,6 @@ int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
*/
int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r);
-
/**
* omap_pm_set_max_dev_wakeup_lat - set the maximum device enable latency
* @req_dev: struct device * requesting the constraint, or NULL if none
@@ -169,10 +131,53 @@ int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r);
int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev,
long t);
+/**
+ * omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
+ * @qos_request: handle for the constraint
+ * @t: maximum MPU wakeup latency in microseconds
+ *
+ * Request that the maximum interrupt latency for the MPU to be no
+ * greater than @t microseconds. "Interrupt latency" in this case is
+ * defined as the elapsed time from the occurrence of a hardware or
+ * timer interrupt to the time when the device driver's interrupt
+ * service routine has been entered by the MPU.
+ *
+ * It is intended that underlying PM code will use this information to
+ * determine what power state to put the MPU powerdomain into, and
+ * possibly the CORE powerdomain as well, since interrupt handling
+ * code currently runs from SDRAM. Advanced PM or board*.c code may
+ * also configure interrupt controller priorities, OCP bus priorities,
+ * CPU speed(s), etc.
+ *
+ * This function will not affect device wakeup latency, e.g., time
+ * elapsed from when a device driver enables a hardware device with
+ * clk_enable(), to when the device is ready for register access or
+ * other use. To control this device wakeup latency, use
+ * omap_pm_set_max_dev_wakeup_lat()
+ *
+ * Multiple calls to omap_pm_set_max_mpu_wakeup_lat() will replace the
+ * previous t value. To remove the latency target for the MPU, call
+ * with t = -1.
+ *
+ * Notes about the qos_request handle:
+ * - the caller has to first allocate the pm_qos_request_list struct and
+ * then call pm_qos_add_request(qos_request, PM_QOS_CPU_DMA_LATENCY,
+ * PM_QOS_DEFAULT_VALUE) in order to initialize the constraint struct.
+ * - the handle is stored by the caller for later use (update or removal of
+ * the constraint).
+ *
+ * XXX This constraint will be deprecated soon in favor of the more
+ * general omap_pm_set_max_dev_wakeup_lat()
+ *
+ * Returns -EINVAL for an invalid argument, -ERANGE if the constraint
+ * is not satisfiable, or 0 upon success.
+ */
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list *qos_request,
+ long t);
/**
* omap_pm_set_max_sdma_lat - set the maximum system DMA transfer start latency
- * @dev: struct device *
+ * @qos_request: handle for the constraint
* @t: maximum DMA transfer start latency in microseconds
*
* Request that the maximum system DMA transfer start latency for this
@@ -194,11 +199,18 @@ int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev,
* value for this device. To remove the maximum DMA latency for this
* device, call with t = -1.
*
+ * Notes about the qos_request handle:
+ * - the caller has to first allocate the pm_qos_request_list struct and
+ * then call pm_qos_add_request(qos_request, PM_QOS_CPU_DMA_LATENCY,
+ * PM_QOS_DEFAULT_VALUE) in order to initialize the constraint struct.
+ * - the handle is stored by the caller for later use (update or removal of
+ * the constraint).
+ *
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_sdma_lat(struct device *dev, long t);
-
+int omap_pm_set_max_sdma_lat(struct pm_qos_request_list *qos_request,
+ long t);
/**
* omap_pm_set_min_clk_rate - set minimum clock rate requested by @dev
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..8826295 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -73,6 +73,7 @@ struct omap_device {
s8 pm_lat_level;
u8 hwmods_cnt;
u8 _state;
+ struct pm_qos_request_list *pm_qos_request;
};
/* Device driver interface (call via platform_data fn ptrs) */
diff --git a/arch/arm/plat-omap/omap-pm-constraints.c b/arch/arm/plat-omap/omap-pm-constraints.c
index c8b4e4c..66366b1 100644
--- a/arch/arm/plat-omap/omap-pm-constraints.c
+++ b/arch/arm/plat-omap/omap-pm-constraints.c
@@ -28,38 +28,10 @@
static bool off_mode_enabled;
static u32 dummy_context_loss_counter;
+
/*
* Device-driver-originated constraints (via board-*.c files)
*/
-
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
-{
- if (!dev || t < -1) {
- WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
- return -EINVAL;
- };
-
- if (t == -1)
- pr_debug("OMAP PM: remove max MPU wakeup latency constraint: "
- "dev %s\n", dev_name(dev));
- else
- pr_debug("OMAP PM: add max MPU wakeup latency constraint: "
- "dev %s, t = %ld usec\n", dev_name(dev), t);
-
- /*
- * For current Linux, this needs to map the MPU to a
- * powerdomain, then go through the list of current max lat
- * constraints on the MPU and find the smallest. If
- * the latency constraint has changed, the code should
- * recompute the state to enter for the next powerdomain
- * state.
- *
- * TI CDP code can call constraint_set here.
- */
-
- return 0;
-}
-
int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r)
{
if (!dev || (agent_id != OCP_INITIATOR_AGENT &&
@@ -118,33 +90,47 @@ int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev,
return 0;
}
-int omap_pm_set_max_sdma_lat(struct device *dev, long t)
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list *qos_request,
+ long t)
{
- if (!dev || t < -1) {
+ /*
+ * The current state is: use PM QOS with the PM_QOS_CPU_DMA_LATENCY
+ * as pm_qos class. PM QOS records and sorts the constraints.
+ * Cpuidle is using PM QOS to retrieve the strongest constraint
+ * from the list, then changes the MPU and CORE power domains
+ * states to honor the constraint.
+ * Note that only MPU and CORE power domains states are affected.
+ *
+ * This shall use omap_pm_set_max_dev_wakeup_lat with the MPU
+ * as the device to put the constraints on
+ */
+ if (!qos_request || t < -1) {
WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
return -EINVAL;
};
- if (t == -1)
- pr_debug("OMAP PM: remove max DMA latency constraint: "
- "dev %s\n", dev_name(dev));
- else
- pr_debug("OMAP PM: add max DMA latency constraint: "
- "dev %s, t = %ld usec\n", dev_name(dev), t);
+ if (t == -1) {
+ pm_qos_update_request(qos_request, PM_QOS_DEFAULT_VALUE);
+ pr_debug("OMAP PM: remove max MPU wakeup latency "
+ "constraint\n");
+ } else {
+ pm_qos_update_request(qos_request, t);
+ pr_debug("OMAP PM: add max MPU wakeup latency constraint: "
+ "t=%ld us\n", t);
+ }
+
+ return 0;
+}
+int omap_pm_set_max_sdma_lat(struct pm_qos_request_list *qos_request, long t)
+{
/*
- * For current Linux PM QOS params, this code should scan the
- * list of maximum CPU and DMA latencies and select the
- * smallest, then set cpu_dma_latency pm_qos_param
- * accordingly.
- *
- * For future Linux PM QOS params, with separate CPU and DMA
- * latency params, this code should just set the dma_latency param.
+ * Currently identical to omap_pm_set_max_mpu_wakeup_lat.
*
- * TI CDP code can call constraint_set here.
+ * This shall use omap_pm_set_max_dev_wakeup_lat with the SDMA
+ * as device to put the constraints on
*/
-
- return 0;
+ return omap_pm_set_max_mpu_wakeup_lat(qos_request, t);
}
int omap_pm_set_min_clk_rate(struct device *dev, struct clk *c, long r)
diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-omap/omap-pm-noop.c
index b0471bb2..10b39b1 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -29,38 +29,10 @@
static bool off_mode_enabled;
static u32 dummy_context_loss_counter;
+
/*
* Device-driver-originated constraints (via board-*.c files)
*/
-
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
-{
- if (!dev || t < -1) {
- WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
- return -EINVAL;
- };
-
- if (t == -1)
- pr_debug("OMAP PM: remove max MPU wakeup latency constraint: "
- "dev %s\n", dev_name(dev));
- else
- pr_debug("OMAP PM: add max MPU wakeup latency constraint: "
- "dev %s, t = %ld usec\n", dev_name(dev), t);
-
- /*
- * For current Linux, this needs to map the MPU to a
- * powerdomain, then go through the list of current max lat
- * constraints on the MPU and find the smallest. If
- * the latency constraint has changed, the code should
- * recompute the state to enter for the next powerdomain
- * state.
- *
- * TI CDP code can call constraint_set here.
- */
-
- return 0;
-}
-
int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r)
{
if (!dev || (agent_id != OCP_INITIATOR_AGENT &&
@@ -119,19 +91,49 @@ int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev,
return 0;
}
-int omap_pm_set_max_sdma_lat(struct device *dev, long t)
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list *qos_request,
+ long t)
{
- if (!dev || t < -1) {
+ if (!qos_request || t < -1) {
WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
return -EINVAL;
};
if (t == -1)
- pr_debug("OMAP PM: remove max DMA latency constraint: "
- "dev %s\n", dev_name(dev));
+ pr_debug("OMAP PM: remove max MPU wakeup latency "
+ "constraint\n");
+ else
+ pr_debug("OMAP PM: add max MPU wakeup latency constraint: "
+ "t=%ld us\n", t);
+
+ /*
+ * For current Linux, this needs to map the MPU to a
+ * powerdomain, then go through the list of current max lat
+ * constraints on the MPU and find the smallest. If
+ * the latency constraint has changed, the code should
+ * recompute the state to enter for the next powerdomain
+ * state.
+ *
+ * TI CDP code can call constraint_set here.
+ */
+
+ return 0;
+}
+
+int omap_pm_set_max_sdma_lat(struct pm_qos_request_list *qos_request,
+ long t)
+{
+ if (!qos_request || t < -1) {
+ WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
+ return -EINVAL;
+ };
+
+ if (t == -1)
+ pr_debug("OMAP PM: remove max DMA latency "
+ "constraint\n");
else
pr_debug("OMAP PM: add max DMA latency constraint: "
- "dev %s, t = %ld usec\n", dev_name(dev), t);
+ "t=%ld us\n", t);
/*
* For current Linux PM QOS params, this code should scan the
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/3] OMAP PM: create a PM layer plugin for the devices wakeup latency constraints
From: jean.pihet at newoldbits.com @ 2011-02-28 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298914884-16468-1-git-send-email-j-pihet@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Based on the original patch from Vishwanath,
cf. https://patchwork.kernel.org/patch/327312/
Cc: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
---
arch/arm/plat-omap/Kconfig | 7 +
arch/arm/plat-omap/Makefile | 1 +
arch/arm/plat-omap/omap-pm-constraints.c | 363 ++++++++++++++++++++++++++++++
3 files changed, 371 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/omap-pm-constraints.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index b6333ae..b8f51e3 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -215,6 +215,13 @@ config OMAP_PM_NONE
config OMAP_PM_NOOP
bool "No-op/debug PM layer"
+config OMAP_PM_CONSTRAINTS
+ depends on PM
+ bool "OMAP PM layer implementation, devices wakeup latency constraints"
+ help
+ Select this option to enable the PM layer plugin for
+ the devices wakeup latency constraints support
+
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a4a1285..a293367 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM_CONSTRAINTS) += omap-pm-constraints.o
diff --git a/arch/arm/plat-omap/omap-pm-constraints.c b/arch/arm/plat-omap/omap-pm-constraints.c
new file mode 100644
index 0000000..c8b4e4c
--- /dev/null
+++ b/arch/arm/plat-omap/omap-pm-constraints.c
@@ -0,0 +1,363 @@
+/*
+ * omap-pm.c - OMAP power management interface
+ *
+ * This code implements the OMAP power management interface to
+ * drivers, CPUIdle, CPUFreq, and DSP Bridge.
+ *
+ * Copyright (C) 2008-2009 Texas Instruments, Inc.
+ * Copyright (C) 2008-2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * Interface developed by (in alphabetical order):
+ * Karthik Dasu, Tony Lindgren, Jean Pihet, Rajendra Nayak, Sakari Poussa,
+ * Veeramanikandan Raju, Anand Sawant, Igor Stoppa, Paul Walmsley,
+ * Richard Woodruff
+ */
+
+#undef DEBUG
+
+#include <linux/init.h>
+#include <linux/cpufreq.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+
+/* Interface documentation is in mach/omap-pm.h */
+#include <plat/omap-pm.h>
+#include <plat/omap_device.h>
+
+static bool off_mode_enabled;
+static u32 dummy_context_loss_counter;
+
+/*
+ * Device-driver-originated constraints (via board-*.c files)
+ */
+
+int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
+{
+ if (!dev || t < -1) {
+ WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
+ return -EINVAL;
+ };
+
+ if (t == -1)
+ pr_debug("OMAP PM: remove max MPU wakeup latency constraint: "
+ "dev %s\n", dev_name(dev));
+ else
+ pr_debug("OMAP PM: add max MPU wakeup latency constraint: "
+ "dev %s, t = %ld usec\n", dev_name(dev), t);
+
+ /*
+ * For current Linux, this needs to map the MPU to a
+ * powerdomain, then go through the list of current max lat
+ * constraints on the MPU and find the smallest. If
+ * the latency constraint has changed, the code should
+ * recompute the state to enter for the next powerdomain
+ * state.
+ *
+ * TI CDP code can call constraint_set here.
+ */
+
+ return 0;
+}
+
+int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r)
+{
+ if (!dev || (agent_id != OCP_INITIATOR_AGENT &&
+ agent_id != OCP_TARGET_AGENT)) {
+ WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
+ return -EINVAL;
+ };
+
+ if (r == 0)
+ pr_debug("OMAP PM: remove min bus tput constraint: "
+ "dev %s for agent_id %d\n", dev_name(dev), agent_id);
+ else
+ pr_debug("OMAP PM: add min bus tput constraint: "
+ "dev %s for agent_id %d: rate %ld KiB\n",
+ dev_name(dev), agent_id, r);
+
+ /*
+ * This code should model the interconnect and compute the
+ * required clock frequency, convert that to a VDD2 OPP ID, then
+ * set the VDD2 OPP appropriately.
+ *
+ * TI CDP code can call constraint_set here on the VDD2 OPP.
+ */
+
+ return 0;
+}
+
+int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev,
+ long t)
+{
+ if (!req_dev || !dev || t < -1) {
+ WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
+ return -EINVAL;
+ };
+
+ if (t == -1)
+ pr_debug("OMAP PM: remove max device latency constraint: "
+ "dev %s\n", dev_name(dev));
+ else
+ pr_debug("OMAP PM: add max device latency constraint: "
+ "dev %s, t = %ld usec\n", dev_name(dev), t);
+
+ /*
+ * For current Linux, this needs to map the device to a
+ * powerdomain, then go through the list of current max lat
+ * constraints on that powerdomain and find the smallest. If
+ * the latency constraint has changed, the code should
+ * recompute the state to enter for the next powerdomain
+ * state. Conceivably, this code should also determine
+ * whether to actually disable the device clocks or not,
+ * depending on how long it takes to re-enable the clocks.
+ *
+ * TI CDP code can call constraint_set here.
+ */
+
+ return 0;
+}
+
+int omap_pm_set_max_sdma_lat(struct device *dev, long t)
+{
+ if (!dev || t < -1) {
+ WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
+ return -EINVAL;
+ };
+
+ if (t == -1)
+ pr_debug("OMAP PM: remove max DMA latency constraint: "
+ "dev %s\n", dev_name(dev));
+ else
+ pr_debug("OMAP PM: add max DMA latency constraint: "
+ "dev %s, t = %ld usec\n", dev_name(dev), t);
+
+ /*
+ * For current Linux PM QOS params, this code should scan the
+ * list of maximum CPU and DMA latencies and select the
+ * smallest, then set cpu_dma_latency pm_qos_param
+ * accordingly.
+ *
+ * For future Linux PM QOS params, with separate CPU and DMA
+ * latency params, this code should just set the dma_latency param.
+ *
+ * TI CDP code can call constraint_set here.
+ */
+
+ return 0;
+}
+
+int omap_pm_set_min_clk_rate(struct device *dev, struct clk *c, long r)
+{
+ if (!dev || !c || r < 0) {
+ WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
+ return -EINVAL;
+ }
+
+ if (r == 0)
+ pr_debug("OMAP PM: remove min clk rate constraint: "
+ "dev %s\n", dev_name(dev));
+ else
+ pr_debug("OMAP PM: add min clk rate constraint: "
+ "dev %s, rate = %ld Hz\n", dev_name(dev), r);
+
+ /*
+ * Code in a real implementation should keep track of these
+ * constraints on the clock, and determine the highest minimum
+ * clock rate. It should iterate over each OPP and determine
+ * whether the OPP will result in a clock rate that would
+ * satisfy this constraint (and any other PM constraint in effect
+ *@that time). Once it finds the lowest-voltage OPP that
+ * meets those conditions, it should switch to it, or return
+ * an error if the code is not capable of doing so.
+ */
+
+ return 0;
+}
+
+/*
+ * DSP Bridge-specific constraints
+ */
+
+const struct omap_opp *omap_pm_dsp_get_opp_table(void)
+{
+ pr_debug("OMAP PM: DSP request for OPP table\n");
+
+ /*
+ * Return DSP frequency table here: The final item in the
+ * array should have .rate = .opp_id = 0.
+ */
+
+ return NULL;
+}
+
+void omap_pm_dsp_set_min_opp(u8 opp_id)
+{
+ if (opp_id == 0) {
+ WARN_ON(1);
+ return;
+ }
+
+ pr_debug("OMAP PM: DSP requests minimum VDD1 OPP to be %d\n", opp_id);
+
+ /*
+ *
+ * For l-o dev tree, our VDD1 clk is keyed on OPP ID, so we
+ * can just test to see which is higher, the CPU's desired OPP
+ * ID or the DSP's desired OPP ID, and use whichever is
+ * highest.
+ *
+ * In CDP12.14+, the VDD1 OPP custom clock that controls the DSP
+ * rate is keyed on MPU speed, not the OPP ID. So we need to
+ * map the OPP ID to the MPU speed for use with clk_set_rate()
+ * if it is higher than the current OPP clock rate.
+ *
+ */
+}
+
+
+u8 omap_pm_dsp_get_opp(void)
+{
+ pr_debug("OMAP PM: DSP requests current DSP OPP ID\n");
+
+ /*
+ * For l-o dev tree, call clk_get_rate() on VDD1 OPP clock
+ *
+ * CDP12.14+:
+ * Call clk_get_rate() on the OPP custom clock, map that to an
+ * OPP ID using the tables defined in board-*.c/chip-*.c files.
+ */
+
+ return 0;
+}
+
+/*
+ * CPUFreq-originated constraint
+ *
+ * In the future, this should be handled by custom OPP clocktype
+ * functions.
+ */
+
+struct cpufreq_frequency_table **omap_pm_cpu_get_freq_table(void)
+{
+ pr_debug("OMAP PM: CPUFreq request for frequency table\n");
+
+ /*
+ * Return CPUFreq frequency table here: loop over
+ * all VDD1 clkrates, pull out the mpu_ck frequencies, build
+ * table
+ */
+
+ return NULL;
+}
+
+void omap_pm_cpu_set_freq(unsigned long f)
+{
+ if (f == 0) {
+ WARN_ON(1);
+ return;
+ }
+
+ pr_debug("OMAP PM: CPUFreq requests CPU frequency to be set to %lu\n",
+ f);
+
+ /*
+ * For l-o dev tree, determine whether MPU freq or DSP OPP id
+ * freq is higher. Find the OPP ID corresponding to the
+ * higher frequency. Call clk_round_rate() and clk_set_rate()
+ * on the OPP custom clock.
+ *
+ * CDP should just be able to set the VDD1 OPP clock rate here.
+ */
+}
+
+unsigned long omap_pm_cpu_get_freq(void)
+{
+ pr_debug("OMAP PM: CPUFreq requests current CPU frequency\n");
+
+ /*
+ * Call clk_get_rate() on the mpu_ck.
+ */
+
+ return 0;
+}
+
+/**
+ * omap_pm_enable_off_mode - notify OMAP PM that off-mode is enabled
+ *
+ * Intended for use only by OMAP PM core code to notify this layer
+ * that off mode has been enabled.
+ */
+void omap_pm_enable_off_mode(void)
+{
+ off_mode_enabled = true;
+}
+
+/**
+ * omap_pm_disable_off_mode - notify OMAP PM that off-mode is disabled
+ *
+ * Intended for use only by OMAP PM core code to notify this layer
+ * that off mode has been disabled.
+ */
+void omap_pm_disable_off_mode(void)
+{
+ off_mode_enabled = false;
+}
+
+/*
+ * Device context loss tracking
+ */
+
+#ifdef CONFIG_ARCH_OMAP2PLUS
+
+u32 omap_pm_get_dev_context_loss_count(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ u32 count;
+
+ if (WARN_ON(!dev))
+ return 0;
+
+ if (dev->parent == &omap_device_parent) {
+ count = omap_device_get_context_loss_count(pdev);
+ } else {
+ WARN_ONCE(off_mode_enabled, "omap_pm: using dummy context "
+ "loss counter; device %s should be converted to "
+ "omap_device", dev_name(dev));
+ if (off_mode_enabled)
+ dummy_context_loss_counter++;
+ count = dummy_context_loss_counter;
+ }
+
+ pr_debug("OMAP PM: context loss count for dev %s = %d\n",
+ dev_name(dev), count);
+
+ return count;
+}
+
+#else
+
+u32 omap_pm_get_dev_context_loss_count(struct device *dev)
+{
+ return dummy_context_loss_counter;
+}
+
+#endif
+
+/* Should be called before clk framework init */
+int __init omap_pm_if_early_init(void)
+{
+ return 0;
+}
+
+/* Must be called after clock framework is initialized */
+int __init omap_pm_if_init(void)
+{
+ return 0;
+}
+
+void omap_pm_if_exit(void)
+{
+ /* Deallocate CPUFreq frequency table here */
+}
+
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/3] OMAP PM: implement the wake-up latency constraints using PM QOS
From: jean.pihet at newoldbits.com @ 2011-02-28 17:41 UTC (permalink / raw)
To: linux-arm-kernel
From: Jean Pihet <j-pihet@ti.com>
Use the PM QOS framework to set wake-up latency constraints on the MPU and DMA.
Cpuidle for OMAP34xx uses PM QOS to retreive the strongest constraint and to
determine the next state for the MPU and CORE power domains.
As of today only I2C is requesting a constraint, but every omap_device
should be able to do so.
Note: To be replaced by a more generic solution which allows every
device to put a constraint, and which can control all power
domains in the system. This solution is currently under
investigation.
Jean Pihet (3):
OMAP PM: create a PM layer plugin for the devices wakeup latency
constraints
OMAP: implement MPU and DMA wake-up constraints using PM_QOS
OMAP: use PM QOS for wake-up constraints from I2C
arch/arm/plat-omap/Kconfig | 7 +
arch/arm/plat-omap/Makefile | 1 +
arch/arm/plat-omap/i2c.c | 22 ++-
arch/arm/plat-omap/include/plat/omap-pm.h | 96 ++++---
arch/arm/plat-omap/include/plat/omap_device.h | 1 +
arch/arm/plat-omap/omap-pm-constraints.c | 349 +++++++++++++++++++++++++
arch/arm/plat-omap/omap-pm-noop.c | 70 +++---
7 files changed, 469 insertions(+), 77 deletions(-)
create mode 100644 arch/arm/plat-omap/omap-pm-constraints.c
--
1.7.2.3
^ permalink raw reply
* [PATCH] ARM: Thumb-2: Work around buggy Thumb-2 short branch relocations in gas
From: Dave Martin @ 2011-02-28 17:38 UTC (permalink / raw)
To: linux-arm-kernel
Various binutils versions can resolve Thumb-2 branches to
locally-defined, preemptible global symbols as short-range "b.n"
branch instructions.
This is a problem, because there's no guarantee the final
destination of the symbol, or any candidate locations for a
trampoline, are within range of the branch. For this reason, the
kernel does not support fixing up the R_ARM_THM_JUMP11 (102)
relocation in modules at all, and it makes little sense to add
support.
The symptom is that the kernel fails with an "unsupported
relocation" error when loading some modules.
Until fixed tools are available, passing
-fno-optimize-sibling-calls to gcc should prevent gcc generating
code which hits this problem, at the cost of a bit of extra runtime
stack usage in some cases.
The problem is described in more detail at:
https://bugs.launchpad.net/binutils-linaro/+bug/725126
Only Thumb-2 kernels are affected.
This patch adds a new CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11 config
option which adds -fno-optimize-sibling-calls to CFLAGS_MODULE
when building a Thumb-2 kernel.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
arch/arm/Kconfig | 31 +++++++++++++++++++++++++++++++
arch/arm/Makefile | 4 ++++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5cff165..196f6d2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1371,6 +1371,37 @@ config THUMB2_KERNEL
If unsure, say N.
+config THUMB2_AVOID_R_ARM_THM_JUMP11
+ bool "Work around buggy Thumb-2 short branch relocations in gas"
+ depends on THUMB2_KERNEL && MODULES
+ default y
+ help
+ Various binutils versions can resolve Thumb-2 branches to
+ locally-defined, preemptible global symbols as short-range "b.n"
+ branch instructions.
+
+ This is a problem, because there's no guarantee the final
+ destination of the symbol, or any candidate locations for a
+ trampoline, are within range of the branch. For this reason, the
+ kernel does not support fixing up the R_ARM_THM_JUMP11 (102)
+ relocation in modules at all, and it makes little sense to add
+ support.
+
+ The symptom is that the kernel fails with an "unsupported
+ relocation" error when loading some modules.
+
+ Until fixed tools are available, passing
+ -fno-optimize-sibling-calls to gcc should prevent gcc generating
+ code which hits this problem, at the cost of a bit of extra runtime
+ stack usage in some cases.
+
+ The problem is described in more detail at:
+ https://bugs.launchpad.net/binutils-linaro/+bug/725126
+
+ Only Thumb-2 kernels are affected.
+
+ Unless you are sure your tools don't have this problem, say Y.
+
config ARM_ASM_UNIFIED
bool
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c22c1ad..ef5105a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -105,6 +105,10 @@ AFLAGS_AUTOIT :=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mau
AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
CFLAGS_THUMB2 :=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
AFLAGS_THUMB2 :=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
+# Work around buggy relocation from gas if requested:
+ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
+CFLAGS_MODULE +=-fno-optimize-sibling-calls
+endif
endif
# Need -Uarm for gcc < 3.x
--
1.7.1
^ permalink raw reply related
* [PATCH 3/8] Add a mfd IPUv3 driver
From: Arnd Bergmann @ 2011-02-28 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298887229-7987-4-git-send-email-s.hauer@pengutronix.de>
Hi Sascha,
I've had a brief look around the driver. It looks reasonable in general,
but the division into subdrivers feels a bit ad-hoc. If all the components
are built into a single module, I don't see the need for separating the
data by functional units by file. It seems simple enough to turn this
into a layered driver with multiple sub-devices each derived from a
platform_device on its own.
On Monday 28 February 2011, Sascha Hauer wrote:
> arch/arm/plat-mxc/include/mach/ipu-v3.h | 49 +++
> drivers/video/Kconfig | 2 +
> drivers/video/Makefile | 1 +
> drivers/video/imx-ipu-v3/Kconfig | 10 +
> drivers/video/imx-ipu-v3/Makefile | 3 +
> drivers/video/imx-ipu-v3/ipu-common.c | 666 +++++++++++++++++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-cpmem.c | 612 ++++++++++++++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-dc.c | 364 +++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-di.c | 550 +++++++++++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-dmfc.c | 355 ++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-dp.c | 476 ++++++++++++++++++++++
> drivers/video/imx-ipu-v3/ipu-prv.h | 216 ++++++++++
> include/video/imx-ipu-v3.h | 219 ++++++++++
I wonder if this is something that would fit better in drivers/gpu instead
of drivers/video. We recently discussed the benefits of KMS vs fb drivers,
and I think it would be good to be prepared for making this a KMS driver
in the long run, even if the immediate target has to be a simple frame buffer
driver.
> +#include "ipu-prv.h"
> +
> +static struct clk *ipu_clk;
> +static struct device *ipu_dev;
> +
> +static DEFINE_SPINLOCK(ipu_lock);
> +static DEFINE_MUTEX(ipu_channel_lock);
> +void __iomem *ipu_cm_reg;
> +void __iomem *ipu_idmac_reg;
> +
> +static int ipu_use_count;
> +
> +static struct ipu_channel channels[64];
Keeping these global limits you to just one ipu, and makes
understanding the code a little harder. How about moving
these variables into a struct ipu_data (or similar) that
is referenced from the platform_device?
> +EXPORT_SYMBOL(ipu_idmac_put);
Why not EXPORT_SYMBOL_GPL?
> +static LIST_HEAD(ipu_irq_handlers);
> +
> +static void ipu_irq_update_irq_mask(void)
> +{
> + struct ipu_irq_handler *handler;
> + int i;
> +
> + DECLARE_IPU_IRQ_BITMAP(irqs);
> +
> + bitmap_zero(irqs, IPU_IRQ_COUNT);
> +
> + list_for_each_entry(handler, &ipu_irq_handlers, list)
> + bitmap_or(irqs, irqs, handler->ipu_irqs, IPU_IRQ_COUNT);
> +
> + for (i = 0; i < BITS_TO_LONGS(IPU_IRQ_COUNT); i++)
> + ipu_cm_write(irqs[i], IPU_INT_CTRL(i + 1));
> +}
> +
> +int ipu_irq_add_handler(struct ipu_irq_handler *ipuirq)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ipu_lock, flags);
> +
> + list_add_tail(&ipuirq->list, &ipu_irq_handlers);
> + ipu_irq_update_irq_mask();
> +
> + spin_unlock_irqrestore(&ipu_lock, flags);
> + return 0;
> +}
> +EXPORT_SYMBOL(ipu_irq_add_handler);
The interrupt logic needs some comments. What are you trying to achieve here?
> +int ipu_wait_for_interrupt(int interrupt, int timeout_ms)
> +{
> + struct ipu_irq_handler handler;
> + DECLARE_COMPLETION_ONSTACK(completion);
> + int ret;
> +
> + bitmap_zero(handler.ipu_irqs, IPU_IRQ_COUNT);
> + bitmap_set(handler.ipu_irqs, interrupt, 1);
> +
> + ipu_cm_write(1 << (interrupt % 32), IPU_INT_STAT(interrupt / 32 + 1));
> +
> + handler.handler = ipu_completion_handler;
> + handler.context = &completion;
> + ipu_irq_add_handler(&handler);
> +
> + ret = wait_for_completion_timeout(&completion,
> + msecs_to_jiffies(timeout_ms));
> +
> + ipu_irq_remove_handler(&handler);
> +
> + if (ret > 0)
> + ret = 0;
> + else
> + ret = -ETIMEDOUT;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(ipu_wait_for_interrupt);
If I understand this correctly, this is a very complicated way to implement
something that could be done with a single wait_event_timeout() and
wake_up_interruptible_all() from the irq handler.
> +static irqreturn_t ipu_irq_handler(int irq, void *desc)
> +{
> + DECLARE_IPU_IRQ_BITMAP(status);
> + struct ipu_irq_handler *handler;
> + int i;
> +
> + for (i = 0; i < BITS_TO_LONGS(IPU_IRQ_COUNT); i++) {
> + status[i] = ipu_cm_read(IPU_INT_STAT(i + 1));
> + ipu_cm_write(status[i], IPU_INT_STAT(i + 1));
> + }
> +
> + list_for_each_entry(handler, &ipu_irq_handlers, list) {
> + DECLARE_IPU_IRQ_BITMAP(tmp);
> + if (bitmap_and(tmp, status, handler->ipu_irqs, IPU_IRQ_COUNT))
> + handler->handler(tmp, handler->context);
> + }
> +
> + return IRQ_HANDLED;
> +}
This needs to take spin_lock_irqsave before walking the ipu_irq_handlers
list, in order to prevent another CPU from modifying the list
while you are in the handler.
> +static int ipu_reset(void)
> +{
> + int timeout = 10000;
> + u32 val;
> +
> + /* hard reset the IPU */
> + val = readl(MX51_IO_ADDRESS(MX51_SRC_BASE_ADDR));
> + val |= 1 << 3;
> + writel(val, MX51_IO_ADDRESS(MX51_SRC_BASE_ADDR));
> +
> + ipu_cm_write(0x807FFFFF, IPU_MEM_RST);
> +
> + while (ipu_cm_read(IPU_MEM_RST) & 0x80000000) {
> + if (!timeout--)
> + return -ETIME;
> + udelay(100);
> + }
You have a timeout of over one second with udelay, which
is not acceptable on many systems. AFAICT, the function
can sleep, so you can replace udelay with msleep(1), and
you should use a better logic to determine the end of the
loop:
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
while (ipu_cm_read(IPU_MEM_RST) & 0x80000000) {
if (time_after(jiffies, timeout))
return -ETIME;
msleep(1);
}
> +static u32 *ipu_cpmem_base;
> +static struct device *ipu_dev;
> +
> +struct ipu_ch_param_word {
> + u32 data[5];
> + u32 res[3];
> +};
> +
> +struct ipu_ch_param {
> + struct ipu_ch_param_word word[2];
> +};
Same comment as for the previous file
> +
> +static void __iomem *ipu_dc_reg;
> +static void __iomem *ipu_dc_tmpl_reg;
> +static struct device *ipu_dev;
> +
> +struct ipu_dc {
> + unsigned int di; /* The display interface number assigned to this dc channel */
> + unsigned int channel_offset;
> +};
> +
> +static struct ipu_dc dc_channels[10];
And here again.
> +static void ipu_dc_link_event(int chan, int event, int addr, int priority)
> +{
> + u32 reg;
> +
> + reg = __raw_readl(DC_RL_CH(chan, event));
> + reg &= ~(0xFFFF << (16 * (event & 0x1)));
> + reg |= ((addr << 8) | priority) << (16 * (event & 0x1));
> + __raw_writel(reg, DC_RL_CH(chan, event));
> +}
Better use readl/writel instead of __raw_readl/__raw_writel, throughout the
code.
> +int ipu_di_init(struct platform_device *pdev, int id, unsigned long base,
> + u32 module, struct clk *ipu_clk);
> +void ipu_di_exit(struct platform_device *pdev, int id);
> +
> +int ipu_dmfc_init(struct platform_device *pdev, unsigned long base,
> + struct clk *ipu_clk);
> +void ipu_dmfc_exit(struct platform_device *pdev);
> +
> +int ipu_dp_init(struct platform_device *pdev, unsigned long base);
> +void ipu_dp_exit(struct platform_device *pdev);
> +
> +int ipu_dc_init(struct platform_device *pdev, unsigned long base,
> + unsigned long template_base);
> +void ipu_dc_exit(struct platform_device *pdev);
> +
> +int ipu_cpmem_init(struct platform_device *pdev, unsigned long base);
> +void ipu_cpmem_exit(struct platform_device *pdev);
If you make the main driver an mfd device, the sub-drivers could become
real platform drivers, which can structure the layering in a more modular
way.
E.g. instead of a single module init function, each subdriver can be
a module by itself and look at the resources associated with the
platform device it matches.
Arnd
^ permalink raw reply
* [PATCH 2/2] ARM: imx: remove #includes already available from devices-common.h
From: Uwe Kleine-König @ 2011-02-28 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298912674-15153-1-git-send-email-u.kleine-koenig@pengutronix.de>
Most machine files include "devices-imxXX.h" which in turn includes
<mach/devices-common.h>. The latter already includes many headers
that the machine files don't need to include again.
These were found by:
$ grep \#include arch/arm/plat-mxc/include/mach/devices-common.h > tmpfile
$ git grep -l 'devices-imx' arch/arm | xargs grep -f tmpfile -F
(but I kept linux/init.h, linux/kernel.h and linux/platform_device.h)
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-imx/eukrea_mbimx27-baseboard.c | 1 -
arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c | 1 -
arch/arm/mach-imx/mach-cpuimx27.c | 1 -
arch/arm/mach-imx/mach-eukrea_cpuimx25.c | 2 --
arch/arm/mach-imx/mach-mx1ads.c | 1 -
arch/arm/mach-imx/mach-mx21ads.c | 1 -
arch/arm/mach-imx/mach-mx25_3ds.c | 1 -
arch/arm/mach-imx/mach-mx27ads.c | 1 -
arch/arm/mach-imx/mach-mxt_td60.c | 1 -
arch/arm/mach-imx/mach-pca100.c | 1 -
arch/arm/mach-imx/mach-pcm038.c | 1 -
arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c | 1 -
arch/arm/mach-mx3/mach-cpuimx35.c | 1 -
arch/arm/mach-mx3/mach-mx31moboard.c | 1 -
arch/arm/mach-mx3/mach-pcm037_eet.c | 1 -
arch/arm/mach-mx3/mx31moboard-marxbot.c | 1 -
arch/arm/mach-mx5/board-cpuimx51.c | 2 --
arch/arm/mach-mx5/board-cpuimx51sd.c | 2 --
arch/arm/mach-mx5/board-mx51_babbage.c | 4 ----
arch/arm/mach-mx5/board-mx51_efikamx.c | 3 ---
arch/arm/mach-mx5/board-mx53_evk.c | 2 --
arch/arm/mach-mx5/board-mx53_loco.c | 2 --
arch/arm/mach-mx5/board-mx53_smd.c | 2 --
arch/arm/mach-mx5/eukrea_mbimx51-baseboard.c | 2 --
arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c | 1 -
25 files changed, 0 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c b/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c
index d12815d..cc8a2ff 100644
--- a/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c
+++ b/arch/arm/mach-imx/eukrea_mbimx27-baseboard.c
@@ -32,7 +32,6 @@
#include <mach/common.h>
#include <mach/iomux-mx27.h>
#include <mach/hardware.h>
-#include <mach/spi.h>
#include <mach/audmux.h>
#include "devices-imx27.h"
diff --git a/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c b/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c
index 3745e50..71d0fe6 100644
--- a/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c
+++ b/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c
@@ -31,7 +31,6 @@
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <mach/mx25.h>
-#include <mach/imx-uart.h>
#include <mach/audmux.h>
#include "devices-imx25.h"
diff --git a/arch/arm/mach-imx/mach-cpuimx27.c b/arch/arm/mach-imx/mach-cpuimx27.c
index 6cf04da..bb302f3 100644
--- a/arch/arm/mach-imx/mach-cpuimx27.c
+++ b/arch/arm/mach-imx/mach-cpuimx27.c
@@ -38,7 +38,6 @@
#include <mach/common.h>
#include <mach/hardware.h>
#include <mach/iomux-mx27.h>
-#include <mach/mxc_nand.h>
#include <mach/ulpi.h>
#include "devices-imx27.h"
diff --git a/arch/arm/mach-imx/mach-eukrea_cpuimx25.c b/arch/arm/mach-imx/mach-eukrea_cpuimx25.c
index eb395ab..9122aba 100644
--- a/arch/arm/mach-imx/mach-eukrea_cpuimx25.c
+++ b/arch/arm/mach-imx/mach-eukrea_cpuimx25.c
@@ -36,8 +36,6 @@
#include <asm/mach/map.h>
#include <mach/common.h>
#include <mach/mx25.h>
-#include <mach/mxc_nand.h>
-#include <mach/imxfb.h>
#include <mach/iomux-mx25.h>
#include "devices-imx25.h"
diff --git a/arch/arm/mach-imx/mach-mx1ads.c b/arch/arm/mach-imx/mach-mx1ads.c
index 1f446e5..832e87c 100644
--- a/arch/arm/mach-imx/mach-mx1ads.c
+++ b/arch/arm/mach-imx/mach-mx1ads.c
@@ -25,7 +25,6 @@
#include <mach/common.h>
#include <mach/hardware.h>
-#include <mach/i2c.h>
#include <mach/iomux-mx1.h>
#include <mach/irqs.h>
diff --git a/arch/arm/mach-imx/mach-mx21ads.c b/arch/arm/mach-imx/mach-mx21ads.c
index 0a37257..36483b8 100644
--- a/arch/arm/mach-imx/mach-mx21ads.c
+++ b/arch/arm/mach-imx/mach-mx21ads.c
@@ -25,7 +25,6 @@
#include <asm/mach/time.h>
#include <asm/mach/map.h>
#include <mach/iomux-mx21.h>
-#include <mach/mxc_nand.h>
#include "devices-imx21.h"
diff --git a/arch/arm/mach-imx/mach-mx25_3ds.c b/arch/arm/mach-imx/mach-mx25_3ds.c
index 8382e79..0c635d2 100644
--- a/arch/arm/mach-imx/mach-mx25_3ds.c
+++ b/arch/arm/mach-imx/mach-mx25_3ds.c
@@ -29,7 +29,6 @@
#include <linux/irq.h>
#include <linux/gpio.h>
#include <linux/platform_device.h>
-#include <linux/input/matrix_keypad.h>
#include <linux/usb/otg.h>
#include <mach/hardware.h>
diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c
index b832f96..65645ee 100644
--- a/arch/arm/mach-imx/mach-mx27ads.c
+++ b/arch/arm/mach-imx/mach-mx27ads.c
@@ -29,7 +29,6 @@
#include <asm/mach/map.h>
#include <mach/gpio.h>
#include <mach/iomux-mx27.h>
-#include <mach/mxc_nand.h>
#include "devices-imx27.h"
diff --git a/arch/arm/mach-imx/mach-mxt_td60.c b/arch/arm/mach-imx/mach-mxt_td60.c
index 4ce71b0..719936f 100644
--- a/arch/arm/mach-imx/mach-mxt_td60.c
+++ b/arch/arm/mach-imx/mach-mxt_td60.c
@@ -29,7 +29,6 @@
#include <asm/mach/map.h>
#include <linux/gpio.h>
#include <mach/iomux-mx27.h>
-#include <mach/mxc_nand.h>
#include <linux/i2c/pca953x.h>
#include "devices-imx27.h"
diff --git a/arch/arm/mach-imx/mach-pca100.c b/arch/arm/mach-imx/mach-pca100.c
index cccc0a0..354094f 100644
--- a/arch/arm/mach-imx/mach-pca100.c
+++ b/arch/arm/mach-imx/mach-pca100.c
@@ -37,7 +37,6 @@
#include <mach/iomux-mx27.h>
#include <asm/mach/time.h>
#include <mach/audmux.h>
-#include <mach/mxc_nand.h>
#include <mach/irqs.h>
#include <mach/ulpi.h>
diff --git a/arch/arm/mach-imx/mach-pcm038.c b/arch/arm/mach-imx/mach-pcm038.c
index ca20117..ff09b5d 100644
--- a/arch/arm/mach-imx/mach-pcm038.c
+++ b/arch/arm/mach-imx/mach-pcm038.c
@@ -36,7 +36,6 @@
#include <mach/common.h>
#include <mach/hardware.h>
#include <mach/iomux-mx27.h>
-#include <mach/mxc_nand.h>
#include <mach/ulpi.h>
#include "devices-imx27.h"
diff --git a/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c b/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
index 0d3f4b5..5e28208 100644
--- a/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
+++ b/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
@@ -37,7 +37,6 @@
#include <mach/hardware.h>
#include <mach/common.h>
-#include <mach/imx-uart.h>
#include <mach/iomux-mx35.h>
#include <mach/ipu.h>
#include <mach/mx3fb.h>
diff --git a/arch/arm/mach-mx3/mach-cpuimx35.c b/arch/arm/mach-mx3/mach-cpuimx35.c
index 26ae90f..81436de 100644
--- a/arch/arm/mach-mx3/mach-cpuimx35.c
+++ b/arch/arm/mach-mx3/mach-cpuimx35.c
@@ -41,7 +41,6 @@
#include <mach/hardware.h>
#include <mach/common.h>
#include <mach/iomux-mx35.h>
-#include <mach/mxc_nand.h>
#include "devices-imx35.h"
#include "devices.h"
diff --git a/arch/arm/mach-mx3/mach-mx31moboard.c b/arch/arm/mach-mx3/mach-mx31moboard.c
index 8fcf991..80764b3 100644
--- a/arch/arm/mach-mx3/mach-mx31moboard.c
+++ b/arch/arm/mach-mx3/mach-mx31moboard.c
@@ -41,7 +41,6 @@
#include <mach/iomux-mx3.h>
#include <mach/ipu.h>
#include <mach/mx3_camera.h>
-#include <mach/spi.h>
#include <mach/ulpi.h>
#include "devices-imx31.h"
diff --git a/arch/arm/mach-mx3/mach-pcm037_eet.c b/arch/arm/mach-mx3/mach-pcm037_eet.c
index e5756d4..f2be3ae 100644
--- a/arch/arm/mach-mx3/mach-pcm037_eet.c
+++ b/arch/arm/mach-mx3/mach-pcm037_eet.c
@@ -13,7 +13,6 @@
#include <mach/common.h>
#include <mach/iomux-mx3.h>
-#include <mach/spi.h>
#include <asm/mach-types.h>
diff --git a/arch/arm/mach-mx3/mx31moboard-marxbot.c b/arch/arm/mach-mx3/mx31moboard-marxbot.c
index f449a97..65b3c32 100644
--- a/arch/arm/mach-mx3/mx31moboard-marxbot.c
+++ b/arch/arm/mach-mx3/mx31moboard-marxbot.c
@@ -26,7 +26,6 @@
#include <mach/common.h>
#include <mach/hardware.h>
-#include <mach/imx-uart.h>
#include <mach/iomux-mx3.h>
#include <mach/ulpi.h>
diff --git a/arch/arm/mach-mx5/board-cpuimx51.c b/arch/arm/mach-mx5/board-cpuimx51.c
index f8652ef..7a1186c 100644
--- a/arch/arm/mach-mx5/board-cpuimx51.c
+++ b/arch/arm/mach-mx5/board-cpuimx51.c
@@ -23,13 +23,11 @@
#include <linux/io.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
-#include <linux/fsl_devices.h>
#include <mach/eukrea-baseboards.h>
#include <mach/common.h>
#include <mach/hardware.h>
#include <mach/iomux-mx51.h>
-#include <mach/mxc_ehci.h>
#include <asm/irq.h>
#include <asm/setup.h>
diff --git a/arch/arm/mach-mx5/board-cpuimx51sd.c b/arch/arm/mach-mx5/board-cpuimx51sd.c
index ad93189..920b791 100644
--- a/arch/arm/mach-mx5/board-cpuimx51sd.c
+++ b/arch/arm/mach-mx5/board-cpuimx51sd.c
@@ -23,7 +23,6 @@
#include <linux/io.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
-#include <linux/fsl_devices.h>
#include <linux/i2c-gpio.h>
#include <linux/spi/spi.h>
#include <linux/can/platform/mcp251x.h>
@@ -32,7 +31,6 @@
#include <mach/common.h>
#include <mach/hardware.h>
#include <mach/iomux-mx51.h>
-#include <mach/mxc_ehci.h>
#include <asm/irq.h>
#include <asm/setup.h>
diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c
index 1d231e8..a8d509f 100644
--- a/arch/arm/mach-mx5/board-mx51_babbage.c
+++ b/arch/arm/mach-mx5/board-mx51_babbage.c
@@ -16,9 +16,6 @@
#include <linux/gpio.h>
#include <linux/delay.h>
#include <linux/io.h>
-#include <linux/fsl_devices.h>
-#include <linux/fec.h>
-#include <linux/gpio_keys.h>
#include <linux/input.h>
#include <linux/spi/flash.h>
#include <linux/spi/spi.h>
@@ -26,7 +23,6 @@
#include <mach/common.h>
#include <mach/hardware.h>
#include <mach/iomux-mx51.h>
-#include <mach/mxc_ehci.h>
#include <asm/irq.h>
#include <asm/setup.h>
diff --git a/arch/arm/mach-mx5/board-mx51_efikamx.c b/arch/arm/mach-mx5/board-mx51_efikamx.c
index b7946f8..33270e1 100644
--- a/arch/arm/mach-mx5/board-mx51_efikamx.c
+++ b/arch/arm/mach-mx5/board-mx51_efikamx.c
@@ -22,15 +22,12 @@
#include <linux/input.h>
#include <linux/delay.h>
#include <linux/io.h>
-#include <linux/fsl_devices.h>
#include <linux/spi/flash.h>
#include <linux/spi/spi.h>
#include <mach/common.h>
#include <mach/hardware.h>
#include <mach/iomux-mx51.h>
-#include <mach/i2c.h>
-#include <mach/mxc_ehci.h>
#include <asm/irq.h>
#include <asm/setup.h>
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index caee04c..ec0f02a 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -21,7 +21,6 @@
#include <linux/init.h>
#include <linux/clk.h>
-#include <linux/fec.h>
#include <linux/delay.h>
#include <linux/gpio.h>
#include <linux/spi/flash.h>
@@ -31,7 +30,6 @@
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
-#include <mach/imx-uart.h>
#include <mach/iomux-mx53.h>
#define SMD_FEC_PHY_RST IMX_GPIO_NR(7, 6)
diff --git a/arch/arm/mach-mx5/board-mx53_loco.c b/arch/arm/mach-mx5/board-mx53_loco.c
index d1348e0..5e55520 100644
--- a/arch/arm/mach-mx5/board-mx53_loco.c
+++ b/arch/arm/mach-mx5/board-mx53_loco.c
@@ -20,13 +20,11 @@
#include <linux/init.h>
#include <linux/clk.h>
-#include <linux/fec.h>
#include <linux/delay.h>
#include <linux/gpio.h>
#include <mach/common.h>
#include <mach/hardware.h>
-#include <mach/imx-uart.h>
#include <mach/iomux-mx53.h>
#include <asm/mach-types.h>
diff --git a/arch/arm/mach-mx5/board-mx53_smd.c b/arch/arm/mach-mx5/board-mx53_smd.c
index 7970f7a..262813e 100644
--- a/arch/arm/mach-mx5/board-mx53_smd.c
+++ b/arch/arm/mach-mx5/board-mx53_smd.c
@@ -20,13 +20,11 @@
#include <linux/init.h>
#include <linux/clk.h>
-#include <linux/fec.h>
#include <linux/delay.h>
#include <linux/gpio.h>
#include <mach/common.h>
#include <mach/hardware.h>
-#include <mach/imx-uart.h>
#include <mach/iomux-mx53.h>
#include <asm/mach-types.h>
diff --git a/arch/arm/mach-mx5/eukrea_mbimx51-baseboard.c b/arch/arm/mach-mx5/eukrea_mbimx51-baseboard.c
index e83ffad..a608337 100644
--- a/arch/arm/mach-mx5/eukrea_mbimx51-baseboard.c
+++ b/arch/arm/mach-mx5/eukrea_mbimx51-baseboard.c
@@ -18,13 +18,11 @@
#include <linux/io.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
-#include <linux/fsl_devices.h>
#include <linux/i2c/tsc2007.h>
#include <linux/leds.h>
#include <mach/common.h>
#include <mach/hardware.h>
-#include <mach/imx-uart.h>
#include <mach/iomux-mx51.h>
#include <asm/mach/arch.h>
diff --git a/arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c b/arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c
index 606b7b2..db81ede 100644
--- a/arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c
+++ b/arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c
@@ -37,7 +37,6 @@
#include <mach/hardware.h>
#include <mach/common.h>
-#include <mach/imx-uart.h>
#include <mach/iomux-mx51.h>
#include <mach/audmux.h>
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] ARM: imx: use imx_add_gpio_keys to register "gpio-keys" devices
From: Uwe Kleine-König @ 2011-02-28 17:04 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c | 15 +++------------
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 14 +++-----------
arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c | 15 +++------------
arch/arm/mach-mx3/mach-armadillo5x0.c | 15 +++------------
arch/arm/mach-mx3/mach-pcm037_eet.c | 15 +++------------
arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c | 15 +++------------
6 files changed, 18 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c b/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c
index cb705c2..3745e50 100644
--- a/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c
+++ b/arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c
@@ -22,7 +22,6 @@
#include <linux/gpio.h>
#include <linux/leds.h>
#include <linux/platform_device.h>
-#include <linux/gpio_keys.h>
#include <linux/input.h>
#include <video/platform_lcd.h>
@@ -207,23 +206,14 @@ static struct gpio_keys_button eukrea_mbimxsd_gpio_buttons[] = {
},
};
-static struct gpio_keys_platform_data eukrea_mbimxsd_button_data = {
+static const struct gpio_keys_platform_data
+ eukrea_mbimxsd_button_data __initconst = {
.buttons = eukrea_mbimxsd_gpio_buttons,
.nbuttons = ARRAY_SIZE(eukrea_mbimxsd_gpio_buttons),
};
-static struct platform_device eukrea_mbimxsd_button_device = {
- .name = "gpio-keys",
- .id = -1,
- .num_resources = 0,
- .dev = {
- .platform_data = &eukrea_mbimxsd_button_data,
- }
-};
-
static struct platform_device *platform_devices[] __initdata = {
&eukrea_mbimxsd_leds_gpio,
- &eukrea_mbimxsd_button_device,
&eukrea_mbimxsd_lcd_powerdev,
};
@@ -293,4 +283,5 @@ void __init eukrea_mbimxsd25_baseboard_init(void)
ARRAY_SIZE(eukrea_mbimxsd_i2c_devices));
platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices));
+ imx_add_gpio_keys(&eukrea_mbimxsd_button_data);
}
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 40a3666..94fd02d 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -27,7 +27,6 @@
#include <linux/mtd/physmap.h>
#include <linux/i2c.h>
#include <linux/i2c/pca953x.h>
-#include <linux/gpio_keys.h>
#include <linux/input.h>
#include <linux/gpio.h>
#include <asm/mach-types.h>
@@ -124,19 +123,12 @@ static struct gpio_keys_button visstrim_gpio_keys[] = {
}
};
-static struct gpio_keys_platform_data visstrim_gpio_keys_platform_data = {
+static const struct gpio_keys_platform_data
+ visstrim_gpio_keys_platform_data __initconst = {
.buttons = visstrim_gpio_keys,
.nbuttons = ARRAY_SIZE(visstrim_gpio_keys),
};
-static struct platform_device visstrim_gpio_keys_device = {
- .name = "gpio-keys",
- .id = -1,
- .dev = {
- .platform_data = &visstrim_gpio_keys_platform_data,
- },
-};
-
/* Visstrim_SM10 has a microSD slot connected to sdhc1 */
static int visstrim_m10_sdhc1_init(struct device *dev,
irq_handler_t detect_irq, void *data)
@@ -180,7 +172,6 @@ static struct platform_device visstrim_m10_nor_mtd_device = {
};
static struct platform_device *platform_devices[] __initdata = {
- &visstrim_gpio_keys_device,
&visstrim_m10_nor_mtd_device,
};
@@ -238,6 +229,7 @@ static void __init visstrim_m10_board_init(void)
imx27_add_mxc_mmc(0, &visstrim_m10_sdhc_pdata);
imx27_add_mxc_ehci_otg(&visstrim_m10_usbotg_pdata);
imx27_add_fec(NULL);
+ imx_add_gpio_keys(&visstrim_gpio_keys_platform_data);
platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices));
}
diff --git a/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c b/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
index 14a5ffc..0d3f4b5 100644
--- a/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
+++ b/arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c
@@ -26,7 +26,6 @@
#include <linux/interrupt.h>
#include <linux/leds.h>
#include <linux/platform_device.h>
-#include <linux/gpio_keys.h>
#include <linux/input.h>
#include <video/platform_lcd.h>
#include <linux/i2c.h>
@@ -219,23 +218,14 @@ static struct gpio_keys_button eukrea_mbimxsd_gpio_buttons[] = {
},
};
-static struct gpio_keys_platform_data eukrea_mbimxsd_button_data = {
+static const struct gpio_keys_platform_data
+ eukrea_mbimxsd_button_data __initconst = {
.buttons = eukrea_mbimxsd_gpio_buttons,
.nbuttons = ARRAY_SIZE(eukrea_mbimxsd_gpio_buttons),
};
-static struct platform_device eukrea_mbimxsd_button_device = {
- .name = "gpio-keys",
- .id = -1,
- .num_resources = 0,
- .dev = {
- .platform_data = &eukrea_mbimxsd_button_data,
- }
-};
-
static struct platform_device *platform_devices[] __initdata = {
&eukrea_mbimxsd_leds_gpio,
- &eukrea_mbimxsd_button_device,
&eukrea_mbimxsd_lcd_powerdev,
};
@@ -307,4 +297,5 @@ void __init eukrea_mbimxsd35_baseboard_init(void)
ARRAY_SIZE(eukrea_mbimxsd_i2c_devices));
platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices));
+ imx_add_gpio_keys(&eukrea_mbimxsd_button_data);
}
diff --git a/arch/arm/mach-mx3/mach-armadillo5x0.c b/arch/arm/mach-mx3/mach-armadillo5x0.c
index 28b6f41..c801eba 100644
--- a/arch/arm/mach-mx3/mach-armadillo5x0.c
+++ b/arch/arm/mach-mx3/mach-armadillo5x0.c
@@ -34,7 +34,6 @@
#include <linux/mtd/physmap.h>
#include <linux/io.h>
#include <linux/input.h>
-#include <linux/gpio_keys.h>
#include <linux/i2c.h>
#include <linux/usb/otg.h>
#include <linux/usb/ulpi.h>
@@ -280,20 +279,12 @@ static struct gpio_keys_button armadillo5x0_buttons[] = {
}
};
-static struct gpio_keys_platform_data armadillo5x0_button_data = {
+static const struct gpio_keys_platform_data
+ armadillo5x0_button_data __initconst = {
.buttons = armadillo5x0_buttons,
.nbuttons = ARRAY_SIZE(armadillo5x0_buttons),
};
-static struct platform_device armadillo5x0_button_device = {
- .name = "gpio-keys",
- .id = -1,
- .num_resources = 0,
- .dev = {
- .platform_data = &armadillo5x0_button_data,
- }
-};
-
/*
* NAND Flash
*/
@@ -496,7 +487,6 @@ static const struct imxuart_platform_data uart_pdata __initconst = {
static struct platform_device *devices[] __initdata = {
&armadillo5x0_smc911x_device,
- &armadillo5x0_button_device,
};
/*
@@ -508,6 +498,7 @@ static void __init armadillo5x0_init(void)
ARRAY_SIZE(armadillo5x0_pins), "armadillo5x0");
platform_add_devices(devices, ARRAY_SIZE(devices));
+ imx_add_gpio_keys(&armadillo5x0_button_data);
imx31_add_imx_i2c1(NULL);
/* Register UART */
diff --git a/arch/arm/mach-mx3/mach-pcm037_eet.c b/arch/arm/mach-mx3/mach-pcm037_eet.c
index fda5654..e5756d4 100644
--- a/arch/arm/mach-mx3/mach-pcm037_eet.c
+++ b/arch/arm/mach-mx3/mach-pcm037_eet.c
@@ -7,7 +7,6 @@
* published by the Free Software Foundation.
*/
#include <linux/gpio.h>
-#include <linux/gpio_keys.h>
#include <linux/input.h>
#include <linux/platform_device.h>
#include <linux/spi/spi.h>
@@ -156,20 +155,13 @@ static struct gpio_keys_button pcm037_gpio_keys[] = {
},
};
-static struct gpio_keys_platform_data pcm037_gpio_keys_platform_data = {
+static const struct gpio_keys_platform_data
+ pcm037_gpio_keys_platform_data __initconst = {
.buttons = pcm037_gpio_keys,
.nbuttons = ARRAY_SIZE(pcm037_gpio_keys),
.rep = 0, /* No auto-repeat */
};
-static struct platform_device pcm037_gpio_keys_device = {
- .name = "gpio-keys",
- .id = -1,
- .dev = {
- .platform_data = &pcm037_gpio_keys_platform_data,
- },
-};
-
static int __init eet_init_devices(void)
{
if (!machine_is_pcm037() || pcm037_variant() != PCM037_EET)
@@ -184,9 +176,8 @@ static int __init eet_init_devices(void)
imx31_add_spi_imx0(&pcm037_spi1_pdata);
#endif
- platform_device_register(&pcm037_gpio_keys_device);
+ imx_add_gpio_keys(&pcm037_gpio_keys_platform_data);
return 0;
}
-
late_initcall(eet_init_devices);
diff --git a/arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c b/arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c
index c372a43..606b7b2 100644
--- a/arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c
+++ b/arch/arm/mach-mx5/eukrea_mbimxsd-baseboard.c
@@ -27,7 +27,6 @@
#include <linux/irq.h>
#include <linux/leds.h>
#include <linux/platform_device.h>
-#include <linux/gpio_keys.h>
#include <linux/input.h>
#include <linux/i2c.h>
@@ -104,23 +103,14 @@ static struct gpio_keys_button eukrea_mbimxsd_gpio_buttons[] = {
},
};
-static struct gpio_keys_platform_data eukrea_mbimxsd_button_data = {
+static const struct gpio_keys_platform_data
+ eukrea_mbimxsd_button_data __initconst = {
.buttons = eukrea_mbimxsd_gpio_buttons,
.nbuttons = ARRAY_SIZE(eukrea_mbimxsd_gpio_buttons),
};
-static struct platform_device eukrea_mbimxsd_button_device = {
- .name = "gpio-keys",
- .id = -1,
- .num_resources = 0,
- .dev = {
- .platform_data = &eukrea_mbimxsd_button_data,
- }
-};
-
static struct platform_device *platform_devices[] __initdata = {
&eukrea_mbimxsd_leds_gpio,
- &eukrea_mbimxsd_button_device,
};
static const struct imxuart_platform_data uart_pdata __initconst = {
@@ -162,4 +152,5 @@ void __init eukrea_mbimxsd51_baseboard_init(void)
ARRAY_SIZE(eukrea_mbimxsd_i2c_devices));
platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices));
+ imx_add_gpio_keys(&eukrea_mbimxsd_button_data);
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] arm: mxs: tx28: add i2c bus and connected RTC
From: Wolfram Sang @ 2011-02-28 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298911205-3070-1-git-send-email-w.sang@pengutronix.de>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
arch/arm/mach-mxs/Kconfig | 1 +
arch/arm/mach-mxs/mach-tx28.c | 10 ++++++++++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 895d066..4f0b673 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -45,6 +45,7 @@ config MODULE_TX28
select MXS_HAVE_AMBA_DUART
select MXS_HAVE_PLATFORM_AUART
select MXS_HAVE_PLATFORM_FEC
+ select MXS_HAVE_PLATFORM_MXS_I2C
select MXS_HAVE_PLATFORM_MXS_PWM
config MACH_TX28
diff --git a/arch/arm/mach-mxs/mach-tx28.c b/arch/arm/mach-mxs/mach-tx28.c
index b609b84..b65e371 100644
--- a/arch/arm/mach-mxs/mach-tx28.c
+++ b/arch/arm/mach-mxs/mach-tx28.c
@@ -14,6 +14,7 @@
#include <linux/platform_device.h>
#include <linux/spi/spi.h>
#include <linux/spi/spi_gpio.h>
+#include <linux/i2c.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
@@ -140,6 +141,12 @@ static struct spi_board_info tx28_spi_board_info[] = {
},
};
+static struct i2c_board_info tx28_stk5v3_i2c_boardinfo[] __initdata = {
+ {
+ I2C_BOARD_INFO("ds1339", 0x68),
+ },
+};
+
static void __init tx28_stk5v3_init(void)
{
mxs_iomux_setup_multiple_pads(tx28_stk5v3_pads,
@@ -154,6 +161,9 @@ static void __init tx28_stk5v3_init(void)
ARRAY_SIZE(tx28_spi_board_info));
mxs_add_platform_device("leds-gpio", 0, NULL, 0,
&tx28_stk5v3_led_data, sizeof(tx28_stk5v3_led_data));
+ mx28_add_mxs_i2c(0);
+ i2c_register_board_info(0, tx28_stk5v3_i2c_boardinfo,
+ ARRAY_SIZE(tx28_stk5v3_i2c_boardinfo));
}
static void __init tx28_timer_init(void)
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] arm: mxs: add i2c-devices for mx28
From: Wolfram Sang @ 2011-02-28 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298911205-3070-1-git-send-email-w.sang@pengutronix.de>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mxs/devices-mx28.h | 3 +
arch/arm/mach-mxs/devices/Kconfig | 3 +
arch/arm/mach-mxs/devices/Makefile | 1 +
arch/arm/mach-mxs/devices/platform-mxs-i2c.c | 51 +++++++++++++++++++++++
arch/arm/mach-mxs/include/mach/devices-common.h | 9 ++++
5 files changed, 67 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mxs/devices/platform-mxs-i2c.c
diff --git a/arch/arm/mach-mxs/devices-mx28.h b/arch/arm/mach-mxs/devices-mx28.h
index 69d19ea..a9eecdc 100644
--- a/arch/arm/mach-mxs/devices-mx28.h
+++ b/arch/arm/mach-mxs/devices-mx28.h
@@ -33,4 +33,7 @@ extern const struct mxs_flexcan_data mx28_flexcan_data[] __initconst;
#define mx28_add_flexcan0(pdata) mx28_add_flexcan(0, pdata)
#define mx28_add_flexcan1(pdata) mx28_add_flexcan(1, pdata)
+extern const struct mxs_i2c_data mx28_mxs_i2c_data[] __initconst;
+#define mx28_add_mxs_i2c(id) mxs_add_mxs_i2c(&mx28_mxs_i2c_data[id])
+
#define mx28_add_mxs_pwm(id) mxs_add_mxs_pwm(MX28_PWM_BASE_ADDR, id)
diff --git a/arch/arm/mach-mxs/devices/Kconfig b/arch/arm/mach-mxs/devices/Kconfig
index 3aeec24..a878915 100644
--- a/arch/arm/mach-mxs/devices/Kconfig
+++ b/arch/arm/mach-mxs/devices/Kconfig
@@ -12,5 +12,8 @@ config MXS_HAVE_PLATFORM_FLEXCAN
select HAVE_CAN_FLEXCAN if CAN
bool
+config MXS_HAVE_PLATFORM_MXS_I2C
+ bool
+
config MXS_HAVE_PLATFORM_MXS_PWM
bool
diff --git a/arch/arm/mach-mxs/devices/Makefile b/arch/arm/mach-mxs/devices/Makefile
index 978310f..345b839 100644
--- a/arch/arm/mach-mxs/devices/Makefile
+++ b/arch/arm/mach-mxs/devices/Makefile
@@ -2,4 +2,5 @@ obj-$(CONFIG_MXS_HAVE_AMBA_DUART) += amba-duart.o
obj-$(CONFIG_MXS_HAVE_PLATFORM_AUART) += platform-auart.o
obj-$(CONFIG_MXS_HAVE_PLATFORM_FEC) += platform-fec.o
obj-$(CONFIG_MXS_HAVE_PLATFORM_FLEXCAN) += platform-flexcan.o
+obj-$(CONFIG_MXS_HAVE_PLATFORM_MXS_I2C) += platform-mxs-i2c.o
obj-$(CONFIG_MXS_HAVE_PLATFORM_MXS_PWM) += platform-mxs-pwm.o
diff --git a/arch/arm/mach-mxs/devices/platform-mxs-i2c.c b/arch/arm/mach-mxs/devices/platform-mxs-i2c.c
new file mode 100644
index 0000000..eab3a06
--- /dev/null
+++ b/arch/arm/mach-mxs/devices/platform-mxs-i2c.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2011 Pengutronix
+ * Wolfram Sang <w.sang@pengutronix.de>
+ *
+ * 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 <asm/sizes.h>
+#include <mach/mx28.h>
+#include <mach/devices-common.h>
+
+#define mxs_i2c_data_entry_single(soc, _id) \
+ { \
+ .id = _id, \
+ .iobase = soc ## _I2C ## _id ## _BASE_ADDR, \
+ .errirq = soc ## _INT_I2C ## _id ## _ERROR, \
+ .dmairq = soc ## _INT_I2C ## _id ## _DMA, \
+ }
+
+#define mxs_i2c_data_entry(soc, _id) \
+ [_id] = mxs_i2c_data_entry_single(soc, _id)
+
+#ifdef CONFIG_SOC_IMX28
+const struct mxs_i2c_data mx28_mxs_i2c_data[] __initconst = {
+ mxs_i2c_data_entry(MX28, 0),
+ mxs_i2c_data_entry(MX28, 1),
+};
+#endif
+
+struct platform_device *__init mxs_add_mxs_i2c(const struct mxs_i2c_data *data)
+{
+ struct resource res[] = {
+ {
+ .start = data->iobase,
+ .end = data->iobase + SZ_8K - 1,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = data->errirq,
+ .end = data->errirq,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ .start = data->dmairq,
+ .end = data->dmairq,
+ .flags = IORESOURCE_IRQ,
+ },
+ };
+
+ return mxs_add_platform_device("mxs-i2c", data->id, res,
+ ARRAY_SIZE(res), NULL, 0);
+}
diff --git a/arch/arm/mach-mxs/include/mach/devices-common.h b/arch/arm/mach-mxs/include/mach/devices-common.h
index d460d30..71f2448 100644
--- a/arch/arm/mach-mxs/include/mach/devices-common.h
+++ b/arch/arm/mach-mxs/include/mach/devices-common.h
@@ -64,6 +64,15 @@ struct platform_device *__init mxs_add_flexcan(
const struct mxs_flexcan_data *data,
const struct flexcan_platform_data *pdata);
+/* i2c */
+struct mxs_i2c_data {
+ int id;
+ resource_size_t iobase;
+ resource_size_t errirq;
+ resource_size_t dmairq;
+};
+struct platform_device * __init mxs_add_mxs_i2c(const struct mxs_i2c_data *data);
+
/* pwm */
struct platform_device *__init mxs_add_mxs_pwm(
resource_size_t iobase, int id);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/2] mach-mxs: dynamic device creation for i.MX28-i2c
From: Wolfram Sang @ 2011-02-28 16:40 UTC (permalink / raw)
To: linux-arm-kernel
Currently for mx28 only, because the driver submitted for mainline does only
PIOQUEUE which is only available on that cpu. mx23 can be added if support is
available.
Patches are based on imx-for-2.6.39.
Changes since last version:
* dropped mx23-related corrections (not needed now)
* added support for Karo's TX28
Wolfram Sang (2):
arm: mxs: add i2c-devices for mx28
arm: mxs: tx28: add i2c bus and connected RTC
arch/arm/mach-mxs/Kconfig | 1 +
arch/arm/mach-mxs/devices-mx28.h | 3 +
arch/arm/mach-mxs/devices/Kconfig | 3 +
arch/arm/mach-mxs/devices/Makefile | 1 +
arch/arm/mach-mxs/devices/platform-mxs-i2c.c | 51 +++++++++++++++++++++++
arch/arm/mach-mxs/include/mach/devices-common.h | 9 ++++
arch/arm/mach-mxs/mach-tx28.c | 10 ++++
7 files changed, 78 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mxs/devices/platform-mxs-i2c.c
--
1.7.2.3
^ permalink raw reply
* [PATCH] perf: add OMAP support for the new power events
From: Jean Pihet @ 2011-02-28 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5dad46ab75a15145f907aeca53f769c1@mail.gmail.com>
Hi Kevin,
Can you please check this patch? From the previous discussions I
understood it was OK.
This one has been submitted to and l-o and l-a-k MLs. How will this
one be merged in?
Thanks,
Jean
On Mon, Feb 21, 2011 at 9:53 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: Jean Pihet [mailto:jean.pihet at newoldbits.com]
>> Sent: Monday, February 21, 2011 2:14 PM
>> To: Santosh Shilimkar
>> Cc: Kevin Hilman; Thomas Renninger; linux-omap at vger.kernel.org;
>> linux-arm-kernel at lists.infradead.org; Jean Pihet-XID
>> Subject: Re: [PATCH] perf: add OMAP support for the new power events
>>
>> Hi Santosh,
>>
>
> [...]
>
>> >> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
>> >> omap2/pm34xx.c
>> >> index 2f864e4..d1cc3f4 100644
>> >> --- a/arch/arm/mach-omap2/pm34xx.c
>> >> +++ b/arch/arm/mach-omap2/pm34xx.c
>> >> @@ -29,6 +29,7 @@
>> >> ?#include <linux/delay.h>
>> >> ?#include <linux/slab.h>
>> >> ?#include <linux/console.h>
>> >> +#include <trace/events/power.h>
>> >>
>> >> ?#include <plat/sram.h>
>> >> ?#include "clockdomain.h"
>> >> @@ -519,8 +520,14 @@ static void omap3_pm_idle(void)
>> >> ? ? ? if (omap_irq_pending() || need_resched())
>> >> ? ? ? ? ? ? ? goto out;
>> >>
>> >> + ? ? trace_power_start(POWER_CSTATE, 1, smp_processor_id());
>> >> + ? ? trace_cpu_idle(1, smp_processor_id());
>> >> +
>> >
>> > This default idle code won't be used when you enable the
>> > CONFIG_CPUIDLE. That case the cpuidle34xx.c idle code gets
>> > registered.
>> That is correct. OMAP has a default idle handler (omap3_pm_idle) and
>> a
>> cpuidle handler (omap3_enter_idle in
>> arch/arm/mach-omap2/cpuidle34xx.c).
>>
>> > Shouldn't you patch that code instead? This is more or less
>> > dead code and it is just like default idle code when idle
>> > drivers isn't registered.
>> The cpuidle framework already is instrumented in a generic way. This
>> code adds the instrumentation to the default idle handler so that
>> all
>> cases are covered. BTW the patch description gives that information.
>>
>> If there is dead code then it is not only the code from this patch
>> but
>> all the code for the default idle handler.
>>
> I read your change log. It says.
>
>>> The trace points are for:
>>> - default idle handler. Since the cpuidle framework is
>>> ? instrumented in the generic way there is no need to
>>> ? add trace points in the OMAP specific cpuidle handler;
> Now code in cpuilde34xx.c is also OMAP specific and hence the
> confusion at least for me.
> Regarding dead code, I meant existing code of default handler.
>
> Thanks for clarification.
>
> Regards,
> Santosh
>
^ permalink raw reply
* When does mach-types get updated in a tree?
From: Detlef Vollmann @ 2011-02-28 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228154913.GC1937@n2100.arm.linux.org.uk>
On 02/28/11 16:49, Russell King - ARM Linux wrote:
>>> I do think we're heading for a major problem with the mach-types file
>>> becoming too big inspite of its brevity. I think I may start marking
>>> entries as 'inactive' and therefore omitted from the kernel's tree if
>>> they don't appear in mainline within one year of being allocated (or
>>> some similar rule.)
> Having now done some investigations, this is silly. About 86% of the
> entries in the machine registry are not merged into the kernel. 48%
> of the contents of the machine registry refer to platforms registered
> more than two years ago but are not merged into mainline. For four
> years, that figure drops to 27%. For one year, it's 64%.
>
> So, merely implmenting a rule which says that entries which haven't
> been merged into mainline within 12 months from the date they were last
> updated would cut the file down to about 48K, almost 90K smaller. I
> think that's worth doing.
Hmmm, we have currently two entries registered for CPU modules we
use in a number of internal projects. Though we're happy to
share the code for these modules, we never intended to propose it
for mainline (as nobody alse can use these modules).
What do you propose for such cases?
Do you have a block of numbers for "private use"?
Detlef
^ permalink raw reply
* When does mach-types get updated in a tree?
From: Russell King - ARM Linux @ 2011-02-28 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d2617607-dfa2-4f72-9a42-4345b4a43307@VA3EHSMHS027.ehs.local>
On Mon, Feb 28, 2011 at 08:34:38AM -0700, John Linn wrote:
> > I do think we're heading for a major problem with the mach-types file
> > becoming too big inspite of its brevity. I think I may start marking
> > entries as 'inactive' and therefore omitted from the kernel's tree if
> > they don't appear in mainline within one year of being allocated (or
> > some similar rule.)
> >
>
> Wouldn't device tree help with this problem?
We'll just end up with a string-space problem instead of a number space
problem.
I don't know how many clashing names we end up with today (because the
machine number allocator explicitly prevents it happening) but I would
not be surprised if there weren't clashes occuring with 3500 names
registered.
Having now done some investigations, this is silly. About 86% of the
entries in the machine registry are not merged into the kernel. 48%
of the contents of the machine registry refer to platforms registered
more than two years ago but are not merged into mainline. For four
years, that figure drops to 27%. For one year, it's 64%.
So, merely implmenting a rule which says that entries which haven't
been merged into mainline within 12 months from the date they were last
updated would cut the file down to about 48K, almost 90K smaller. I
think that's worth doing.
^ permalink raw reply
* When does mach-types get updated in a tree?
From: John Linn @ 2011-02-28 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228151100.GB1937@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Monday, February 28, 2011 8:11 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org; grant.likely at secretlab.ca
> Subject: Re: When does mach-types get updated in a tree?
>
> On Mon, Feb 28, 2011 at 07:35:57AM -0700, John Linn wrote:
> > What is your suggestion to people with regards to patches that need
the
> > update?
>
> The only suggestion I can make is: don't wait until the last minute
before
> putting something into the machine registry, because you will get into
> these kinds of problems.
Yes agreed. My fault, lesson learned.
>
> If I do an update now, it'll be the second time it's happened in
February.
> It's likely it will need another update just before the merge window
too
> in 3-4 weeks time.
>
> So really all that I can say is that people need to ensure that they
get
> stuff from the machine registry earlier rather than later.
>
> I do think we're heading for a major problem with the mach-types file
> becoming too big inspite of its brevity. I think I may start marking
> entries as 'inactive' and therefore omitted from the kernel's tree if
> they don't appear in mainline within one year of being allocated (or
> some similar rule.)
>
Wouldn't device tree help with this problem?
> > I'm open to suggestions, just trying to work with everyone the best
way
> > to get Xilinx patches into the system.
>
> The only thing I can think is to wait a couple more weeks and I'll see
> about doing an update mid-March. Maybe by then we can have a smaller
> file...
Ok, thanks.
-- John
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [patch 1/2] mc13892: reboot on wdi event
From: Arnaud Patard (Rtp) @ 2011-02-28 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228143740.GD13869@opensource.wolfsonmicro.com>
Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> On Mon, Feb 28, 2011 at 02:21:33PM +0100, Arnaud Patard wrote:
>
>> +
>> + /* allows to reboot on wdi event */
>> + ret = mc13xxx_reg_read(mc13892, MC13892_POWERCTL2, &val);
>> + if (!ret) {
>> + val |= MC13892_POWERCTL2_WDIRESET;
>> + mc13xxx_reg_write(mc13892, MC13892_POWERCTL2, val);
>> + }
>> +
>
> Also, why is this in the regulator driver? The MFD core for the device
> might be a better choice - that'll ensure it gets done even if regulator
> support isn't enabled for some reason.
I was not sure where to put it so I put it in the place where the power
management is done. I can move it to the mfd driver. I'll only have to
make sure it's done only for mc13892 (I don't know what would be the
consequences to do it on mc13783 too and if there's a similar
configuration setting).
Arnaud
^ permalink raw reply
* [patch 1/2] mc13892: reboot on wdi event
From: Arnaud Patard (Rtp) @ 2011-02-28 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228143552.GC13869@opensource.wolfsonmicro.com>
Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> On Mon, Feb 28, 2011 at 02:21:33PM +0100, Arnaud Patard wrote:
>> By default, on wdi (watchdog input) event the mc13892 is powering off.
>> This patch is changing this to reboot on wdi event.
>>
>> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>
> This strikes me as something that should be configurable by platforms.
afaik, mc13892 is used only on imx designs and the reset for imx is done
only throught the watchdog. From this point of view, I don't see any
valid reason for powering off instead of rebooting on watchdog event
Arnaud
^ permalink raw reply
* When does mach-types get updated in a tree?
From: Russell King - ARM Linux @ 2011-02-28 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0812376c-ea4b-4185-aa6e-6fb582dce21f@VA3EHSMHS032.ehs.local>
On Mon, Feb 28, 2011 at 07:35:57AM -0700, John Linn wrote:
> What is your suggestion to people with regards to patches that need the
> update?
The only suggestion I can make is: don't wait until the last minute before
putting something into the machine registry, because you will get into
these kinds of problems.
If I do an update now, it'll be the second time it's happened in February.
It's likely it will need another update just before the merge window too
in 3-4 weeks time.
So really all that I can say is that people need to ensure that they get
stuff from the machine registry earlier rather than later.
I do think we're heading for a major problem with the mach-types file
becoming too big inspite of its brevity. I think I may start marking
entries as 'inactive' and therefore omitted from the kernel's tree if
they don't appear in mainline within one year of being allocated (or
some similar rule.)
> I'm open to suggestions, just trying to work with everyone the best way
> to get Xilinx patches into the system.
The only thing I can think is to wait a couple more weeks and I'll see
about doing an update mid-March. Maybe by then we can have a smaller
file...
^ permalink raw reply
* [PATCH resend] omap: Fix linker error in drivers/video/omap/lcd_2430sdp.c
From: Tomi Valkeinen @ 2011-02-28 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228164715.e34a965e.jhnikula@gmail.com>
On Mon, 2011-02-28 at 08:47 -0600, Jarkko Nikula wrote:
> On Thu, 24 Feb 2011 13:26:44 -0800
> Tony Lindgren <tony@atomide.com> wrote:
>
> > We should avoid selecting driver related things, otherwise we can never
> > build a tiny kernel with initramfs with everything as modules.
> >
> > Can you see if adding depends to the LCD panel option does the trick
> > instead?
> >
> True and as lcd_2430sdp.c is not compiled without CONFIG_FB_OMAP a hack
> below should work a bit better.
>
> What would you think Tomi?
>
> diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
> index 083c8fe..c981249 100644
> --- a/drivers/video/omap/Kconfig
> +++ b/drivers/video/omap/Kconfig
> @@ -5,6 +5,7 @@ config FB_OMAP
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> + select TWL4030_CORE if MACH_OMAP_2430SDP
> help
> Frame buffer driver for OMAP based boards.
>
Well, it's a bit ugly, but I'm fine with it. It's for the old omapfb,
which hopefully nobody uses anymore (right =), and there's no simple way
to make it modular and neat.
The old omapfb compiles lcd_2430sdp always into the kernel if
MACH_OMAP_2430SDP is defined, so this looks like a correct fix to me.
Heh, interestingly, the old omapfb Makefile says: "Makefile for the new
OMAP framebuffer device driver". Things are relative =).
Tomi
^ 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