* [PATCH 00/11] OMAP2+: clock: add clockfw autoidle for iclks, OMAP2xxx
From: Kevin Hilman @ 2011-03-01 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216065030.22089.61217.stgit@twilight.localdomain>
Paul Walmsley <paul@pwsan.com> writes:
> Hello,
>
> This patch series adds clock framework-controlled autoidle support for
> the OMAP2xxx DPLL, APLLs, and OMAP2/3 interface clocks. The old
> direct register writes in the PM code to enable clock autoidle have been
> removed.
>
> This series also ensures that all clock autoidle is disabled during
> boot and only re-enabled if CONFIG_PM is enabled.
>
> The series applies on the 'clk_autoidle_a_2.6.39' branch of
> git://git.pwsan.com/linux-2.6.
>
> Boot-tested on N800, and dynamic idle-tested on OMAP3430 Beagleboard.
> Compile-tested with omap1_defconfig, omap2plus_defconfig, a 5912
> OSK-only config, an N8x0-only config, an OMAP3-only config, and an OMAP4-only
> config.
Reviewed-by: Kevin Hilman <khilman@ti.com>
Feel free to merge the various pm*.c changes via your tree.
Kevin
^ permalink raw reply
* [patch 1/2] mc13892: reboot on wdi event
From: Liam Girdwood @ 2011-03-01 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k4gkyydi.fsf@lebrac.rtp-net.org>
On Mon, 2011-02-28 at 16:25 +0100, Arnaud Patard wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>
> > On Mon, Feb 28, 2011 at 02:21:33PM +0100, Arnaud Patard wrote:
> >> By default, on wdi (watchdog input) event the mc13892 is powering off.
> >> This patch is changing this to reboot on wdi event.
> >>
> >> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
> >
> > This strikes me as something that should be configurable by platforms.
>
> afaik, mc13892 is used only on imx designs and the reset for imx is done
> only throught the watchdog. From this point of view, I don't see any
> valid reason for powering off instead of rebooting on watchdog event
>
If this change is for i.MX only then it should be optional as Freescale
probably will sell this PMIC to non i.MX users.
Thanks
Liam
^ permalink raw reply
* [PATCH 1/2] ARM: mx3/cpuimx35: fix build failure
From: Uwe Kleine-König @ 2011-03-01 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301203734.GF27107@n2100.arm.linux.org.uk>
Hi Russell,
On Tue, Mar 01, 2011 at 08:37:34PM +0000, Russell King - ARM Linux wrote:
> On Tue, Mar 01, 2011 at 09:30:58PM +0100, Uwe Kleine-K?nig wrote:
> > It seems vim's autocompletion played tricks on me without me noticing.
>
> Every time I hear the word 'autocompletion' it's always associated with
> the wrong thing happening. I really don't know why people even bother
> with 'autocompletion' because it seems to go wrong very often. Whether
> it be with code, or with nicknames on IRC...
>
> The only autocompletion that I've seen which works right and avoids these
> kinds of issues is in things like bash, where it won't autocomplete unless
> there is exactly one completion available.
Yeah, for vim autocompletion is "pop up a menu of possibilities and
already select the first one".
Still I consider the real problem to be "without me noticing".
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 1/2] ARM: mx3/cpuimx35: fix build failure
From: Russell King - ARM Linux @ 2011-03-01 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299011459-18200-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Tue, Mar 01, 2011 at 09:30:58PM +0100, Uwe Kleine-K?nig wrote:
> It seems vim's autocompletion played tricks on me without me noticing.
Every time I hear the word 'autocompletion' it's always associated with
the wrong thing happening. I really don't know why people even bother
with 'autocompletion' because it seems to go wrong very often. Whether
it be with code, or with nicknames on IRC...
The only autocompletion that I've seen which works right and avoids these
kinds of issues is in things like bash, where it won't autocomplete unless
there is exactly one completion available.
^ permalink raw reply
* [PATCH 2/2] ARM: mxc91231/iomux: mark pin_list as const
From: Uwe Kleine-König @ 2011-03-01 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299011621-18886-1-git-send-email-u.kleine-koenig@pengutronix.de>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mxc91231/iomux.c | 4 ++--
arch/arm/plat-mxc/include/mach/iomux-mxc91231.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mxc91231/iomux.c b/arch/arm/mach-mxc91231/iomux.c
index 405d9b1..5acb4d0 100644
--- a/arch/arm/mach-mxc91231/iomux.c
+++ b/arch/arm/mach-mxc91231/iomux.c
@@ -134,10 +134,10 @@ int mxc_iomux_alloc_pin(const unsigned int pin_mode, const char *label)
}
EXPORT_SYMBOL(mxc_iomux_alloc_pin);
-int mxc_iomux_setup_multiple_pins(unsigned int *pin_list, unsigned count,
+int mxc_iomux_setup_multiple_pins(const unsigned int *pin_list, unsigned count,
const char *label)
{
- unsigned int *p = pin_list;
+ const unsigned int *p = pin_list;
int i;
int ret = -EINVAL;
diff --git a/arch/arm/plat-mxc/include/mach/iomux-mxc91231.h b/arch/arm/plat-mxc/include/mach/iomux-mxc91231.h
index 15d5951..a86983d 100644
--- a/arch/arm/plat-mxc/include/mach/iomux-mxc91231.h
+++ b/arch/arm/plat-mxc/include/mach/iomux-mxc91231.h
@@ -51,7 +51,7 @@ int mxc_iomux_alloc_pin(const unsigned int pin_mode, const char *label);
* setups mutliple pins
* convenient way to call the above function with tables
*/
-int mxc_iomux_setup_multiple_pins(unsigned int *pin_list, unsigned count,
+int mxc_iomux_setup_multiple_pins(const unsigned int *pin_list, unsigned count,
const char *label);
/*
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] ARM: iomux-imx31: mark pin_list as const
From: Uwe Kleine-König @ 2011-03-01 20:33 UTC (permalink / raw)
To: linux-arm-kernel
This fixes the following warning in a mx3_defconfig build:
arch/arm/mach-mx3/mach-bug.c: In function 'bug_board_init':
arch/arm/mach-mx3/mach-bug.c:47: warning: passing argument 1 of 'mxc_iomux_setup_multiple_pins' discards qualifiers from pointer target type
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mx3/iomux-imx31.c | 4 ++--
arch/arm/plat-mxc/include/mach/iomux-mx3.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mx3/iomux-imx31.c b/arch/arm/mach-mx3/iomux-imx31.c
index a1d7fa5..525071b 100644
--- a/arch/arm/mach-mx3/iomux-imx31.c
+++ b/arch/arm/mach-mx3/iomux-imx31.c
@@ -118,10 +118,10 @@ int mxc_iomux_alloc_pin(const unsigned int pin, const char *label)
}
EXPORT_SYMBOL(mxc_iomux_alloc_pin);
-int mxc_iomux_setup_multiple_pins(unsigned int *pin_list, unsigned count,
+int mxc_iomux_setup_multiple_pins(const unsigned int *pin_list, unsigned count,
const char *label)
{
- unsigned int *p = pin_list;
+ const unsigned int *p = pin_list;
int i;
int ret = -EINVAL;
diff --git a/arch/arm/plat-mxc/include/mach/iomux-mx3.h b/arch/arm/plat-mxc/include/mach/iomux-mx3.h
index cbaed29..b07008f 100644
--- a/arch/arm/plat-mxc/include/mach/iomux-mx3.h
+++ b/arch/arm/plat-mxc/include/mach/iomux-mx3.h
@@ -117,7 +117,7 @@ int mxc_iomux_alloc_pin(const unsigned int pin, const char *label);
* setups mutliple pins
* convenient way to call the above function with tables
*/
-int mxc_iomux_setup_multiple_pins(unsigned int *pin_list, unsigned count,
+int mxc_iomux_setup_multiple_pins(const unsigned int *pin_list, unsigned count,
const char *label);
/*
--
1.7.2.3
^ permalink raw reply related
* [RFC PATCH] ARM: Use generic BUG() handler
From: Russell King - ARM Linux @ 2011-03-01 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298939263-16421-1-git-send-email-sjg@chromium.org>
On Mon, Feb 28, 2011 at 04:27:43PM -0800, Simon Glass wrote:
> @@ -55,7 +56,8 @@ static void dump_mem(const char *, const char *, unsigned long, unsigned long);
> void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame)
> {
> #ifdef CONFIG_KALLSYMS
> - printk("[<%08lx>] (%pS) from [<%08lx>] (%pS)\n", where, (void *)where, from, (void *)from);
> + printk(" [<%08lx>] (%pS) from [<%08lx>] (%pS)\n", where, (void *)where,
> + from, (void *)from);
> #else
> printk("Function entered at [<%08lx>] from [<%08lx>]\n", where, from);
> #endif
> @@ -171,7 +173,7 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> unsigned int fp, mode;
> int ok = 1;
>
> - printk("Backtrace: ");
> + printk("Backtrace:\n");
>
> if (!tsk)
> tsk = current;
Why are you changing the way backtraces are printed? This introduces a
useless blank line in the oops dump. The previous hunk increases the
probability of mailers wrapping the backtrace making it harder to read.
If you're going to change the formatting of the Oops dump, please do it
as a separate patch and explain carefully why the change is necessary.
> diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
> index d2cb0b3..3f065bd 100644
> --- a/arch/arm/kernel/unwind.c
> +++ b/arch/arm/kernel/unwind.c
> @@ -355,6 +355,7 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> register unsigned long current_sp asm ("sp");
>
> pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
> + printk("Backtrace:\n");
Err, no. This is in the wrong place.
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 86b66f3..591ab50 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -72,6 +72,18 @@ SECTIONS
>
> PERCPU(PAGE_SIZE)
>
> + /*
> + * .exit.text is discarded at runtime, not link time, to deal with
> + * references from bug_table
> + */
> + .exit.text : AT(ADDR(.exit.text)) {
> + EXIT_TEXT
> + }
> +
> + .exit.data : AT(ADDR(.exit.data)) {
> + EXIT_DATA
> + }
> +
> #ifndef CONFIG_XIP_KERNEL
> . = ALIGN(PAGE_SIZE);
> __init_end = .;
> @@ -246,7 +258,6 @@ SECTIONS
> __tcm_end = .;
> }
> #endif
> -
> BSS_SECTION(0, 0, 0)
> _end = .;
>
> @@ -254,7 +265,7 @@ SECTIONS
> .comment 0 : { *(.comment) }
>
> /* Default discards */
> - DISCARDS
> + /*DISCARDS*/
>
> #ifndef CONFIG_SMP_ON_UP
> /DISCARD/ : {
And this is a mess.
^ permalink raw reply
* [PATCH 2/2] ARM: mx3/pcm043: fix build failure
From: Uwe Kleine-König @ 2011-03-01 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301203018.GY22310@pengutronix.de>
Commit
530aca5 (arm: mach-mx3: pcm043: add write-protect and card-detect for SD1)
assigned a non-existing member .cd_gpio in a struct esdhc_platform_data.
Though I expect this to change soon I remove it for now to unbreak the
autobuilders.
Cc: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mx3/mach-pcm043.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mx3/mach-pcm043.c b/arch/arm/mach-mx3/mach-pcm043.c
index 3a7b3c3..b5ee66e 100644
--- a/arch/arm/mach-mx3/mach-pcm043.c
+++ b/arch/arm/mach-mx3/mach-pcm043.c
@@ -227,7 +227,6 @@ static iomux_v3_cfg_t pcm043_pads[] = {
#define AC97_GPIO_RESET IMX_GPIO_NR(2, 0)
#define SD1_GPIO_WP IMX_GPIO_NR(2, 23)
-#define SD1_GPIO_CD IMX_GPIO_NR(2, 24)
static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
{
@@ -313,7 +312,6 @@ pcm037_nand_board_info __initconst = {
static struct esdhc_platform_data sd1_pdata = {
.wp_gpio = SD1_GPIO_WP,
- .cd_gpio = SD1_GPIO_CD,
};
#if defined(CONFIG_USB_ULPI)
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] ARM: mx3/cpuimx35: fix build failure
From: Uwe Kleine-König @ 2011-03-01 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301203018.GY22310@pengutronix.de>
It seems vim's autocompletion played tricks on me without me noticing.
This was intruduced in
97976e2 (ARM: mx3: use .init_early to initialize cpu type, reset address and iomuxer)
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mx3/mach-cpuimx35.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-mx3/mach-cpuimx35.c b/arch/arm/mach-mx3/mach-cpuimx35.c
index a42f1a9..ec63d99 100644
--- a/arch/arm/mach-mx3/mach-cpuimx35.c
+++ b/arch/arm/mach-mx3/mach-cpuimx35.c
@@ -196,7 +196,7 @@ MACHINE_START(EUKREA_CPUIMX35, "Eukrea CPUIMX35")
/* Maintainer: Eukrea Electromatique */
.boot_params = MX3x_PHYS_OFFSET + 0x100,
.map_io = mx35_map_io,
- .init_ext3_fs = imx35_init_early,
+ .init_early = imx35_init_early,
.init_irq = mx35_init_irq,
.timer = &eukrea_cpuimx35_timer,
.init_machine = eukrea_cpuimx35_init,
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/2] 3 build failures in imx-for-2.6.39
From: Uwe Kleine-König @ 2011-03-01 20:30 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
currently there are 3 build failures in Sascha's imx-for-2.6.39 branch.
Two of them are fixed in this series, I didn't find motivation to fix
the third (in mx51_defconfig):
arch/arm/mach-mx5/built-in.o: In function `efika_board_common_init':
board-mx51_efikamx.c:(.init.text+0x1384): undefined reference to `otg_ulpi_create'
board-mx51_efikamx.c:(.init.text+0x1430): undefined reference to `mxc_ulpi_access_ops'
I guess there are some #ifdefs missing somewhere.
I talked shortly to Sascha about it and we both think that these #ifdefs
are ugly and a better fix is needed here. (E.g. providing dummys for
the used functions. But I didn't look into that yet.)
For the two patches in this series I'd suggest to squash them in the
offending commits, but that's up to Sascha to decide.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [RFC PATCH] ARM: Use generic BUG() handler
From: Russell King - ARM Linux @ 2011-03-01 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinMnZAupxn7oYFhqkN1Y0OD-eyN=UeRpw96no9r@mail.gmail.com>
On Tue, Mar 01, 2011 at 08:34:37AM -0800, Simon Glass wrote:
> It seems I am lucky with the gcc I am using. I would have thought this
> would be a pretty fundamental feature, but yes I did notice that %c
> wasn't used anywhere.
It is, and I think it's something that I found back in 2002 or so.
I've still not had the time yet to search out the bug report, and
probably won't do for some time yet.
> Would this kernel feature be acceptable as a selectable config option
> on ARM then?
If I were to ask you if you knew which GCC version supported this,
would you know that answer?
If the answer to that is no, how would you expect people configuring
the kernel to know whether they should enable or disable this option?
^ permalink raw reply
* Fwd: [RFC] MMC: error handling improvements
From: Russell King - ARM Linux @ 2011-03-01 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a8453bae3ced14c4c325d1782be92e24.squirrel@www.codeaurora.org>
On Tue, Mar 01, 2011 at 10:39:59AM -0800, Murali Krishna Palnati wrote:
> Our main concern in moving to mmci is support for DMA that needs to be
> added to this driver. I believe PL180 controller does have the ability to
> talk to DMA engines, but i dont see any relevant support for that in mmci
> driver, unless i grossly missed something.
DMA engine support will be added at the next merge window. It's already
in linux-next.
Note that as ARM evaluation boards all have entirely broken DMA, it's
something I can't test here, so I'm entirely reliant on other people
using the driver with working DMA engines, testing it, and reporting
back. This is why the ARM primecell drivers traditionally have had no
DMA support - I just don't have any working hardware to develop such
facilities.
^ permalink raw reply
* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Russell King - ARM Linux @ 2011-03-01 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103011140560.2701@localhost6.localdomain6>
On Tue, Mar 01, 2011 at 11:57:48AM +0100, Thomas Gleixner wrote:
> On Mon, 28 Feb 2011, Russell King - ARM Linux wrote:
>
> > On Mon, Feb 28, 2011 at 08:16:25PM +0100, Thomas Gleixner wrote:
> > > So what's the gain of a barebone chained handler over a regular
> > > interrupt:
> > >
> > > - 100 instructions less
> > > - lack of statistics
> >
> > We don't want statistics. Don't care how many times we go to look
> > at the interrupt controller - and actually it's really wrong to count
> > them in the first place. Counting them means that you double-count
> > these interrupt events, and the more layers of interrupt controllers
> > there are the worse that problem gets.
> >
> > So no, that's a definite argument *for* chained handers.
>
> Errm, why do you double account them ? The accounting goes to
> different irq numbers, but we could exclude them from accounting and
> showing up in proc/interrupts easily.
We don't want the parent interrupt counted because the interrupt sum
which is exported from the kernel via the various statistics interface
will be screwed by this. For N levels of classical interrupt handlers,
causing I interrupts, you end up with I*N interrupts reported.
So if you have a 100Hz interrupt coming from a timer on a 2nd level IRQ
controller, you'll end up seeing a 200Hz interrupt rate, which is quite
obviously wrong.
> > Don't want affinity for them, as setting their affinity means that
> > you then end up forcing the affinity for the sub-interrupts too.
> > How you do cope with the high-level interrupt having affinity to
> > CPU0 but a lower level interrupt being affine to CPU1 only?
> >
> > It's non-sensible, and is broken. So no, again this isn't an
> > argument for not using chained handlers. It's an argument *for*
> > them.
>
> Well, moving the whole group to a particular cpu is sensible and the
> sub interrupts don't have a set_affinity function anyway as they are
> always called on the cpu on which the primary interrupt is handled.
Not quite correct - there's systems with two GICs chained one after each
other. The second GIC will not have a NULL set_affinity function.
However, it is meaningless to set the affinity for the second GIC as it
is not multi-CPU aware.
> > Sorry, but I think this stuff is right, and chained handlers like
> > these have their place.
>
> I'm not against chained handlers per se. I'm against creating a
> necessarity to make a chained handler deal with various different
> underlying primary irq chips and their oddities. That's simply wrong
> and broken.
That wasn't a problem before genirq came along and invented many more
different ways for 'flow' handlers to call into the lower level IRQ
specific code.
> I don't say you have to use the existing flow handlers, if they are
> too heavy weight for your purpose, but pushing conditional flow
> handling into the chained handler is violating all principles of
> layering.
Chained handlers *are* a *direct* replacement for flow handlers because
the normal flow handler is *meaningless* for chained handlers. Trying
to separate them into different layers is a mistake in itself.
Chained handlers require the parent to behave differently. Eg, in the
case of a level IRQ input, you don't want IRQs to be masked just because
we're in the middle of servicing a down-stream interrupt. You want it
left enabled so that if the ultimate device handler decides it needs to
have IRQs enabled, then all interrupts are serviced in a fair manner.
If you mask the parent interrupt, then only primary level interrupts
get serviced and fairness goes out the window.
Maybe you never got that point when you decided to create genirq from
my work, but that's *your* problem, not mine. And it seems you're
hell bent on breaking this for ARM. So, I say again - if you persist
with this, I'll replace the ARM IRQ implementation and stop using genirq
because you're taking it in a direction which will cause problems for
ARM. And I *really* mean that.
^ permalink raw reply
* [PATCH 1/5] ARM: mx35_3ds: Add I2C support
From: Uwe Kleine-König @ 2011-03-01 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299009588-8783-1-git-send-email-fabio.estevam@freescale.com>
Hello,
On Tue, Mar 01, 2011 at 04:59:44PM -0300, Fabio Estevam wrote:
> + imx35_add_imx_i2c0(&mx35_3ds_i2c0_data);
I'd slightly prefer using
imx35_add_imx_i2c(0, ...)
because I intend to remove the imx35_add_imx_i2c0-like macros soon. But
if nothing else pops up there is no need to respin the series because of
that.
Other than that all 5 patches look good;
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] S3C64XX: Fix keypad setup to configure correct number of rows
From: Mark Brown @ 2011-03-01 20:16 UTC (permalink / raw)
To: linux-arm-kernel
From: Ben Dooks <ben-linux@fluff.org>
The call to s3c_gpio_cfgrange_nopull() takes a size and base
but this looks like it is trying to do base and end. This means
it is configuring too many GPIOs and on the case of the Cragganmore
means we're seeing an overflow of the ROW pins causing problems
with the keyboard driver.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
arch/arm/mach-s3c64xx/setup-keypad.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/setup-keypad.c b/arch/arm/mach-s3c64xx/setup-keypad.c
index f8ed0d2..1d4d0ee 100644
--- a/arch/arm/mach-s3c64xx/setup-keypad.c
+++ b/arch/arm/mach-s3c64xx/setup-keypad.c
@@ -17,7 +17,7 @@
void samsung_keypad_cfg_gpio(unsigned int rows, unsigned int cols)
{
/* Set all the necessary GPK pins to special-function 3: KP_ROW[x] */
- s3c_gpio_cfgrange_nopull(S3C64XX_GPK(8), 8 + rows, S3C_GPIO_SFN(3));
+ s3c_gpio_cfgrange_nopull(S3C64XX_GPK(8), rows, S3C_GPIO_SFN(3));
/* Set all the necessary GPL pins to special-function 3: KP_COL[x] */
s3c_gpio_cfgrange_nopull(S3C64XX_GPL(0), cols, S3C_GPIO_SFN(3));
--
1.7.2.3
^ permalink raw reply related
* [RFC PATCH 5/5] RFC: msm: sps: Smart Peripheral System (SPS) driver.
From: David Brown @ 2011-03-01 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298941892-25173-6-git-send-email-kheitke@codeaurora.org>
On Mon, Feb 28 2011, Kenneth Heitke wrote:
> diff --git a/arch/arm/mach-msm/include/mach/msm_sps.h b/arch/arm/mach-msm/include/mach/msm_sps.h
> +
> diff --git a/arch/arm/mach-msm/sps/Makefile b/arch/arm/mach-msm/sps/Makefile
> +
> diff --git a/arch/arm/mach-msm/sps/sps.c b/arch/arm/mach-msm/sps/sps.c
> +
> diff --git a/arch/arm/mach-msm/sps/sps_bam.c b/arch/arm/mach-msm/sps/sps_bam.c
> +
These four files add spurious blank lines to the end of their files. If
there are no other changes to the patches, I can fix this up before
applying the patches. Otherwise, please remove these before resending
the patches.
Thanks,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 5/5] ARM: mx53_smd: Add I2C support
From: Fabio Estevam @ 2011-03-01 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299009588-8783-4-git-send-email-fabio.estevam@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-mx5/Kconfig | 1 +
arch/arm/mach-mx5/board-mx53_smd.c | 8 ++++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index f065a0d..b916d0d 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -151,6 +151,7 @@ config MACH_MX53_SMD
bool "Support MX53 SMD platforms"
select SOC_IMX53
select IMX_HAVE_PLATFORM_IMX2_WDT
+ select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_UART
help
Include support for MX53 SMD platform. This includes specific
diff --git a/arch/arm/mach-mx5/board-mx53_smd.c b/arch/arm/mach-mx5/board-mx53_smd.c
index 8a8694c..5eb1638 100644
--- a/arch/arm/mach-mx5/board-mx53_smd.c
+++ b/arch/arm/mach-mx5/board-mx53_smd.c
@@ -51,6 +51,9 @@ static iomux_v3_cfg_t mx53_smd_pads[] = {
MX53_PAD_PATA_CS_1__UART3_RXD_MUX,
MX53_PAD_PATA_DA_1__UART3_CTS,
MX53_PAD_PATA_DA_2__UART3_RTS,
+ /* I2C1 */
+ MX53_PAD_CSI0_DAT8__I2C1_SDA,
+ MX53_PAD_CSI0_DAT9__I2C1_SCL,
};
static const struct imxuart_platform_data mx53_smd_uart_data __initconst = {
@@ -83,6 +86,10 @@ static struct fec_platform_data mx53_smd_fec_data = {
.phy = PHY_INTERFACE_MODE_RMII,
};
+static const struct imxi2c_platform_data mx53_smd_i2c_data __initconst = {
+ .bitrate = 100000,
+};
+
static void __init mx53_smd_board_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx53_smd_pads,
@@ -91,6 +98,7 @@ static void __init mx53_smd_board_init(void)
mx53_smd_fec_reset();
imx53_add_fec(&mx53_smd_fec_data);
imx53_add_imx2_wdt(0, NULL);
+ imx53_add_imx_i2c(0, &mx53_smd_i2c_data);
}
static void __init mx53_smd_timer_init(void)
--
1.6.0.4
^ permalink raw reply related
* [PATCH 4/5] ARM: mx25_3ds: Add I2C support
From: Fabio Estevam @ 2011-03-01 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299009588-8783-3-git-send-email-fabio.estevam@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/mach-mx25_3ds.c | 8 ++++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 01c6c72..e3f62b5 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -100,6 +100,7 @@ config MACH_MX25_3DS
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
select IMX_HAVE_PLATFORM_IMXDI_RTC
+ select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_FB
select IMX_HAVE_PLATFORM_IMX_KEYPAD
select IMX_HAVE_PLATFORM_IMX_UART
diff --git a/arch/arm/mach-imx/mach-mx25_3ds.c b/arch/arm/mach-imx/mach-mx25_3ds.c
index 561f07f..da00b3c 100644
--- a/arch/arm/mach-imx/mach-mx25_3ds.c
+++ b/arch/arm/mach-imx/mach-mx25_3ds.c
@@ -106,6 +106,9 @@ static iomux_v3_cfg_t mx25pdk_pads[] = {
MX25_PAD_SD1_DATA3__SD1_DATA3,
MX25_PAD_A14__GPIO_2_0, /* WriteProtect */
MX25_PAD_A15__GPIO_2_1, /* CardDetect */
+ /* I2C1 */
+ MX25_PAD_I2C1_CLK__I2C1_CLK,
+ MX25_PAD_I2C1_DAT__I2C1_DAT,
};
static const struct fec_platform_data mx25_fec_pdata __initconst = {
@@ -211,6 +214,10 @@ static const struct esdhc_platform_data mx25pdk_esdhc_pdata __initconst = {
.cd_gpio = SD1_GPIO_CD,
};
+static const struct imxi2c_platform_data mx25_3ds_i2c0_data __initconst = {
+ .bitrate = 100000,
+};
+
static void __init mx25pdk_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx25pdk_pads,
@@ -229,6 +236,7 @@ static void __init mx25pdk_init(void)
imx25_add_imx_keypad(&mx25pdk_keymap_data);
imx25_add_sdhci_esdhc_imx(0, &mx25pdk_esdhc_pdata);
+ imx25_add_imx_i2c0(&mx25_3ds_i2c0_data);
}
static void __init mx25pdk_timer_init(void)
--
1.6.0.4
^ permalink raw reply related
* [PATCH 3/5] ARM: mx27_3ds: Add I2C support
From: Fabio Estevam @ 2011-03-01 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299009588-8783-2-git-send-email-fabio.estevam@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/mach-mx27_3ds.c | 7 +++++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index c172418..01c6c72 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -238,6 +238,7 @@ config MACH_MX27_3DS
select SOC_IMX27
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
+ select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_KEYPAD
select IMX_HAVE_PLATFORM_IMX_UART
select IMX_HAVE_PLATFORM_MXC_EHCI
diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
index ba88417..f4f2725 100644
--- a/arch/arm/mach-imx/mach-mx27_3ds.c
+++ b/arch/arm/mach-imx/mach-mx27_3ds.c
@@ -98,6 +98,9 @@ static const int mx27pdk_pins[] __initconst = {
PD22_PF_CSPI2_SCLK,
PD23_PF_CSPI2_MISO,
PD24_PF_CSPI2_MOSI,
+ /* I2C1 */
+ PD17_PF_I2C_DATA,
+ PD18_PF_I2C_CLK,
};
static const struct imxuart_platform_data uart_pdata __initconst = {
@@ -257,6 +260,9 @@ static struct spi_board_info mx27_3ds_spi_devs[] __initdata = {
},
};
+static const struct imxi2c_platform_data mx27_3ds_i2c0_data __initconst = {
+ .bitrate = 100000,
+};
static void __init mx27pdk_init(void)
{
@@ -286,6 +292,7 @@ static void __init mx27pdk_init(void)
if (mxc_expio_init(MX27_CS5_BASE_ADDR, EXPIO_PARENT_INT))
pr_warn("Init of the debugboard failed, all devices on the debugboard are unusable.\n");
+ imx27_add_imx_i2c(0, &mx27_3ds_i2c0_data);
}
static void __init mx27pdk_timer_init(void)
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/5] ARM: mx31_3ds: Add I2C support
From: Fabio Estevam @ 2011-03-01 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299009588-8783-1-git-send-email-fabio.estevam@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-mx3/Kconfig | 1 +
arch/arm/mach-mx3/mach-mx31_3ds.c | 8 ++++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx3/Kconfig b/arch/arm/mach-mx3/Kconfig
index 8b4b097..340809a 100644
--- a/arch/arm/mach-mx3/Kconfig
+++ b/arch/arm/mach-mx3/Kconfig
@@ -94,6 +94,7 @@ config MACH_MX31_3DS
select MXC_DEBUG_BOARD
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
+ select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_KEYPAD
select IMX_HAVE_PLATFORM_IMX_UART
select IMX_HAVE_PLATFORM_MXC_EHCI
diff --git a/arch/arm/mach-mx3/mach-mx31_3ds.c b/arch/arm/mach-mx3/mach-mx31_3ds.c
index b7d0953..35fdb2a 100644
--- a/arch/arm/mach-mx3/mach-mx31_3ds.c
+++ b/arch/arm/mach-mx3/mach-mx31_3ds.c
@@ -96,6 +96,9 @@ static int mx31_3ds_pins[] = {
IOMUX_MODE(MX31_PIN_PC_RW_B, IOMUX_CONFIG_ALT1),
/* USB Host2 reset */
IOMUX_MODE(MX31_PIN_USB_BYP, IOMUX_CONFIG_GPIO),
+ /* I2C1 */
+ MX31_PIN_I2C_CLK__I2C1_SCL,
+ MX31_PIN_I2C_DAT__I2C1_SDA,
};
/*
@@ -323,6 +326,10 @@ static const struct imxuart_platform_data uart_pdata __initconst = {
.flags = IMXUART_HAVE_RTSCTS,
};
+static const struct imxi2c_platform_data mx31_3ds_i2c0_data __initconst = {
+ .bitrate = 100000,
+};
+
static void __init mx31_3ds_init(void)
{
mxc_iomux_setup_multiple_pins(mx31_3ds_pins, ARRAY_SIZE(mx31_3ds_pins),
@@ -356,6 +363,7 @@ static void __init mx31_3ds_init(void)
printk(KERN_WARNING "Init of the debug board failed, all "
"devices on the debug board are unusable.\n");
imx31_add_imx2_wdt(NULL);
+ imx31_add_imx_i2c0(&mx31_3ds_i2c0_data);
}
static void __init mx31_3ds_timer_init(void)
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/5] ARM: mx35_3ds: Add I2C support
From: Fabio Estevam @ 2011-03-01 19:59 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-mx3/Kconfig | 1 +
arch/arm/mach-mx3/mach-mx35_3ds.c | 8 ++++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx3/Kconfig b/arch/arm/mach-mx3/Kconfig
index 4f57f13..8b4b097 100644
--- a/arch/arm/mach-mx3/Kconfig
+++ b/arch/arm/mach-mx3/Kconfig
@@ -183,6 +183,7 @@ config MACH_MX35_3DS
select MXC_DEBUG_BOARD
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
+ select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_UART
select IMX_HAVE_PLATFORM_MXC_EHCI
select IMX_HAVE_PLATFORM_MXC_NAND
diff --git a/arch/arm/mach-mx3/mach-mx35_3ds.c b/arch/arm/mach-mx3/mach-mx35_3ds.c
index be12ac1..5f35d5c 100644
--- a/arch/arm/mach-mx3/mach-mx35_3ds.c
+++ b/arch/arm/mach-mx3/mach-mx35_3ds.c
@@ -118,6 +118,9 @@ static iomux_v3_cfg_t mx35pdk_pads[] = {
MX35_PAD_SD1_DATA1__ESDHC1_DAT1,
MX35_PAD_SD1_DATA2__ESDHC1_DAT2,
MX35_PAD_SD1_DATA3__ESDHC1_DAT3,
+ /* I2C1 */
+ MX35_PAD_I2C1_CLK__I2C1_SCL,
+ MX35_PAD_I2C1_DAT__I2C1_SDA,
};
static int mx35_3ds_otg_init(struct platform_device *pdev)
@@ -163,6 +166,10 @@ static int __init mx35_3ds_otg_mode(char *options)
}
__setup("otg_mode=", mx35_3ds_otg_mode);
+static const struct imxi2c_platform_data mx35_3ds_i2c0_data __initconst = {
+ .bitrate = 100000,
+};
+
/*
* Board specific initialization.
*/
@@ -190,6 +197,7 @@ static void __init mx35_3ds_init(void)
if (mxc_expio_init(MX35_CS5_BASE_ADDR, EXPIO_PARENT_INT))
pr_warn("Init of the debugboard failed, all "
"devices on the debugboard are unusable.\n");
+ imx35_add_imx_i2c0(&mx35_3ds_i2c0_data);
}
static void __init mx35pdk_timer_init(void)
--
1.6.0.4
^ permalink raw reply related
* MMC quirks relating to performance/lifetime.
From: Arnd Bergmann @ 2011-03-01 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D45D2.2020900@kernel.dk>
On Tuesday 01 March 2011 20:15:30 Jens Axboe wrote:
> Thanks for the recap. One way to handle this would be to have a dm
> target that ensures that requests are never built up to violate any of
> the above items. Doing splitting is a little silly, when you can prevent
> it from happening in the first place.
Ok, that sounds good. I didn't know that it's possible to prevent
bios from getting created that violate this.
I'm actually trying to do a device mapper target that does much more than
this, see
https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashDeviceMapper
for an early draft. The design has moved on since I wrote that, but
the basic idea is still the same: all blocks get written in a way that
fills up entire 4MB segments before moving to another segment,
independent of what the logical block numbers are, and a little space
is used to store a lookup table for the logical-to-physical block mapping.
> Alternatively, a queue ->merge_bvec_fn() with a settings table could
> provide the same.
That's probably better for the common case. The device mapper target
would be useful for those that want the best case write performance,
but if I understand you correctly, the merge_bvec_fn() could be used
per block driver, so we could simply add that to the SCSI (for USB and
consumer SSD) case and MMC block drivers.
The point that this does not solve is submitting all outstanding writes
for an erase block together, which is needed to reduce the garbage
collection overhead. When you do a partial update of an erase block
(4MB typically) and then start writing to another erase block, the
drive will have to copy all data you did not write in order to free
up internal resources.
> As this is of limited scope, I would prefer having this done via a
> plugin of some sort (like a dm target).
I'm not sure what you mean with limited scope. This is certainly not
as important for the classic server environment (aside from USB boot
drives), but I assume that it is highly relevant for the a large
portion of new embedded designs as people move from raw flash to
eMMC and similar "technologies".
Arnd
^ permalink raw reply
* [PATCH] OMAP:iommu - pgd and pte entries weren't getting flushed out
From: Fernando Guzman Lugo @ 2011-03-01 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299008793-27428-1-git-send-email-fernando.lugo@ti.com>
From: Hari Kanigeri <h-kanigeri2@ti.com>
pgd and pte entries weren't getting flushed out leading to MMU faults.
Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
---
arch/arm/plat-omap/iommu.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index aeb2c33..e9473ff 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -508,7 +508,7 @@ static u32 *iopte_alloc(struct iommu *obj, u32 *iopgd, u32 da)
return ERR_PTR(-ENOMEM);
*iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_range(iopgd, iopgd + 1);
dev_vdbg(obj->dev, "%s: a new pte:%p\n", __func__, iopte);
} else {
@@ -537,7 +537,7 @@ static int iopgd_alloc_section(struct iommu *obj, u32 da, u32 pa, u32 prot)
}
*iopgd = (pa & IOSECTION_MASK) | prot | IOPGD_SECTION;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_range(iopgd, iopgd + 1);
return 0;
}
@@ -554,7 +554,7 @@ static int iopgd_alloc_super(struct iommu *obj, u32 da, u32 pa, u32 prot)
for (i = 0; i < 16; i++)
*(iopgd + i) = (pa & IOSUPER_MASK) | prot | IOPGD_SUPER;
- flush_iopgd_range(iopgd, iopgd + 15);
+ flush_iopgd_range(iopgd, iopgd + 16);
return 0;
}
@@ -567,7 +567,7 @@ static int iopte_alloc_page(struct iommu *obj, u32 da, u32 pa, u32 prot)
return PTR_ERR(iopte);
*iopte = (pa & IOPAGE_MASK) | prot | IOPTE_SMALL;
- flush_iopte_range(iopte, iopte);
+ flush_iopte_range(iopte, iopte + 1);
dev_vdbg(obj->dev, "%s: da:%08x pa:%08x pte:%p *pte:%08x\n",
__func__, da, pa, iopte, *iopte);
@@ -592,7 +592,7 @@ static int iopte_alloc_large(struct iommu *obj, u32 da, u32 pa, u32 prot)
for (i = 0; i < 16; i++)
*(iopte + i) = (pa & IOLARGE_MASK) | prot | IOPTE_LARGE;
- flush_iopte_range(iopte, iopte + 15);
+ flush_iopte_range(iopte, iopte + 16);
return 0;
}
@@ -763,7 +763,7 @@ void iopgtable_clear_entry_all(struct iommu *obj)
iopte_free(iopte_offset(iopgd, 0));
*iopgd = 0;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_range(iopgd, iopgd + 1);
}
flush_iotlb_all(obj);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] omap:iommu-added cache flushing operation for L2 cache
From: Fernando Guzman Lugo @ 2011-03-01 19:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Ramesh Gupta <grgupta@ti.com>
Signed-off-by: Ramesh Gupta <grgupta@ti.com>
Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
---
arch/arm/plat-omap/iommu.c | 22 ++++++++--------------
1 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index e3eb038..aeb2c33 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -471,22 +471,15 @@ EXPORT_SYMBOL_GPL(foreach_iommu_device);
*/
static void flush_iopgd_range(u32 *first, u32 *last)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm("mcr p15, 0, %0, c7, c10, 1 @ flush_pgd"
- : : "r" (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first <= last);
+ dmac_flush_range(first, last);
+ outer_flush_range(virt_to_phys(first), virt_to_phys(last));
}
+
static void flush_iopte_range(u32 *first, u32 *last)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm("mcr p15, 0, %0, c7, c10, 1 @ flush_pte"
- : : "r" (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first <= last);
+ dmac_flush_range(first, last);
+ outer_flush_range(virt_to_phys(first), virt_to_phys(last));
}
static void iopte_free(u32 *iopte)
@@ -750,7 +743,7 @@ size_t iopgtable_clear_entry(struct iommu *obj, u32 da)
}
EXPORT_SYMBOL_GPL(iopgtable_clear_entry);
-static void iopgtable_clear_entry_all(struct iommu *obj)
+void iopgtable_clear_entry_all(struct iommu *obj)
{
int i;
@@ -777,7 +770,7 @@ static void iopgtable_clear_entry_all(struct iommu *obj)
spin_unlock(&obj->page_table_lock);
}
-
+EXPORT_SYMBOL_GPL(iopgtable_clear_entry_all);
/*
* Device IOMMU generic operations
*/
@@ -1068,6 +1061,7 @@ static void iopte_cachep_ctor(void *iopte)
clean_dcache_area(iopte, IOPTE_TABLE_SIZE);
}
+
static int __init omap_iommu_init(void)
{
struct kmem_cache *p;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
From: Sricharan R @ 2011-03-01 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298903958-6496-7-git-send-email-govindraj.raja@ti.com>
Hi,
>diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
>index 755f4aa..530e9e3 100644
>--- a/arch/arm/mach-omap2/serial.c
>+++ b/arch/arm/mach-omap2/serial.c
>@@ -44,6 +44,15 @@
>
> static int omap_uart_con_id __initdata = -1;
>
>+static struct omap_uart_port_info omap_serial_default_info[] = {
>+ {
>+ .dma_enabled = 0,
>+ .dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
>+ .dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
>+ .idle_timeout = DEFAULT_IDLE_TIMEOUT,
>+ },
>+};
>+
> static int uart_idle_hwmod(struct omap_device *od)
> {
> omap_hwmod_idle(od->hwmods[0]);
>@@ -66,6 +75,54 @@ static struct omap_device_pm_latency
omap_uart_latency[]
>= {
> },
> };
>
>+#ifdef CONFIG_OMAP_MUX
>+static struct omap_device_pad default_serial0_pads[] __initdata = {
>+ {
>+ .name = "uart1_rx.uart1_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
>+
>+static struct omap_device_pad default_serial1_pads[] __initdata = {
>+ {
>+ .name = "uart2_rx.uart2_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
>+
>+static struct omap_device_pad default_serial2_pads[] __initdata = {
>+ {
>+ .name = "uart3_rx_irrx.uart3_rx_irrx",
>+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
>+
>+static struct omap_device_pad default_omap36xx_serial3_pads[] __initdata
=
>{
>+ {
>+ .name = "gpmc_wait3.uart4_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE2,
>+ },
>+};
>+
>+static struct omap_device_pad default_omap4_serial3_pads[] __initdata =
{
>+ {
>+ .name = "uart4_rx.uart4_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
Here only the UART RX pins are muxed, so what about the cts, rts, tx pins?
Is it consistent that across all socs that only UART3 would have UART/IRDA
functions capability so that serial2 pads can always be called "rx_irxx"
?.
Thanks,
sricharan
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo at vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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