* [PATCH] mmci: make sure DMA transfers wait for FIFO drain
From: Russell King - ARM Linux @ 2011-02-11 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=jP1G=foehWYNai5H=_F372FwpkLEO4wSkmqBc@mail.gmail.com>
On Fri, Feb 11, 2011 at 10:46:46AM +0100, Linus Walleij wrote:
> After discussing this with Ulf I think something like this is
> still needed...
>
> 2011/2/1 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > With the code I have in place, you'll notice I have:
> >
> > ? ? ? ?/* Wait up to 1ms for the DMA to complete */
> > ? ? ? ?for (i = 0; ; i++) {
> > ? ? ? ? ? ? ? ?status = readl(host->base + MMCISTATUS);
> > ? ? ? ? ? ? ? ?if (!(status & MCI_RXDATAAVLBLMASK) || i >= 100)
> > ? ? ? ? ? ? ? ? ? ? ? ?break;
> > ? ? ? ? ? ? ? ?udelay(10);
> > ? ? ? ?}
> >
> > This waits for the DMA controller to read the last data out of the FIFO
> > before allowing the request to complete. ?As it has a timeout, it is
> > able to detect ARMs broken DMA setup on their MMCI/DMAC, and disable DMA
> > support for this primecell rather than getting stuck.
> >
> > This may be sufficient without using the DMA callbacks.
>
> According to our tests this does not really cut it on
> Ux500. Sometimes we get the DMA completion before the
> MCI_DATAEND IRQ, and sometimes after.
>
> When we get the callback *after* the MCI_DATAEND irq
> this does not work properly, since we still don't know if the DMA
> job is complete, so the DMA engine is not in sync and we mess up
> the channels by issuing a new job, hammering the DMA engine
> while it's still busy on the channel.
That may be a problem if the channel is still busy, but it in any case
it shouldn't result in the DMA engine being hammered. The DMA
engine API is a queue based API - you submit requests to it and it
deals with them one after each other. If you submit two requests in
succession, it should process the first request, complete that, before
it starts to process the second request. I'd suggest fixing this in
any case.
Maybe a solution to this is to use the DMA callback to signal that the
data path has completed, but still have the data end interrupt in place
so that it can trigger the stop command. That shouldn't result in
additional delays or even the requirement for a timeout.
^ permalink raw reply
* [PATCH 2/5] mmc: sdhci-esdhc: broken card detection is not a default quirk
From: Anton Vorontsov @ 2011-02-11 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210191821.GD2206@pengutronix.de>
On Thu, Feb 10, 2011 at 08:18:21PM +0100, Wolfram Sang wrote:
>
> Adding Anton to Cc...
[...]
> > struct sdhci_pltfm_data sdhci_esdhc_imx_pdata = {
> > - .quirks = ESDHC_DEFAULT_QUIRKS | SDHCI_QUIRK_BROKEN_ADMA,
> > + .quirks = ESDHC_DEFAULT_QUIRKS | SDHCI_QUIRK_BROKEN_ADMA
> > + | SDHCI_QUIRK_BROKEN_CARD_DETECTION,
Minor nit: "|" should be on the previous line.
Otherwise,
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
Thanks!
--
Anton Vorontsov
Email: cbouatmailru at gmail.com
^ permalink raw reply
* [PATCH] mmci: make sure DMA transfers wait for FIFO drain
From: Linus Walleij @ 2011-02-11 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201110348.GB31216@n2100.arm.linux.org.uk>
After discussing this with Ulf I think something like this is
still needed...
2011/2/1 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Jan 31, 2011 at 10:39:40PM +0100, Linus Walleij wrote:
>> The DMA mode also needs to wait until the FIFO is drained before
>> enabling the MCI_DATAEND IRQ.
>
> Hmm. ?This will cause attempted DMA usage on ARM MMCI primecells to get
> stuck as we'll wait for the never-delivered callback.
I don' know if we have semantics for the DMA completion callback,
either:
A) it's to be called whenever the transaction is complete without
errors - in this case the driver using it must supply some timeout
mechanism to avoid hanging on DMA or:
B) It's supposed to be called whenever the DMA stops working
no matter whether this was due to errors or not.
Since the callback isn't supplying any status indication I
assume it's case (A). But if we're allowed to call
.device_tx_status() on the channel in callback context, we can
get the status here and determine whether the transaction was
OK or not, and then it's case (B).
So I should either reconsider this patch to either do:
(A) a timeout that terminates the DMA if too much time passes
(which will in turn have to be caclulated from the xfer size and
MCLK frequency) or
(B) a call to device_tx_status() and check whether there was an
error and set data->error accordingly in the error case.
(This may in turn require changed to amba-pl08x to e.g. timeout
and report such errors properly.) or
(C) (Dan) will dma_sync_wait(chan, cookie) on the descriptor
in the MCI_DATAEND IRQ path suffice? If that happens we
may have a bug in the DMA engine(s) in that it doesn't
timeout or error out if a DMA job locks up.
I don't particularly like dma_sync_wait() since it is hardwired
to wait 5 seconds, which seems arbitrarily chosen. If that is
the approach, a new sync wait function taking timeout as
argument will likely be needed.
My current assumption is something like (A)...
> With the code I have in place, you'll notice I have:
>
> ? ? ? ?/* Wait up to 1ms for the DMA to complete */
> ? ? ? ?for (i = 0; ; i++) {
> ? ? ? ? ? ? ? ?status = readl(host->base + MMCISTATUS);
> ? ? ? ? ? ? ? ?if (!(status & MCI_RXDATAAVLBLMASK) || i >= 100)
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?udelay(10);
> ? ? ? ?}
>
> This waits for the DMA controller to read the last data out of the FIFO
> before allowing the request to complete. ?As it has a timeout, it is
> able to detect ARMs broken DMA setup on their MMCI/DMAC, and disable DMA
> support for this primecell rather than getting stuck.
>
> This may be sufficient without using the DMA callbacks.
According to our tests this does not really cut it on
Ux500. Sometimes we get the DMA completion before the
MCI_DATAEND IRQ, and sometimes after.
When we get the callback *after* the MCI_DATAEND irq
this does not work properly, since we still don't know if the DMA
job is complete, so the DMA engine is not in sync and we mess up
the channels by issuing a new job, hammering the DMA engine
while it's still busy on the channel.
We either have to sync in the DMA engine or timeout
on the DMA job as far as I can tell. One of A thru C.
Yours,
Linus Walleij
^ permalink raw reply
* ARM: relocation out of range (when loading a module)
From: Dave Martin @ 2011-02-11 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211093853.GA23404@n2100.arm.linux.org.uk>
On Fri, Feb 11, 2011 at 9:38 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Feb 11, 2011 at 09:31:04AM +0000, Dave Martin wrote:
>> You could probably cook up a good upper bound based on the size of the
>> kernel and the number of symbols in the module: i.e., assume that
>> every undefined symbol in the module needs to be fixed up to point at
>> the most distant symbol in the kernel.
>>
>> For people with normal-sized kernels, this bound will probably work
>> out as zero most of the time (i.e., the current situation). ?For
>> people with big kernels, or when many modules are already loaded, it
>> may work out at 100% -- but that's the price to pay for guaranteed
>> preallocation of the space required for the veneers. ?And anyway, you
>> may really need a substantial chunk of those veneers in such cases.
>
> I think it's going to be easier just to re-order the kernel image link
> order to solve that problem. ?That just leaves uclinux...
>
But if the kernel is big, or there are many modules, changing the
order can't solve the problem surely? Or is the problem purely caused
by having the initramfs in the way, and we think the amount of actual
code will never be big enough to cause a problem?
Cheers
---Dave
^ permalink raw reply
* [PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S
From: Dave Martin @ 2011-02-11 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d3mzh6vq.fsf@ti.com>
On Thu, Feb 10, 2011 at 10:17 PM, Kevin Hilman <khilman@ti.com> wrote:
> Dave Martin <dave.martin@linaro.org> writes:
>
>> ?* Use BSYM() to get the correct Thumb branch address
>> ? ?for adr <Rd>, <label>
>>
>> ?* Fix an out-of-range ADR when building for ARM
>>
>> ?* Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>>
>> ?* Remove deprecated/undefined PC-relative stores
>>
>> ?* Add the required ENDPROC() directive for each ENTRY().
>>
>> ?* .align before data words
>>
>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>
> I'm attempting to test this series with OMAP PM, but some changes here
> don't compile for me.
>
> My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)
>
> First, I merged your arm/omap-thumb2+merged branch with my pm branch
> from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>
> There were some minor conflicts here, but they looked simple enough and
> I just resolved in favor of your branch.
Thanks for giving it a try.
>
> Trying to build with CONFIG_THUMB2_KERNEL=y, I ran into a compile
> problem...
>
>
[...]
>> + ? ? adr ? ? r0, es3_sdrc_fix ? ? ? ?@ Not using BSYM clears the Thumb bit.
>
> This fails to compile:
>
> /work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S: Assembler messages:
> /work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S:361: Error: invalid immediate for address calculation (value = 0x00000004)
Unfortunately, this is caused by a bug in the assembler.
arch/arm/kernel/relocate_kernel.S also suffers from the same bug when
built with CONFIG_THUMB2_KERNEL.
If you had got as far a linking, it's likely you would hit a
'reference to discarded section problem' error in the linker, due to
discarding of some sections referenced by SMP_ON_UP fixups.
If you merge the 3 extra patches from dirty/arm/omap-thumb2+merged it
should resolve these issues, but how to fix these things upstream is
still under discussion.
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/5] mmc: sdhci-esdhc-imx: add support for write protect on custom GPIO
From: Wolfram Sang @ 2011-02-11 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102110924.38338.marc@cpdesign.com.au>
Marc,
On Fri, Feb 11, 2011 at 09:24:38AM +1100, Marc Reilly wrote:
> Tested-by: Marc Reilly <marc@cpdesign.com.au>
Thanks a lot!
> > + if (boarddata) {
>
> Perhaps (boarddata && gpio_is_valid(boarddata->wp_gpio) as above?
>
> For example what if someone sets up the boarddata for a card detect, but not
> write protect.
Well, I couldn't do this here, because later the cd_pin-stuff will also
be added to the if-block. However, I see what you mean and that could
still be added before the gpio_request below. That would add another
level of indentation, though, for a case I'd consider to be more
theoretical (and definately not recommended). Maybe I will adjust the
warning message to be also understandable for the case a GPIO is preset
with an invalid number. I think the warning itself is justified.
>
> > + err = gpio_request_one(boarddata->wp_gpio, GPIOF_IN, "ESDHC_WP");
> > + if (err) {
> > + dev_warn(mmc_dev(host->mmc), "can't get wp_pin!\n");
> > + boarddata->wp_gpio = err;
> > + }
> > + }
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* ARM: relocation out of range (when loading a module)
From: Russell King - ARM Linux @ 2011-02-11 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=KtFf5BU-iH-sUUL=Q30S90bk608JR4zFz2CKf@mail.gmail.com>
On Fri, Feb 11, 2011 at 09:31:04AM +0000, Dave Martin wrote:
> You could probably cook up a good upper bound based on the size of the
> kernel and the number of symbols in the module: i.e., assume that
> every undefined symbol in the module needs to be fixed up to point at
> the most distant symbol in the kernel.
>
> For people with normal-sized kernels, this bound will probably work
> out as zero most of the time (i.e., the current situation). For
> people with big kernels, or when many modules are already loaded, it
> may work out at 100% -- but that's the price to pay for guaranteed
> preallocation of the space required for the veneers. And anyway, you
> may really need a substantial chunk of those veneers in such cases.
I think it's going to be easier just to re-order the kernel image link
order to solve that problem. That just leaves uclinux...
^ permalink raw reply
* [PATCH v2 2/2] ARM: IMX5 bbg: add cpuidle parameters
From: yong.shen at linaro.org @ 2011-02-11 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297416973-32740-1-git-send-email-yong.shen@linaro.org>
From: Yong Shen <yong.shen@freescale.com>
This parameters are workable, but need further tuning.
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/board-mx51_babbage.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c
index d9d402e..168b09c 100644
--- a/arch/arm/mach-mx5/board-mx51_babbage.c
+++ b/arch/arm/mach-mx5/board-mx51_babbage.c
@@ -37,6 +37,7 @@
#include "devices-imx51.h"
#include "devices.h"
#include "cpu_op-mx51.h"
+#include "cpuidle.h"
#define BABBAGE_USB_HUB_RESET IMX_GPIO_NR(1, 7)
#define BABBAGE_USBH1_STP IMX_GPIO_NR(1, 27)
@@ -333,6 +334,11 @@ static const struct spi_imx_master mx51_babbage_spi_pdata __initconst = {
.num_chipselect = ARRAY_SIZE(mx51_babbage_spi_cs),
};
+static struct imx_cpuidle_params babage_cpuidle_params[] = {
+ {100,},
+ {150,},
+ {1000,},
+};
/*
* Board specific initialization.
*/
@@ -383,6 +389,8 @@ static void __init mxc_board_init(void)
ARRAY_SIZE(mx51_babbage_spi_board_info));
imx51_add_ecspi(0, &mx51_babbage_spi_pdata);
imx51_add_imx2_wdt(0, NULL);
+
+ imx_cpuidle_board_params(babage_cpuidle_params);
}
static void __init mx51_babbage_timer_init(void)
--
1.7.1
^ permalink raw reply related
* [PATCH v2 1/2] ARM: IMX5: cpuidle driver
From: yong.shen at linaro.org @ 2011-02-11 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297416973-32740-1-git-send-email-yong.shen@linaro.org>
From: Yong Shen <yong.shen@freescale.com>
implement cpuidle driver for iMX5 SOCs, leave cpuidle params to board
related code.
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/Makefile | 1 +
arch/arm/mach-mx5/cpuidle.c | 113 +++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-mx5/cpuidle.h | 26 ++++++++++
3 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mx5/cpuidle.c
create mode 100644 arch/arm/mach-mx5/cpuidle.h
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 0d43be9..12239e0 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -7,6 +7,7 @@ obj-y := cpu.o mm.o clock-mx51-mx53.o devices.o
obj-$(CONFIG_SOC_IMX50) += mm-mx50.o
obj-$(CONFIG_CPU_FREQ_IMX) += cpu_op-mx51.o
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
obj-$(CONFIG_MACH_MX51_3DS) += board-mx51_3ds.o
obj-$(CONFIG_MACH_MX53_EVK) += board-mx53_evk.o
diff --git a/arch/arm/mach-mx5/cpuidle.c b/arch/arm/mach-mx5/cpuidle.c
new file mode 100644
index 0000000..9d77c47
--- /dev/null
+++ b/arch/arm/mach-mx5/cpuidle.c
@@ -0,0 +1,113 @@
+/*
+ * arch/arm/mach-mx5/cpuidle.c
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/io.h>
+#include <linux/cpuidle.h>
+#include <asm/proc-fns.h>
+#include <mach/hardware.h>
+#include "cpuidle.h"
+#include "crm_regs.h"
+
+static struct imx_cpuidle_params *imx_cpuidle_params;
+void imx_cpuidle_board_params(struct imx_cpuidle_params *cpuidle_params)
+{
+ imx_cpuidle_params = cpuidle_params;
+}
+
+extern int tzic_enable_wake(int is_idle);
+static int imx_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ struct timeval before, after;
+ int idle_time;
+ u32 plat_lpc, arm_srpgcr, ccm_clpcr;
+ u32 empgc0, empgc1;
+
+ local_irq_disable();
+ do_gettimeofday(&before);
+
+ plat_lpc = __raw_readl(MXC_CORTEXA8_PLAT_LPC) &
+ ~(MXC_CORTEXA8_PLAT_LPC_DSM);
+ ccm_clpcr = __raw_readl(MXC_CCM_CLPCR) & ~(MXC_CCM_CLPCR_LPM_MASK);
+ arm_srpgcr = __raw_readl(MXC_SRPG_ARM_SRPGCR) & ~(MXC_SRPGCR_PCR);
+ empgc0 = __raw_readl(MXC_SRPG_EMPGC0_SRPGCR) & ~(MXC_SRPGCR_PCR);
+ empgc1 = __raw_readl(MXC_SRPG_EMPGC1_SRPGCR) & ~(MXC_SRPGCR_PCR);
+
+ if (state == &dev->states[WAIT_CLK_ON])
+ ;
+ else if (state == &dev->states[WAIT_CLK_OFF])
+ ccm_clpcr |= (0x1 << MXC_CCM_CLPCR_LPM_OFFSET);
+ else if (state == &dev->states[WAIT_CLK_OFF_POWER_OFF]) {
+ /* Wait unclocked, power off */
+ plat_lpc |= MXC_CORTEXA8_PLAT_LPC_DSM
+ | MXC_CORTEXA8_PLAT_LPC_DBG_DSM;
+ arm_srpgcr |= MXC_SRPGCR_PCR;
+ ccm_clpcr |= (0x1 << MXC_CCM_CLPCR_LPM_OFFSET);
+ ccm_clpcr &= ~MXC_CCM_CLPCR_VSTBY;
+ ccm_clpcr &= ~MXC_CCM_CLPCR_SBYOS;
+ if (tzic_enable_wake(1) != 0) {
+ local_irq_enable();
+ return 0;
+ }
+ }
+
+ __raw_writel(plat_lpc, MXC_CORTEXA8_PLAT_LPC);
+ __raw_writel(ccm_clpcr, MXC_CCM_CLPCR);
+ __raw_writel(arm_srpgcr, MXC_SRPG_ARM_SRPGCR);
+
+ cpu_do_idle();
+
+ do_gettimeofday(&after);
+ local_irq_enable();
+ idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
+ (after.tv_usec - before.tv_usec);
+ return idle_time;
+}
+
+static struct cpuidle_driver imx_cpuidle_driver = {
+ .name = "imx_idle",
+ .owner = THIS_MODULE,
+};
+
+static DEFINE_PER_CPU(struct cpuidle_device, imx_cpuidle_device);
+
+static int __init imx_cpuidle_init(void)
+{
+ struct cpuidle_device *device;
+ int i;
+
+ if (imx_cpuidle_params == NULL)
+ return -ENODEV;
+
+ cpuidle_register_driver(&imx_cpuidle_driver);
+
+ device = &per_cpu(imx_cpuidle_device, smp_processor_id());
+ device->state_count = IMX_MAX_CPUIDLE_STATE;
+
+ for (i = 0; i < IMX_MAX_CPUIDLE_STATE && i < CPUIDLE_STATE_MAX; i++) {
+ device->states[i].enter = imx_enter_idle;
+ device->states[i].exit_latency = imx_cpuidle_params[i].latency;
+ device->states[i].flags = CPUIDLE_FLAG_TIME_VALID;
+ }
+
+ strcpy(device->states[WAIT_CLK_ON].name, "WFI 0");
+ strcpy(device->states[WAIT_CLK_ON].desc, "Wait with clock on");
+ strcpy(device->states[WAIT_CLK_OFF].name, "WFI 1");
+ strcpy(device->states[WAIT_CLK_OFF].desc, "Wait with clock off");
+ strcpy(device->states[WAIT_CLK_OFF_POWER_OFF].name, "WFI 2");
+ strcpy(device->states[WAIT_CLK_OFF_POWER_OFF].desc,
+ "Wait with clock off and power gating");
+
+ if (cpuidle_register_device(device)) {
+ printk(KERN_ERR "imx_cpuidle_init: Failed registering\n");
+ return -ENODEV;
+ }
+ return 0;
+}
+
+late_initcall(imx_cpuidle_init);
diff --git a/arch/arm/mach-mx5/cpuidle.h b/arch/arm/mach-mx5/cpuidle.h
new file mode 100644
index 0000000..e5ba495
--- /dev/null
+++ b/arch/arm/mach-mx5/cpuidle.h
@@ -0,0 +1,26 @@
+/*
+ * arch/arm/mach-mx5/cpuidle.h
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+enum {
+ WAIT_CLK_ON, /* c1 */
+ WAIT_CLK_OFF, /* c2 */
+ WAIT_CLK_OFF_POWER_OFF, /* c3 */
+ IMX_MAX_CPUIDLE_STATE,
+};
+
+struct imx_cpuidle_params {
+ unsigned int latency;
+};
+
+#ifdef CONFIG_CPU_IDLE
+extern void imx_cpuidle_board_params(struct imx_cpuidle_params *cpuidle_params);
+#else
+inline void imx_cpuidle_board_params(struct imx_cpuidle_params *cpuidle_params)
+{}
+#endif
+
--
1.7.1
^ permalink raw reply related
* [PATCH v2 0/2] ARM: IMX5: cpuidle driver
From: yong.shen at linaro.org @ 2011-02-11 9:36 UTC (permalink / raw)
To: linux-arm-kernel
change log:
1. move code to arch/arm/mach-mx5/, since it is cpu-type specific
2. provide a interface for various board to register board-specific params.
^ permalink raw reply
* [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
From: Dave Martin @ 2011-02-11 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87sjvvh8oc.fsf@ti.com>
On Thu, Feb 10, 2011 at 9:38 PM, Kevin Hilman <khilman@ti.com> wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> [...]
>
>>>
>>> The SD card gets suspended, but nothing else seems to happen, and I
>>> can't resume the system.
>>>
>>> Am I doing something wrong?
>>>
>> MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing
>>
>
> Just to clarify, MMC suspend is not broken. ?It's a "feature" the MMC
> core. ?See the help text of the following Kconfig option, and ensure
> that it's enabled:
>
>
> config MMC_UNSAFE_RESUME
> ? ? ? ?bool "Assume MMC/SD cards are non-removable (DANGEROUS)"
> ? ? ? ?help
> ? ? ? ? ?If you say Y here, the MMC layer will assume that all cards
> ? ? ? ? ?stayed in their respective slots during the suspend. The
> ? ? ? ? ?normal behaviour is to remove them at suspend and
> ? ? ? ? ?redetecting them at resume. Breaking this assumption will
> ? ? ? ? ?in most cases result in data corruption.
>
> ? ? ? ? ?This option is usually just for embedded systems which use
> ? ? ? ? ?a MMC/SD card for rootfs. Most people should say N here.
>
> ? ? ? ? ?This option sets a default which can be overridden by the
> ? ? ? ? ?module parameter "removable=0" or "removable=1".
>
> Looking at Dave's .config, this option is disabled, so suspend will hang
> when rootfs is on MMC.
Thanks for the clarification. For simplicity, and since Thumb-2
should be unrelated to the MMC subsystem, I've been testing suspend
from the initramfs instead ... which sidesteps the MMC issue.
Power-off-suspend does still have some weird problems when
CONFIG_THUMB2_KERNEL is enabled; I'm still investigating this.
Cheers
---Dave
^ permalink raw reply
* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
From: Dave Martin @ 2011-02-11 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210191125.GA12582@n2100.arm.linux.org.uk>
On Thu, Feb 10, 2011 at 7:11 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Feb 10, 2011 at 06:29:41PM +0000, Dave Martin wrote:
>> On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
>> >> Note that this tree contains some extra patches (though I believe
>> >> nothing is there which should cause the problem), and does not contain
>> >> everything from rmk/devel -- so it's possible this has been fixed in
>> >> the meantime or no longer occurs for some other reason...
>> >
>> > No need - I now have some modules which contain SMP alternatives, so we
>> > do need to fix the module loader for this, and keep the SMP alternatives
>> > replacement code around. ?It's not worth eliminating the code as if we
>> > include an informative printk() to say why we're refusing to load the
>> > module, the string would be larger than the code it eliminates. ?So, I
>> > think we need to merge the patch below to avoid run-time problems.
>>
>> I thought the problem was not caused by removal of the fixup code, but
>> rather by the removal of code referenced by fixups?
>
> It is. ?But:
>
> arm-linux-objdump -h sound/core/snd-timer.ko
>
> sound/core/snd-timer.ko: ? ? file format elf32-littlearm
>
> Sections:
> Idx Name ? ? ? ? ?Size ? ? ?VMA ? ? ? LMA ? ? ? File off ?Algn
> ?0 .text ? ? ? ? 00002f34 ?00000000 ?00000000 ?00000034 ?2**2
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> ?1 .exit.text ? ?00000070 ?00000000 ?00000000 ?00002f68 ?2**2
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> ?2 .init.text ? ?000001b4 ?00000000 ?00000000 ?00002fd8 ?2**2
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> ?3 .rodata ? ? ? 000000bc ?00000000 ?00000000 ?0000318c ?2**2
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> ?4 .rodata.str1.1 00000156 ?00000000 ?00000000 ?00003248 ?2**0
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, READONLY, DATA
> ?5 .alt.smp.init 00000088 ?00000000 ?00000000 ?0000339e ?2**0
> ? ? ? ? ? ? ? ? ?CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> ...
>
> Here we have a module which contains the spin_unlock assembly, which
> contains the SMP alternatives. ?If we insert that into a kernel also
> built with SMP alternatives support, but which is running on a UP
> system, we need to run these fixups as well when the module is loaded.
>
Agreed -- actually, I suspected we might need to support this. But I
don't think solving this problem (= keeping the fixup implementation
in memory and enhancing the module loader) solved the
fixups-referencing-sections-discarded-from-vmlinux problem. These
seem to be two separate issues. I am filing to understand something?
Cheers
---Dave
^ permalink raw reply
* ARM: relocation out of range (when loading a module)
From: Dave Martin @ 2011-02-11 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102101405010.14920@xanadu.home>
On Thu, Feb 10, 2011 at 7:41 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 10 Feb 2011, Russell King - ARM Linux wrote:
>
>> On Thu, Jan 27, 2011 at 12:43:54AM -0500, Nicolas Pitre wrote:
>> > The MMU-less kernel should still favor allocations close to the kernel
>> > text for modules, and anything else away from the kernel going
>> > downwards.
>> >
>> > Otherwise a veneer should be created by the module symbol resolver such
>> > that if the branch distance to reach, say, printk is too large, then the
>> > following code would have to be dynamically generated right next to the
>> > module:
>> >
>> > ? ? ldr ? ? pc, [pc, #-4]
>> > ? ? .word ? <far_away_symbol>
>> >
>> > Then, in your module, you patch the branch relocation for printk so that
>> > it branches to the code above instead, and then store the address of
>> > printk at the location represented by the .word directive.
>>
>> What you're suggesting is what we used to do with the old user-space
>> module tools, which would've been nice to carry forwards to the new
>> module code. ?I never found a way to do it.
>>
>> The problems:
>> 1. Where do you create those veneers?
>> 2. How many veneers do you allocate space for?
>> 3. How do you determine that you need a veneer?
>>
>> While you can say "next to the module" for (1), you can only do that at
>> the point in time when the space for the module is allocated, and you
>> need to know at that point how much space you require.
>
> You would have to guess of course. ?Having a guess of 1/2 the module
> size should be pretty safe. ?So allocating 3/2 the space in
> module_alloc(), and then suffice to free the unused portion in
> module_finalize().
>
>> For (2), you could always allocate space for one veneer per symbol present
>> in the module, but that's very wasteful.
>>
>> (3) is almost impossible to know ahead of time as you don't have the
>> relocations, realistically you have to allocate one veneer per symbol,
>> and as you don't know whether it's a data or code symbol, you'll have
>> to allocate one veneer for every symbol in a module.
>
> I don't think you may know the number of symbols in advance either
> anyway.
You could probably cook up a good upper bound based on the size of the
kernel and the number of symbols in the module: i.e., assume that
every undefined symbol in the module needs to be fixed up to point at
the most distant symbol in the kernel.
For people with normal-sized kernels, this bound will probably work
out as zero most of the time (i.e., the current situation). For
people with big kernels, or when many modules are already loaded, it
may work out at 100% -- but that's the price to pay for guaranteed
preallocation of the space required for the veneers. And anyway, you
may really need a substantial chunk of those veneers in such cases.
---Dave
^ permalink raw reply
* [PATCH 1/3 v2] ARM: mx3+mx5: rename mxc_board_init to ${machine}_init
From: Uwe Kleine-König @ 2011-02-11 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297416069-6861-1-git-send-email-u.kleine-koenig@pengutronix.de>
mxc_board_init is too generic to be useful. Additionally change some
mxc_timer to ${machine}_timer, too.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,
sorry, the first version had a word missing in the Subject.
Uwe
arch/arm/mach-mx3/mach-cpuimx35.c | 4 ++--
arch/arm/mach-mx3/mach-kzm_arm11_01.c | 6 +-----
arch/arm/mach-mx3/mach-mx31_3ds.c | 7 ++-----
arch/arm/mach-mx3/mach-mx31ads.c | 7 ++-----
arch/arm/mach-mx3/mach-mx31lite.c | 4 ++--
arch/arm/mach-mx3/mach-mx31moboard.c | 4 ++--
arch/arm/mach-mx3/mach-mx35_3ds.c | 4 ++--
arch/arm/mach-mx3/mach-pcm037.c | 4 ++--
arch/arm/mach-mx3/mach-pcm043.c | 4 ++--
arch/arm/mach-mx3/mach-qong.c | 4 ++--
arch/arm/mach-mx5/board-mx51_3ds.c | 10 +++++-----
arch/arm/mach-mx5/board-mx51_babbage.c | 10 +++++-----
arch/arm/mach-mx5/board-mx51_efikamx.c | 10 +++++-----
13 files changed, 34 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-mx3/mach-cpuimx35.c b/arch/arm/mach-mx3/mach-cpuimx35.c
index 3eedf0f..7364db1 100644
--- a/arch/arm/mach-mx3/mach-cpuimx35.c
+++ b/arch/arm/mach-mx3/mach-cpuimx35.c
@@ -146,7 +146,7 @@ __setup("otg_mode=", eukrea_cpuimx35_otg_mode);
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init eukrea_cpuimx35_init(void)
{
mxc_iomux_v3_setup_multiple_pads(eukrea_cpuimx35_pads,
ARRAY_SIZE(eukrea_cpuimx35_pads));
@@ -189,5 +189,5 @@ MACHINE_START(EUKREA_CPUIMX35, "Eukrea CPUIMX35")
.init_ext3_fs = imx35_init_early,
.init_irq = mx35_init_irq,
.timer = &eukrea_cpuimx35_timer,
- .init_machine = mxc_board_init,
+ .init_machine = eukrea_cpuimx35_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-kzm_arm11_01.c b/arch/arm/mach-mx3/mach-kzm_arm11_01.c
index 52b8dd7..d3cc739 100644
--- a/arch/arm/mach-mx3/mach-kzm_arm11_01.c
+++ b/arch/arm/mach-mx3/mach-kzm_arm11_01.c
@@ -266,13 +266,9 @@ static void __init kzm_timer_init(void)
}
static struct sys_timer kzm_timer = {
- .init = kzm_timer_init,
+ .init = kzm_timer_init,
};
-/*
- * The following uses standard kernel macros define in arch.h in order to
- * initialize __mach_desc_KZM_ARM11_01 data structure.
- */
MACHINE_START(KZM_ARM11_01, "Kyoto Microcomputer Co., Ltd. KZM-ARM11-01")
.boot_params = MX3x_PHYS_OFFSET + 0x100,
.map_io = kzm_map_io,
diff --git a/arch/arm/mach-mx3/mach-mx31_3ds.c b/arch/arm/mach-mx3/mach-mx31_3ds.c
index 3d0ded9..1360fe4 100644
--- a/arch/arm/mach-mx3/mach-mx31_3ds.c
+++ b/arch/arm/mach-mx3/mach-mx31_3ds.c
@@ -320,10 +320,7 @@ static const struct imxuart_platform_data uart_pdata __initconst = {
.flags = IMXUART_HAVE_RTSCTS,
};
-/*!
- * Board specific initialization.
- */
-static void __init mxc_board_init(void)
+static void __init mx31_3ds_init(void)
{
mxc_iomux_setup_multiple_pins(mx31_3ds_pins, ARRAY_SIZE(mx31_3ds_pins),
"mx31_3ds");
@@ -378,5 +375,5 @@ MACHINE_START(MX31_3DS, "Freescale MX31PDK (3DS)")
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.timer = &mx31_3ds_timer,
- .init_machine = mxc_board_init,
+ .init_machine = mx31_3ds_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-mx31ads.c b/arch/arm/mach-mx3/mach-mx31ads.c
index 787bdc4..cb80b96 100644
--- a/arch/arm/mach-mx3/mach-mx31ads.c
+++ b/arch/arm/mach-mx3/mach-mx31ads.c
@@ -524,10 +524,7 @@ static void __init mx31ads_init_irq(void)
mx31ads_init_expio();
}
-/*!
- * Board specific initialization.
- */
-static void __init mxc_board_init(void)
+static void __init mx31ads_init(void)
{
mxc_init_extuart();
mxc_init_imx_uart();
@@ -555,5 +552,5 @@ MACHINE_START(MX31ADS, "Freescale MX31ADS")
.init_early = imx31_init_early,
.init_irq = mx31ads_init_irq,
.timer = &mx31ads_timer,
- .init_machine = mxc_board_init,
+ .init_machine = mx31ads_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-mx31lite.c b/arch/arm/mach-mx3/mach-mx31lite.c
index 01e24b5..64a1c1e 100644
--- a/arch/arm/mach-mx3/mach-mx31lite.c
+++ b/arch/arm/mach-mx3/mach-mx31lite.c
@@ -227,7 +227,7 @@ void __init mx31lite_map_io(void)
static int mx31lite_baseboard;
core_param(mx31lite_baseboard, mx31lite_baseboard, int, 0444);
-static void __init mxc_board_init(void)
+static void __init mx31lite_init(void)
{
int ret;
@@ -286,5 +286,5 @@ MACHINE_START(MX31LITE, "LogicPD i.MX31 SOM")
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.timer = &mx31lite_timer,
- .init_machine = mxc_board_init,
+ .init_machine = mx31lite_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-mx31moboard.c b/arch/arm/mach-mx3/mach-mx31moboard.c
index fd988a0..e77b081 100644
--- a/arch/arm/mach-mx3/mach-mx31moboard.c
+++ b/arch/arm/mach-mx3/mach-mx31moboard.c
@@ -503,7 +503,7 @@ core_param(mx31moboard_baseboard, mx31moboard_baseboard, int, 0444);
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init mx31moboard_init(void)
{
mxc_iomux_setup_multiple_pins(moboard_pins, ARRAY_SIZE(moboard_pins),
"moboard");
@@ -569,5 +569,5 @@ MACHINE_START(MX31MOBOARD, "EPFL Mobots mx31moboard")
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.timer = &mx31moboard_timer,
- .init_machine = mxc_board_init,
+ .init_machine = mx31moboard_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-mx35_3ds.c b/arch/arm/mach-mx3/mach-mx35_3ds.c
index c5115dc..0665111 100644
--- a/arch/arm/mach-mx3/mach-mx35_3ds.c
+++ b/arch/arm/mach-mx3/mach-mx35_3ds.c
@@ -156,7 +156,7 @@ __setup("otg_mode=", mx35_3ds_otg_mode);
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init mx35_3ds_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx35pdk_pads, ARRAY_SIZE(mx35pdk_pads));
@@ -198,5 +198,5 @@ MACHINE_START(MX35_3DS, "Freescale MX35PDK")
.init_early = imx35_init_early,
.init_irq = mx35_init_irq,
.timer = &mx35pdk_timer,
- .init_machine = mxc_board_init,
+ .init_machine = mx35_3ds_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-pcm037.c b/arch/arm/mach-mx3/mach-pcm037.c
index 7d444f7..b4f9ace 100644
--- a/arch/arm/mach-mx3/mach-pcm037.c
+++ b/arch/arm/mach-mx3/mach-pcm037.c
@@ -568,7 +568,7 @@ __setup("otg_mode=", pcm037_otg_mode);
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init pcm037_init(void)
{
int ret;
@@ -680,5 +680,5 @@ MACHINE_START(PCM037, "Phytec Phycore pcm037")
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.timer = &pcm037_timer,
- .init_machine = mxc_board_init,
+ .init_machine = pcm037_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-pcm043.c b/arch/arm/mach-mx3/mach-pcm043.c
index b03e19d..912841c 100644
--- a/arch/arm/mach-mx3/mach-pcm043.c
+++ b/arch/arm/mach-mx3/mach-pcm043.c
@@ -341,7 +341,7 @@ __setup("otg_mode=", pcm043_otg_mode);
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init pcm043_init(void)
{
mxc_iomux_v3_setup_multiple_pads(pcm043_pads, ARRAY_SIZE(pcm043_pads));
@@ -408,5 +408,5 @@ MACHINE_START(PCM043, "Phytec Phycore pcm043")
.init_early = imx35_init_early,
.init_irq = mx35_init_irq,
.timer = &pcm043_timer,
- .init_machine = mxc_board_init,
+ .init_machine = pcm043_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-qong.c b/arch/arm/mach-mx3/mach-qong.c
index 064f2db..0028163 100644
--- a/arch/arm/mach-mx3/mach-qong.c
+++ b/arch/arm/mach-mx3/mach-qong.c
@@ -247,7 +247,7 @@ static void __init qong_init_fpga(void)
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init qong_init(void)
{
mxc_init_imx_uart();
qong_init_nor_mtd();
@@ -275,5 +275,5 @@ MACHINE_START(QONG, "Dave/DENX QongEVB-LITE")
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.timer = &qong_timer,
- .init_machine = mxc_board_init,
+ .init_machine = qong_init,
MACHINE_END
diff --git a/arch/arm/mach-mx5/board-mx51_3ds.c b/arch/arm/mach-mx5/board-mx51_3ds.c
index 0168470..63dfbea 100644
--- a/arch/arm/mach-mx5/board-mx51_3ds.c
+++ b/arch/arm/mach-mx5/board-mx51_3ds.c
@@ -133,7 +133,7 @@ static struct spi_board_info mx51_3ds_spi_nor_device[] = {
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init mx51_3ds_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx51_3ds_pads,
ARRAY_SIZE(mx51_3ds_pads));
@@ -160,8 +160,8 @@ static void __init mx51_3ds_timer_init(void)
mx51_clocks_init(32768, 24000000, 22579200, 0);
}
-static struct sys_timer mxc_timer = {
- .init = mx51_3ds_timer_init,
+static struct sys_timer mx51_3ds_timer = {
+ .init = mx51_3ds_timer_init,
};
MACHINE_START(MX51_3DS, "Freescale MX51 3-Stack Board")
@@ -170,6 +170,6 @@ MACHINE_START(MX51_3DS, "Freescale MX51 3-Stack Board")
.map_io = mx51_map_io,
.init_early = imx51_init_early,
.init_irq = mx51_init_irq,
- .timer = &mxc_timer,
- .init_machine = mxc_board_init,
+ .timer = &mx51_3ds_timer,
+ .init_machine = mx51_3ds_init,
MACHINE_END
diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c
index 2bd9c9e..ab725e0 100644
--- a/arch/arm/mach-mx5/board-mx51_babbage.c
+++ b/arch/arm/mach-mx5/board-mx51_babbage.c
@@ -336,7 +336,7 @@ static const struct spi_imx_master mx51_babbage_spi_pdata __initconst = {
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init mx51_babbage_init(void)
{
iomux_v3_cfg_t usbh1stp = MX51_PAD_USBH1_STP__USBH1_STP;
iomux_v3_cfg_t power_key = _MX51_PAD_EIM_A27__GPIO2_21 |
@@ -390,8 +390,8 @@ static void __init mx51_babbage_timer_init(void)
mx51_clocks_init(32768, 24000000, 22579200, 0);
}
-static struct sys_timer mxc_timer = {
- .init = mx51_babbage_timer_init,
+static struct sys_timer mx51_babbage_timer = {
+ .init = mx51_babbage_timer_init,
};
MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board")
@@ -400,6 +400,6 @@ MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board")
.map_io = mx51_map_io,
.init_early = imx51_init_early,
.init_irq = mx51_init_irq,
- .timer = &mxc_timer,
- .init_machine = mxc_board_init,
+ .timer = &mx51_babbage_timer,
+ .init_machine = mx51_babbage_init,
MACHINE_END
diff --git a/arch/arm/mach-mx5/board-mx51_efikamx.c b/arch/arm/mach-mx5/board-mx51_efikamx.c
index 2aac4c5..6b35c7d 100644
--- a/arch/arm/mach-mx5/board-mx51_efikamx.c
+++ b/arch/arm/mach-mx5/board-mx51_efikamx.c
@@ -301,7 +301,7 @@ void mx51_efikamx_reset(void)
gpio_direction_output(EFIKAMX_RESET, 0);
}
-static void __init mxc_board_init(void)
+static void __init mx51_efikamx_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx51efikamx_pads,
ARRAY_SIZE(mx51efikamx_pads));
@@ -339,8 +339,8 @@ static void __init mx51_efikamx_timer_init(void)
mx51_clocks_init(32768, 24000000, 22579200, 24576000);
}
-static struct sys_timer mxc_timer = {
- .init = mx51_efikamx_timer_init,
+static struct sys_timer mx51_efikamx_timer = {
+ .init = mx51_efikamx_timer_init,
};
MACHINE_START(MX51_EFIKAMX, "Genesi EfikaMX nettop")
@@ -349,6 +349,6 @@ MACHINE_START(MX51_EFIKAMX, "Genesi EfikaMX nettop")
.map_io = mx51_map_io,
.init_early = imx51_init_early,
.init_irq = mx51_init_irq,
- .timer = &mxc_timer,
- .init_machine = mxc_board_init,
+ .timer = &mx51_efikamx_timer,
+ .init_machine = mx51_efikamx_init,
MACHINE_END
--
1.7.2.3
^ permalink raw reply related
* [PATCH] ARM: SAMSUNG: Removing dependency on CONFIG_PM_DEBUG for clock debugging
From: Amit Kachhap @ 2011-02-11 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinjhPP9NxLsOMovETAZLzFO70zmVWtPQ+E4PZj9@mail.gmail.com>
yes this is a temporary patch untill all the PM
components(sleep/resume) are mainlined.
The exact compilation error is,
CC arch/arm/plat-samsung/pm.o
arch/arm/plat-samsung/pm.c:32: fatal error: mach/pm-core.h: No such
file or directory
compilation terminated.
make[1]: *** [arch/arm/plat-samsung/pm.o] Error 1
Thanks,
Amit Daniel
On 11 February 2011 02:57, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>
> On Sat, Feb 12, 2011 at 7:06 PM, Amit Daniel Kachhap
> <amit.kachhap@linaro.org> wrote:
> > Enabling the macro CONFIG_PM_DEBUG is causing compilation error as all PM components
> > are included which is not in mainline for samsung V310 platform, therefore, this patch
> > removes the dependency on macro CONFIG_PM_DEBUG for clock debugging through debugfs
> > interface.
>
> What is the exact error? Might be helpful to have it in the patch description.
>
> Presumably, this is a temporary patch until PM components
> (suspend/resume hooks?) are mainlined and then we can put all this
> back under PM_DEBUG? In that case, it might be a good idea to mark it
> as such.
>
> Regards,
> Amit
>
> > Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
> > ---
> > ?arch/arm/plat-samsung/clock.c ? ? ? ? ? ? ?| ? ?4 ++--
> > ?arch/arm/plat-samsung/include/plat/clock.h | ? ?2 +-
> > ?2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/plat-samsung/clock.c b/arch/arm/plat-samsung/clock.c
> > index 7728928..aca5a25 100644
> > --- a/arch/arm/plat-samsung/clock.c
> > +++ b/arch/arm/plat-samsung/clock.c
> > @@ -450,7 +450,7 @@ int __init s3c24xx_register_baseclocks(unsigned long xtal)
> > ? ? ? ?return 0;
> > ?}
> >
> > -#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
> > +#if defined(CONFIG_DEBUG_FS)
> > ?/* debugfs support to trace clock tree hierarchy and attributes */
> >
> > ?static struct dentry *clk_debugfs_root;
> > @@ -538,4 +538,4 @@ err_out:
> > ?}
> > ?late_initcall(clk_debugfs_init);
> >
> > -#endif /* defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS) */
> > +#endif /* defined(CONFIG_DEBUG_FS) */
> > diff --git a/arch/arm/plat-samsung/include/plat/clock.h b/arch/arm/plat-samsung/include/plat/clock.h
> > index 9a82b88..f6180ab 100644
> > --- a/arch/arm/plat-samsung/include/plat/clock.h
> > +++ b/arch/arm/plat-samsung/include/plat/clock.h
> > @@ -47,7 +47,7 @@ struct clk {
> >
> > ? ? ? ?struct clk_ops ? ? ? ? ?*ops;
> > ? ? ? ?int ? ? ? ? ? ? ? ? (*enable)(struct clk *, int enable);
> > -#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
> > +#if defined(CONFIG_DEBUG_FS)
> > ? ? ? ?struct dentry ? ? ? ? ? *dent; ?/* For visible tree hierarchy */
> > ?#endif
> > ?};
> > --
> > 1.7.1
> >
> >
> > _______________________________________________
> > linaro-dev mailing list
> > linaro-dev at lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/linaro-dev
> >
^ permalink raw reply
* [PATCH 3/3] ARM: mx3/mx31ads: fix comments of irq callbacks
From: Uwe Kleine-König @ 2011-02-11 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211081050.GD27982@pengutronix.de>
The arguments to these callbacks were changed in
e981a30 (ARM: mx3: irq_data conversion.)
but the comments were not adapted.
Cc: Lennert Buytenhek <buytenh@secretlab.ca>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mx3/mach-mx31ads.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mx3/mach-mx31ads.c b/arch/arm/mach-mx3/mach-mx31ads.c
index 14e7671..4e4b780 100644
--- a/arch/arm/mach-mx3/mach-mx31ads.c
+++ b/arch/arm/mach-mx3/mach-mx31ads.c
@@ -144,7 +144,7 @@ static void mx31ads_expio_irq_handler(u32 irq, struct irq_desc *desc)
/*
* Disable an expio pin's interrupt by setting the bit in the imr.
- * @param irq an expio virtual irq number
+ * @param d an expio virtual irq description
*/
static void expio_mask_irq(struct irq_data *d)
{
@@ -156,7 +156,7 @@ static void expio_mask_irq(struct irq_data *d)
/*
* Acknowledge an expanded io pin's interrupt by clearing the bit in the isr.
- * @param irq an expanded io virtual irq number
+ * @param d an expio virtual irq description
*/
static void expio_ack_irq(struct irq_data *d)
{
@@ -167,7 +167,7 @@ static void expio_ack_irq(struct irq_data *d)
/*
* Enable a expio pin's interrupt by clearing the bit in the imr.
- * @param irq a expio virtual irq number
+ * @param d an expio virtual irq description
*/
static void expio_unmask_irq(struct irq_data *d)
{
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] ARM: mx3: remove some useless comments
From: Uwe Kleine-König @ 2011-02-11 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211081050.GD27982@pengutronix.de>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mx3/mach-mx31_3ds.c | 8 --------
arch/arm/mach-mx3/mach-mx31ads.c | 14 +-------------
arch/arm/mach-mx3/mach-qong.c | 9 ---------
arch/arm/mach-mx3/mm.c | 9 ---------
4 files changed, 1 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-mx3/mach-mx31_3ds.c b/arch/arm/mach-mx3/mach-mx31_3ds.c
index 1360fe4..817a275 100644
--- a/arch/arm/mach-mx3/mach-mx31_3ds.c
+++ b/arch/arm/mach-mx3/mach-mx31_3ds.c
@@ -42,10 +42,6 @@
/* CPLD IRQ line for external uart, external ethernet etc */
#define EXPIO_PARENT_INT IOMUX_TO_IRQ(MX31_PIN_GPIO1_1)
-/*
- * This file contains the board-specific initialization routines.
- */
-
static int mx31_3ds_pins[] = {
/* UART1 */
MX31_PIN_CTS1__CTS1,
@@ -364,10 +360,6 @@ static struct sys_timer mx31_3ds_timer = {
.init = mx31_3ds_timer_init,
};
-/*
- * The following uses standard kernel macros defined in arch.h in order to
- * initialize __mach_desc_MX31_3DS data structure.
- */
MACHINE_START(MX31_3DS, "Freescale MX31PDK (3DS)")
/* Maintainer: Freescale Semiconductor, Inc. */
.boot_params = MX3x_PHYS_OFFSET + 0x100,
diff --git a/arch/arm/mach-mx3/mach-mx31ads.c b/arch/arm/mach-mx3/mach-mx31ads.c
index cb80b96..14e7671 100644
--- a/arch/arm/mach-mx3/mach-mx31ads.c
+++ b/arch/arm/mach-mx3/mach-mx31ads.c
@@ -69,9 +69,6 @@
#define EXPIO_INT_XUART_INTB (MXC_EXP_IO_BASE + 11)
#define MXC_MAX_EXP_IO_LINES 16
-/*
- * This file contains the board-specific initialization routines.
- */
/*
* The serial port definition structure.
@@ -497,9 +494,7 @@ static void mxc_init_audio(void)
mxc_iomux_setup_multiple_pins(ssi_pins, ARRAY_SIZE(ssi_pins), "ssi");
}
-/*!
- * This structure defines static mappings for the i.MX31ADS board.
- */
+/* static mappings */
static struct map_desc mx31ads_io_desc[] __initdata = {
{
.virtual = MX31_CS4_BASE_ADDR_VIRT,
@@ -509,9 +504,6 @@ static struct map_desc mx31ads_io_desc[] __initdata = {
},
};
-/*!
- * Set up static virtual mappings.
- */
static void __init mx31ads_map_io(void)
{
mx31_map_io();
@@ -541,10 +533,6 @@ static struct sys_timer mx31ads_timer = {
.init = mx31ads_timer_init,
};
-/*
- * The following uses standard kernel macros defined in arch.h in order to
- * initialize __mach_desc_MX31ADS data structure.
- */
MACHINE_START(MX31ADS, "Freescale MX31ADS")
/* Maintainer: Freescale Semiconductor, Inc. */
.boot_params = MX3x_PHYS_OFFSET + 0x100,
diff --git a/arch/arm/mach-mx3/mach-qong.c b/arch/arm/mach-mx3/mach-qong.c
index 0028163..17f758b 100644
--- a/arch/arm/mach-mx3/mach-qong.c
+++ b/arch/arm/mach-mx3/mach-qong.c
@@ -54,10 +54,6 @@
#define QONG_FPGA_IRQ IOMUX_TO_IRQ(MX31_PIN_DTR_DCE1)
-/*
- * This file contains the board-specific initialization routines.
- */
-
static const struct imxuart_platform_data uart_pdata __initconst = {
.flags = IMXUART_HAVE_RTSCTS,
};
@@ -263,11 +259,6 @@ static struct sys_timer qong_timer = {
.init = qong_timer_init,
};
-/*
- * The following uses standard kernel macros defined in arch.h in order to
- * initialize __mach_desc_QONG data structure.
- */
-
MACHINE_START(QONG, "Dave/DENX QongEVB-LITE")
/* Maintainer: DENX Software Engineering GmbH */
.boot_params = MX3x_PHYS_OFFSET + 0x100,
diff --git a/arch/arm/mach-mx3/mm.c b/arch/arm/mach-mx3/mm.c
index 3387319..eefd4cf 100644
--- a/arch/arm/mach-mx3/mm.c
+++ b/arch/arm/mach-mx3/mm.c
@@ -28,14 +28,6 @@
#include <mach/hardware.h>
#include <mach/iomux-v3.h>
-/*!
- * @file mm.c
- *
- * @brief This file creates static virtual to physical mappings, common to all MX3 boards.
- *
- * @ingroup Memory
- */
-
#ifdef CONFIG_SOC_IMX31
static struct map_desc mx31_io_desc[] __initdata = {
imx_map_entry(MX31, X_MEMC, MT_DEVICE),
@@ -135,4 +127,3 @@ static int mxc_init_l2x0(void)
arch_initcall(mxc_init_l2x0);
#endif
-
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/3] ARM: mx3+mx5: rename to ${machine}_init
From: Uwe Kleine-König @ 2011-02-11 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211081050.GD27982@pengutronix.de>
mxc_board_init is too generic to be useful. Additionally change some
mxc_timer to ${machine}_timer, too.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mx3/mach-cpuimx35.c | 4 ++--
arch/arm/mach-mx3/mach-kzm_arm11_01.c | 6 +-----
arch/arm/mach-mx3/mach-mx31_3ds.c | 7 ++-----
arch/arm/mach-mx3/mach-mx31ads.c | 7 ++-----
arch/arm/mach-mx3/mach-mx31lite.c | 4 ++--
arch/arm/mach-mx3/mach-mx31moboard.c | 4 ++--
arch/arm/mach-mx3/mach-mx35_3ds.c | 4 ++--
arch/arm/mach-mx3/mach-pcm037.c | 4 ++--
arch/arm/mach-mx3/mach-pcm043.c | 4 ++--
arch/arm/mach-mx3/mach-qong.c | 4 ++--
arch/arm/mach-mx5/board-mx51_3ds.c | 10 +++++-----
arch/arm/mach-mx5/board-mx51_babbage.c | 10 +++++-----
arch/arm/mach-mx5/board-mx51_efikamx.c | 10 +++++-----
13 files changed, 34 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-mx3/mach-cpuimx35.c b/arch/arm/mach-mx3/mach-cpuimx35.c
index 3eedf0f..7364db1 100644
--- a/arch/arm/mach-mx3/mach-cpuimx35.c
+++ b/arch/arm/mach-mx3/mach-cpuimx35.c
@@ -146,7 +146,7 @@ __setup("otg_mode=", eukrea_cpuimx35_otg_mode);
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init eukrea_cpuimx35_init(void)
{
mxc_iomux_v3_setup_multiple_pads(eukrea_cpuimx35_pads,
ARRAY_SIZE(eukrea_cpuimx35_pads));
@@ -189,5 +189,5 @@ MACHINE_START(EUKREA_CPUIMX35, "Eukrea CPUIMX35")
.init_ext3_fs = imx35_init_early,
.init_irq = mx35_init_irq,
.timer = &eukrea_cpuimx35_timer,
- .init_machine = mxc_board_init,
+ .init_machine = eukrea_cpuimx35_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-kzm_arm11_01.c b/arch/arm/mach-mx3/mach-kzm_arm11_01.c
index 52b8dd7..d3cc739 100644
--- a/arch/arm/mach-mx3/mach-kzm_arm11_01.c
+++ b/arch/arm/mach-mx3/mach-kzm_arm11_01.c
@@ -266,13 +266,9 @@ static void __init kzm_timer_init(void)
}
static struct sys_timer kzm_timer = {
- .init = kzm_timer_init,
+ .init = kzm_timer_init,
};
-/*
- * The following uses standard kernel macros define in arch.h in order to
- * initialize __mach_desc_KZM_ARM11_01 data structure.
- */
MACHINE_START(KZM_ARM11_01, "Kyoto Microcomputer Co., Ltd. KZM-ARM11-01")
.boot_params = MX3x_PHYS_OFFSET + 0x100,
.map_io = kzm_map_io,
diff --git a/arch/arm/mach-mx3/mach-mx31_3ds.c b/arch/arm/mach-mx3/mach-mx31_3ds.c
index 3d0ded9..1360fe4 100644
--- a/arch/arm/mach-mx3/mach-mx31_3ds.c
+++ b/arch/arm/mach-mx3/mach-mx31_3ds.c
@@ -320,10 +320,7 @@ static const struct imxuart_platform_data uart_pdata __initconst = {
.flags = IMXUART_HAVE_RTSCTS,
};
-/*!
- * Board specific initialization.
- */
-static void __init mxc_board_init(void)
+static void __init mx31_3ds_init(void)
{
mxc_iomux_setup_multiple_pins(mx31_3ds_pins, ARRAY_SIZE(mx31_3ds_pins),
"mx31_3ds");
@@ -378,5 +375,5 @@ MACHINE_START(MX31_3DS, "Freescale MX31PDK (3DS)")
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.timer = &mx31_3ds_timer,
- .init_machine = mxc_board_init,
+ .init_machine = mx31_3ds_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-mx31ads.c b/arch/arm/mach-mx3/mach-mx31ads.c
index 787bdc4..cb80b96 100644
--- a/arch/arm/mach-mx3/mach-mx31ads.c
+++ b/arch/arm/mach-mx3/mach-mx31ads.c
@@ -524,10 +524,7 @@ static void __init mx31ads_init_irq(void)
mx31ads_init_expio();
}
-/*!
- * Board specific initialization.
- */
-static void __init mxc_board_init(void)
+static void __init mx31ads_init(void)
{
mxc_init_extuart();
mxc_init_imx_uart();
@@ -555,5 +552,5 @@ MACHINE_START(MX31ADS, "Freescale MX31ADS")
.init_early = imx31_init_early,
.init_irq = mx31ads_init_irq,
.timer = &mx31ads_timer,
- .init_machine = mxc_board_init,
+ .init_machine = mx31ads_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-mx31lite.c b/arch/arm/mach-mx3/mach-mx31lite.c
index 01e24b5..64a1c1e 100644
--- a/arch/arm/mach-mx3/mach-mx31lite.c
+++ b/arch/arm/mach-mx3/mach-mx31lite.c
@@ -227,7 +227,7 @@ void __init mx31lite_map_io(void)
static int mx31lite_baseboard;
core_param(mx31lite_baseboard, mx31lite_baseboard, int, 0444);
-static void __init mxc_board_init(void)
+static void __init mx31lite_init(void)
{
int ret;
@@ -286,5 +286,5 @@ MACHINE_START(MX31LITE, "LogicPD i.MX31 SOM")
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.timer = &mx31lite_timer,
- .init_machine = mxc_board_init,
+ .init_machine = mx31lite_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-mx31moboard.c b/arch/arm/mach-mx3/mach-mx31moboard.c
index fd988a0..e77b081 100644
--- a/arch/arm/mach-mx3/mach-mx31moboard.c
+++ b/arch/arm/mach-mx3/mach-mx31moboard.c
@@ -503,7 +503,7 @@ core_param(mx31moboard_baseboard, mx31moboard_baseboard, int, 0444);
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init mx31moboard_init(void)
{
mxc_iomux_setup_multiple_pins(moboard_pins, ARRAY_SIZE(moboard_pins),
"moboard");
@@ -569,5 +569,5 @@ MACHINE_START(MX31MOBOARD, "EPFL Mobots mx31moboard")
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.timer = &mx31moboard_timer,
- .init_machine = mxc_board_init,
+ .init_machine = mx31moboard_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-mx35_3ds.c b/arch/arm/mach-mx3/mach-mx35_3ds.c
index c5115dc..0665111 100644
--- a/arch/arm/mach-mx3/mach-mx35_3ds.c
+++ b/arch/arm/mach-mx3/mach-mx35_3ds.c
@@ -156,7 +156,7 @@ __setup("otg_mode=", mx35_3ds_otg_mode);
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init mx35_3ds_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx35pdk_pads, ARRAY_SIZE(mx35pdk_pads));
@@ -198,5 +198,5 @@ MACHINE_START(MX35_3DS, "Freescale MX35PDK")
.init_early = imx35_init_early,
.init_irq = mx35_init_irq,
.timer = &mx35pdk_timer,
- .init_machine = mxc_board_init,
+ .init_machine = mx35_3ds_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-pcm037.c b/arch/arm/mach-mx3/mach-pcm037.c
index 7d444f7..b4f9ace 100644
--- a/arch/arm/mach-mx3/mach-pcm037.c
+++ b/arch/arm/mach-mx3/mach-pcm037.c
@@ -568,7 +568,7 @@ __setup("otg_mode=", pcm037_otg_mode);
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init pcm037_init(void)
{
int ret;
@@ -680,5 +680,5 @@ MACHINE_START(PCM037, "Phytec Phycore pcm037")
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.timer = &pcm037_timer,
- .init_machine = mxc_board_init,
+ .init_machine = pcm037_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-pcm043.c b/arch/arm/mach-mx3/mach-pcm043.c
index b03e19d..912841c 100644
--- a/arch/arm/mach-mx3/mach-pcm043.c
+++ b/arch/arm/mach-mx3/mach-pcm043.c
@@ -341,7 +341,7 @@ __setup("otg_mode=", pcm043_otg_mode);
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init pcm043_init(void)
{
mxc_iomux_v3_setup_multiple_pads(pcm043_pads, ARRAY_SIZE(pcm043_pads));
@@ -408,5 +408,5 @@ MACHINE_START(PCM043, "Phytec Phycore pcm043")
.init_early = imx35_init_early,
.init_irq = mx35_init_irq,
.timer = &pcm043_timer,
- .init_machine = mxc_board_init,
+ .init_machine = pcm043_init,
MACHINE_END
diff --git a/arch/arm/mach-mx3/mach-qong.c b/arch/arm/mach-mx3/mach-qong.c
index 064f2db..0028163 100644
--- a/arch/arm/mach-mx3/mach-qong.c
+++ b/arch/arm/mach-mx3/mach-qong.c
@@ -247,7 +247,7 @@ static void __init qong_init_fpga(void)
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init qong_init(void)
{
mxc_init_imx_uart();
qong_init_nor_mtd();
@@ -275,5 +275,5 @@ MACHINE_START(QONG, "Dave/DENX QongEVB-LITE")
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.timer = &qong_timer,
- .init_machine = mxc_board_init,
+ .init_machine = qong_init,
MACHINE_END
diff --git a/arch/arm/mach-mx5/board-mx51_3ds.c b/arch/arm/mach-mx5/board-mx51_3ds.c
index 0168470..63dfbea 100644
--- a/arch/arm/mach-mx5/board-mx51_3ds.c
+++ b/arch/arm/mach-mx5/board-mx51_3ds.c
@@ -133,7 +133,7 @@ static struct spi_board_info mx51_3ds_spi_nor_device[] = {
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init mx51_3ds_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx51_3ds_pads,
ARRAY_SIZE(mx51_3ds_pads));
@@ -160,8 +160,8 @@ static void __init mx51_3ds_timer_init(void)
mx51_clocks_init(32768, 24000000, 22579200, 0);
}
-static struct sys_timer mxc_timer = {
- .init = mx51_3ds_timer_init,
+static struct sys_timer mx51_3ds_timer = {
+ .init = mx51_3ds_timer_init,
};
MACHINE_START(MX51_3DS, "Freescale MX51 3-Stack Board")
@@ -170,6 +170,6 @@ MACHINE_START(MX51_3DS, "Freescale MX51 3-Stack Board")
.map_io = mx51_map_io,
.init_early = imx51_init_early,
.init_irq = mx51_init_irq,
- .timer = &mxc_timer,
- .init_machine = mxc_board_init,
+ .timer = &mx51_3ds_timer,
+ .init_machine = mx51_3ds_init,
MACHINE_END
diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c
index 2bd9c9e..ab725e0 100644
--- a/arch/arm/mach-mx5/board-mx51_babbage.c
+++ b/arch/arm/mach-mx5/board-mx51_babbage.c
@@ -336,7 +336,7 @@ static const struct spi_imx_master mx51_babbage_spi_pdata __initconst = {
/*
* Board specific initialization.
*/
-static void __init mxc_board_init(void)
+static void __init mx51_babbage_init(void)
{
iomux_v3_cfg_t usbh1stp = MX51_PAD_USBH1_STP__USBH1_STP;
iomux_v3_cfg_t power_key = _MX51_PAD_EIM_A27__GPIO2_21 |
@@ -390,8 +390,8 @@ static void __init mx51_babbage_timer_init(void)
mx51_clocks_init(32768, 24000000, 22579200, 0);
}
-static struct sys_timer mxc_timer = {
- .init = mx51_babbage_timer_init,
+static struct sys_timer mx51_babbage_timer = {
+ .init = mx51_babbage_timer_init,
};
MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board")
@@ -400,6 +400,6 @@ MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board")
.map_io = mx51_map_io,
.init_early = imx51_init_early,
.init_irq = mx51_init_irq,
- .timer = &mxc_timer,
- .init_machine = mxc_board_init,
+ .timer = &mx51_babbage_timer,
+ .init_machine = mx51_babbage_init,
MACHINE_END
diff --git a/arch/arm/mach-mx5/board-mx51_efikamx.c b/arch/arm/mach-mx5/board-mx51_efikamx.c
index 2aac4c5..6b35c7d 100644
--- a/arch/arm/mach-mx5/board-mx51_efikamx.c
+++ b/arch/arm/mach-mx5/board-mx51_efikamx.c
@@ -301,7 +301,7 @@ void mx51_efikamx_reset(void)
gpio_direction_output(EFIKAMX_RESET, 0);
}
-static void __init mxc_board_init(void)
+static void __init mx51_efikamx_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx51efikamx_pads,
ARRAY_SIZE(mx51efikamx_pads));
@@ -339,8 +339,8 @@ static void __init mx51_efikamx_timer_init(void)
mx51_clocks_init(32768, 24000000, 22579200, 24576000);
}
-static struct sys_timer mxc_timer = {
- .init = mx51_efikamx_timer_init,
+static struct sys_timer mx51_efikamx_timer = {
+ .init = mx51_efikamx_timer_init,
};
MACHINE_START(MX51_EFIKAMX, "Genesi EfikaMX nettop")
@@ -349,6 +349,6 @@ MACHINE_START(MX51_EFIKAMX, "Genesi EfikaMX nettop")
.map_io = mx51_map_io,
.init_early = imx51_init_early,
.init_irq = mx51_init_irq,
- .timer = &mxc_timer,
- .init_machine = mxc_board_init,
+ .timer = &mx51_efikamx_timer,
+ .init_machine = mx51_efikamx_init,
MACHINE_END
--
1.7.2.3
^ permalink raw reply related
* [PATCH] omap3: fix compile-time warnings
From: Sanjeev Premi @ 2011-02-11 9:05 UTC (permalink / raw)
To: linux-arm-kernel
This patch fixes these warnings when building kernel for OMAP3EVM
only.
CC arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.o
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c:95: warning:
'dsp_24xx_wkdeps' defined but not used
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c:119: warning:
'mpu_24xx_wkdeps' defined but not used
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c:147: warning:
'core_24xx_wkdeps' defined but not used
The problem should be noticed when building for other OMAP3
platforms (only) as well.
Signed-off-by: Sanjeev Premi <premi@ti.com>
---
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
index e6f0d18..8134bb3 100644
--- a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
@@ -89,6 +89,8 @@ static struct clkdm_dep gfx_sgx_wkdeps[] = {
/* 24XX-specific possible dependencies */
+#ifdef CONFIG_ARCH_OMAP2
+
/* Wakeup dependency source arrays */
/* 2420/2430 PM_WKDEP_DSP: CORE, MPU, WKUP */
@@ -168,6 +170,7 @@ static struct clkdm_dep core_24xx_wkdeps[] = {
{ NULL },
};
+#endif /* CONFIG_ARCH_OMAP2 */
/* 2430-specific possible wakeup dependencies */
--
1.7.2.2
^ permalink raw reply related
* [PATCH] i.MX51 iomux: Fixes MX51_PAD_UART2_TXD__UART2_TXD declaration
From: Richard Zhao @ 2011-02-11 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210131051.GU9041@pengutronix.de>
Hi Sascha,
On Thu, Feb 10, 2011 at 02:10:51PM +0100, Sascha Hauer wrote:
> Hi Julien,
>
> The patch is probably fine. Can you provide a better commit log,
> something like 'fixes uart3 on $myboard'?
>
> From looking at the datasheet it is not clear to me how the current pin
> configuration bahaves. It looks like a uart tx loopback in the iomuxer.
> Is this correct?
Yes. IOMUXC_UART2_IPP_UART_RXD_MUX_SELECT_INPUT is used to select input of
IPP_UART_RXD. We always want it to connect to actual RXD pad.
I'll check mx50 iomux header for such issues.
Thanks
Richard
>
> Sascha
>
> On Wed, Feb 09, 2011 at 10:54:01AM +0100, julien.boibessot at free.fr wrote:
> > From: Julien Boibessot <julien.boibessot@armadeus.com>
> >
> >
> > Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
> > ---
> > arch/arm/plat-mxc/include/mach/iomux-mx51.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/plat-mxc/include/mach/iomux-mx51.h b/arch/arm/plat-mxc/include/mach/iomux-mx51.h
> > index b6767f9..df531aa 100644
> > --- a/arch/arm/plat-mxc/include/mach/iomux-mx51.h
> > +++ b/arch/arm/plat-mxc/include/mach/iomux-mx51.h
> > @@ -473,7 +473,7 @@
> > #define _MX51_PAD_UART2_RXD__UART2_RXD IOMUX_PAD(0x628, 0x238, 0, 0x09ec, 2, 0)
> > #define _MX51_PAD_UART2_TXD__FIRI_RXD IOMUX_PAD(0x62c, 0x23c, 1, 0x0000, 0, 0)
> > #define _MX51_PAD_UART2_TXD__GPIO1_21 IOMUX_PAD(0x62c, 0x23c, 3, 0x0000, 0, 0)
> > -#define _MX51_PAD_UART2_TXD__UART2_TXD IOMUX_PAD(0x62c, 0x23c, 0, 0x09ec, 3, 0)
> > +#define _MX51_PAD_UART2_TXD__UART2_TXD IOMUX_PAD(0x62c, 0x23c, 0, 0x0000, 0, 0)
> > #define _MX51_PAD_UART3_RXD__CSI1_D0 IOMUX_PAD(0x630, 0x240, 2, 0x0000, 0, 0)
> > #define _MX51_PAD_UART3_RXD__GPIO1_22 IOMUX_PAD(0x630, 0x240, 3, 0x0000, 0, 0)
> > #define _MX51_PAD_UART3_RXD__UART1_DTR IOMUX_PAD(0x630, 0x240, 0, 0x0000, 0, 0)
> > --
> > 1.6.0.4
> >
> >
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
> _______________________________________________
> 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] mx31: add support for the bugbase 1.3 from buglabs
From: Uwe Kleine-König @ 2011-02-11 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297372554-19527-1-git-send-email-GNUtoo@no-log.org>
On Thu, Feb 10, 2011 at 10:15:54PM +0100, Denis 'GNUtoo' Carikli wrote:
> This work was based on bug-linux-2.6.30.patch that can be found
> in buglabs's svn here:
> svn://bugcamp.net/bug/branches/izzy/experimental
>
> Note that the hardware schematics and documentations can be obtained
> here: http://www.bugcommunity.com/wiki/index.php/BUGbase
>
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> ---
> arch/arm/mach-mx3/Kconfig | 9 +++
> arch/arm/mach-mx3/Makefile | 1 +
> arch/arm/mach-mx3/mach-mx31bugbase.c | 97 ++++++++++++++++++++++++++++++++++
> 3 files changed, 107 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-mx3/mach-mx31bugbase.c
>
> diff --git a/arch/arm/mach-mx3/Kconfig b/arch/arm/mach-mx3/Kconfig
> index de80d98..4f57f13 100644
> --- a/arch/arm/mach-mx3/Kconfig
> +++ b/arch/arm/mach-mx3/Kconfig
> @@ -199,6 +199,15 @@ config MACH_KZM_ARM11_01
> Include support for KZM-ARM11-01. This includes specific
> configurations for the board and its peripherals.
>
> +config MACH_BUG
> + bool "Support Buglabs BUGBase platform"
> + select SOC_IMX31
> + select IMX_HAVE_PLATFORM_IMX_UART
> + default y
> + help
> + Include support for BUGBase 1.3 platform. This includes specific
> + configurations for the board and its peripherals.
> +
> config MACH_EUKREA_CPUIMX35
> bool "Support Eukrea CPUIMX35 Platform"
> select SOC_IMX35
> diff --git a/arch/arm/mach-mx3/Makefile b/arch/arm/mach-mx3/Makefile
> index bc7294f..98e5eb3 100644
> --- a/arch/arm/mach-mx3/Makefile
> +++ b/arch/arm/mach-mx3/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_MACH_PCM043) += mach-pcm043.o
> obj-$(CONFIG_MACH_ARMADILLO5X0) += mach-armadillo5x0.o
> obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
> obj-$(CONFIG_MACH_KZM_ARM11_01) += mach-kzm_arm11_01.o
> +obj-$(CONFIG_MACH_BUG) += mach-mx31bugbase.o
> obj-$(CONFIG_MACH_EUKREA_CPUIMX35) += mach-cpuimx35.o
> obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd-baseboard.o
> obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
> diff --git a/arch/arm/mach-mx3/mach-mx31bugbase.c b/arch/arm/mach-mx3/mach-mx31bugbase.c
> new file mode 100644
> index 0000000..e0ad0f0
> --- /dev/null
> +++ b/arch/arm/mach-mx3/mach-mx31bugbase.c
> @@ -0,0 +1,97 @@
> +/*
> + * Copyright (C) 2000 Deep Blue Solutions Ltd
> + * Copyright (C) 2002 Shane Nay (shane at minirl.com)
> + * Copyright 2005-2007 Freescale Semiconductor, Inc. All Rights Reserved.
If you ask me, remove the double space before the "Copyright"s.
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +
> +#include <mach/iomux-mx3.h>
> +#include <mach/imx-uart.h>
> +#include <mach/hardware.h>
> +#include <mach/common.h>
> +
> +#include <asm/mach/time.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach-types.h>
> +
> +#include "devices-imx31.h"
> +
> +/*!
> + * @file mx31bugbase.c
> + *
> + * @brief This file contains the board-specific initialization routines.
> + *
> + * @ingroup System
> + */
No doxygen-like comments, please. This comment is quite useless
actually.
> +
> +#if defined(CONFIG_SERIAL_IMX) || defined(CONFIG_SERIAL_IMX_MODULE)
> +static struct imxuart_platform_data uart_pdata = {
> + .flags = IMXUART_HAVE_RTSCTS,
> +};
> +
> +static unsigned int uart5_pins[] = {
> + MX31_PIN_PC_RST__CTS5,
> + MX31_PIN_PC_VS2__RTS5,
> + MX31_PIN_PC_BVD2__TXD5,
> + MX31_PIN_PC_BVD1__RXD5
> +};
> +
> +static inline void mxc_init_imx_uart(void)
> +{
> + mxc_iomux_setup_multiple_pins(uart5_pins,
> + ARRAY_SIZE(uart5_pins), "uart-4");
> + imx31_add_imx_uart4(&uart_pdata);
> +}
> +#else /* !SERIAL_IMX */
> +static inline void mxc_init_imx_uart(void)
> +{
> +}
> +#endif /* !SERIAL_IMX */
We usually register devices independant of the availability of the
drivers.
> +
> +/*!
> + * Board specific initialization.
> + */
> +static void __init mxc_board_init(void)
Please use a different name. mxc_board_init is used much and so makes
ctags and backtraces less valuable. Something like mx31bug_init would
be fine.
> +{
> + mxc_init_imx_uart();
> +}
> +
> +
> +static void __init mx31bug_timer_init(void)
> +{
> + mx31_clocks_init(26000000);
> +}
> +
> +static struct sys_timer mx31bug_timer = {
> + .init = mx31bug_timer_init,
> +};
> +
> +/*
> + * The following uses standard kernel macros defined in arch.h in order to
> + * initialize __mach_desc_MX31BUG data structure.
> + */
not usefull.
> +
> +MACHINE_START(BUG, "BugLabs BUGBase")
> + .boot_params = PHYS_OFFSET + 0x100,
use MX3_PHYS_OFFSET here please.
> + .timer = &mx31bug_timer,
> + .map_io = mx31_map_io,
> + .init_irq = mx31_init_irq,
> + .init_machine = mxc_board_init,
> +MACHINE_END
Note that this patch conflicts with
http://mid.gmane.org/1297092922-12741-2-git-send-email-u.kleine-koenig at pengutronix.de
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: SAMSUNG: Removing dependency on CONFIG_PM_DEBUG for clock debugging
From: Amit Kucheria @ 2011-02-11 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297530374-32635-1-git-send-email-amit.kachhap@linaro.org>
On Sat, Feb 12, 2011 at 7:06 PM, Amit Daniel Kachhap
<amit.kachhap@linaro.org> wrote:
> Enabling the macro CONFIG_PM_DEBUG is causing compilation error as all PM components
> are included which is not in mainline for samsung V310 platform, therefore, this patch
> removes the dependency on macro CONFIG_PM_DEBUG for clock debugging through debugfs
> interface.
What is the exact error? Might be helpful to have it in the patch description.
Presumably, this is a temporary patch until PM components
(suspend/resume hooks?) are mainlined and then we can put all this
back under PM_DEBUG? In that case, it might be a good idea to mark it
as such.
Regards,
Amit
> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
> ---
> ?arch/arm/plat-samsung/clock.c ? ? ? ? ? ? ?| ? ?4 ++--
> ?arch/arm/plat-samsung/include/plat/clock.h | ? ?2 +-
> ?2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/clock.c b/arch/arm/plat-samsung/clock.c
> index 7728928..aca5a25 100644
> --- a/arch/arm/plat-samsung/clock.c
> +++ b/arch/arm/plat-samsung/clock.c
> @@ -450,7 +450,7 @@ int __init s3c24xx_register_baseclocks(unsigned long xtal)
> ? ? ? ?return 0;
> ?}
>
> -#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
> +#if defined(CONFIG_DEBUG_FS)
> ?/* debugfs support to trace clock tree hierarchy and attributes */
>
> ?static struct dentry *clk_debugfs_root;
> @@ -538,4 +538,4 @@ err_out:
> ?}
> ?late_initcall(clk_debugfs_init);
>
> -#endif /* defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS) */
> +#endif /* defined(CONFIG_DEBUG_FS) */
> diff --git a/arch/arm/plat-samsung/include/plat/clock.h b/arch/arm/plat-samsung/include/plat/clock.h
> index 9a82b88..f6180ab 100644
> --- a/arch/arm/plat-samsung/include/plat/clock.h
> +++ b/arch/arm/plat-samsung/include/plat/clock.h
> @@ -47,7 +47,7 @@ struct clk {
>
> ? ? ? ?struct clk_ops ? ? ? ? ?*ops;
> ? ? ? ?int ? ? ? ? ? ? ? ? (*enable)(struct clk *, int enable);
> -#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
> +#if defined(CONFIG_DEBUG_FS)
> ? ? ? ?struct dentry ? ? ? ? ? *dent; ?/* For visible tree hierarchy */
> ?#endif
> ?};
> --
> 1.7.1
>
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
^ permalink raw reply
* [PATCH V3 1/1] ST SPEAr: PCIE gadget suppport
From: Andrew Morton @ 2011-02-11 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D54E39C.6070306@st.com>
On Fri, 11 Feb 2011 12:52:04 +0530 pratyush <pratyush.anand@st.com> wrote:
> >>> This interface implies that there will only ever be one device in the
> >>> machine, yes? Seems a bit short-sighted?
> >>>
> >>
> >> This device supports only one BAR in EP mode.
> >
> > I don't understand that.
> >
> > What happens if someone builds a computer with three of these devices
> > in it?
> >
>
> I understood it. I will modify the code to work with multiple instances of
> pcie device.
I don't think you need to go that far, unless you see a significant
likelihood think that such a computer might be created one day. This
depends on how hard and risky such a change is, of course.
But the current driver's userspace interface should at least
anticipate the possibility, so you aren't trapped into a weird or
non-back-compatible interface in the future.
So for now you might choose to do something as simple as renaming
/config/pcie-gadget to /config/pcie-gadget0 and leave it at that.
^ permalink raw reply
* [PATCH V3 1/1] ST SPEAr: PCIE gadget suppport
From: pratyush @ 2011-02-11 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210125256.609a1143.akpm@linux-foundation.org>
On 2/11/2011 2:22 AM, Andrew Morton wrote:
> On Thu, 10 Feb 2011 15:19:53 +0530
> pratyush <pratyush.anand@st.com> wrote:
>
>> On 2/10/2011 4:59 AM, Andrew Morton wrote:
>>> On Thu, 3 Feb 2011 19:39:09 +0530
>>> Pratyush Anand <pratyush.anand@st.com> wrote:
>>>
>>>> This is a configurable gadget. can be configured by configfs interface. Any
>>>> IP available at PCIE bus can be programmed to be used by host
>>>> controller.It supoorts both INTX and MSI.
>>>> By default, gadget is configured for INTX and SYSRAM1 is mapped to BAR0
>>>> with size 0x1000
>>>>
>>>>
>>>> ...
>>>>
>>>> --- /dev/null
>>>> +++ b/Documentation/ABI/testing/configfs-spear-pcie-gadget
>>>> @@ -0,0 +1,30 @@
>>>> +What: /config/pcie-gadget
>>>> +Date: Feb 2011
>>>> +KernelVersion: 2.6.37
>>>> +Contact: Pratyush Anand <pratyush.anand@st.com>
>>>> +Description:
>>>> +
>>>> + Interface is used to configure selected dual mode pcie controller
>>>> + as device and then program its various registers to configure it
>>>> + as a particular device type.
>>>> + This interfaces can be used to show spear's pcie device capability.
>>>> +
>>>> + Nodes are only visible when configfs is mounted. To mount configfs
>>>> + in /config directory use:
>>>> + # mount -t configfs none /config/
>>>> +
>>>> + /config/pcie-gadget/
>>>> + link ... used to enable ltssm and read its status.
>>>> + int_type ...used to configure and read type of supported
>>>> + interrupt
>>>> + no_of_msi ... used to configure number of MSI vector needed and
>>>> + to read no of MSI granted.
>>>> + inta ... write 1 to assert INTA and 0 to de-assert.
>>>> + send_msi ... write MSI vector to be sent.
>>>> + vendor_id ... used to write and read vendor id (hex)
>>>> + device_id ... used to write and read device id (hex)
>>>> + bar0_size ... used to write and read bar0_size
>>>> + bar0_address ... used to write and read bar0 mapped area in hex.
>>>> + bar0_rw_offset ... used to write and read offset of bar0 where
>>>> + bar0_data will be written or read.
>>>> + bar0_data ... used to write and read data at bar0_rw_offset.
>>>
>>> This interface implies that there will only ever be one device in the
>>> machine, yes? Seems a bit short-sighted?
>>>
>>
>> This device supports only one BAR in EP mode.
>
> I don't understand that.
>
> What happens if someone builds a computer with three of these devices
> in it?
>
I understood it. I will modify the code to work with multiple instances of
pcie device.
>>>> + flags &= ~PCI_MSI_FLAGS_QMASK;
>>>> + flags |= vec << 1;
>>>> + spear_dbi_write_reg(config, cap + PCI_MSI_FLAGS, 1, flags);
>>>> + } else
>>>> + return -EINVAL;
>>>> +
>>>> + strcpy(config->int_type, int_type);
>>>> +
>>>> + return count;
>>>> +}
>>>> +
>>>> +static ssize_t pcie_gadget_show_no_of_msi(
>>>> + struct spear_pcie_gadget_config *config,
>>>> + char *buf)
>>>> +{
>>>> + struct pcie_app_reg __iomem *app_reg =
>>>> + (struct pcie_app_reg __iomem *)config->va_app_base;
>>>> + u32 cap, vector, vec, flags;
>>>> +
>>>> + if ((readl(&app_reg->msg_status) & (1 << CFG_MSI_EN_ID))
>>>> + != (1 << CFG_MSI_EN_ID))
>>>> + vector = 0;
>>>> + else {
>>>> + cap = pci_find_own_capability(config, PCI_CAP_ID_MSI);
>>>> + spear_dbi_read_reg(config, cap + PCI_MSI_FLAGS, 1, &flags);
>>>> + flags &= ~PCI_MSI_FLAGS_QSIZE;
>>>> + vec = flags >> 4;
>>>> + vector = 1;
>>>> + while (vec--)
>>>> + vector *= 2;
>>>> + }
>>>> + config->configured_msi = vector;
>>>
>>> Wait. A "show" function is modifying kernel state?!?!?
>>>
>>
>> this show is a must call part of MSI vector negotiation.
>> A device must read first configured number of MSI, before
>> sending any MSI. Here value of vector is read from HW
>> and stored in a SW variable. So, it is not programmed
>> by any application input.
>
> What happens if a (buggy?) application tries to send an MSI before
> calling pcie_gadget_show_no_of_msi()?
>
It will receive an -EINVAL.
Regards
Pratyush
>
> .
>
^ permalink raw reply
* [PATCH 3/3] OMAP4: clockdomain: Add wkup/sleep dependency support
From: Rajendra Nayak @ 2011-02-11 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1102102209080.21991@utopia.booyaka.com>
> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Friday, February 11, 2011 10:44 AM
> To: Rajendra Nayak
> Cc: linux-omap at vger.kernel.org; Kevin Hilman; Benoit Cousson;
linux-arm-kernel at lists.infradead.org
> Subject: RE: [PATCH 3/3] OMAP4: clockdomain: Add wkup/sleep dependency
support
>
> Hi Rajendra
>
> On Fri, 11 Feb 2011, Rajendra Nayak wrote:
>
> > Failing silently is going to make it more difficult to identify and
fix.
> > Maybe a WARN in else?
> >
> > if (cd->clkdm) {
> > ...
> > } else
> > WARN()
>
> I was thinking it might be nice to put it right next to the
> _clkdm_lookup()s in clkdm_init(), since the _clkdm_lookup is what is
> actually failing. Then we could do a
>
> if (!cd->clkdm)
> continue;
>
> in the SoC-specific *_all_wkdep/sleepdep* code, just to keep the system
> from crashing...
>
> Does that sound okay to you?
Yep, that sounds better.
Thanks,
Rajendra
>
>
> - Paul
^ 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