* [PATCH 2/4] msm: scm: Fix improper register assignment
From: Stephen Boyd @ 2011-02-24 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298573085-23217-1-git-send-email-sboyd@codeaurora.org>
Assign the registers used in the inline assembly immediately
before the inline assembly block. This ensures the compiler
doesn't optimize away dead register assignments when it
shouldn't.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/mach-msm/scm.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-msm/scm.c b/arch/arm/mach-msm/scm.c
index ba57b5a..5eddf54 100644
--- a/arch/arm/mach-msm/scm.c
+++ b/arch/arm/mach-msm/scm.c
@@ -264,13 +264,16 @@ u32 scm_get_version(void)
{
int context_id;
static u32 version = -1;
- register u32 r0 asm("r0") = 0x1 << 8;
- register u32 r1 asm("r1") = (u32)&context_id;
+ register u32 r0 asm("r0");
+ register u32 r1 asm("r1");
if (version != -1)
return version;
mutex_lock(&scm_lock);
+
+ r0 = 0x1 << 8;
+ r1 = (u32)&context_id;
asm volatile(
__asmeq("%0", "r1")
__asmeq("%1", "r0")
--
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 related
* [PATCH 3/4] msm: scm: Check for interruption immediately
From: Stephen Boyd @ 2011-02-24 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298573085-23217-1-git-send-email-sboyd@codeaurora.org>
When we're interrupted on the secure side, we should just issue
another smc instruction again instead of replaying the arguments
to smc. Fix it.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/mach-msm/scm.c | 51 ++++++++++++++++++++++++----------------------
1 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-msm/scm.c b/arch/arm/mach-msm/scm.c
index 5eddf54..cfa808d 100644
--- a/arch/arm/mach-msm/scm.c
+++ b/arch/arm/mach-msm/scm.c
@@ -174,15 +174,18 @@ static u32 smc(u32 cmd_addr)
register u32 r0 asm("r0") = 1;
register u32 r1 asm("r1") = (u32)&context_id;
register u32 r2 asm("r2") = cmd_addr;
- asm volatile(
- __asmeq("%0", "r0")
- __asmeq("%1", "r0")
- __asmeq("%2", "r1")
- __asmeq("%3", "r2")
- "smc #0 @ switch to secure world\n"
- : "=r" (r0)
- : "r" (r0), "r" (r1), "r" (r2)
- : "r3");
+ do {
+ asm volatile(
+ __asmeq("%0", "r0")
+ __asmeq("%1", "r0")
+ __asmeq("%2", "r1")
+ __asmeq("%3", "r2")
+ "smc #0 @ switch to secure world\n"
+ : "=r" (r0)
+ : "r" (r0), "r" (r1), "r" (r2)
+ : "r3");
+ } while (r0 == SCM_INTERRUPTED);
+
return r0;
}
@@ -197,13 +200,9 @@ static int __scm_call(const struct scm_command *cmd)
* side in the buffer.
*/
flush_cache_all();
- do {
- ret = smc(cmd_addr);
- if (ret < 0) {
- ret = scm_remap_error(ret);
- break;
- }
- } while (ret == SCM_INTERRUPTED);
+ ret = smc(cmd_addr);
+ if (ret < 0)
+ ret = scm_remap_error(ret);
return ret;
}
@@ -274,14 +273,18 @@ u32 scm_get_version(void)
r0 = 0x1 << 8;
r1 = (u32)&context_id;
- asm volatile(
- __asmeq("%0", "r1")
- __asmeq("%1", "r0")
- __asmeq("%2", "r1")
- "smc #0 @ switch to secure world\n"
- : "=r" (r1)
- : "r" (r0), "r" (r1)
- : "r2", "r3");
+ do {
+ asm volatile(
+ __asmeq("%0", "r0")
+ __asmeq("%1", "r1")
+ __asmeq("%2", "r0")
+ __asmeq("%3", "r1")
+ "smc #0 @ switch to secure world\n"
+ : "=r" (r0), "=r" (r1)
+ : "r" (r0), "r" (r1)
+ : "r2", "r3");
+ } while (r0 == SCM_INTERRUPTED);
+
version = r1;
mutex_unlock(&scm_lock);
--
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 related
* [PATCH 4/4] msm: scm: Get cacheline size from CTR
From: Stephen Boyd @ 2011-02-24 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298573085-23217-1-git-send-email-sboyd@codeaurora.org>
Instead of hardcoding the cacheline size as 32, get the cacheline
size from the CTR register.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/mach-msm/scm.c | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-msm/scm.c b/arch/arm/mach-msm/scm.c
index cfa808d..0528c71 100644
--- a/arch/arm/mach-msm/scm.c
+++ b/arch/arm/mach-msm/scm.c
@@ -26,9 +26,6 @@
#include "scm.h"
-/* Cache line size for msm8x60 */
-#define CACHELINESIZE 32
-
#define SCM_ENOMEM -5
#define SCM_EOPNOTSUPP -4
#define SCM_EINVAL_ADDR -3
@@ -207,6 +204,14 @@ static int __scm_call(const struct scm_command *cmd)
return ret;
}
+static inline u32 dcache_line_size(void)
+{
+ u32 ctr;
+
+ asm volatile("mrc p15, 0, %0, c0, c0, 1" : "=r" (ctr));
+ return 4 << ((ctr >> 16) & 0xf);
+}
+
/**
* scm_call() - Send an SCM command
* @svc_id: service identifier
@@ -243,11 +248,13 @@ int scm_call(u32 svc_id, u32 cmd_id, const void *cmd_buf, size_t cmd_len,
do {
u32 start = (u32)rsp;
u32 end = (u32)scm_get_response_buffer(rsp) + resp_len;
- start &= ~(CACHELINESIZE - 1);
+ u32 cacheline_size = dcache_line_size();
+
+ start &= ~(cacheline_size - 1);
while (start < end) {
asm ("mcr p15, 0, %0, c7, c6, 1" : : "r" (start)
: "memory");
- start += CACHELINESIZE;
+ start += cacheline_size;
}
} while (!rsp->is_complete);
--
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 related
* [TRIVIAL/PATCH] ARM: hw_breakpoint: Fix newlines in WARN messages
From: Stephen Boyd @ 2011-02-24 18:55 UTC (permalink / raw)
To: linux-arm-kernel
These warnings are missing newlines and spaces causing confusing
looking output when they trigger.
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/kernel/hw_breakpoint.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index d600bd3..5aab00e 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -238,8 +238,8 @@ static int enable_monitor_mode(void)
ARM_DBG_READ(c1, 0, dscr);
/* Ensure that halting mode is disabled. */
- if (WARN_ONCE(dscr & ARM_DSCR_HDBGEN, "halting debug mode enabled."
- "Unable to access hardware resources.")) {
+ if (WARN_ONCE(dscr & ARM_DSCR_HDBGEN, "halting debug mode enabled. "
+ "Unable to access hardware resources.\n")) {
ret = -EPERM;
goto out;
}
@@ -377,7 +377,7 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
}
}
- if (WARN_ONCE(i == max_slots, "Can't find any breakpoint slot")) {
+ if (WARN_ONCE(i == max_slots, "Can't find any breakpoint slot\n")) {
ret = -EBUSY;
goto out;
}
@@ -423,7 +423,7 @@ void arch_uninstall_hw_breakpoint(struct perf_event *bp)
}
}
- if (WARN_ONCE(i == max_slots, "Can't find any breakpoint slot"))
+ if (WARN_ONCE(i == max_slots, "Can't find any breakpoint slot\n"))
return;
/* Reset the control register. */
@@ -635,7 +635,7 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
if (WARN_ONCE(!bp->overflow_handler &&
(arch_check_bp_in_kernelspace(bp) || !core_has_mismatch_brps()
|| !bp->hw.bp_target),
- "overflow handler required but none found")) {
+ "overflow handler required but none found\n")) {
ret = -EINVAL;
}
out:
@@ -917,7 +917,8 @@ static int __init arch_hw_breakpoint_init(void)
if (dscr & ARM_DSCR_HDBGEN) {
max_watchpoint_len = 4;
pr_warning("halting debug mode enabled. Assuming maximum "
- "watchpoint size of %u bytes.", max_watchpoint_len);
+ "watchpoint size of %u bytes.\n",
+ max_watchpoint_len);
} else {
/* Work out the maximum supported watchpoint length. */
max_watchpoint_len = get_max_wp_len();
--
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 related
* [PATCH V3 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
From: Eric Benard @ 2011-02-24 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k4gp3bl1.fsf@lebrac.rtp-net.org>
Hi Arnaud,
On 24/02/2011 12:40, Arnaud Patard (Rtp) wrote:
> Wolfram Sang<w.sang@pengutronix.de> writes:
>
> Hi,
>
>> Take #3, changes:
>>
>> * also intercept calls to SDHCI_SIGNAL_ENABLE (needed on mx25)
>> * remove unconditional BROKEN_CARD_DETECTION (leftover)
>> * improved kernel-doc about unused GPIO
>> * added tags from Eric
>>
>> Tested now by me and Marc on mx35, Eric on mx25/35/51. Arnaud, did you have a
>> chance to retest on mx51? What about the FSL guys? :)
>
> I'm getting a hard freeze on my efika sb and mx once I remove the
> unconditional BROKEN_CARD_DETECTION flag. I'm still investigating the
> issue. I'll keep you informed if I find something.
>
may you please test the attached patch. It may give someone with a better
knowledge of sdhci than me an idea of what is wrong.
Here are the workaround this patch add :
- we can't let enable or disable irq enabled when the card is present/not
present, else the irq triger again which explains why you get the freeze -> so
we must rely on the card presence bit to enable the right interrupt,
- we can't turn the clock off if we want the card detect to work when the card
is removed -> as a quick workaround this patch prevents sdhci_set_clock from
turning off the clocks when the SDHCI_INT_CARD_INSERT interrupt is enabled.
Also, I had to change the MX51_PAD_GPIO1_0__SD1_CD pad setting as follows to
enable the internal pull up :
_MX51_PAD_GPIO1_0__SD1_CD | MUX_PAD_CTRL(PAD_CTL_PUS_22K_UP |
PAD_CTL_PKE | PAD_CTL_SRE_FAST |
PAD_CTL_DSE_HIGH | PAD_CTL_PUE | PAD_CTL_HYS),
Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mx51_sdhci_cd_fix.patch
Type: text/x-patch
Size: 2488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110224/e118ff7a/attachment-0001.bin>
^ permalink raw reply
* [PATCH 4/4] msm: scm: Get cacheline size from CTR
From: Thomas Gleixner @ 2011-02-24 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298573085-23217-5-git-send-email-sboyd@codeaurora.org>
On Thu, 24 Feb 2011, Stephen Boyd wrote:
> Instead of hardcoding the cacheline size as 32, get the cacheline
> size from the CTR register.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> arch/arm/mach-msm/scm.c | 17 ++++++++++++-----
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-msm/scm.c b/arch/arm/mach-msm/scm.c
> index cfa808d..0528c71 100644
> --- a/arch/arm/mach-msm/scm.c
> +++ b/arch/arm/mach-msm/scm.c
> @@ -26,9 +26,6 @@
>
> #include "scm.h"
>
> -/* Cache line size for msm8x60 */
> -#define CACHELINESIZE 32
> -
> #define SCM_ENOMEM -5
> #define SCM_EOPNOTSUPP -4
> #define SCM_EINVAL_ADDR -3
> @@ -207,6 +204,14 @@ static int __scm_call(const struct scm_command *cmd)
> return ret;
> }
>
> +static inline u32 dcache_line_size(void)
> +{
> + u32 ctr;
> +
> + asm volatile("mrc p15, 0, %0, c0, c0, 1" : "=r" (ctr));
> + return 4 << ((ctr >> 16) & 0xf);
> +}
> +
> /**
> * scm_call() - Send an SCM command
> * @svc_id: service identifier
> @@ -243,11 +248,13 @@ int scm_call(u32 svc_id, u32 cmd_id, const void *cmd_buf, size_t cmd_len,
> do {
> u32 start = (u32)rsp;
> u32 end = (u32)scm_get_response_buffer(rsp) + resp_len;
> - start &= ~(CACHELINESIZE - 1);
> + u32 cacheline_size = dcache_line_size();
And why do you want to do that on every scm_call() invocation and on
every loop of that code? If your dcache_line_size() changes at
runtime, then you might have other problems.
Thanks,
tglx
^ permalink raw reply
* [PATCH 4/4] msm: scm: Get cacheline size from CTR
From: Sergei Shtylyov @ 2011-02-24 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298573085-23217-5-git-send-email-sboyd@codeaurora.org>
Hello.
Stephen Boyd wrote:
> Instead of hardcoding the cacheline size as 32, get the cacheline
> size from the CTR register.
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> arch/arm/mach-msm/scm.c | 17 ++++++++++++-----
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-msm/scm.c b/arch/arm/mach-msm/scm.c
> index cfa808d..0528c71 100644
> --- a/arch/arm/mach-msm/scm.c
> +++ b/arch/arm/mach-msm/scm.c
[...]
> @@ -207,6 +204,14 @@ static int __scm_call(const struct scm_command *cmd)
> return ret;
> }
>
> +static inline u32 dcache_line_size(void)
> +{
> + u32 ctr;
> +
> + asm volatile("mrc p15, 0, %0, c0, c0, 1" : "=r" (ctr));
> + return 4 << ((ctr >> 16) & 0xf);
> +}
Won't generic cache_line_size() macro do instead? It's defined as
L1_CACHE_BYTES.
WBR, Sergei
^ permalink raw reply
* [PATCH 4/4] msm: scm: Get cacheline size from CTR
From: Stephen Boyd @ 2011-02-24 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102241959290.2701@localhost6.localdomain6>
On 02/24/2011 11:01 AM, Thomas Gleixner wrote:
> On Thu, 24 Feb 2011, Stephen Boyd wrote:
>
>>
>> /**
>> * scm_call() - Send an SCM command
>> * @svc_id: service identifier
>> @@ -243,11 +248,13 @@ int scm_call(u32 svc_id, u32 cmd_id, const void *cmd_buf, size_t cmd_len,
>> do {
>> u32 start = (u32)rsp;
>> u32 end = (u32)scm_get_response_buffer(rsp) + resp_len;
>> - start &= ~(CACHELINESIZE - 1);
>> + u32 cacheline_size = dcache_line_size();
>
> And why do you want to do that on every scm_call() invocation and on
> every loop of that code? If your dcache_line_size() changes at
> runtime, then you might have other problems.
I definitely don't want to do it for every loop. I'm fine with getting
it every scm_call() invocation though.
For now, I'll pull the end and cacheline_size variables out of the
do-while loop.
--
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 V3 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
From: Wolfram Sang @ 2011-02-24 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110224160300.GA1483@S2100-06.ap.freescale.net>
On Fri, Feb 25, 2011 at 12:03:01AM +0800, Shawn Guo wrote:
> On Thu, Feb 24, 2011 at 11:51:28PM +0800, Shawn Guo wrote:
> > On Thu, Feb 24, 2011 at 04:18:05PM +0800, Shawn Guo wrote:
> > > Hi Wolfram,
> > >
> > > On Wed, Feb 23, 2011 at 02:51:53PM +0100, Wolfram Sang wrote:
> > > > Take #3, changes:
> > > >
> > > > * also intercept calls to SDHCI_SIGNAL_ENABLE (needed on mx25)
> > > > * remove unconditional BROKEN_CARD_DETECTION (leftover)
> > > > * improved kernel-doc about unused GPIO
> > > > * added tags from Eric
> > > >
> > > > Tested now by me and Marc on mx35, Eric on mx25/35/51. Arnaud, did you have a
> > > > chance to retest on mx51? What about the FSL guys? :)
> > > >
> > > I'm testing it on mx25 3ds and mx51 babbage. Both card-detect and
> > > write-protect are working on mx25 3ds, but write-protect has some
> > > problem on babbage, and I need some time to figure it out.
> > >
> > I just figured out why wp_gpio does not work on mx51.
> >
> > + if (cpu_is_mx25() || cpu_is_mx35()) {
> > + /* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */
> > host->quirks |= SDHCI_QUIRK_NO_MULTIBLOCK;
> > + /* write_protect can't be routed to controller, use gpio */
> > + sdhci_esdhc_ops.get_ro = esdhc_pltfm_get_ro;
> > + }
> >
> > Would it make sense to do the same for mx51? On babbage board,
> > SD1_WP is routed to controller, but SD2_WP is not, so we have to use
> > gpio for SD2 write_protect.
> >
> We should probably have esdhc_pltfm_get_ro whenever platform provides
> a wp_gpio, and fall on controller SD_WP only when platform does not
> provide the wp_gpio.
OK, will think about it. Thanks for testing!
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110224/1e00e5e7/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] msm: scm: Get cacheline size from CTR
From: Stephen Boyd @ 2011-02-24 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D66B236.4030003@ru.mvista.com>
On 02/24/2011 11:32 AM, Sergei Shtylyov wrote:
> Stephen Boyd wrote:
>
>> @@ -207,6 +204,14 @@ static int __scm_call(const struct scm_command
>> *cmd)
>> return ret;
>> }
>>
>> +static inline u32 dcache_line_size(void)
>> +{
>> + u32 ctr;
>> +
>> + asm volatile("mrc p15, 0, %0, c0, c0, 1" : "=r" (ctr));
>> + return 4 << ((ctr >> 16) & 0xf);
>> +}
>
> Won't generic cache_line_size() macro do instead? It's defined as
> L1_CACHE_BYTES.
>
Interesting. It would be the same value (32) but I'm not sure how
multi-platform friendly that will be since L1_CACHE_BYTES is (1 <<
CONFIG_ARM_L1_CACHE_SHIFT). I suppose we can punt supporting platforms
with different cache line sizes in one kernel for another day.
--
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] msm: scm: Get cacheline size from CTR
From: Russell King - ARM Linux @ 2011-02-24 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D66B236.4030003@ru.mvista.com>
On Thu, Feb 24, 2011 at 10:32:06PM +0300, Sergei Shtylyov wrote:
> Won't generic cache_line_size() macro do instead? It's defined as
> L1_CACHE_BYTES.
L1_CACHE_BYTES needs to be a compile time constant. As such it ends up
being defined to the largest cache line size for the range of CPUs built
into the kernel. This allows us to appropriately align data structures
to cache line boundaries which are boundaries for any of the CPUs which
are to be supported.
However, if you need to know exactly what cache line size you have for
doing things like cache maintainence then you can not use L1_CACHE_BYTES
or anything related to that.
One of the issues which complicates decoding the cache line size is that
on some CPUs, there's no way to read it. On later CPUs, there's the
cache type register, of which there's several different formats which
makes decoding it rather painful and complicated. Then there's the
related issue as to which cache line size you want - L1 Dcache, L1
Icache, or L2 cache, or some other level of cache?
It's all rather messy.
^ permalink raw reply
* [PATCH 4/4] msm: scm: Get cacheline size from CTR
From: Thomas Gleixner @ 2011-02-24 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D66B505.6010702@codeaurora.org>
On Thu, 24 Feb 2011, Stephen Boyd wrote:
> On 02/24/2011 11:01 AM, Thomas Gleixner wrote:
> > On Thu, 24 Feb 2011, Stephen Boyd wrote:
> >
> >>
> >> /**
> >> * scm_call() - Send an SCM command
> >> * @svc_id: service identifier
> >> @@ -243,11 +248,13 @@ int scm_call(u32 svc_id, u32 cmd_id, const void *cmd_buf, size_t cmd_len,
> >> do {
> >> u32 start = (u32)rsp;
> >> u32 end = (u32)scm_get_response_buffer(rsp) + resp_len;
> >> - start &= ~(CACHELINESIZE - 1);
> >> + u32 cacheline_size = dcache_line_size();
> >
> > And why do you want to do that on every scm_call() invocation and on
> > every loop of that code? If your dcache_line_size() changes at
> > runtime, then you might have other problems.
>
> I definitely don't want to do it for every loop. I'm fine with getting
> it every scm_call() invocation though.
>
> For now, I'll pull the end and cacheline_size variables out of the
> do-while loop.
Why not do it correct right away and retrieve it in an __init
function?
Thanks,
tglx
^ permalink raw reply
* [PATCH] S3C64XX: Tone down SDHCI debugging
From: Mark Brown @ 2011-02-24 20:11 UTC (permalink / raw)
To: linux-arm-kernel
The MMC core calls s3c6400_setup_sdhcp_cfg_card() very frequently, causing
the log message in there at KERN_INFO to be displayed a lot which is slow
and overly chatty. Convert the message into a pr_debug() to tone this down.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
arch/arm/mach-s3c64xx/setup-sdhci.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/setup-sdhci.c b/arch/arm/mach-s3c64xx/setup-sdhci.c
index 1a94203..f344a22 100644
--- a/arch/arm/mach-s3c64xx/setup-sdhci.c
+++ b/arch/arm/mach-s3c64xx/setup-sdhci.c
@@ -56,7 +56,7 @@ void s3c6400_setup_sdhci_cfg_card(struct platform_device *dev,
else
ctrl3 = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
- printk(KERN_INFO "%s: CTRL 2=%08x, 3=%08x\n", __func__, ctrl2, ctrl3);
+ pr_debug("%s: CTRL 2=%08x, 3=%08x\n", __func__, ctrl2, ctrl3);
writel(ctrl2, r + S3C_SDHCI_CONTROL2);
writel(ctrl3, r + S3C_SDHCI_CONTROL3);
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH] OMAP2+: clocksource: fix crash on boot when !CONFIG_OMAP_32K_TIMER
From: Tony Lindgren @ 2011-02-24 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1102221958190.22636@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [110222 18:58]:
>
> OMAP2+ kernels built without CONFIG_OMAP_32K_TIMER crash on boot after the
> 2.6.38 sched_clock changes:
>
> [ 0.000000] OMAP clockevent source: GPTIMER1 at 13000000 Hz
> [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [ 0.000000] pgd = c0004000
> [ 0.000000] [00000000] *pgd=00000000
> [ 0.000000] Internal error: Oops: 80000005 [#1] SMP
> [ 0.000000] last sysfs file:
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 Not tainted (2.6.38-rc5-00057-g04aa67d #152)
> [ 0.000000] PC is at 0x0
> [ 0.000000] LR is at sched_clock_poll+0x2c/0x3c
>
> Without CONFIG_OMAP_32K_TIMER, the kernel has an clockevent and
> clocksource resolution about three orders of magnitude higher than
> with CONFIG_OMAP_32K_TIMER set. The tradeoff is that the lowest
> power consumption states are not available.
>
> Fix by calling init_sched_clock() from the GPTIMER clocksource init code.
I'll queue this as a fix as it's a regression.
Tony
^ permalink raw reply
* [PATCH] OMAP2+: clocksource: fix crash on boot when !CONFIG_OMAP_32K_TIMER
From: Paul Walmsley @ 2011-02-24 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110224202157.GG20560@atomide.com>
On Thu, 24 Feb 2011, Tony Lindgren wrote:
> * Paul Walmsley <paul@pwsan.com> [110222 18:58]:
> >
> > OMAP2+ kernels built without CONFIG_OMAP_32K_TIMER crash on boot after the
> > 2.6.38 sched_clock changes:
> >
> > [ 0.000000] OMAP clockevent source: GPTIMER1 at 13000000 Hz
> > [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > [ 0.000000] pgd = c0004000
> > [ 0.000000] [00000000] *pgd=00000000
> > [ 0.000000] Internal error: Oops: 80000005 [#1] SMP
> > [ 0.000000] last sysfs file:
> > [ 0.000000] Modules linked in:
> > [ 0.000000] CPU: 0 Not tainted (2.6.38-rc5-00057-g04aa67d #152)
> > [ 0.000000] PC is at 0x0
> > [ 0.000000] LR is at sched_clock_poll+0x2c/0x3c
> >
> > Without CONFIG_OMAP_32K_TIMER, the kernel has an clockevent and
> > clocksource resolution about three orders of magnitude higher than
> > with CONFIG_OMAP_32K_TIMER set. The tradeoff is that the lowest
> > power consumption states are not available.
> >
> > Fix by calling init_sched_clock() from the GPTIMER clocksource init code.
>
> I'll queue this as a fix as it's a regression.
Sounds good, I've got one or two other -rc candidates. Want me to build a
branch with this and the other two?
- Paul
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: Tony Lindgren @ 2011-02-24 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikXBKcbOQXdse31=qjoLoAhkvKz15PeFuw3AmCj@mail.gmail.com>
* Guzman Lugo, Fernando <fernando.lugo@ti.com> [110224 09:56]:
> On Thu, Feb 24, 2011 at 5:29 AM, Felipe Balbi <balbi@ti.com> wrote:
> > On Thu, Feb 24, 2011 at 01:26:05PM +0200, David Cohen wrote:
> >> On Thu, Feb 24, 2011 at 10:35 AM, Felipe Balbi <balbi@ti.com> wrote:
> >>
> >> This patch is already acked. What about leave it as it is and discuss
> >> multiple callbacks before release a new patch to support it?
> >
> > fine by me ;-)
>
> Ok, maybe it was too late to change it, due to it is already acked, I
> just wanted to avoid change isr here and then change it on other
> patch. it is ok then.
Hiroshi any comments?
Would like to see a proper Acked-by before I apply, now there's
just the earlier comment "Ok, I see. Let's go with this. Thanks." :)
Tony
^ permalink raw reply
* [PATCH v6 0/4] omap: mailbox: hwmod support
From: Tony Lindgren @ 2011-02-24 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297993347-5654-1-git-send-email-omar.ramirez@ti.com>
* Omar Ramirez Luna <omar.ramirez@ti.com> [110217 17:52]:
> Mailbox hwmod support for OMAP 2,3,4.
Thanks, applying to devel-iommu-mailbox branch for the upcoming
merge window.
Regards,
Tony
^ permalink raw reply
* [PATCH 0/5] my imx patches for 2.6.39
From: Uwe Kleine-König @ 2011-02-24 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218213022.GJ22310@pengutronix.de>
Hello Sascha,
there is now yet another patch, and as you didn't pull yet (maybe you
expected that?) here comes an updated request:
The following changes since commit b807afe41ceefef11a0d965cd9970142afc53d25:
ARM: imx50: correct iomux-mx50.h wrong daisy chain settings (2011-02-18 11:01:34 +0100)
are available in the git repository at:
git://git.pengutronix.de/git/ukl/linux-2.6.git imx-for-2.6.39
Lothar Wa?mann (3):
ARM: mxs: free dma_mask in error path
ARM: mxs: add a dma mask to fec devices
ARM: mxs: Initial support for Ka-Ro TX28
Sascha Hauer (2):
ARM: mxs: Add pwm clocks and device registration
ARM: mxs: Add missing EXPORT_SYMBOL for mxs_reset_block
Uwe Kleine-K?nig (3):
ARM: mxc: free dma_mask in error path
ARM: mxc: add a dma mask to fec devices
ARM: mx51_defconfig: enable various options
arch/arm/configs/mx51_defconfig | 53 ++++++--
arch/arm/mach-mxs/Kconfig | 14 ++
arch/arm/mach-mxs/Makefile | 2 +
arch/arm/mach-mxs/clock-mx23.c | 6 +-
arch/arm/mach-mxs/clock-mx28.c | 9 +-
arch/arm/mach-mxs/devices-mx23.h | 2 +
arch/arm/mach-mxs/devices-mx28.h | 2 +
arch/arm/mach-mxs/devices.c | 2 +
arch/arm/mach-mxs/devices/Kconfig | 3 +
arch/arm/mach-mxs/devices/Makefile | 1 +
arch/arm/mach-mxs/devices/platform-fec.c | 5 +-
arch/arm/mach-mxs/devices/platform-mxs-pwm.c | 22 +++
arch/arm/mach-mxs/include/mach/devices-common.h | 4 +
arch/arm/mach-mxs/include/mach/mxs.h | 9 +-
arch/arm/mach-mxs/include/mach/uncompress.h | 1 +
arch/arm/mach-mxs/mach-tx28.c | 175 +++++++++++++++++++++++
arch/arm/mach-mxs/module-tx28.c | 131 +++++++++++++++++
arch/arm/mach-mxs/module-tx28.h | 9 ++
arch/arm/mach-mxs/system.c | 2 +
arch/arm/plat-mxc/devices.c | 2 +
arch/arm/plat-mxc/devices/platform-fec.c | 4 +-
21 files changed, 441 insertions(+), 17 deletions(-)
create mode 100644 arch/arm/mach-mxs/devices/platform-mxs-pwm.c
create mode 100644 arch/arm/mach-mxs/mach-tx28.c
create mode 100644 arch/arm/mach-mxs/module-tx28.c
create mode 100644 arch/arm/mach-mxs/module-tx28.h
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: mxs: Initial support for Ka-Ro TX28
From: Uwe Kleine-König @ 2011-02-24 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110224210353.GA22310@pengutronix.de>
From: Lothar Wa?mann <LW@KARO-electronics.de>
Based on code created by Lothar Wa?mann, Sascha Hauer, Wolfram Sang and
me.
Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
arch/arm/mach-mxs/Kconfig | 12 ++
arch/arm/mach-mxs/Makefile | 2 +
arch/arm/mach-mxs/include/mach/mxs.h | 9 +-
arch/arm/mach-mxs/include/mach/uncompress.h | 1 +
arch/arm/mach-mxs/mach-tx28.c | 175 +++++++++++++++++++++++++++
arch/arm/mach-mxs/module-tx28.c | 131 ++++++++++++++++++++
arch/arm/mach-mxs/module-tx28.h | 9 ++
7 files changed, 337 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-mxs/mach-tx28.c
create mode 100644 arch/arm/mach-mxs/module-tx28.c
create mode 100644 arch/arm/mach-mxs/module-tx28.h
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 836cc81..895d066 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -39,4 +39,16 @@ config MACH_MX28EVK
Include support for MX28EVK platform. This includes specific
configurations for the board and its peripherals.
+config MODULE_TX28
+ bool
+ select SOC_IMX28
+ select MXS_HAVE_AMBA_DUART
+ select MXS_HAVE_PLATFORM_AUART
+ select MXS_HAVE_PLATFORM_FEC
+ select MXS_HAVE_PLATFORM_MXS_PWM
+
+config MACH_TX28
+ bool "Ka-Ro TX28 module"
+ select MODULE_TX28
+
endif
diff --git a/arch/arm/mach-mxs/Makefile b/arch/arm/mach-mxs/Makefile
index 6b26f02..2f1f614 100644
--- a/arch/arm/mach-mxs/Makefile
+++ b/arch/arm/mach-mxs/Makefile
@@ -9,5 +9,7 @@ obj-$(CONFIG_SOC_IMX28) += clock-mx28.o mm-mx28.o
obj-$(CONFIG_MACH_MX23EVK) += mach-mx23evk.o
obj-$(CONFIG_MACH_MX28EVK) += mach-mx28evk.o
+obj-$(CONFIG_MODULE_TX28) += module-tx28.o
+obj-$(CONFIG_MACH_TX28) += mach-tx28.o
obj-y += devices/
diff --git a/arch/arm/mach-mxs/include/mach/mxs.h b/arch/arm/mach-mxs/include/mach/mxs.h
index f186c08..35a89dd 100644
--- a/arch/arm/mach-mxs/include/mach/mxs.h
+++ b/arch/arm/mach-mxs/include/mach/mxs.h
@@ -28,8 +28,13 @@
/*
* MXS CPU types
*/
-#define cpu_is_mx23() (machine_is_mx23evk())
-#define cpu_is_mx28() (machine_is_mx28evk())
+#define cpu_is_mx23() ( \
+ machine_is_mx23evk() || \
+ 0)
+#define cpu_is_mx28() ( \
+ machine_is_mx28evk() || \
+ machine_is_tx28() || \
+ 0)
/*
* IO addresses common to MXS-based
diff --git a/arch/arm/mach-mxs/include/mach/uncompress.h b/arch/arm/mach-mxs/include/mach/uncompress.h
index a005e76..f12a173 100644
--- a/arch/arm/mach-mxs/include/mach/uncompress.h
+++ b/arch/arm/mach-mxs/include/mach/uncompress.h
@@ -63,6 +63,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
mxs_duart_base = MX23_DUART_BASE_ADDR;
break;
case MACH_TYPE_MX28EVK:
+ case MACH_TYPE_TX28:
mxs_duart_base = MX28_DUART_BASE_ADDR;
break;
default:
diff --git a/arch/arm/mach-mxs/mach-tx28.c b/arch/arm/mach-mxs/mach-tx28.c
new file mode 100644
index 0000000..540d6ea
--- /dev/null
+++ b/arch/arm/mach-mxs/mach-tx28.c
@@ -0,0 +1,175 @@
+/*
+ * Copyright (C) 2010 <LW@KARO-electronics.de>
+ *
+ * based on: mach-mx28_evk.c
+ * Copyright 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation
+ */
+#include <linux/kernel.h>
+#include <linux/gpio.h>
+#include <linux/leds.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/spi_gpio.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+
+#include <mach/common.h>
+#include <mach/iomux-mx28.h>
+
+#include "devices-mx28.h"
+#include "module-tx28.h"
+
+#define TX28_STK5_GPIO_LED MXS_GPIO_NR(4, 10)
+
+static const iomux_cfg_t tx28_stk5v3_pads[] __initconst = {
+ /* LED */
+ MX28_PAD_ENET0_RXD3__GPIO_4_10 |
+ MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL,
+
+ /* framebuffer */
+#define LCD_MODE (MXS_PAD_3V3 | MXS_PAD_4MA)
+ MX28_PAD_LCD_D00__LCD_D0 | LCD_MODE,
+ MX28_PAD_LCD_D01__LCD_D1 | LCD_MODE,
+ MX28_PAD_LCD_D02__LCD_D2 | LCD_MODE,
+ MX28_PAD_LCD_D03__LCD_D3 | LCD_MODE,
+ MX28_PAD_LCD_D04__LCD_D4 | LCD_MODE,
+ MX28_PAD_LCD_D05__LCD_D5 | LCD_MODE,
+ MX28_PAD_LCD_D06__LCD_D6 | LCD_MODE,
+ MX28_PAD_LCD_D07__LCD_D7 | LCD_MODE,
+ MX28_PAD_LCD_D08__LCD_D8 | LCD_MODE,
+ MX28_PAD_LCD_D09__LCD_D9 | LCD_MODE,
+ MX28_PAD_LCD_D10__LCD_D10 | LCD_MODE,
+ MX28_PAD_LCD_D11__LCD_D11 | LCD_MODE,
+ MX28_PAD_LCD_D12__LCD_D12 | LCD_MODE,
+ MX28_PAD_LCD_D13__LCD_D13 | LCD_MODE,
+ MX28_PAD_LCD_D14__LCD_D14 | LCD_MODE,
+ MX28_PAD_LCD_D15__LCD_D15 | LCD_MODE,
+ MX28_PAD_LCD_D16__LCD_D16 | LCD_MODE,
+ MX28_PAD_LCD_D17__LCD_D17 | LCD_MODE,
+ MX28_PAD_LCD_D18__LCD_D18 | LCD_MODE,
+ MX28_PAD_LCD_D19__LCD_D19 | LCD_MODE,
+ MX28_PAD_LCD_D20__LCD_D20 | LCD_MODE,
+ MX28_PAD_LCD_D21__LCD_D21 | LCD_MODE,
+ MX28_PAD_LCD_D22__LCD_D22 | LCD_MODE,
+ MX28_PAD_LCD_D23__LCD_D23 | LCD_MODE,
+ MX28_PAD_LCD_RD_E__LCD_VSYNC | LCD_MODE,
+ MX28_PAD_LCD_WR_RWN__LCD_HSYNC | LCD_MODE,
+ MX28_PAD_LCD_RS__LCD_DOTCLK | LCD_MODE,
+ MX28_PAD_LCD_CS__LCD_CS | LCD_MODE,
+ MX28_PAD_LCD_VSYNC__LCD_VSYNC | LCD_MODE,
+ MX28_PAD_LCD_HSYNC__LCD_HSYNC | LCD_MODE,
+ MX28_PAD_LCD_DOTCLK__LCD_DOTCLK | LCD_MODE,
+ MX28_PAD_LCD_ENABLE__GPIO_1_31 | LCD_MODE,
+ MX28_PAD_LCD_RESET__GPIO_3_30 | LCD_MODE,
+ MX28_PAD_PWM0__PWM_0 | LCD_MODE,
+
+ /* UART1 */
+ MX28_PAD_AUART0_CTS__DUART_RX,
+ MX28_PAD_AUART0_RTS__DUART_TX,
+ MX28_PAD_AUART0_TX__DUART_RTS,
+ MX28_PAD_AUART0_RX__DUART_CTS,
+
+ /* UART2 */
+ MX28_PAD_AUART1_RX__AUART1_RX,
+ MX28_PAD_AUART1_TX__AUART1_TX,
+ MX28_PAD_AUART1_RTS__AUART1_RTS,
+ MX28_PAD_AUART1_CTS__AUART1_CTS,
+
+ /* CAN */
+ MX28_PAD_GPMI_RDY2__CAN0_TX,
+ MX28_PAD_GPMI_RDY3__CAN0_RX,
+
+ /* I2C */
+ MX28_PAD_I2C0_SCL__I2C0_SCL,
+ MX28_PAD_I2C0_SDA__I2C0_SDA,
+
+ /* TSC2007 */
+ MX28_PAD_SAIF0_MCLK__GPIO_3_20 | MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_PULLUP,
+
+ /* MMC0 */
+ MX28_PAD_SSP0_DATA0__SSP0_D0 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA1__SSP0_D1 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA2__SSP0_D2 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA3__SSP0_D3 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA4__SSP0_D4 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA5__SSP0_D5 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA6__SSP0_D6 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DATA7__SSP0_D7 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_CMD__SSP0_CMD |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+ MX28_PAD_SSP0_SCK__SSP0_SCK |
+ (MXS_PAD_12MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+};
+
+static struct gpio_led tx28_stk5v3_leds[] = {
+ {
+ .name = "GPIO-LED",
+ .default_trigger = "heartbeat",
+ .gpio = TX28_STK5_GPIO_LED,
+ },
+};
+
+static const struct gpio_led_platform_data tx28_stk5v3_led_data __initconst = {
+ .leds = tx28_stk5v3_leds,
+ .num_leds = ARRAY_SIZE(tx28_stk5v3_leds),
+};
+
+static struct spi_board_info tx28_spi_board_info[] = {
+#if defined(CONFIG_SPI_SPIDEV) || defined(CONFIG_SPI_SPIDEV_MODULE)
+ {
+ .modalias = "spidev",
+ .max_speed_hz = 20000000,
+ .bus_num = 0,
+ .chip_select = 1,
+ .controller_data = (void *)SPI_GPIO_NO_CHIPSELECT,
+ .mode = SPI_MODE_0,
+ },
+#endif
+};
+
+static void __init tx28_stk5v3_init(void)
+{
+ mxs_iomux_setup_multiple_pads(tx28_stk5v3_pads,
+ ARRAY_SIZE(tx28_stk5v3_pads));
+
+ mx28_add_duart(); /* UART1 */
+ mx28_add_auart(1); /* UART2 */
+
+ tx28_add_fec0();
+ /* spi via ssp will be added when available */
+ spi_register_board_info(tx28_spi_board_info,
+ ARRAY_SIZE(tx28_spi_board_info));
+ mxs_add_platform_device("leds-gpio", 0, NULL, 0,
+ &tx28_stk5v3_led_data, sizeof(tx28_stk5v3_led_data));
+}
+
+static void __init tx28_timer_init(void)
+{
+ mx28_clocks_init();
+}
+
+static struct sys_timer tx28_timer = {
+ .init = tx28_timer_init,
+};
+
+MACHINE_START(TX28, "Ka-Ro electronics TX28 module")
+ .map_io = mx28_map_io,
+ .init_irq = mx28_init_irq,
+ .init_machine = tx28_stk5v3_init,
+ .timer = &tx28_timer,
+MACHINE_END
diff --git a/arch/arm/mach-mxs/module-tx28.c b/arch/arm/mach-mxs/module-tx28.c
new file mode 100644
index 0000000..fa0b154
--- /dev/null
+++ b/arch/arm/mach-mxs/module-tx28.c
@@ -0,0 +1,131 @@
+/*
+ * Copyright (C) 2010 <LW@KARO-electronics.de>
+ *
+ * This program is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation.
+ */
+
+#include <linux/delay.h>
+#include <linux/fec.h>
+#include <linux/gpio.h>
+
+#include <mach/iomux-mx28.h>
+#include "../devices-mx28.h"
+
+#include "module-tx28.h"
+
+#define TX28_FEC_PHY_POWER MXS_GPIO_NR(3, 29)
+#define TX28_FEC_PHY_RESET MXS_GPIO_NR(4, 13)
+
+static const iomux_cfg_t tx28_fec_gpio_pads[] __initconst = {
+ /* PHY POWER */
+ MX28_PAD_PWM4__GPIO_3_29 |
+ MXS_PAD_4MA | MXS_PAD_NOPULL | MXS_PAD_3V3,
+ /* PHY RESET */
+ MX28_PAD_ENET0_RX_CLK__GPIO_4_13 |
+ MXS_PAD_4MA | MXS_PAD_NOPULL | MXS_PAD_3V3,
+ /* Mode strap pins 0-2 */
+ MX28_PAD_ENET0_RXD0__GPIO_4_3 |
+ MXS_PAD_8MA | MXS_PAD_PULLUP | MXS_PAD_3V3,
+ MX28_PAD_ENET0_RXD1__GPIO_4_4 |
+ MXS_PAD_8MA | MXS_PAD_PULLUP | MXS_PAD_3V3,
+ MX28_PAD_ENET0_RX_EN__GPIO_4_2 |
+ MXS_PAD_8MA | MXS_PAD_PULLUP | MXS_PAD_3V3,
+ /* nINT */
+ MX28_PAD_ENET0_TX_CLK__GPIO_4_5 |
+ MXS_PAD_4MA | MXS_PAD_NOPULL | MXS_PAD_3V3,
+
+ MX28_PAD_ENET0_MDC__GPIO_4_0,
+ MX28_PAD_ENET0_MDIO__GPIO_4_1,
+ MX28_PAD_ENET0_TX_EN__GPIO_4_6,
+ MX28_PAD_ENET0_TXD0__GPIO_4_7,
+ MX28_PAD_ENET0_TXD1__GPIO_4_8,
+ MX28_PAD_ENET_CLK__GPIO_4_16,
+};
+
+#define FEC_MODE (MXS_PAD_8MA | MXS_PAD_PULLUP | MXS_PAD_3V3)
+static const iomux_cfg_t tx28_fec_pads[] __initconst = {
+ MX28_PAD_ENET0_MDC__ENET0_MDC | FEC_MODE,
+ MX28_PAD_ENET0_MDIO__ENET0_MDIO | FEC_MODE,
+ MX28_PAD_ENET0_RX_EN__ENET0_RX_EN | FEC_MODE,
+ MX28_PAD_ENET0_RXD0__ENET0_RXD0 | FEC_MODE,
+ MX28_PAD_ENET0_RXD1__ENET0_RXD1 | FEC_MODE,
+ MX28_PAD_ENET0_TX_EN__ENET0_TX_EN | FEC_MODE,
+ MX28_PAD_ENET0_TXD0__ENET0_TXD0 | FEC_MODE,
+ MX28_PAD_ENET0_TXD1__ENET0_TXD1 | FEC_MODE,
+ MX28_PAD_ENET_CLK__CLKCTRL_ENET | FEC_MODE,
+};
+
+static const struct fec_platform_data tx28_fec_data __initconst = {
+ .phy = PHY_INTERFACE_MODE_RMII,
+};
+
+int __init tx28_add_fec0(void)
+{
+ int i, ret;
+
+ pr_debug("%s: Switching FEC PHY power off\n", __func__);
+ ret = mxs_iomux_setup_multiple_pads(tx28_fec_gpio_pads,
+ ARRAY_SIZE(tx28_fec_gpio_pads));
+ for (i = 0; i < ARRAY_SIZE(tx28_fec_gpio_pads); i++) {
+ unsigned int gpio = MXS_GPIO_NR(PAD_BANK(tx28_fec_gpio_pads[i]),
+ PAD_PIN(tx28_fec_gpio_pads[i]));
+
+ ret = gpio_request(gpio, "FEC");
+ if (ret) {
+ pr_err("Failed to request GPIO_%d_%d: %d\n",
+ PAD_BANK(tx28_fec_gpio_pads[i]),
+ PAD_PIN(tx28_fec_gpio_pads[i]), ret);
+ goto free_gpios;
+ }
+ ret = gpio_direction_output(gpio, 0);
+ if (ret) {
+ pr_err("Failed to set direction of GPIO_%d_%d to output: %d\n",
+ gpio / 32 + 1, gpio % 32, ret);
+ goto free_gpios;
+ }
+ }
+
+ /* Power up fec phy */
+ pr_debug("%s: Switching FEC PHY power on\n", __func__);
+ ret = gpio_direction_output(TX28_FEC_PHY_POWER, 1);
+ if (ret) {
+ pr_err("Failed to power on PHY: %d\n", ret);
+ goto free_gpios;
+ }
+ mdelay(26); /* 25ms according to data sheet */
+
+ /* nINT */
+ gpio_direction_input(MXS_GPIO_NR(4, 5));
+ /* Mode strap pins */
+ gpio_direction_output(MXS_GPIO_NR(4, 2), 1);
+ gpio_direction_output(MXS_GPIO_NR(4, 3), 1);
+ gpio_direction_output(MXS_GPIO_NR(4, 4), 1);
+
+ udelay(100); /* minimum assertion time for nRST */
+
+ pr_debug("%s: Deasserting FEC PHY RESET\n", __func__);
+ gpio_set_value(TX28_FEC_PHY_RESET, 1);
+
+ ret = mxs_iomux_setup_multiple_pads(tx28_fec_pads,
+ ARRAY_SIZE(tx28_fec_pads));
+ if (ret) {
+ pr_debug("%s: mxs_iomux_setup_multiple_pads() failed with rc: %d\n",
+ __func__, ret);
+ goto free_gpios;
+ }
+ pr_debug("%s: Registering FEC device\n", __func__);
+ mx28_add_fec(0, &tx28_fec_data);
+ return 0;
+
+free_gpios:
+ while (--i >= 0) {
+ unsigned int gpio = MXS_GPIO_NR(PAD_BANK(tx28_fec_gpio_pads[i]),
+ PAD_PIN(tx28_fec_gpio_pads[i]));
+
+ gpio_free(gpio);
+ }
+
+ return ret;
+}
diff --git a/arch/arm/mach-mxs/module-tx28.h b/arch/arm/mach-mxs/module-tx28.h
new file mode 100644
index 0000000..df9e1b6
--- /dev/null
+++ b/arch/arm/mach-mxs/module-tx28.h
@@ -0,0 +1,9 @@
+/*
+ * Copyright (C) 2010 Pengutronix
+ * Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation.
+ */
+int __init tx28_add_fec0(void);
--
1.7.2.3
^ permalink raw reply related
* [PATCH v6] OMAP2/3/4: DSS2: Enable Display SubSystem as modules
From: Tony Lindgren @ 2011-02-24 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298536312.16119.23.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [110224 00:30]:
> On Thu, 2011-02-24 at 00:26 -0600, Nilofer, Samreen wrote:
> > Enabling all the display interface options to be built as module
> > And enabling all the display panels to be built as modules.
> >
> > Signed-off-by: Samreen <samreen@ti.com>
>
> This looks good to me.
>
> Tony, want to ack this? This enables all DSS features as modules. This
> should go through dss tree, as this doesn't work without a fix that is
> there.
Sounds good to me:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH] OMAP2+: clocksource: fix crash on boot when !CONFIG_OMAP_32K_TIMER
From: Tony Lindgren @ 2011-02-24 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1102241330500.6198@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [110224 12:29]:
> On Thu, 24 Feb 2011, Tony Lindgren wrote:
>
> > * Paul Walmsley <paul@pwsan.com> [110222 18:58]:
> > >
> > > OMAP2+ kernels built without CONFIG_OMAP_32K_TIMER crash on boot after the
> > > 2.6.38 sched_clock changes:
> > >
> > > [ 0.000000] OMAP clockevent source: GPTIMER1 at 13000000 Hz
> > > [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > > [ 0.000000] pgd = c0004000
> > > [ 0.000000] [00000000] *pgd=00000000
> > > [ 0.000000] Internal error: Oops: 80000005 [#1] SMP
> > > [ 0.000000] last sysfs file:
> > > [ 0.000000] Modules linked in:
> > > [ 0.000000] CPU: 0 Not tainted (2.6.38-rc5-00057-g04aa67d #152)
> > > [ 0.000000] PC is at 0x0
> > > [ 0.000000] LR is at sched_clock_poll+0x2c/0x3c
> > >
> > > Without CONFIG_OMAP_32K_TIMER, the kernel has an clockevent and
> > > clocksource resolution about three orders of magnitude higher than
> > > with CONFIG_OMAP_32K_TIMER set. The tradeoff is that the lowest
> > > power consumption states are not available.
> > >
> > > Fix by calling init_sched_clock() from the GPTIMER clocksource init code.
> >
> > I'll queue this as a fix as it's a regression.
>
> Sounds good, I've got one or two other -rc candidates. Want me to build a
> branch with this and the other two?
Well I already applied this one. But for the two others yes please.
Tony
^ permalink raw reply
* [PATCH resend] omap: Fix linker error in drivers/video/omap/lcd_2430sdp.c
From: Tony Lindgren @ 2011-02-24 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298232248-347-1-git-send-email-jhnikula@gmail.com>
Hi,
* Jarkko Nikula <jhnikula@gmail.com> [110220 12:13]:
> There is a linker error from lcd_2430sdp.c if CONFIG_TWL4030_CORE is not
> set. This can be triggered on OMAP2 builds where OMAP3 or OMAP4 are not set.
>
> drivers/built-in.o: In function `sdp2430_panel_disable':
> drivers/video/omap/lcd_2430sdp.c:123: undefined reference to `twl_i2c_write_u8'
> drivers/video/omap/lcd_2430sdp.c:124: undefined reference to `twl_i2c_write_u8'
> drivers/built-in.o: In function `sdp2430_panel_enable':
> drivers/video/omap/lcd_2430sdp.c:110: undefined reference to `twl_i2c_write_u8'
> drivers/video/omap/lcd_2430sdp.c:112: undefined reference to `twl_i2c_write_u8'
>
> Fix this by adding TWL4030_CORE dependency to CONFIG_MACH_OMAP_2430SDP as
> there is no own entry in drivers/video/omap/Kconfig.
>
> Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> Resend = forgot to cc LAKML.
> Quite old issue most probably. Can be triggered in mainline anyway.
> ---
> arch/arm/mach-omap2/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index b9d8a7b..bfdf240 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -132,6 +132,7 @@ config MACH_OMAP_2430SDP
> depends on SOC_OMAP2430
> default y
> select OMAP_PACKAGE_ZAC
> + select TWL4030_CORE
>
> config MACH_OMAP3_BEAGLE
> bool "OMAP3 BEAGLE board"
We should avoid selecting driver related things, otherwise we can never
build a tiny kernel with initramfs with everything as modules.
Can you see if adding depends to the LCD panel option does the trick
instead?
Thanks,
Tony
^ permalink raw reply
* [PATCH resend] omap: rx51: Add SI4713 FM transmitter
From: Tony Lindgren @ 2011-02-24 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298270556-11571-1-git-send-email-jhnikula@gmail.com>
* Jarkko Nikula <jhnikula@gmail.com> [110220 22:40]:
> Add SI4713 FM transmitter supplies, platform data and setup to RX-51/N900.
Thanks adding to devel-board for the upcoming merge window.
Tony
^ permalink raw reply
* [PATCH] MAINTAINERS: Update MSM maintainers
From: Bryan Huntsman @ 2011-02-24 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298512932.17118.16.camel@m0nster>
On 02/23/2011 06:02 PM, Daniel Walker wrote:
> There's nothing really to figure out. I don't feel like you and David
> can do the job alone. My intentions are just to make sure that you don't
> mess with my targets, and that you do the right thing by the community.
>
> Daniel
I'd like to address the points you mention. I disagree with your
personal feelings about David's suitability for the task. David has
been involved with Linux MSM development for it's entire history. This
is important because he knows the HW behavior and SW designs for all the
MSM chips and drivers. This gives him the context to recognize
potentially subtle interactions and behavioral issues. I hope you would
agree that this type of expertise and insight is valuable for any
maintainer to have. Regarding his ability to do this on his own, public
maintainership of the MSM architecture is David's primary
responsibility. I agree that this is a somewhat new role for him, but
maintainers have to start somewhere. From what I've seen so far, David
is showing the proper maturity and judgement expected from a
maintainer. As an example, I would point to David's handling of Arnd's
comments in this thread; https://lkml.org/lkml/2010/12/16/434. This
caused a considerable amount re-work and testing for us but David made
sure that it was addressed and resolved correctly and in a timely manner.
For your second point, would you please explain how we're "messing with
your targets"? I understand that you have a personal interest in
getting G1 and NexusOne support into the kernel. This is a great goal
and I would encourage you to continue with this effort. We're happy to
accept any patches you submit in this regard. Additionally, I think you
would provide value to the MSM maintainer and the community by testing
patches on these targets once there is support for them in the kernel.
However, I would like to point out that the MSM architecture includes
much more that just G1 or NexusOne. By my last last count, there were
about 47 MSM machines registered.
For your last point, would you please explain why it falls to you to
"make sure ... that we do the right thing by the community"? We are
trying very hard to become good citizens in the Linux kernel development
community. This is not always an easy thing to do. The issues with SOC
vendors are well known. I think the fact that one of our key MSM
developers, David Brown, has stepped up to handle public maintainership
of the MSM architecture, as well as the fact that many of our developers
are now submitting patches upstream, demonstrates that we are trying to
do the right thing. I'm sure there are lots of areas where we could
improve and many things we could do better. This is a learning process
for many of us. If you have specific examples of things that should be
fixed or could be done better, please let us know. That kind of
feedback is why we're participating and sending patches out for public
review in the first place. If you have specific examples of us doing
wrong by the community please share those as well. To my knowledge, no
such issues have been raised by anyone in the community so far.
Finally, it's my hope that you and Linux community will help and support
David as the MSM maintainer by reviewing MSM-related patches and
pointing out areas where the MSM architecture could be improved. In
this spirit, I'm asking you to please acknowledge the patch that started
this email chain. Please let the MSM developers take full
responsibility for the MSM architecture. That is, after all, what the
community typically asks from SOC vendors. Thanks.
- Bryan
--
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] i.MX51 & i.MX53: move registration of gpios to plat-mxc/gpio.c
From: Eric Bénard @ 2011-02-24 21:42 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Eric B?nard <eric@eukrea.com>
---
arch/arm/mach-mx5/devices.c | 63 -------------------------------------------
arch/arm/mach-mx5/mm.c | 39 +++++++++++++++-----------
arch/arm/plat-mxc/gpio.c | 27 ++++++++++++++++++
3 files changed, 49 insertions(+), 80 deletions(-)
diff --git a/arch/arm/mach-mx5/devices.c b/arch/arm/mach-mx5/devices.c
index 153ada5..8951312 100644
--- a/arch/arm/mach-mx5/devices.c
+++ b/arch/arm/mach-mx5/devices.c
@@ -119,66 +119,3 @@ struct platform_device mxc_usbh2_device = {
.coherent_dma_mask = DMA_BIT_MASK(32),
},
};
-
-static struct mxc_gpio_port mxc_gpio_ports[] = {
- {
- .chip.label = "gpio-0",
- .base = MX51_IO_ADDRESS(MX51_GPIO1_BASE_ADDR),
- .irq = MX51_MXC_INT_GPIO1_LOW,
- .irq_high = MX51_MXC_INT_GPIO1_HIGH,
- .virtual_irq_start = MXC_GPIO_IRQ_START
- },
- {
- .chip.label = "gpio-1",
- .base = MX51_IO_ADDRESS(MX51_GPIO2_BASE_ADDR),
- .irq = MX51_MXC_INT_GPIO2_LOW,
- .irq_high = MX51_MXC_INT_GPIO2_HIGH,
- .virtual_irq_start = MXC_GPIO_IRQ_START + 32 * 1
- },
- {
- .chip.label = "gpio-2",
- .base = MX51_IO_ADDRESS(MX51_GPIO3_BASE_ADDR),
- .irq = MX51_MXC_INT_GPIO3_LOW,
- .irq_high = MX51_MXC_INT_GPIO3_HIGH,
- .virtual_irq_start = MXC_GPIO_IRQ_START + 32 * 2
- },
- {
- .chip.label = "gpio-3",
- .base = MX51_IO_ADDRESS(MX51_GPIO4_BASE_ADDR),
- .irq = MX51_MXC_INT_GPIO4_LOW,
- .irq_high = MX51_MXC_INT_GPIO4_HIGH,
- .virtual_irq_start = MXC_GPIO_IRQ_START + 32 * 3
- },
- {
- .chip.label = "gpio-4",
- .base = MX53_IO_ADDRESS(MX53_GPIO5_BASE_ADDR),
- .irq = MX53_INT_GPIO5_LOW,
- .irq_high = MX53_INT_GPIO5_HIGH,
- .virtual_irq_start = MXC_GPIO_IRQ_START + 32 * 4
- },
- {
- .chip.label = "gpio-5",
- .base = MX53_IO_ADDRESS(MX53_GPIO6_BASE_ADDR),
- .irq = MX53_INT_GPIO6_LOW,
- .irq_high = MX53_INT_GPIO6_HIGH,
- .virtual_irq_start = MXC_GPIO_IRQ_START + 32 * 5
- },
- {
- .chip.label = "gpio-6",
- .base = MX53_IO_ADDRESS(MX53_GPIO7_BASE_ADDR),
- .irq = MX53_INT_GPIO7_LOW,
- .irq_high = MX53_INT_GPIO7_HIGH,
- .virtual_irq_start = MXC_GPIO_IRQ_START + 32 * 6
- },
-};
-
-int __init imx51_register_gpios(void)
-{
- return mxc_gpio_init(mxc_gpio_ports, 4);
-}
-
-int __init imx53_register_gpios(void)
-{
- return mxc_gpio_init(mxc_gpio_ports, ARRAY_SIZE(mxc_gpio_ports));
-}
-
diff --git a/arch/arm/mach-mx5/mm.c b/arch/arm/mach-mx5/mm.c
index 457f9f9..c6d6787 100644
--- a/arch/arm/mach-mx5/mm.c
+++ b/arch/arm/mach-mx5/mm.c
@@ -20,6 +20,7 @@
#include <mach/common.h>
#include <mach/iomux-v3.h>
+#if defined(CONFIG_SOC_IMX51)
/*
* Define the MX51 memory map.
*/
@@ -32,15 +33,6 @@ static struct map_desc mx51_io_desc[] __initdata = {
};
/*
- * Define the MX53 memory map.
- */
-static struct map_desc mx53_io_desc[] __initdata = {
- imx_map_entry(MX53, AIPS1, MT_DEVICE),
- imx_map_entry(MX53, SPBA0, MT_DEVICE),
- imx_map_entry(MX53, AIPS2, MT_DEVICE),
-};
-
-/*
* This function initializes the memory map. It is called during the
* system startup to create static physical to virtual memory mappings
* for the IO modules.
@@ -53,14 +45,6 @@ void __init mx51_map_io(void)
iotable_init(mx51_io_desc, ARRAY_SIZE(mx51_io_desc));
}
-void __init mx53_map_io(void)
-{
- mxc_set_cpu_type(MXC_CPU_MX53);
- mxc_iomux_v3_init(MX53_IO_ADDRESS(MX53_IOMUXC_BASE_ADDR));
- mxc_arch_reset_init(MX53_IO_ADDRESS(MX53_WDOG_BASE_ADDR));
- iotable_init(mx53_io_desc, ARRAY_SIZE(mx53_io_desc));
-}
-
int imx51_register_gpios(void);
void __init mx51_init_irq(void)
@@ -80,6 +64,26 @@ void __init mx51_init_irq(void)
tzic_init_irq(tzic_virt);
imx51_register_gpios();
}
+#endif /* if defined(CONFIG_SOC_IMX51) */
+
+#if defined(CONFIG_SOC_IMX53)
+
+/*
+ * Define the MX53 memory map.
+ */
+static struct map_desc mx53_io_desc[] __initdata = {
+ imx_map_entry(MX53, AIPS1, MT_DEVICE),
+ imx_map_entry(MX53, SPBA0, MT_DEVICE),
+ imx_map_entry(MX53, AIPS2, MT_DEVICE),
+};
+
+void __init mx53_map_io(void)
+{
+ mxc_set_cpu_type(MXC_CPU_MX53);
+ mxc_iomux_v3_init(MX53_IO_ADDRESS(MX53_IOMUXC_BASE_ADDR));
+ mxc_arch_reset_init(MX53_IO_ADDRESS(MX53_WDOG_BASE_ADDR));
+ iotable_init(mx53_io_desc, ARRAY_SIZE(mx53_io_desc));
+}
int imx53_register_gpios(void);
@@ -97,3 +101,4 @@ void __init mx53_init_irq(void)
tzic_init_irq(tzic_virt);
imx53_register_gpios();
}
+#endif /* if defined(CONFIG_SOC_IMX53) */
diff --git a/arch/arm/plat-mxc/gpio.c b/arch/arm/plat-mxc/gpio.c
index d17b3c9..b204b45 100644
--- a/arch/arm/plat-mxc/gpio.c
+++ b/arch/arm/plat-mxc/gpio.c
@@ -459,3 +459,30 @@ static struct mxc_gpio_port imx50_gpio_ports[] = {
DEFINE_REGISTER_FUNCTION(imx50)
#endif /* if defined(CONFIG_SOC_IMX50) */
+
+#if defined(CONFIG_SOC_IMX51)
+static struct mxc_gpio_port imx51_gpio_ports[] = {
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 0, 1, MX51_MXC_INT_GPIO1_LOW, MX51_MXC_INT_GPIO1_HIGH),
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 1, 2, MX51_MXC_INT_GPIO2_LOW, MX51_MXC_INT_GPIO2_HIGH),
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 2, 3, MX51_MXC_INT_GPIO3_LOW, MX51_MXC_INT_GPIO3_HIGH),
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 3, 4, MX51_MXC_INT_GPIO4_LOW, MX51_MXC_INT_GPIO4_HIGH),
+};
+
+DEFINE_REGISTER_FUNCTION(imx51)
+
+#endif /* if defined(CONFIG_SOC_IMX51) */
+
+#if defined(CONFIG_SOC_IMX53)
+static struct mxc_gpio_port imx53_gpio_ports[] = {
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 0, 1, MX51_MXC_INT_GPIO1_LOW, MX51_MXC_INT_GPIO1_HIGH),
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 1, 2, MX51_MXC_INT_GPIO2_LOW, MX51_MXC_INT_GPIO2_HIGH),
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 2, 3, MX51_MXC_INT_GPIO3_LOW, MX51_MXC_INT_GPIO3_HIGH),
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 3, 4, MX51_MXC_INT_GPIO4_LOW, MX51_MXC_INT_GPIO4_HIGH),
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 4, 5, MX53_INT_GPIO5_LOW, MX53_INT_GPIO5_HIGH),
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 5, 6, MX53_INT_GPIO6_LOW, MX53_INT_GPIO6_HIGH),
+ DEFINE_IMX_GPIO_PORT_IRQ_HIGH(MX51, 6, 7, MX53_INT_GPIO7_LOW, MX53_INT_GPIO7_HIGH),
+};
+
+DEFINE_REGISTER_FUNCTION(imx53)
+
+#endif /* if defined(CONFIG_SOC_IMX53) */
--
1.7.4
^ permalink raw reply related
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