* [PATCH] ARM: Thumb-2: Enable ARM/Thumb interworking for v7 cache maintenance
From: Russell King - ARM Linux @ 2011-02-15 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297792565-30401-1-git-send-email-dave.martin@linaro.org>
On Tue, Feb 15, 2011 at 05:56:05PM +0000, Dave Martin wrote:
> Cache maintenence functions may need to be called from low-level
> platform code (such as for omap3).
I'd rather wait until we have the suspend stuff sorted out. I'm
waiting for OMAP folk to sort out what's happening with the sleep*.S
code so that it can have the generic CPU suspend code integrated.
That could result in this change not being required.
^ permalink raw reply
* [PATCH v7 3/4] TI816X: Create board support and enable build for TI816X EVM
From: Russell King - ARM Linux @ 2011-02-15 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297791368-32042-1-git-send-email-hemantp@ti.com>
On Tue, Feb 15, 2011 at 11:06:08PM +0530, Hemant Pedanekar wrote:
> +static void __init ti8168_evm_init_irq(void)
> +{
> + omap_board_config = ti8168_evm_config;
> + omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
> + omap2_init_common_infrastructure();
> + omap2_init_common_devices(NULL, NULL);
> + omap_init_irq();
> +}
What here can use the new init_early hook in the machine record?
^ permalink raw reply
* [PATCH v7 3/4] TI816X: Create board support and enable build for TI816X EVM
From: Tony Lindgren @ 2011-02-15 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215180139.GF11199@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [110215 10:00]:
> On Tue, Feb 15, 2011 at 11:06:08PM +0530, Hemant Pedanekar wrote:
> > +static void __init ti8168_evm_init_irq(void)
> > +{
> > + omap_board_config = ti8168_evm_config;
> > + omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
> > + omap2_init_common_infrastructure();
> > + omap2_init_common_devices(NULL, NULL);
> > + omap_init_irq();
> > +}
>
> What here can use the new init_early hook in the machine record?
I can fix this up for the init_early changes when I merge the branches
together.
Tony
^ permalink raw reply
* [PATCH 2/6] ARM: pm: add generic CPU suspend/resume support
From: Colin Cross @ 2011-02-15 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110215105050.GA11199@n2100.arm.linux.org.uk>
On Tue, Feb 15, 2011 at 2:50 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Feb 14, 2011 at 08:11:23PM -0800, Colin Cross wrote:
>> Even with a cache flush, cpu_resume_turn_on_mmu fails because the page
>> table modification, done with the cache off, ends up in memory, but
>> the L2 contains the old value. ?When the MMU and cache are enabled,
>> the 1:1 mapping disappears. ?The page table would need to be
>> invalidated during suspend.
>>
>> I can avoid the problem entirely by leaving the MMU on and skipping
>> cpu_resume when the CPU does not go through reset.
>
> If you're not losing CPU state, what's the point in calling the suspend
> function? ?It's purpose is to save CPU state ready for the CPU going to
> sleep and losing power, and restoring that state when the CPU wakes up
> sometime later.
The CPU is going to a state where it may lose power (if the other CPU
enters the same state), or it may get an interrupt before the other
CPU powers down and wake back up again. In the second case, it has
already called cpu_suspend, so it either needs to return without
calling cpu_resume (which I have working), or cpu_suspend/cpu_resume
needs to work with the L2 cache enabled.
^ permalink raw reply
* [PATCH v2 1/2] ARM: IMX5: cpuidle driver
From: Sascha Hauer @ 2011-02-15 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297416973-32740-2-git-send-email-yong.shen@linaro.org>
On Fri, Feb 11, 2011 at 10:36:12AM +0100, yong.shen at linaro.org wrote:
> 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);
Please put this into a header file.
> +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])
> + ;
An if without code? This looks strange.
> + 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);
We have a late_initcall here which needs to be protected from other
cpus. On the other hand we depend on board code calling
imx_cpuidle_board_params() before this initcall. I think the board code
should call a imx_cpuidle_init(struct imx_cpuidle_params
*cpuidle_params) instead which makes the flow of execution more clear.
Also, the function should be named mx51_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
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* N50 Stuff
From: Marcel Böttcher @ 2011-02-15 18:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi there,
I saw, that a mach_n50 is in the machines list.
Does possibly anyone have further details like default configs or drivers?
Regards
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110215/bfedd963/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6414 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110215/bfedd963/attachment.p7s>
^ permalink raw reply
* compiling 2.6.37 kernel in THUMB2 mode
From: vb at vsbe.com @ 2011-02-15 19:26 UTC (permalink / raw)
To: linux-arm-kernel
hello all,
I am trying to compile the 2.6.37 kernel in THUMB2 mode and am
experiencing some compilation problems. Some inline assembly in some
files uses commands inappropriate for THUMB2 mode.
I wonder if the kernel is expected to compile cleanly when
CONFIG_THUMB2_KERNEL is enabled (and I am doing something wrong), or
is it know not to compile/work in Thumb2 node for any reason?
Thank you in advance for your help,
Vadim
^ permalink raw reply
* [PATCH] ARM: Thumb-2: Enable ARM/Thumb interworking for v7 cache maintenance
From: Nicolas Pitre @ 2011-02-15 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297792565-30401-1-git-send-email-dave.martin@linaro.org>
On Tue, 15 Feb 2011, Dave Martin wrote:
> Cache maintenence functions may need to be called from low-level
> platform code (such as for omap3).
>
> Some low-level code may need to be built as ARM code even in a Thumb-2
> kernel, if the code needs to talk to a non-Thumb-2-aware bootloader
> or firmware (again, omap3 is an example).
>
> In order to avoid the need for complex hacks to make calling
> these cache maintenance routines work, simply use "bx lr" to
> return from these functions.
>
> There's no risk of build failures, since mm/*-v7.S are by definition
> built with -march=armv7-a.
>
> bx lr always does the right thing for a pure ARM kernel, so we
> shouldn't need any conditional assembly here.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> ---
> arch/arm/mm/cache-v7.S | 20 ++++++++++----------
> 1 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
> index 6136e68..a5e5aa1 100644
> --- a/arch/arm/mm/cache-v7.S
> +++ b/arch/arm/mm/cache-v7.S
> @@ -29,7 +29,7 @@ ENTRY(v7_flush_icache_all)
> mov r0, #0
> ALT_SMP(mcr p15, 0, r0, c7, c1, 0) @ invalidate I-cache inner shareable
> ALT_UP(mcr p15, 0, r0, c7, c5, 0) @ I+BTB cache invalidate
> - mov pc, lr
> + bx lr
> ENDPROC(v7_flush_icache_all)
>
> /*
> @@ -87,7 +87,7 @@ finished:
> mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr
> dsb
> isb
> - mov pc, lr
> + bx lr
> ENDPROC(v7_flush_dcache_all)
>
> /*
> @@ -110,7 +110,7 @@ ENTRY(v7_flush_kern_cache_all)
> ALT_UP(mcr p15, 0, r0, c7, c5, 0) @ I+BTB cache invalidate
> ARM( ldmfd sp!, {r4-r5, r7, r9-r11, lr} )
> THUMB( ldmfd sp!, {r4-r7, r9-r11, lr} )
> - mov pc, lr
> + bx lr
> ENDPROC(v7_flush_kern_cache_all)
>
> /*
> @@ -136,7 +136,7 @@ ENTRY(v7_flush_user_cache_all)
> * - we have a VIPT cache.
> */
> ENTRY(v7_flush_user_cache_range)
> - mov pc, lr
> + bx lr
> ENDPROC(v7_flush_user_cache_all)
> ENDPROC(v7_flush_user_cache_range)
>
> @@ -194,7 +194,7 @@ ENTRY(v7_coherent_user_range)
> ALT_UP(mcr p15, 0, r0, c7, c5, 6) @ invalidate BTB
> dsb
> isb
> - mov pc, lr
> + bx lr
>
> /*
> * Fault handling for the cache operation above. If the virtual address in r0
> @@ -227,7 +227,7 @@ ENTRY(v7_flush_kern_dcache_area)
> cmp r0, r1
> blo 1b
> dsb
> - mov pc, lr
> + bx lr
> ENDPROC(v7_flush_kern_dcache_area)
>
> /*
> @@ -256,7 +256,7 @@ v7_dma_inv_range:
> cmp r0, r1
> blo 1b
> dsb
> - mov pc, lr
> + bx lr
> ENDPROC(v7_dma_inv_range)
>
> /*
> @@ -274,7 +274,7 @@ v7_dma_clean_range:
> cmp r0, r1
> blo 1b
> dsb
> - mov pc, lr
> + bx lr
> ENDPROC(v7_dma_clean_range)
>
> /*
> @@ -292,7 +292,7 @@ ENTRY(v7_dma_flush_range)
> cmp r0, r1
> blo 1b
> dsb
> - mov pc, lr
> + bx lr
> ENDPROC(v7_dma_flush_range)
>
> /*
> @@ -318,7 +318,7 @@ ENTRY(v7_dma_unmap_area)
> add r1, r1, r0
> teq r2, #DMA_TO_DEVICE
> bne v7_dma_inv_range
> - mov pc, lr
> + bx lr
> ENDPROC(v7_dma_unmap_area)
>
> __INITDATA
> --
> 1.7.1
>
>
> _______________________________________________
> 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 1/3] msm: iommu: Create a Kconfig item for the IOMMU driver
From: David Brown @ 2011-02-15 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297456729.4852.9.camel@m0nster>
On Fri, Feb 11 2011, Daniel Walker wrote:
> On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote:
>> +config MSM_IOMMU
>> + bool "MSM IOMMU Support"
>> + depends on ARCH_MSM8X60
>> + select IOMMU_API
>> + default n
>> + help
>> + Support for the IOMMUs found on certain Qualcomm SOCs.
>> + These IOMMUs allow virtualization of the address space used by most
>> + cores within the multimedia subsystem.
>> +
>> + If unsure, say N here.
>
> I think you should just make this a hidden option, unless there is a
> good reason why any given users might want to turn this off.
In this particular case, the driver is optional, even devices that use
it will be able to work both with and without it. It makes sense to be
able to decide whether to have it or not.
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] dmaengine: add slave-dma maintainer
From: Linus Walleij @ 2011-02-15 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110214115523.25875.45143.stgit@localhost6.localdomain6>
2011/2/14 Dan Williams <dan.j.williams@intel.com>:
> I have asked my colleague, Vinod Koul, to:
> 1/ put more definition around the slave api and usages to try to ensure
> consistent behavior across drivers (as much as possible)
> 2/ help review and merge new drivers according to this definition
Excellent choice, thanks to Dan & Vinod for taking on this!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/3] msm: iommu: Create a Kconfig item for the IOMMU driver
From: Daniel Walker @ 2011-02-15 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8yar5b9850l.fsf@huya.qualcomm.com>
On Tue, 2011-02-15 at 11:35 -0800, David Brown wrote:
> On Fri, Feb 11 2011, Daniel Walker wrote:
>
> > On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote:
> >> +config MSM_IOMMU
> >> + bool "MSM IOMMU Support"
> >> + depends on ARCH_MSM8X60
> >> + select IOMMU_API
> >> + default n
> >> + help
> >> + Support for the IOMMUs found on certain Qualcomm SOCs.
> >> + These IOMMUs allow virtualization of the address space used by most
> >> + cores within the multimedia subsystem.
> >> +
> >> + If unsure, say N here.
> >
> > I think you should just make this a hidden option, unless there is a
> > good reason why any given users might want to turn this off.
>
> In this particular case, the driver is optional, even devices that use
> it will be able to work both with and without it. It makes sense to be
> able to decide whether to have it or not.
Typically we include everything the SoC has regardless of if drivers use
the hardware or not . For instance there could be modules that use the
hardware ..
Regardless of this point, I've nacked the whole series. It looks like
there was very little thought put into this.
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH] spi/imx: select master mode for all channels
From: Grant Likely @ 2011-02-15 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297195739-24951-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Tue, Feb 08, 2011 at 09:08:59PM +0100, Uwe Kleine-K?nig wrote:
> From: Sascha Hauer <s.hauer@pengutronix.de>
>
> The hardware seems to have a race condition when the inactive
> channels are in slave mode. We support master mode only, so
> we can just switch all channels to master mode.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> [ukleinek: add more verbose comment about the race]
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> maybe one of our friends at Freescale can comment?
Any feedback on this one? Or should I just merge it?
g.
>
> Best regards
> Uwe
>
> drivers/spi/spi_imx.c | 12 +++++++++---
> 1 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c
> index 1cf9d5f..69d6dba 100644
> --- a/drivers/spi/spi_imx.c
> +++ b/drivers/spi/spi_imx.c
> @@ -174,7 +174,7 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
> #define SPI_IMX2_3_CTRL 0x08
> #define SPI_IMX2_3_CTRL_ENABLE (1 << 0)
> #define SPI_IMX2_3_CTRL_XCH (1 << 2)
> -#define SPI_IMX2_3_CTRL_MODE(cs) (1 << ((cs) + 4))
> +#define SPI_IMX2_3_CTRL_MODE_MASK (0xf << 4)
> #define SPI_IMX2_3_CTRL_POSTDIV_OFFSET 8
> #define SPI_IMX2_3_CTRL_PREDIV_OFFSET 12
> #define SPI_IMX2_3_CTRL_CS(cs) ((cs) << 18)
> @@ -253,8 +253,14 @@ static int __maybe_unused spi_imx2_3_config(struct spi_imx_data *spi_imx,
> {
> u32 ctrl = SPI_IMX2_3_CTRL_ENABLE, cfg = 0;
>
> - /* set master mode */
> - ctrl |= SPI_IMX2_3_CTRL_MODE(config->cs);
> + /*
> + * The hardware seems to have a race condition when changing modes. The
> + * current assumption is that the selection of the channel arrives
> + * earlier in the hardware than the mode bits when they are written at
> + * the same time.
> + * So set master mode for all channels as we do not support slave mode.
> + */
> + ctrl |= SPI_IMX2_3_CTRL_MODE_MASK;
>
> /* set clock speed */
> ctrl |= spi_imx2_3_clkdiv(spi_imx->spi_clk, config->speed_hz);
> --
> 1.7.2.3
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> spi-devel-general mailing list
> spi-devel-general at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
^ permalink raw reply
* [PATCH v5 0/5] omap: mailbox: hwmod support
From: Ramirez Luna, Omar @ 2011-02-15 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ipwq89by.fsf@ti.com>
Hi Kevin, Benoit,
On Fri, Feb 11, 2011 at 5:01 PM, Kevin Hilman <khilman@ti.com> wrote:
> Omar Ramirez Luna <omar.ramirez@ti.com> writes:
>
>> Mailbox hwmod support for OMAP 2,3,4.
>>
>> This was tested on OMAP3 (3430, 3630), minor testing
>> was made on OMAP4.
>>
>> No testing on OMAP2 since I don't have the hardware.
>
> To help in testing, I wrote a simple mailbox loopback test module for
> OMAP2/3/4 that I used to do send and receive messages on the MPU. ?This
> can be used to test the mailbox without any DSP software.
>
> I tested it against l-o master branch and found a couple bugs in the
> mailbox driver (patches posted earlier today.)
>
> With those patches plus my test I can send & receieve a series of
> messages on the MPU, which is enough to sanity test the basic sending
> and receiving messages on the MPU.
>
> I've tested the master branch, now it's your turn to use this test
> module to validate this hmod conversion series.
>
> The test module is available here:
>
> ? ?git://gitorious.org/omap-test/mailbox.git
I rechecked on OMAP3 (zoom2, zoom3) and OMAP4 (blaze), and
functionality hasn't changed with the hwmod support + Kevin's mbox
test.
On OMAP3, although functionality is ok with this patch set, I noticed
that the interface clock is not being disabled with its corresponding
pm_runtime_disable call. Previously, the driver enabled/disabled the
ick clock on demand, but now the clock stays enabled always (only
affected by the smart-idle feature, I presume).
Should this clock be placed in the main_clk field of omap_hwmod struct
instead of omap_hwmod_ocp_if, I moved it to ocp_if because of the ick
thing, any comment?
Regards,
Omar
^ permalink raw reply
* [PATCH v2 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-15 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110213192609.GA21429@void.printf.net>
Hi Chris,
On Sun, Feb 13, 2011 at 07:26:09PM +0000, Chris Ball wrote:
> Hi Shawn,
>
> On Mon, Feb 14, 2011 at 10:32:20AM +0800, Shawn Guo wrote:
> > This adds the mmc host driver for Freescale MXS-based SoC i.MX23/28.
> > The driver calls into mxs-dma via generic dmaengine api for both pio
> > and data transfer.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
>
> Please add a Reviewed-by: from Arnd and a Tested-by: from Lothar.
> Could you add a MODULE_AUTHOR() field, too?
>
OK. It will be - MODULE_AUTHOR("Freescale Semiconductor");
> I could take the drivers/mmc files through the MMC tree and have you
> submit the architecture patches separately, or you can send everything
> through an ARM tree with my ACK -- whichever you prefer.
>
I will send this single patch in v3 with new comments/concerns
addressed for you to pick up on MMC tree, and follow up others with
Sascha.
> Here's an indentation patch:
>
Thanks.
Regards,
Shawn
> diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
> index f359093..3a609f9 100644
> --- a/drivers/mmc/host/mxs-mmc.c
> +++ b/drivers/mmc/host/mxs-mmc.c
> @@ -127,13 +127,13 @@
> #define BF_SSP(value, field) (((value) << BP_SSP_##field) & BM_SSP_##field)
>
> #define MXS_MMC_IRQ_BITS (BM_SSP_CTRL1_SDIO_IRQ | \
> - BM_SSP_CTRL1_RESP_ERR_IRQ | \
> - BM_SSP_CTRL1_RESP_TIMEOUT_IRQ | \
> - BM_SSP_CTRL1_DATA_TIMEOUT_IRQ | \
> - BM_SSP_CTRL1_DATA_CRC_IRQ | \
> - BM_SSP_CTRL1_FIFO_UNDERRUN_IRQ | \
> - BM_SSP_CTRL1_RECV_TIMEOUT_IRQ | \
> - BM_SSP_CTRL1_FIFO_OVERRUN_IRQ)
> + BM_SSP_CTRL1_RESP_ERR_IRQ | \
> + BM_SSP_CTRL1_RESP_TIMEOUT_IRQ | \
> + BM_SSP_CTRL1_DATA_TIMEOUT_IRQ | \
> + BM_SSP_CTRL1_DATA_CRC_IRQ | \
> + BM_SSP_CTRL1_FIFO_UNDERRUN_IRQ | \
> + BM_SSP_CTRL1_RECV_TIMEOUT_IRQ | \
> + BM_SSP_CTRL1_FIFO_OVERRUN_IRQ)
>
> #define SSP_PIO_NUM 3
>
> @@ -165,7 +165,7 @@ static int mxs_mmc_get_ro(struct mmc_host *mmc)
> {
> struct mxs_mmc_host *host = mmc_priv(mmc);
> struct mxs_mmc_platform_data *pdata =
> - mmc_dev(host->mmc)->platform_data;
> + mmc_dev(host->mmc)->platform_data;
>
> if (!pdata)
> return -EFAULT;
> @@ -181,7 +181,7 @@ static int mxs_mmc_get_cd(struct mmc_host *mmc)
> struct mxs_mmc_host *host = mmc_priv(mmc);
>
> return !(readl(host->base + HW_SSP_STATUS) &
> - BM_SSP_STATUS_CARD_DETECT);
> + BM_SSP_STATUS_CARD_DETECT);
> }
>
> static void mxs_mmc_reset(struct mxs_mmc_host *host)
> @@ -202,21 +202,21 @@ static void mxs_mmc_reset(struct mxs_mmc_host *host)
> BM_SSP_CTRL1_RESP_ERR_IRQ_EN;
>
> writel(BF_SSP(0xffff, TIMING_TIMEOUT) |
> - BF_SSP(2, TIMING_CLOCK_DIVIDE) |
> - BF_SSP(0, TIMING_CLOCK_RATE),
> - host->base + HW_SSP_TIMING);
> + BF_SSP(2, TIMING_CLOCK_DIVIDE) |
> + BF_SSP(0, TIMING_CLOCK_RATE),
> + host->base + HW_SSP_TIMING);
>
> if (host->sdio_irq_en) {
> ctrl0 |= BM_SSP_CTRL0_SDIO_IRQ_CHECK;
> ctrl1 |= BM_SSP_CTRL1_SDIO_IRQ_EN;
> - }
> + }
>
> writel(ctrl0, host->base + HW_SSP_CTRL0);
> writel(ctrl1, host->base + HW_SSP_CTRL1);
> }
>
> static void mxs_mmc_start_cmd(struct mxs_mmc_host *host,
> - struct mmc_command *cmd);
> + struct mmc_command *cmd);
>
> static void mxs_mmc_request_done(struct mxs_mmc_host *host)
> {
> @@ -240,13 +240,13 @@ static void mxs_mmc_request_done(struct mxs_mmc_host *host)
> break;
> default:
> dev_warn(mmc_dev(host->mmc),
> - "%s: unsupported response type 0x%x\n",
> - __func__, mmc_resp_type(cmd));
> + "%s: unsupported response type 0x%x\n",
> + __func__, mmc_resp_type(cmd));
> }
>
> if (data) {
> dma_unmap_sg(mmc_dev(host->mmc), data->sg,
> - data->sg_len, host->dma_dir);
> + data->sg_len, host->dma_dir);
> /*
> * If there was an error on any block, we mark all
> * data blocks as being in error.
> @@ -285,7 +285,7 @@ static irqreturn_t mxs_mmc_irq_handler(int irq, void *dev_id)
>
> stat = readl(host->base + HW_SSP_CTRL1);
> writel(stat & MXS_MMC_IRQ_BITS,
> - host->base + HW_SSP_CTRL1 + MXS_CLR_ADDR);
> + host->base + HW_SSP_CTRL1 + MXS_CLR_ADDR);
>
> if ((stat & BM_SSP_CTRL1_SDIO_IRQ) && (stat & BM_SSP_CTRL1_SDIO_IRQ_EN))
> mmc_signal_sdio_irq(host->mmc);
> @@ -299,7 +299,7 @@ static irqreturn_t mxs_mmc_irq_handler(int irq, void *dev_id)
>
> if (data) {
> if (stat & (BM_SSP_CTRL1_DATA_TIMEOUT_IRQ |
> - BM_SSP_CTRL1_RECV_TIMEOUT_IRQ))
> + BM_SSP_CTRL1_RECV_TIMEOUT_IRQ))
> data->error = -ETIMEDOUT;
> else if (stat & BM_SSP_CTRL1_DATA_CRC_IRQ)
> data->error = -EILSEQ;
> @@ -313,7 +313,7 @@ static irqreturn_t mxs_mmc_irq_handler(int irq, void *dev_id)
> }
>
> static struct dma_async_tx_descriptor *mxs_mmc_prep_dma(
> - struct mxs_mmc_host *host, unsigned int append)
> + struct mxs_mmc_host *host, unsigned int append)
> {
> struct dma_async_tx_descriptor *desc;
> struct mmc_data *data = host->data;
> @@ -323,7 +323,7 @@ static struct dma_async_tx_descriptor *mxs_mmc_prep_dma(
> if (data) {
> /* data */
> dma_map_sg(mmc_dev(host->mmc), data->sg,
> - data->sg_len, host->dma_dir);
> + data->sg_len, host->dma_dir);
> sgl = data->sg;
> sg_len = data->sg_len;
> } else {
> @@ -340,7 +340,7 @@ static struct dma_async_tx_descriptor *mxs_mmc_prep_dma(
> } else {
> if (data)
> dma_unmap_sg(mmc_dev(host->mmc), data->sg,
> - data->sg_len, host->dma_dir);
> + data->sg_len, host->dma_dir);
> }
>
> return desc;
> @@ -374,7 +374,7 @@ static void mxs_mmc_bc(struct mxs_mmc_host *host)
>
> out:
> dev_warn(mmc_dev(host->mmc),
> - "%s: failed to prep dma\n", __func__);
> + "%s: failed to prep dma\n", __func__);
> }
>
> static void mxs_mmc_ac(struct mxs_mmc_host *host)
> @@ -413,7 +413,7 @@ static void mxs_mmc_ac(struct mxs_mmc_host *host)
>
> out:
> dev_warn(mmc_dev(host->mmc),
> - "%s: failed to prep dma\n", __func__);
> + "%s: failed to prep dma\n", __func__);
> }
>
> static unsigned short mxs_ns_to_ssp_ticks(unsigned clock_rate, unsigned ns)
> @@ -492,12 +492,12 @@ static void mxs_mmc_adtc(struct mxs_mmc_host *host)
> } else {
> writel(data_size, host->base + HW_SSP_XFER_SIZE);
> writel(BF_SSP(log2_blksz, BLOCK_SIZE_BLOCK_SIZE) |
> - BF_SSP(blocks - 1, BLOCK_SIZE_BLOCK_COUNT),
> - host->base + HW_SSP_BLOCK_SIZE);
> + BF_SSP(blocks - 1, BLOCK_SIZE_BLOCK_COUNT),
> + host->base + HW_SSP_BLOCK_SIZE);
> }
>
> if ((cmd->opcode == MMC_STOP_TRANSMISSION) ||
> - (cmd->opcode == SD_IO_RW_EXTENDED))
> + (cmd->opcode == SD_IO_RW_EXTENDED))
> cmd0 |= BM_SSP_CMD0_APPEND_8CYC;
>
> cmd1 = cmd->arg;
> @@ -535,11 +535,11 @@ static void mxs_mmc_adtc(struct mxs_mmc_host *host)
> return;
> out:
> dev_warn(mmc_dev(host->mmc),
> - "%s: failed to prep dma\n", __func__);
> + "%s: failed to prep dma\n", __func__);
> }
>
> static void mxs_mmc_start_cmd(struct mxs_mmc_host *host,
> - struct mmc_command *cmd)
> + struct mmc_command *cmd)
> {
> host->cmd = cmd;
>
> @@ -558,7 +558,7 @@ static void mxs_mmc_start_cmd(struct mxs_mmc_host *host,
> break;
> default:
> dev_warn(mmc_dev(host->mmc),
> - "%s: unknown MMC command\n", __func__);
> + "%s: unknown MMC command\n", __func__);
> break;
> }
> }
> @@ -636,18 +636,18 @@ static void mxs_mmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
>
> if (enable) {
> writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
> - host->base + HW_SSP_CTRL0 + MXS_SET_ADDR);
> + host->base + HW_SSP_CTRL0 + MXS_SET_ADDR);
> writel(BM_SSP_CTRL1_SDIO_IRQ_EN,
> - host->base + HW_SSP_CTRL1 + MXS_SET_ADDR);
> + host->base + HW_SSP_CTRL1 + MXS_SET_ADDR);
>
> if (readl(host->base + HW_SSP_STATUS) & BM_SSP_STATUS_SDIO_IRQ)
> mmc_signal_sdio_irq(host->mmc);
>
> } else {
> writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
> - host->base + HW_SSP_CTRL0 + MXS_CLR_ADDR);
> + host->base + HW_SSP_CTRL0 + MXS_CLR_ADDR);
> writel(BM_SSP_CTRL1_SDIO_IRQ_EN,
> - host->base + HW_SSP_CTRL1 + MXS_CLR_ADDR);
> + host->base + HW_SSP_CTRL1 + MXS_CLR_ADDR);
> }
>
> spin_unlock_irqrestore(&host->lock, flags);
> @@ -710,7 +710,7 @@ static int mxs_mmc_probe(struct platform_device *pdev)
>
> /* only major verion does matter */
> host->version = readl(host->base + HW_SSP_VERSION) >>
> - BP_SSP_VERSION_MAJOR;
> + BP_SSP_VERSION_MAJOR;
>
> host->mmc = mmc;
> host->res = r;
> @@ -755,8 +755,7 @@ static int mxs_mmc_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, mmc);
>
> - ret = request_irq(host->irq, mxs_mmc_irq_handler, 0,
> - DRIVER_NAME, host);
> + ret = request_irq(host->irq, mxs_mmc_irq_handler, 0, DRIVER_NAME, host);
> if (ret)
> goto out_free_dma;
>
> --
> Chris Ball <cjb@laptop.org> <http://printf.net/>
> One Laptop Per Child
>
^ permalink raw reply
* [PATCH v2 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-15 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102132335.54868.arnd@arndb.de>
On Sun, Feb 13, 2011 at 11:35:54PM +0100, Arnd Bergmann wrote:
> On Sunday 13 February 2011, Chris Ball wrote:
> > On Mon, Feb 14, 2011 at 10:32:20AM +0800, Shawn Guo wrote:
> > > This adds the mmc host driver for Freescale MXS-based SoC i.MX23/28.
> > > The driver calls into mxs-dma via generic dmaengine api for both pio
> > > and data transfer.
> > >
> > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> >
> > Please add a Reviewed-by: from Arnd and a Tested-by: from Lothar.
> > Could you add a MODULE_AUTHOR() field, too?
>
> In general, these tags should not simply be added by the author without
> having the person who did the reviewing or testing specifically provide
> them!
>
> In this particular case, I'm happy with the driver in version 2, good job!
> Please do add my
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>
Will do. Appreciate the review effort.
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-15 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110214153952.GE10709@pengutronix.de>
Hi Wolfram,
On Mon, Feb 14, 2011 at 04:39:52PM +0100, Wolfram Sang wrote:
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index afe8c6f..42a9e21 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -319,6 +319,15 @@ config MMC_MXC
> >
> > If unsure, say N.
> >
> > +config MMC_MXS
> > + tristate "Freescale MXS Multimedia Card Interface support"
> > + depends on ARCH_MXS
> > + help
> > + This selects the Freescale SSP MMC controller found on MXS based
> > + platforms like mx23/28.
> > +
> > + If unsure, say N.
> > +
>
> It should also depend on MXS_DMA?
>
Good point. Will do.
Regards,
Shawn
^ permalink raw reply
* [PATCH 2/4] arm: V2 configs: update mmp2 defconfig for brownstone and SoC Selection
From: Philip Rakity @ 2011-02-15 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102141320410.14920@xanadu.home>
V2
==
Use make savedefconfigconfig to produce reduced size defconfig
per suggestion of Nico Pitre.
V1
==
took old mmp2_defconfig --
did make menuconfig
changed to CPU_MMP2
added brownstone as supported board
Signed-off-by: Philip Rakity <prakity@marvell.com>
---
arch/arm/configs/mmp2_defconfig | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/configs/mmp2_defconfig b/arch/arm/configs/mmp2_defconfig
index 47ad3b1..93c03df 100644
--- a/arch/arm/configs/mmp2_defconfig
+++ b/arch/arm/configs/mmp2_defconfig
@@ -1,13 +1,14 @@
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_ARCH_MMP=y
+CONFIG_CPU_MMP2=y
+CONFIG_MACH_BROWNSTONE=y
CONFIG_MACH_FLINT=y
CONFIG_MACH_MARVELL_JASPER=y
CONFIG_HIGH_RES_TIMERS=y
@@ -16,7 +17,6 @@ CONFIG_AEABI=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="root=/dev/nfs rootfstype=nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on console=ttyS2,38400 mem=128M user_debug=255"
-CONFIG_VFP=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
@@ -33,7 +33,6 @@ CONFIG_MTD_NAND=y
CONFIG_MTD_ONENAND=y
CONFIG_MTD_ONENAND_GENERIC=y
# CONFIG_BLK_DEV is not set
-# CONFIG_MISC_DEVICES is not set
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_SMC91X=y
@@ -58,13 +57,11 @@ CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_MAX8925=y
-# CONFIG_VGA_CONSOLE is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_MAX8925=y
# CONFIG_DNOTIFY is not set
-CONFIG_INOTIFY=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_JFFS2_FS=y
--
1.7.0.4
^ permalink raw reply related
* BUG: ARM: MMP and PXA: nr_irqs > NR_IRQS
From: Lars-Peter Clausen @ 2011-02-15 21:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi
I stumbled upon this while looking through the existing archs using SPARSE_IRQ.
Even with SPARSE_IRQ the NR_IRQS is still the upper limit for the number of IRQs.
Both PXA and MMP set NR_IRQS to IRQ_BOARD_START, with IRQ_BOARD_START being the
number of IRQs used by the core.
In various machine files the nr_irqs field of the ARM machine defintion struct
is then set to "IRQ_BOARD_START + NR_BOARD_IRQS".
As a result "nr_irqs" will greater then NR_IRQS which then again causes the
"allocated_irqs" bitmap in the core irq code to be accessed beyond its size
overwriting unrelated data.
So as a fix I suggest setting NR_IRQS to a large a enough value like 1024 or
something.
- Lars
^ permalink raw reply
* platform data and mfd design question
From: Abhijeet Dharmapurikar @ 2011-02-15 21:51 UTC (permalink / raw)
To: linux-arm-kernel
Currently all the mfd devices declare their struct mfd_cell
sub_devices[] array within the core driver. The platform data to them is
either passed in as a part of the core driver's platform data.
Msm on the other hand declares the struct mfd_cell subdevice[] array in
the board file and passes this on to the core driver via platfom data.
This code can be found here (sorry for the long url - it is convinient
to click on it),
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=arch/arm/mach-msm/board-msm8x60.c;h=ed9e9a7674b5ee443f25af828a0044ff99fac483;hb=refs/heads/android-msm-2.6.35
look for static struct mfd_cell pm8058_subdevs[]
This gives one the convenience of changing the mfd_cells and their
platform data in the board file itself. There are boards where the
platform data of some cells changes and in some cases we dont even add a
particular cell.
This design makes the core driver very light weight. All it does is
calls mfd_add_devices on the cell array passed from its platform data.
Will this be acceptable in mainline OR do we need to change to follow
how others in drivers/mfd do it which is to define the mfd_cell array in
the core file itself and manipulate their platform data before doing
mfd_add_devices.
--
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 4/4] arm: V2 configs: update pxa910 defconfig for SoC Selection
From: Philip Rakity @ 2011-02-15 21:55 UTC (permalink / raw)
To: linux-arm-kernel
V2
==
Use make savedefconfigconfig to produce reduced size defconfig
per suggestion of Nico Pitre.
V1
==
took old pxa910_defconfig --
did make menuconfig
changed to CPU_PXA910
Signed-off-by: Philip Rakity <prakity@marvell.com>
---
arch/arm/configs/pxa910_defconfig | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/arm/configs/pxa910_defconfig b/arch/arm/configs/pxa910_defconfig
index 1cd381e..8c405cd 100644
--- a/arch/arm/configs/pxa910_defconfig
+++ b/arch/arm/configs/pxa910_defconfig
@@ -1,7 +1,6 @@
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_SLAB=y
CONFIG_MODULES=y
@@ -9,7 +8,7 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_ARCH_MMP=y
-CONFIG_MACH_TAVOREVB=y
+CONFIG_CPU_PXA910=y
CONFIG_MACH_TTC_DKB=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
@@ -30,7 +29,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_BLK_DEV is not set
-# CONFIG_MISC_DEVICES is not set
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_SMC91X=y
@@ -45,10 +43,8 @@ CONFIG_SERIAL_PXA_CONSOLE=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
-# CONFIG_VGA_CONSOLE is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
-CONFIG_INOTIFY=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_CRAMFS=y
--
1.7.0.4
^ permalink raw reply related
* [PATCH v5 3/5] OMAP4: hwmod data: add mailbox data
From: Ramirez Luna, Omar @ 2011-02-15 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5943A9.8010205@ti.com>
Hi Benoit,
On Mon, Feb 14, 2011 at 9:00 AM, Cousson, Benoit <b-cousson@ti.com> wrote:
>> +static struct omap_hwmod_irq_info omap44xx_mailbox_irqs[] = {
>> + ? ? ? { .name = "mbox", .irq = 26 + OMAP44XX_IRQ_GIC_START, },
>
> The original entry was unnamed since it is an unique entry and thus does not
> need to be differentiate on this platform.
>
> ? ? ? ?{ .irq = 26 + OMAP44XX_IRQ_GIC_START },
>
> Do you really need to have a name here? The strategy being to provide a name
> only if more than one entry exist.
> It is perfectibility doable, I'm just trying to understand your rational.
It is this way instead of plain platform_get_irq because omap2420 has
two interrupt sources to MPU and mailbox driver uses
platform_get_irq_byname to get the irq number.
Regards,
Omar
^ permalink raw reply
* [PATCH 2/4] arm: V2 configs: update pxa168 defconfig for SoC Selection
From: Philip Rakity @ 2011-02-15 21:56 UTC (permalink / raw)
To: linux-arm-kernel
V2
==
Use make savedefconfigconfig to produce reduced size defconfig
per suggestion of Nico Pitre.
V1
took old pxa168_defconfig --
did make menuconfig
Signed-off-by: Philip Rakity <prakity@marvell.com>
---
arch/arm/configs/pxa168_defconfig | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/configs/pxa168_defconfig b/arch/arm/configs/pxa168_defconfig
index 74d7e01..b07eb58 100644
--- a/arch/arm/configs/pxa168_defconfig
+++ b/arch/arm/configs/pxa168_defconfig
@@ -1,7 +1,6 @@
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
@@ -30,7 +29,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_BLK_DEV is not set
-# CONFIG_MISC_DEVICES is not set
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_SMC91X=y
@@ -45,10 +43,8 @@ CONFIG_SERIAL_PXA_CONSOLE=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
-# CONFIG_VGA_CONSOLE is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
-CONFIG_INOTIFY=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_CRAMFS=y
--
1.7.0.4
^ permalink raw reply related
* [RFC] Inter-processor Mailboxes Drivers
From: Meador Inge @ 2011-02-15 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110214100104.GC4371@pulham.picochip.com>
On 02/14/2011 04:01 AM, Jamie Iles wrote:
> On Fri, Feb 11, 2011 at 03:19:51PM -0600, Meador Inge wrote:
>> 1. Hardware specific bits somewhere under '.../arch/*'. Drivers
>> for the MPIC message registers on Power and OMAP4 mailboxes, for
>> example.
>> 2. A higher level driver under '.../drivers/mailbox/*'. That the
>> pieces in (1) would register with. This piece would expose the
>> main kernel API.
>> 3. Userspace interfaces for accessing the mailboxes. A
>> '/dev/mailbox1', '/dev/mailbox2', etc... mapping, for example.
>
> How about using virtio for all of this and having the mailbox as a
> notification/message passing driver for the virtio backend? There are
> already virtio console and network drivers that could be useful for the
> userspace part of it. drivers/virtio/virtio_ring.c might be a good
> starting point if you thought there was some mileage in this approach.
To be honest, I am not that familiar with 'virtio', but I will take a
look. Thanks for the pointer. Maybe Hollis can speak to this idea more.
> Jamie
>
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* [PATCH v2 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-15 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110214165959.GC31103@n2100.arm.linux.org.uk>
On Mon, Feb 14, 2011 at 04:59:59PM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 14, 2011 at 10:32:20AM +0800, Shawn Guo wrote:
> > + switch (mmc_resp_type(cmd)) {
> > + case MMC_RSP_NONE:
> > + break;
> > + case MMC_RSP_R1:
> > + case MMC_RSP_R1B:
> > + case MMC_RSP_R3:
> > + cmd->resp[0] = readl(host->base + HW_SSP_SDRESP0);
> > + break;
> > + case MMC_RSP_R2:
> > + cmd->resp[3] = readl(host->base + HW_SSP_SDRESP0);
> > + cmd->resp[2] = readl(host->base + HW_SSP_SDRESP1);
> > + cmd->resp[1] = readl(host->base + HW_SSP_SDRESP2);
> > + cmd->resp[0] = readl(host->base + HW_SSP_SDRESP3);
>
> You really should be testing for MMC_RSP_PRESENT and MMC_RSP_136
> here. The response types are made up of a bitfield which allows
> you to detect what's required rather than having to decode the
> response type itself.
>
Please review the update.
if (mmc_resp_type(cmd) & MMC_RSP_PRESENT) {
if (mmc_resp_type(cmd) & MMC_RSP_136) {
cmd->resp[3] = readl(host->base + HW_SSP_SDRESP0);
cmd->resp[2] = readl(host->base + HW_SSP_SDRESP1);
cmd->resp[1] = readl(host->base + HW_SSP_SDRESP2);
cmd->resp[0] = readl(host->base + HW_SSP_SDRESP3);
} else {
cmd->resp[0] = readl(host->base + HW_SSP_SDRESP0);
}
}
> > + else if (stat & BM_SSP_CTRL1_FIFO_UNDERRUN_IRQ)
> > + data->error = -ENODATA;
> > + else if (stat & BM_SSP_CTRL1_FIFO_OVERRUN_IRQ)
> > + data->error = -EOVERFLOW;
>
> Both of these have a common error code - -EIO.
>
OK. Thanks for teaching.
Regards,
Shawn
^ permalink raw reply
* [PATCH v5 3/5] OMAP4: hwmod data: add mailbox data
From: Cousson, Benoit @ 2011-02-15 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinA2a60TSM7qDC1LQiRaUTs0DR3bDMv+oVsVOE0@mail.gmail.com>
Hi Omar,
On 2/15/2011 10:55 PM, Ramirez Luna, Omar wrote:
> Hi Benoit,
>
> On Mon, Feb 14, 2011 at 9:00 AM, Cousson, Benoit<b-cousson@ti.com> wrote:
>>> +static struct omap_hwmod_irq_info omap44xx_mailbox_irqs[] = {
>>> + { .name = "mbox", .irq = 26 + OMAP44XX_IRQ_GIC_START, },
>>
>> The original entry was unnamed since it is an unique entry and thus does not
>> need to be differentiate on this platform.
>>
>> { .irq = 26 + OMAP44XX_IRQ_GIC_START },
>>
>> Do you really need to have a name here? The strategy being to provide a name
>> only if more than one entry exist.
>> It is perfectibility doable, I'm just trying to understand your rational.
>
> It is this way instead of plain platform_get_irq because omap2420 has
> two interrupt sources to MPU and mailbox driver uses
> platform_get_irq_byname to get the irq number.
This is what I was thinking, except that on OMAP2420 the names are:
+ { .name = "dsp", .irq = 26, },
+ { .name = "iva", .irq = 34, },
and on OMAP2430 and OMAP3
+ { .name = "dsp", .irq = 26, },
so why is it named "mbox" on OMAP4?
If you have to do several platform_get_irq_byname to get this one, I'd
prefer to get rid of that name for OMAP4. It will make mailbox irq
consistent with the other hwmods.
Thanks,
Benoit
^ 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