Re: update: n8x0 idle power problem
Yes. I took off N810's battery and powered it with an external power supply. By different power rails, you mean dissecting N810 to do finer-grain power measurement? Hope any people who have also done this 'overall' measurement can confirm my observation or point out my mistake. Best Regards, -- Felix On Mon, Oct 26, 2009 at 6:57 PM, Girish S G wrote: > > >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felix >> Xiaozhu Lin >> Sent: Monday, October 26, 2009 5:36 PM >> To: linux-omap@vger.kernel.org >> Subject: update: n8x0 idle power problem >> >> Hi, All, >> >> Regarding the idle power problem I've mentioned in a mail last weekend: >> >> http://marc.info/?l=linux-omap&m=125634121921583&w=2 >> >> I have spent more efforts on this problem. By comparing with PM debug >> messages from Maemo kernel, it seems full-retention in linux-omap >> 2.6.28 has no problem on n810. Moreover, I've observed that l-o kernel >> consumes more power in other power states (e.g. when USB is plugged >> and the screen is dim but not off, Maemo kernel takes ~9...@3.8v while >> l-o kernel takes ~18...@3.8v). As a result, I think the extra power >> may not be consumed by OMAP processor core but by some device. > > I assume you are measuring at the battery level(?). If you have measurement > done across > different rails then it would help to understand who is consuming more. > > > -Girish > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: update: n8x0 idle power problem
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felix > Xiaozhu Lin > Sent: Monday, October 26, 2009 5:36 PM > To: linux-omap@vger.kernel.org > Subject: update: n8x0 idle power problem > > Hi, All, > > Regarding the idle power problem I've mentioned in a mail last weekend: > > http://marc.info/?l=linux-omap&m=125634121921583&w=2 > > I have spent more efforts on this problem. By comparing with PM debug > messages from Maemo kernel, it seems full-retention in linux-omap > 2.6.28 has no problem on n810. Moreover, I've observed that l-o kernel > consumes more power in other power states (e.g. when USB is plugged > and the screen is dim but not off, Maemo kernel takes ~9...@3.8v while > l-o kernel takes ~18...@3.8v). As a result, I think the extra power > may not be consumed by OMAP processor core but by some device. I assume you are measuring at the battery level(?). If you have measurement done across different rails then it would help to understand who is consuming more. -Girish -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
update: n8x0 idle power problem
Hi, All, Regarding the idle power problem I've mentioned in a mail last weekend: http://marc.info/?l=linux-omap&m=125634121921583&w=2 I have spent more efforts on this problem. By comparing with PM debug messages from Maemo kernel, it seems full-retention in linux-omap 2.6.28 has no problem on n810. Moreover, I've observed that l-o kernel consumes more power in other power states (e.g. when USB is plugged and the screen is dim but not off, Maemo kernel takes ~9...@3.8v while l-o kernel takes ~18...@3.8v). As a result, I think the extra power may not be consumed by OMAP processor core but by some device. I try to disable some devices in kernel configuration (BT/MMC/USB), but it does not work - l-o power consumption is still significantly higher than Maemo kernel. Would you please offer some suggestions? Thanks Best Regards, -- Felix -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAP] GPIO Module is reset during initialization
ch...@ti.com writes:
> From: Charulatha V
>
> During initialization, GPIO module is reset using soft reset bit
> of SYSCONFIG register
>
> Signed-off-by: Charulatha V
> ---
> arch/arm/plat-omap/gpio.c | 12 +++-
> 1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index 2304a5d..4579650 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1670,7 +1671,7 @@ static int __init _omap_gpio_init(void)
> }
> #endif
> for (i = 0; i < gpio_bank_count; i++) {
> - int j, gpio_count = 16;
> + int j, gpio_count = 16, attempt = 0;
>
> bank = &gpio_bank[i];
> spin_lock_init(&bank->lock);
> @@ -1698,6 +1699,15 @@ static int __init _omap_gpio_init(void)
> static const u32 non_wakeup_gpios[] = {
> 0xe203ffc0, 0x08700040
> };
> +
> + /* Software Reset of GPIO module */
> + __raw_writel(0x0002, bank->base + OMAP24XX_GPIO_SYSCONFIG);
> + while (((__raw_readl(bank->base + OMAP24XX_GPIO_SYSSTATUS)
> + & 0x1) == 0) && attempt < 5) {
> + udelay(1);
> + attempt++;
> + }
> +
NAK. Would rather see an omap_hwmod added for GPIO, in which case we
get the reset for free.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3: PM: Check BM for C2 state
Tero Kristo writes: > From: De-Schrijver Peter > > C2 can't be entered while we have bus activity. Why? For the benefit of git history, can you add a more verbose changelog please describing why? Otherwise, patch looks fine. Thanks, Kevin > Signed-off-by: Peter 'p2' De Schrijver > --- > arch/arm/mach-omap2/cpuidle34xx.c |7 --- > 1 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-omap2/cpuidle34xx.c > b/arch/arm/mach-omap2/cpuidle34xx.c > index c44a942..a0d9f56 100644 > --- a/arch/arm/mach-omap2/cpuidle34xx.c > +++ b/arch/arm/mach-omap2/cpuidle34xx.c > @@ -38,7 +38,7 @@ > > #define OMAP3_MAX_STATES 7 > #define OMAP3_STATE_C1 0 /* C1 - MPU WFI + Core active */ > -#define OMAP3_STATE_C2 1 /* C2 - MPU WFI + Core inactive */ > +#define OMAP3_STATE_C2 1 /* C2 - MPU inactive + Core inactive */ > #define OMAP3_STATE_C3 2 /* C3 - MPU CSWR + Core inactive */ > #define OMAP3_STATE_C4 3 /* C4 - MPU OFF + Core iactive */ > #define OMAP3_STATE_C5 4 /* C5 - MPU RET + Core RET */ > @@ -169,7 +169,7 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev); > * > * Below is the desciption of each C state. > * C1 . MPU WFI + Core active > - * C2 . MPU WFI + Core inactive > + * C2 . MPU inactive + Core inactive > * C3 . MPU CSWR + Core inactive > * C4 . MPU OFF + Core inactive > * C5 . MPU CSWR + Core CSWR > @@ -196,7 +196,8 @@ void omap_init_power_states(void) > omap3_power_states[OMAP3_STATE_C2].threshold = 30; > omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON; > omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON; > - omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID; > + omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID | > + CPUIDLE_FLAG_CHECK_BM; > > /* C3 . MPU CSWR + Core inactive */ > omap3_power_states[OMAP3_STATE_C3].valid = 1; > -- > 1.5.4.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] RX51: SDRAM settings changes
Tero Kristo writes: > From: Tero Kristo > > Following patch set fixes a few issues with current RX51 board SDRAM settings. > Applies on top of PM branch. > Tero, Can you resend this series against the master branch? There is no reason this should be carried in the PM branch anymore. You'll have to add to your series the patch to add the board-rx51-sdram.c file, which I currently carry in the PM branch. Then, for the PM branch, we just need a small patch to add the various rate tables in the call to init_common_hw until DVFS stuff is upstream. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
> From: Nishanth Menon [mailto:menon.nisha...@gmail.com] On Behalf Of Menon,
> Nishanth
>
> Benoit,
> thanks.. overall good discussion that is nice to take in.. more comments
You're welcome! My pleasure.
> follow:
>
> Cousson, Benoit said the following on 10/26/2009 08:05 AM:
> >> From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
> >>
> >> Cousson, Benoit said the following on 10/25/2009 05:12 PM:
> >>
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
>
>
> >> [...]
> >>
> + },
> + /* *INDENT-ON* */
> +};
> +
> +/* SR list for 3430 */
> +static __initdata struct omap_sr_list omap34xx_srlist = {
> + .num_sr = 2,
> + .sr_list = {&omap34xx_sr1, &omap34xx_sr2}
> +};
> +
> +/* The final SR list */
> +static struct omap_sr_list *omap_srlist;
>
>
> >>> I have a couple a suggestions regarding the code partitioning:
> >>>
> >>> - SmartReflex is one IP with several instances; it means that only the
> >>>
> >> base address will change between SR1 and SR2. There is no need to
> >> duplicate the mask and shift defines per SR.
> >>
> >> might have been easier with a standard OCP wrapper and standard
> >> INT/INTSTATUS regs for SR instead of the current integration but
> >> yeah, I had been thinking of that- if O4/beyond could have the same IP
> >> wrapped in a different register mapping, i should handle it then, not
> >> dream about it now.. I get your point here.. there are a few places we
> >> can kick it out and some places your are stuck with them!
> >>
> >
> > SR is a regular IP, with a dedicated PD, dedicated fclk and bound to the
> L4...
> > VP/VC is not, that why I was proposing to separated them.
> >
> I am not denying it, but VP/VC functions are already separated out where
> I could do it (note the seperation of function names), only they dont
> have a new file perse.. but that is not needed at the moment.
> >
> >>> Moreover, SR being an IP, I think we can encode the one IP / several
> >>>
> >> instance in a platform_device / platform_driver code. It will allow the
> >> support of several drivers for the same devices in order to implement
> for
> >> example class3, class2 or class1 drivers. SR can even be represented by
> an
> >> HWMOD.
> >>
> >> what is your intention in misusing platform_device for a SOC specific
> >> code? I think you have an idea here that I am completely missing. can
> >> you care to elaborate?
> >>
> >
> > AFAIK, platform_device is there in order to deal with SoC devices???
> > Considering that SR is an IP that can be in several SoC, it looks to me
> the perfect candidate for platform_device/platform_driver.
> > Am I missing something?
> >
> Everything abstracted is a perfect candidate for device-driver model,
> but that is beside the point. platform_device traditionally has been
> platform aka board specific info, not SOC specific info..
Are you sure about that? The definition does not seem to be that strict.
Extract from Documentation/driver-model/platform.txt
Platform Devices and Drivers
[snip]
This pseudo-bus is used to connect devices on busses with minimal
infrastructure, like those used to integrate peripherals on many system-on-chip
processors, or some "legacy" PC interconnects; as opposed to large
formally specified ones like PCI or USB.
[snip]
Moreover, in the current l-o tree, the platform_device is used for DSP, MCBSP,
MMC, uWIRE, UART, USB, ISP, bangap sensor, toaster...
> >
> >>> - The smartreflex.c file contains 34xx specifics code; it should not
> be
> >>>
> >> there, only SR specific code should be there.
> >>
> >> read the TODO. which specific 3430 code does it have? other than using
> >> macros which have 34xx prefix - that should be killed -yep.
> >>
> >
> > omap34xx_sr1, omap34xx_sr2, omap34xx_srlist... seem to be quite OMAP34xx
> specifics...
> >
> please read the code carefully next time, look at how it is copied based
> on cpu_is_ api in in __init??
I did, and... My opinion is that smartreflex.c should contain the code for the
smartreflex IP... that's all. The omap34xx implementation with two SR IP is SoC
specific. And the next time, I will still think the same.
> yes, there are specific paramaters to SOC, you cannot avoid that. but
> you can make the handling independent of the SOC. that is what I have
> done.. let me know if you have a better idea.. :D..
I think I already did. Please read again.
> >
> >>> - If we want to go further, I think that the VP/VC code should not be
> in
> >>>
> >> SR code either. It is located in the PRM, and can be used independently
> of
> >> SR.
> >>
> >>> - In a SR class 2 mode, the smartreflex driver will not use the
> direct
> >>> connection to the VP.
> >>> - If we don't want SR we can still use the VP/VC for device voltage
> >>> control.
> >>>
> >>>
> >> - How about adding - Smart reflex should actually fit in a
> >> voltage control
[PATCH 2/4] RX51: SDRAM: Cleanup the init code
From: Tero Kristo
Removed a few unused functions + macro definitions + variables from the code.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/board-rx51-sdram.c | 51
1 files changed, 0 insertions(+), 51 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-sdram.c
b/arch/arm/mach-omap2/board-rx51-sdram.c
index 78cd5ed..b5d1c55 100644
--- a/arch/arm/mach-omap2/board-rx51-sdram.c
+++ b/arch/arm/mach-omap2/board-rx51-sdram.c
@@ -67,57 +67,6 @@ static const struct sdram_info rx51_info = {
.row_lines = 13,
};
-#define CM_BASE0x48004000
-
-#define CM_CLKSEL_CORE 0x0a40
-#define CM_CLKSEL1_PLL 0x0d40
-
-#define PRM_CLKSEL 0x48306d40
-#define PRM_CLKSRC_CTRL 0x48307270
-
-static u32 cm_base = CM_BASE;
-
-static inline u32 cm_read_reg(int idx)
-{
- return *(u32 *)OMAP2_L4_IO_ADDRESS(cm_base + idx);
-}
-
-static const unsigned long sys_clk_rate_table[] = {
- 12000, 13000, 19200, 26000, 38400, 16800
-};
-
-static unsigned long get_sys_clk_rate(void)
-{
- unsigned long rate;
-
- rate = sys_clk_rate_table[*(u32 *)OMAP2_L4_IO_ADDRESS(PRM_CLKSEL) &
0x07];
- if (((*(u32 *)OMAP2_L4_IO_ADDRESS(PRM_CLKSRC_CTRL) >> 6) & 0x03) ==
0x02)
- rate /= 2;
- return rate;
-}
-
-static unsigned long get_core_rate(void)
-{
- unsigned long rate;
- u32 l;
-
- l = cm_read_reg(CM_CLKSEL1_PLL);
- rate = get_sys_clk_rate();
- rate *= ((l >> 16) & 0x7ff);
- rate /= ((l >> 8) & 0x7f) + 1;
- rate /= (l >> 27) & 0x1f;
-
- return rate;
-}
-
-static unsigned long get_l3_rate(void)
-{
- u32 l;
-
- l = cm_read_reg(CM_CLKSEL_CORE);
- return get_core_rate() / (l & 0x03);
-}
-
static unsigned long sdrc_get_fclk_period(long rate)
{
/* In picoseconds */
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] RX51: SDRC: change timing values to follow generic memory requirements
From: Onkalo Samu.P
Current memory parameters are slightly off-spec. Also, a couple of unused
functions removed from code.
Signed-off-by: Samu Onkalo
---
arch/arm/mach-omap2/board-rx51-sdram.c | 130 ++--
1 files changed, 91 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-sdram.c
b/arch/arm/mach-omap2/board-rx51-sdram.c
index b5d1c55..237b898 100644
--- a/arch/arm/mach-omap2/board-rx51-sdram.c
+++ b/arch/arm/mach-omap2/board-rx51-sdram.c
@@ -1,5 +1,5 @@
/*
- * SDRC register values for the Samsung K4X1G323PC
+ * SDRC register values for RX51
*
* Copyright (C) 2008 Nokia Corporation
*
@@ -23,7 +23,7 @@
#include
-/* In picoseconds, except for tREF */
+/* In picoseconds, except for tREF (ns), tXP, tCKE, tWTR (clks) */
struct sdram_timings {
u32 casl;
u32 tDAL;
@@ -36,7 +36,11 @@ struct sdram_timings {
u32 tRFC;
u32 tXSR;
- u32 tREF; /* in ms */
+ u32 tREF; /* in ns */
+
+ u32 tXP;
+ u32 tCKE;
+ u32 tWTR;
};
struct sdram_info {
@@ -49,22 +53,22 @@ struct omap_sdrc_params rx51_sdrc_params[4];
static const struct sdram_timings rx51_timings[] = {
{
.casl = 3,
- .tDAL = 15000 + 18000,
+ .tDAL = 33000,
.tDPL = 15000,
.tRRD = 12000,
- .tRCD = 18000,
+ .tRCD = 22500,
.tRP = 18000,
.tRAS = 42000,
.tRC = 66000,
- .tRFC = 97500,
- .tXSR = 12,
+ .tRFC = 138000,
+ .tXSR = 20,
- .tREF = 64,
- },
-};
+ .tREF = 7800,
-static const struct sdram_info rx51_info = {
- .row_lines = 13,
+ .tXP = 2,
+ .tCKE = 2,
+ .tWTR = 2
+ },
};
static unsigned long sdrc_get_fclk_period(long rate)
@@ -85,18 +89,14 @@ static unsigned int sdrc_ps_to_ticks(unsigned int time_ps,
long rate)
#undef DEBUG
#ifdef DEBUG
static int set_sdrc_timing_regval(u32 *regval, int st_bit, int end_bit,
- int time, long rate, const char *name)
+ int ticks, long rate, const char *name)
#else
static int set_sdrc_timing_regval(u32 *regval, int st_bit, int end_bit,
- int time, long rate)
+ int ticks)
#endif
{
- int ticks, mask, nr_bits;
+ int mask, nr_bits;
- if (time == 0)
- ticks = 0;
- else
- ticks = sdrc_ps_to_ticks(time, rate);
nr_bits = end_bit - st_bit + 1;
if (ticks >= 1 << nr_bits)
return -1;
@@ -104,7 +104,7 @@ static int set_sdrc_timing_regval(u32 *regval, int st_bit,
int end_bit,
*regval &= ~(mask << st_bit);
*regval |= ticks << st_bit;
#ifdef DEBUG
- printk("SDRC %s: %i ticks %i ns\n", name, ticks,
+ printk(KERN_INFO "SDRC %s: %i ticks %i ns\n", name, ticks,
(unsigned int)sdrc_get_fclk_period(rate) * ticks /
1000);
#endif
@@ -113,46 +113,98 @@ static int set_sdrc_timing_regval(u32 *regval, int
st_bit, int end_bit,
}
#ifdef DEBUG
-#define SDRC_SET_ONE(reg, st, end, field, rate) \
- if (set_sdrc_timing_regval((reg), (st), (end), \
+#define SDRC_SET_ONE(reg, st, end, field, rate)
\
+ if (set_sdrc_timing_regval((reg), (st), (end),\
rx51_timings->field, (rate), #field) < 0) \
err = -1;
#else
-#define SDRC_SET_ONE(reg, st, end, field, rate) \
- if (set_sdrc_timing_regval((reg), (st), (end), \
- rx51_timings->field, (rate)) < 0) \
+#define SDRC_SET_ONE(reg, st, end, field, rate)
\
+ if (set_sdrc_timing_regval((reg), (st), (end), \
+ rx51_timings->field, (rate)) < 0) \
+ err = -1;
+#endif
+
+#ifdef DEBUG
+static int set_sdrc_timing_regval_ps(u32 *regval, int st_bit, int end_bit,
+ int time, long rate, const char *name)
+#else
+static int set_sdrc_timing_regval_ps(u32 *regval, int st_bit, int end_bit,
+ int time, long rate)
+#endif
+{
+ int ticks, ret;
+ ret = 0;
+
+ if (time == 0)
+ ticks = 0;
+ else
+ ticks = sdrc_ps_to_ticks(time, rate);
+
+#ifdef DEBUG
+ ret = set_sdrc_timing_regval(regval, st_bit, end_bit, ticks,
+rate, name);
+#else
+ ret = set_sdrc_timing_regval(regval, st_bit, end_bit, ticks);
+#endif
+
+ return ret;
+}
+
+#ifdef DEBUG
+#define SDRC_SET_ONE_PS(reg, st, end, field, rate) \
+ if (set_sdrc_timing_regval_ps((reg), (st), (end), \
+
[PATCH 0/4] RX51: SDRAM settings changes
From: Tero Kristo Following patch set fixes a few issues with current RX51 board SDRAM settings. Applies on top of PM branch. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] RX51: Add SDRAM configs for different OPPs
From: Tero Kristo
This modification is needed by DVFS.
Signed-off-by: Tero Kristo
Signed-off-by: Jouni Hogander
---
arch/arm/mach-omap2/board-rx51-sdram.c | 84 ++--
1 files changed, 47 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-sdram.c
b/arch/arm/mach-omap2/board-rx51-sdram.c
index 6f1f33c..78cd5ed 100644
--- a/arch/arm/mach-omap2/board-rx51-sdram.c
+++ b/arch/arm/mach-omap2/board-rx51-sdram.c
@@ -44,7 +44,7 @@ struct sdram_info {
};
-struct omap_sdrc_params rx51_sdrc_params[2];
+struct omap_sdrc_params rx51_sdrc_params[4];
static const struct sdram_timings rx51_timings[] = {
{
@@ -118,30 +118,28 @@ static unsigned long get_l3_rate(void)
return get_core_rate() / (l & 0x03);
}
-
-
-static unsigned long sdrc_get_fclk_period(void)
+static unsigned long sdrc_get_fclk_period(long rate)
{
/* In picoseconds */
- return 10 / get_l3_rate();
+ return 10 / rate;
}
-static unsigned int sdrc_ps_to_ticks(unsigned int time_ps)
+static unsigned int sdrc_ps_to_ticks(unsigned int time_ps, long rate)
{
unsigned long tick_ps;
/* Calculate in picosecs to yield more exact results */
- tick_ps = sdrc_get_fclk_period();
+ tick_ps = sdrc_get_fclk_period(rate);
return (time_ps + tick_ps - 1) / tick_ps;
}
#undef DEBUG
#ifdef DEBUG
static int set_sdrc_timing_regval(u32 *regval, int st_bit, int end_bit,
- int time, const char *name)
+ int time, long rate, const char *name)
#else
static int set_sdrc_timing_regval(u32 *regval, int st_bit, int end_bit,
- int time)
+ int time, long rate)
#endif
{
int ticks, mask, nr_bits;
@@ -149,7 +147,7 @@ static int set_sdrc_timing_regval(u32 *regval, int st_bit,
int end_bit,
if (time == 0)
ticks = 0;
else
- ticks = sdrc_ps_to_ticks(time);
+ ticks = sdrc_ps_to_ticks(time, rate);
nr_bits = end_bit - st_bit + 1;
if (ticks >= 1 << nr_bits)
return -1;
@@ -158,42 +156,46 @@ static int set_sdrc_timing_regval(u32 *regval, int
st_bit, int end_bit,
*regval |= ticks << st_bit;
#ifdef DEBUG
printk("SDRC %s: %i ticks %i ns\n", name, ticks,
- (unsigned int)sdrc_get_fclk_period() * ticks / 1000);
+ (unsigned int)sdrc_get_fclk_period(rate) * ticks /
+ 1000);
#endif
return 0;
}
#ifdef DEBUG
-#define SDRC_SET_ONE(reg, st, end, field) \
- if (set_sdrc_timing_regval((reg), (st), (end), rx51_timings->field,
#field) < 0) \
- err = -1
+#define SDRC_SET_ONE(reg, st, end, field, rate) \
+ if (set_sdrc_timing_regval((reg), (st), (end), \
+ rx51_timings->field, (rate), #field) < 0) \
+ err = -1;
#else
-#define SDRC_SET_ONE(reg, st, end, field) \
- if (set_sdrc_timing_regval((reg), (st), (end), rx51_timings->field) <
0) \
- err = -1
+#define SDRC_SET_ONE(reg, st, end, field, rate) \
+ if (set_sdrc_timing_regval((reg), (st), (end), \
+ rx51_timings->field, (rate)) < 0) \
+ err = -1;
#endif
-struct omap_sdrc_params *rx51_get_sdram_timings(void)
+static int sdrc_timings(int id, long rate)
{
u32 ticks_per_ms;
u32 rfr, l;
- u32 actim_ctrla, actim_ctrlb;
+ u32 actim_ctrla = 0, actim_ctrlb = 0;
u32 rfr_ctrl;
int err = 0;
+ long l3_rate = rate / 1000;
- SDRC_SET_ONE(&actim_ctrla, 0, 4, tDAL);
- SDRC_SET_ONE(&actim_ctrla, 6, 8, tDPL);
- SDRC_SET_ONE(&actim_ctrla, 9, 11, tRRD);
- SDRC_SET_ONE(&actim_ctrla, 12, 14, tRCD);
- SDRC_SET_ONE(&actim_ctrla, 15, 17, tRP);
- SDRC_SET_ONE(&actim_ctrla, 18, 21, tRAS);
- SDRC_SET_ONE(&actim_ctrla, 22, 26, tRC);
- SDRC_SET_ONE(&actim_ctrla, 27, 31, tRFC);
+ SDRC_SET_ONE(&actim_ctrla, 0, 4, tDAL, l3_rate);
+ SDRC_SET_ONE(&actim_ctrla, 6, 8, tDPL, l3_rate);
+ SDRC_SET_ONE(&actim_ctrla, 9, 11, tRRD, l3_rate);
+ SDRC_SET_ONE(&actim_ctrla, 12, 14, tRCD, l3_rate);
+ SDRC_SET_ONE(&actim_ctrla, 15, 17, tRP, l3_rate);
+ SDRC_SET_ONE(&actim_ctrla, 18, 21, tRAS, l3_rate);
+ SDRC_SET_ONE(&actim_ctrla, 22, 26, tRC, l3_rate);
+ SDRC_SET_ONE(&actim_ctrla, 27, 31, tRFC, l3_rate);
- SDRC_SET_ONE(&actim_ctrlb, 0, 7, tXSR);
+ SDRC_SET_ONE(&actim_ctrlb, 0, 7, tXSR, l3_rate);
- ticks_per_ms = sdrc_ps_to_ticks(10);
+ ticks_per_ms = sdrc_ps_to_ticks(10, l3_rate);
rfr = rx51_timings[0].tREF * ticks_per_ms / (1 << rx51_info.row_lines);
if (rfr > 65535 + 50)
rfr = 65535;
@@ -203,16 +205,24 @@ struct omap_sdrc_params *rx51_get_sdram_timings(void)
l =
[PATCH 4/4] RX51: Fix SDRAM RFR timings calculation
From: Kalle Jokiniemi
sdrc_ps_to_ticks introduced some unnecessary
rounding error to SDRC_RFR value calculation.
Fixed by adding 10^3 more accuracy before
division and skipping the sdrc_ps_to_ticks call.
Problem-reported-by: Jukka S. Laitinen
Signed-off-by: Kalle Jokiniemi
---
arch/arm/mach-omap2/board-rx51-sdram.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-sdram.c
b/arch/arm/mach-omap2/board-rx51-sdram.c
index 237b898..f3b9917 100644
--- a/arch/arm/mach-omap2/board-rx51-sdram.c
+++ b/arch/arm/mach-omap2/board-rx51-sdram.c
@@ -166,7 +166,7 @@ static int set_sdrc_timing_regval_ps(u32 *regval, int
st_bit, int end_bit,
static int sdrc_timings(int id, long rate)
{
- u32 ticks_per_us;
+ u32 ticks_per_ms;
u32 rfr, l;
u32 actim_ctrla = 0, actim_ctrlb = 0;
u32 rfr_ctrl;
@@ -192,8 +192,8 @@ static int sdrc_timings(int id, long rate)
SDRC_SET_ONE(&actim_ctrlb, 12, 14, tCKE, l3_rate);
SDRC_SET_ONE(&actim_ctrlb, 16, 17, tWTR, l3_rate);
- ticks_per_us = sdrc_ps_to_ticks(100, l3_rate);
- rfr = rx51_timings[0].tREF * ticks_per_us / 1000;
+ ticks_per_ms = l3_rate;
+ rfr = rx51_timings[0].tREF * ticks_per_ms / 100;
if (rfr > 65535 + 50)
rfr = 65535;
else
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 24xx/n8x0 booting again, linux-omap updated to -rc5
Tony Lindgren wrote at 2009-10-21 12:40 -0600: > Well I got took a quick look at it last night to get the LCD working again.. > > I just pushed one fix into omap-fixes, fixed the drivers/cbus compile, updated > the board-n8x0.c for LCD. And then still needed one more hack to skip the LCD > detection.. The current linux-omap master should work with the two attached > patches and the Kconfig I used. Only tested on n810, no idea if the LCD > detection > hack also works on n800. > > Anyways, hopefully that will get you going, I don't know when I'll have > a chance to play with that sfuff again :) It does boot now, using the config you sent. When it boots, and is waiting for the root device (which doesn't exist), I see messages about every 5 seconds like this: lcd_mipid spi1.1: performing LCD ESD recovery > I also pushed the earlier changes for retu wdt to the cbus branch so the > boards keep running by default. Excellent. I appreciate your work (and others here). I am hoping to run Debian, with mainline Linux, on the n810 someday and wish I was able to contribute more myself, though that isn't possible now with almost no knowledge of C and not enough time to learn. So for now I just try to keep up with it somewhat and note here when things don't work in case someone who can fix it is unaware. signature.asc Description: Digital signature
Re: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
Trying not to top post.. Apologies before hand on my client restrictions. Anyways.. Manjunath, Yes, the call sequences are common. We may consider using cpu_relax() in the context of dvfs calls.. Except it could result in race connditions not in intrest. Do me a favor and flag the udelays u'd like to convert and send a patch for fix pls. Regards, Nishanth Menon - Original Message - From: G, Manjunath Kondaiah To: Menon, Nishanth; linux-omap@vger.kernel.org Cc: Imberton Guilhem ; Mike Chan ; Nayak, Rajendra; Roger Quadros ; Kalle Jokiniemi ; Reddy, Teerth; Kevin Hilman ; Paul Walmsley ; Hogander Jouni Sent: Mon Oct 26 10:09:07 2009 Subject: RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0 > -Original Message- > From: Menon, Nishanth > Sent: Monday, October 26, 2009 3:48 PM > To: G, Manjunath Kondaiah; linux-omap@vger.kernel.org > Cc: Imberton Guilhem; Mike Chan; Nayak, Rajendra; Roger > Quadros; Kalle Jokiniemi; Reddy, Teerth; Kevin Hilman; Paul > Walmsley; Hogander Jouni > Subject: RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0 > > > -Original Message- > > From: G, Manjunath Kondaiah > > Sent: Monday, October 26, 2009 3:40 AM > > To: Menon, Nishanth; linux-omap@vger.kernel.org > > Cc: Imberton Guilhem; Mike Chan; Nayak, Rajendra; Roger > Quadros; Kalle > > Jokiniemi; Reddy, Teerth; Kevin Hilman; Paul Walmsley; > Hogander Jouni > > Subject: RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex > Refactor Rev4.0 > > > > > > As per your comments for other patches when ever there is > udelay usage, > > cpu_relax is the better option. I see there are lot of > udelay(...) calls > > used in this patch. Why can't you use cpu_relax() or schedule(). > > Any specific reason? > > > Don’t really want to do cpu_relax in irq_locked context.. if > you look at the code flow, the call from cpu_idle is in > irq_locked.. Further this delay is part of bring up form > saved context where there is nothing else scheduled + we > don’t want anything else scheduled (and causing a change in > scheduling decision). So unfortunately, unlike standard > drivers, this cannot use the same reasoning. > NAK. My understanding is that, SR functions will be called during voltage scaling also. Voltage scaling will happen in non IRQ locked context. Please clarify if I am wrong. -Manjunath
RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
> -Original Message- > From: Menon, Nishanth > Sent: Monday, October 26, 2009 3:48 PM > To: G, Manjunath Kondaiah; linux-omap@vger.kernel.org > Cc: Imberton Guilhem; Mike Chan; Nayak, Rajendra; Roger > Quadros; Kalle Jokiniemi; Reddy, Teerth; Kevin Hilman; Paul > Walmsley; Hogander Jouni > Subject: RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0 > > > -Original Message- > > From: G, Manjunath Kondaiah > > Sent: Monday, October 26, 2009 3:40 AM > > To: Menon, Nishanth; linux-omap@vger.kernel.org > > Cc: Imberton Guilhem; Mike Chan; Nayak, Rajendra; Roger > Quadros; Kalle > > Jokiniemi; Reddy, Teerth; Kevin Hilman; Paul Walmsley; > Hogander Jouni > > Subject: RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex > Refactor Rev4.0 > > > > > > As per your comments for other patches when ever there is > udelay usage, > > cpu_relax is the better option. I see there are lot of > udelay(...) calls > > used in this patch. Why can't you use cpu_relax() or schedule(). > > Any specific reason? > > > Don’t really want to do cpu_relax in irq_locked context.. if > you look at the code flow, the call from cpu_idle is in > irq_locked.. Further this delay is part of bring up form > saved context where there is nothing else scheduled + we > don’t want anything else scheduled (and causing a change in > scheduling decision). So unfortunately, unlike standard > drivers, this cannot use the same reasoning. > NAK. My understanding is that, SR functions will be called during voltage scaling also. Voltage scaling will happen in non IRQ locked context. Please clarify if I am wrong. -Manjunath
RE: [PATCH 1/2] Added board-3630.c file.
> +static int __init omap_i2c_init(void)
> +{
> + omap_register_i2c_bus(1, 2600, sdp3630_i2c_boardinfo,
> + ARRAY_SIZE(sdp3630_i2c_boardinfo));
> + omap_register_i2c_bus(2, 400, NULL, 0);
> + omap_register_i2c_bus(3, 400, NULL, 0);
> + return 0;
> +}
If sdp3630 board is using TWL5030/GAIA, then you need to reduce I2C speed.
http://patchwork.kernel.org/patch/52760/
-Manjunath--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP3: Cpuidle fixes
From: Tero Kristo Following patches apply on top of PM branch. They implement a couple of small fixes for cpuidle. Timer resolution patch probably does not change anything until kernel cpuidle is fixed to support longer timers (there are some pending patches for this.) -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP3: PM: Check BM for C2 state
From: De-Schrijver Peter C2 can't be entered while we have bus activity. Signed-off-by: Peter 'p2' De Schrijver --- arch/arm/mach-omap2/cpuidle34xx.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index c44a942..a0d9f56 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -38,7 +38,7 @@ #define OMAP3_MAX_STATES 7 #define OMAP3_STATE_C1 0 /* C1 - MPU WFI + Core active */ -#define OMAP3_STATE_C2 1 /* C2 - MPU WFI + Core inactive */ +#define OMAP3_STATE_C2 1 /* C2 - MPU inactive + Core inactive */ #define OMAP3_STATE_C3 2 /* C3 - MPU CSWR + Core inactive */ #define OMAP3_STATE_C4 3 /* C4 - MPU OFF + Core iactive */ #define OMAP3_STATE_C5 4 /* C5 - MPU RET + Core RET */ @@ -169,7 +169,7 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev); * * Below is the desciption of each C state. * C1 . MPU WFI + Core active - * C2 . MPU WFI + Core inactive + * C2 . MPU inactive + Core inactive * C3 . MPU CSWR + Core inactive * C4 . MPU OFF + Core inactive * C5 . MPU CSWR + Core CSWR @@ -196,7 +196,8 @@ void omap_init_power_states(void) omap3_power_states[OMAP3_STATE_C2].threshold = 30; omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON; omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON; - omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID; + omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID | + CPUIDLE_FLAG_CHECK_BM; /* C3 . MPU CSWR + Core inactive */ omap3_power_states[OMAP3_STATE_C3].valid = 1; -- 1.5.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP3: CPUidle: Fixed timer resolution
From: Tero Kristo Previously used u32 as temporary data storage that wraps around at 4.294s. Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/cpuidle34xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index a0d9f56..0ac3b63 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -137,7 +137,7 @@ return_sleep_time: local_irq_enable(); local_fiq_enable(); - return (u32)timespec_to_ns(&ts_idle)/1000; + return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC; } /** -- 1.5.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
Benoit,
thanks.. overall good discussion that is nice to take in.. more comments
follow:
Cousson, Benoit said the following on 10/26/2009 08:05 AM:
>> From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
>>
>> Cousson, Benoit said the following on 10/25/2009 05:12 PM:
>>
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
>> [...]
>>
+ },
+ /* *INDENT-ON* */
+};
+
+/* SR list for 3430 */
+static __initdata struct omap_sr_list omap34xx_srlist = {
+ .num_sr = 2,
+ .sr_list = {&omap34xx_sr1, &omap34xx_sr2}
+};
+
+/* The final SR list */
+static struct omap_sr_list *omap_srlist;
>>> I have a couple a suggestions regarding the code partitioning:
>>>
>>> - SmartReflex is one IP with several instances; it means that only the
>>>
>> base address will change between SR1 and SR2. There is no need to
>> duplicate the mask and shift defines per SR.
>>
>> might have been easier with a standard OCP wrapper and standard
>> INT/INTSTATUS regs for SR instead of the current integration but
>> yeah, I had been thinking of that- if O4/beyond could have the same IP
>> wrapped in a different register mapping, i should handle it then, not
>> dream about it now.. I get your point here.. there are a few places we
>> can kick it out and some places your are stuck with them!
>>
>
> SR is a regular IP, with a dedicated PD, dedicated fclk and bound to the L4...
> VP/VC is not, that why I was proposing to separated them.
>
I am not denying it, but VP/VC functions are already separated out where
I could do it (note the seperation of function names), only they dont
have a new file perse.. but that is not needed at the moment.
>
>>> Moreover, SR being an IP, I think we can encode the one IP / several
>>>
>> instance in a platform_device / platform_driver code. It will allow the
>> support of several drivers for the same devices in order to implement for
>> example class3, class2 or class1 drivers. SR can even be represented by an
>> HWMOD.
>>
>> what is your intention in misusing platform_device for a SOC specific
>> code? I think you have an idea here that I am completely missing. can
>> you care to elaborate?
>>
>
> AFAIK, platform_device is there in order to deal with SoC devices???
> Considering that SR is an IP that can be in several SoC, it looks to me the
> perfect candidate for platform_device/platform_driver.
> Am I missing something?
>
Everything abstracted is a perfect candidate for device-driver model,
but that is beside the point. platform_device traditionally has been
platform aka board specific info, not SOC specific info..
>
>>> - The smartreflex.c file contains 34xx specifics code; it should not be
>>>
>> there, only SR specific code should be there.
>>
>> read the TODO. which specific 3430 code does it have? other than using
>> macros which have 34xx prefix - that should be killed -yep.
>>
>
> omap34xx_sr1, omap34xx_sr2, omap34xx_srlist... seem to be quite OMAP34xx
> specifics...
>
please read the code carefully next time, look at how it is copied based
on cpu_is_ api in in __init??
yes, there are specific paramaters to SOC, you cannot avoid that. but
you can make the handling independent of the SOC. that is what I have
done.. let me know if you have a better idea.. :D..
>
>>> - If we want to go further, I think that the VP/VC code should not be in
>>>
>> SR code either. It is located in the PRM, and can be used independently of
>> SR.
>>
>>> - In a SR class 2 mode, the smartreflex driver will not use the direct
>>> connection to the VP.
>>> - If we don't want SR we can still use the VP/VC for device voltage
>>> control.
>>>
>>>
>> - How about adding - Smart reflex should actually fit in a
>> voltage control infrastructure so that the system can manipulate and set
>> voltage with and without SR..
>>
>
> Fully agree, that was one of the proposals I had in mind, but since it will
> require some more works, it should be done in a second pass.
>
>
>> that is what is really missing in our code base today -> SR and VP comes
>> plugged in close as buddies in all silicons, so if your recommendation
>> has an silicon example where OMAP SR talks not to VP, let me know and I
>> will second splitting the code :D. till then sorry.. you dont have a case.
>>
>
> We had the case in several chips that unfortunately are not there anymore
> :-(
> The SR IP was done to handle several config, having SR tied to VP/VC is a
> chip dependant implementation.
>
lets bring in a proper voltage control infrastructure then worry about
SR class2/class3 implementation. class2 is inferior to class 3 and the
overhead of cpu intervention should be balanced with a proper latency
heuristics, the infrastructure is sadly missing at this point of time..
>
>> now, it is a differe
RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
> From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
>
> Cousson, Benoit said the following on 10/25/2009 05:12 PM:
> >> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
> >>
> [...]
> >> + },
> >> + /* *INDENT-ON* */
> >> +};
> >> +
> >> +/* SR list for 3430 */
> >> +static __initdata struct omap_sr_list omap34xx_srlist = {
> >> + .num_sr = 2,
> >> + .sr_list = {&omap34xx_sr1, &omap34xx_sr2}
> >> +};
> >> +
> >> +/* The final SR list */
> >> +static struct omap_sr_list *omap_srlist;
> >>
> >
> > I have a couple a suggestions regarding the code partitioning:
> >
> > - SmartReflex is one IP with several instances; it means that only the
> base address will change between SR1 and SR2. There is no need to
> duplicate the mask and shift defines per SR.
> >
> might have been easier with a standard OCP wrapper and standard
> INT/INTSTATUS regs for SR instead of the current integration but
> yeah, I had been thinking of that- if O4/beyond could have the same IP
> wrapped in a different register mapping, i should handle it then, not
> dream about it now.. I get your point here.. there are a few places we
> can kick it out and some places your are stuck with them!
SR is a regular IP, with a dedicated PD, dedicated fclk and bound to the L4...
VP/VC is not, that why I was proposing to separated them.
> > Moreover, SR being an IP, I think we can encode the one IP / several
> instance in a platform_device / platform_driver code. It will allow the
> support of several drivers for the same devices in order to implement for
> example class3, class2 or class1 drivers. SR can even be represented by an
> HWMOD.
> >
> what is your intention in misusing platform_device for a SOC specific
> code? I think you have an idea here that I am completely missing. can
> you care to elaborate?
AFAIK, platform_device is there in order to deal with SoC devices???
Considering that SR is an IP that can be in several SoC, it looks to me the
perfect candidate for platform_device/platform_driver.
Am I missing something?
> > - The smartreflex.c file contains 34xx specifics code; it should not be
> there, only SR specific code should be there.
> >
> read the TODO. which specific 3430 code does it have? other than using
> macros which have 34xx prefix - that should be killed -yep.
omap34xx_sr1, omap34xx_sr2, omap34xx_srlist... seem to be quite OMAP34xx
specifics...
> > - If we want to go further, I think that the VP/VC code should not be in
> SR code either. It is located in the PRM, and can be used independently of
> SR.
> > - In a SR class 2 mode, the smartreflex driver will not use the direct
> > connection to the VP.
> > - If we don't want SR we can still use the VP/VC for device voltage
> > control.
> >
> - How about adding - Smart reflex should actually fit in a
> voltage control infrastructure so that the system can manipulate and set
> voltage with and without SR..
Fully agree, that was one of the proposals I had in mind, but since it will
require some more works, it should be done in a second pass.
> that is what is really missing in our code base today -> SR and VP comes
> plugged in close as buddies in all silicons, so if your recommendation
> has an silicon example where OMAP SR talks not to VP, let me know and I
> will second splitting the code :D. till then sorry.. you dont have a case.
We had the case in several chips that unfortunately are not there anymore
:-(
The SR IP was done to handle several config, having SR tied to VP/VC is a chip
dependant implementation.
> now, it is a different case where you want to use SR as a pure
> monitoring engine -> that is not an implementation that is exactly
> better than class 3 operation.. why support it at all?
It is not a matter or being better, it is just having HW vs. SW implementation.
The point is Class 3 is not usable with non SR compliant power IC. In that case
you should rely on a Class 2 implementation.
> > [snip]
> >
> >
> >> +/** PMIC WEAK FUNCTIONS FOR TWL4030 derivatives
> >> **/
> >> +
> >> +/**
> >> + * @brief pmic_srinit - Power management IC initialization
> >> + * for smart reflex. The current code is written for TWL4030
> >> + * derivatives, replace in board file if PMIC requires
> >> + * a different sequence
> >> + *
> >> + * @return result of operation
> >> + */
> >> +int __weak __init omap_pmic_srinit(void)
> >> +{
> >> + int ret = -ENODEV;
> >> +#ifdef CONFIG_TWL4030_CORE
> >> + u8 reg;
> >> + /* Enable SR on T2 */
> >> + ret = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, ®,
> >> + R_DCDC_GLOBAL_CFG);
> >> +
> >> + reg |= DCDC_GLOBAL_CFG_ENABLE_SRFLX;
> >> + ret |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, reg,
> >> + R_DCDC_GLOBAL_CFG);
> >> +#endif /* End of CONFIG_TWL4030_CORE */
> >> + return ret;
> >> +}
> >> +
> >> +/**
> >> + *
[PATCH 4/4] OMAP: 3430SDP: Enable NAND in defconfig
>From 7f9c36fb821c2a836508be712e8247d6b283acfe Mon Sep 17 00:00:00 2001 From: Vimal Singh Date: Mon, 26 Oct 2009 17:23:57 +0530 Subject: [PATCH] OMAP: 3430SDP: Enable NAND in defconfig Enable NAND options by default in 3430sdp_defconfig file Other changes in defconfig come from make menuconfig syncup Signed-off-by: Vimal Singh --- arch/arm/configs/omap_3430sdp_defconfig | 574 ++- 1 files changed, 261 insertions(+), 313 deletions(-) diff --git a/arch/arm/configs/omap_3430sdp_defconfig b/arch/arm/configs/omap_3430sdp_defconfig index 8a4a7e2..26abfe4 100644 --- a/arch/arm/configs/omap_3430sdp_defconfig +++ b/arch/arm/configs/omap_3430sdp_defconfig @@ -1,15 +1,13 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-omap1 -# Tue Jun 23 10:36:45 2009 +# Linux kernel version: 2.6.32-rc5 +# Mon Oct 26 17:10:53 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y -CONFIG_MMU=y -# CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -18,14 +16,14 @@ CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_OPROFILE_ARMV7=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" +CONFIG_CONSTRUCTORS=y # # General setup @@ -47,11 +45,12 @@ CONFIG_BSD_PROCESS_ACCT=y # # RCU Subsystem # -CONFIG_CLASSIC_RCU=y -# CONFIG_TREE_RCU is not set -# CONFIG_PREEMPT_RCU is not set +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set -# CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 @@ -67,6 +66,9 @@ CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y @@ -88,6 +90,10 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set @@ -96,13 +102,18 @@ CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y -# CONFIG_MARKERS is not set CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_GCOV_KERNEL is not set +# CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y @@ -114,8 +125,7 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_BLOCK=y -CONFIG_LBD=y -# CONFIG_BLK_DEV_IO_TRACE is not set +CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -136,18 +146,22 @@ CONFIG_FREEZER=y # # System Type # +CONFIG_MMU=y # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set -# CONFIG_ARCH_IMX is not set +# CONFIG_ARCH_NOMADIK is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set @@ -156,24 +170,27 @@ CONFIG_FREEZER=y # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KIRKWOOD is not set -# CONFIG_ARCH_KS8695 is not set -# CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_LOKI is not set # CONFIG_ARCH_MV78XX0 is not set -# CONFIG_ARCH_MXC is not set # CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_MMP is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_W90X900 is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_MSM is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_S3C64XX is not set +# CONFIG_ARCH_S5PC1XX is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_U300 is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y -# CONFIG_ARCH_MSM is not set -# CONFIG_ARCH_W90X900 is not set +# CONFIG_ARCH_BCMRING is not set
[PATCH-v4 3/4] OMAP: Zoom2: Enable NAND and JFFS2 support in defconfig
>From d99d0bb2f2bf1d6a1b8197daf93634dc5a9fa16f Mon Sep 17 00:00:00 2001 From: Vimal Singh Date: Mon, 26 Oct 2009 16:56:16 +0530 Subject: [PATCH] OMAP: Zoom2: Enable NAND and JFFS2 support in defconfig Enable NAND and JFFS2 options by default in zoom2_defconfig file Other changes in defconfig come from make menuconfig syncup Signed-off-by: Vimal Singh --- arch/arm/configs/omap_zoom2_defconfig | 334 - 1 files changed, 244 insertions(+), 90 deletions(-) diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig index f1739fa..c441a58 100644 --- a/arch/arm/configs/omap_zoom2_defconfig +++ b/arch/arm/configs/omap_zoom2_defconfig @@ -1,15 +1,13 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-omap1 -# Fri Jun 12 17:25:46 2009 +# Linux kernel version: 2.6.32-rc5 +# Mon Oct 26 15:12:53 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y -CONFIG_MMU=y -# CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -18,13 +16,13 @@ CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" +CONFIG_CONSTRUCTORS=y # # General setup @@ -46,11 +44,12 @@ CONFIG_BSD_PROCESS_ACCT=y # # RCU Subsystem # -CONFIG_CLASSIC_RCU=y -# CONFIG_TREE_RCU is not set -# CONFIG_PREEMPT_RCU is not set +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set -# CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_GROUP_SCHED=y @@ -77,7 +76,6 @@ CONFIG_UID16=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y -# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y @@ -90,18 +88,25 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set -# CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# # CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y @@ -114,7 +119,7 @@ CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_BLOCK=y -# CONFIG_LBD is not set +CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -135,19 +140,22 @@ CONFIG_FREEZER=y # # System Type # +CONFIG_MMU=y # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set -# CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set -# CONFIG_ARCH_IMX is not set +# CONFIG_ARCH_NOMADIK is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set @@ -156,25 +164,27 @@ CONFIG_FREEZER=y # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KIRKWOOD is not set -# CONFIG_ARCH_KS8695 is not set -# CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_LOKI is not set # CONFIG_ARCH_MV78XX0 is not set -# CONFIG_ARCH_MXC is not set # CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_MMP is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_W90X900 is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set -# CONFIG_ARCH_MMP is not set +# CONFIG_ARCH_MSM is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_S3C64XX is not set +# CONFIG_ARCH_S5PC1XX is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_U300 is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y -# CONFIG_ARCH_MSM is not set -# CONFIG_ARCH_W90X900 is not set +# CONFIG_ARCH_BCMRING is not set # # TI OMAP Implementations @@ -203,20 +213,23 @@ CONFIG_OMAP_DM_TIMER=y # CONFIG_OMAP_LL_DEBUG_UART1 is not set # CONFIG_OMAP_LL_DEBUG_UART2 is not set
[PATCH-v4 2/4] OMAP3: Add support for NAND on ZOOM2/LDP boards
>From 76e86c500e247e231c975f0a5bf01e832bf460d6 Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Mon, 26 Oct 2009 14:25:26 +0530
Subject: [PATCH] OMAP3: Add support for NAND on ZOOM2/LDP boards
Adding NAND support for ZOOM2 and LDP board. I have tested it for ZOOM2 boards,
someone can verify it for LDP, hopefully it should not have any problem.
The size of the U-Boot environment partition was increased to 1.25MB.
Vikram: Changed ldp name to zoom.
Future boards will be called Zoom2/3/4 etc.
LDP is a Zoom1. Somhow the LDP name got stuck to that.
Signed-off-by: Vimal Singh
Signed-off-by: Vikram Pandita
---
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-ldp.c |2 +
arch/arm/mach-omap2/board-zoom-flash.c | 196 ++
arch/arm/mach-omap2/board-zoom2.c|2 +
arch/arm/plat-omap/include/plat/board-zoom.h | 36 +
arch/arm/plat-omap/include/plat/nand.h |2 +
6 files changed, 240 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
create mode 100644 arch/arm/plat-omap/include/plat/board-zoom.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 627f500..b3a9d1c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_MACH_OMAP_APOLLON) +=
board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
+ board-zoom-flash.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
mmc-twl4030.o
@@ -74,6 +75,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-peripherals.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+ board-zoom-flash.o \
mmc-twl4030.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index c062238..8aebdf9 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "mmc-twl4030.h"
@@ -385,6 +386,7 @@ static void __init omap_ldp_init(void)
ads7846_dev_init();
omap_serial_init();
usb_musb_init();
+ zoom_flash_init();
twl4030_mmc_init(mmc);
/* link regulators to MMC adapters */
diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
b/arch/arm/mach-omap2/board-zoom-flash.c
new file mode 100644
index 000..1406a57
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-flash.c
@@ -0,0 +1,196 @@
+/*
+ * arch/arm/mach-omap2/board-zoom-flash.c
+ *
+ * Copyright (C) 2008-09 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-2430sdp-flash.c
+ * Author(s): Rohit Choraria
+ *Vimal Singh
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define NAND_CMD_UNLOCK1 0x23
+#define NAND_CMD_UNLOCK2 0x24
+/**
+ * @brief platform specific unlock function
+ *
+ * @param mtd - mtd info
+ * @param ofs - offset to start unlock from
+ * @param len - length to unlock
+ *
+ * @return - unlock status
+ */
+static int omap_ldp_nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+{
+ int ret = 0;
+ int chipnr;
+ int status;
+ unsigned long page;
+ struct nand_chip *this = mtd->priv;
+ printk(KERN_INFO "nand_unlock: start: %08x, length: %d!\n",
+ (int)ofs, (int)len);
+
+ /* select the NAND device */
+ chipnr = (int)(ofs >> this->chip_shift);
+ this->select_chip(mtd, chipnr);
+ /* check the WP bit */
+ this->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+ if ((this->read_byte(mtd) & 0x80) == 0) {
+ printk(KERN_ERR "nand_unlock: Device is write protected!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if ((ofs & (mtd->writesize - 1)) != 0) {
+ printk(KERN_ERR "nand_unlock: Start address must be"
+ "beginning of nand page!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (len == 0 || (len & (mtd->writesize - 1)) != 0) {
+ printk(K
[PATCH-v4 1/4] OMAP2/3: Add support for flash on SDP boards
>From 92c416f513df62cc0ad75b61639df27f2857b641 Mon Sep 17 00:00:00 2001 From: Vimal Singh Date: Mon, 26 Oct 2009 14:24:18 +0530 Subject: [PATCH] OMAP2/3: Add support for flash on SDP boards Add support for flash on SDP boards. NAND, NOR and OneNAND are supported. Only tested on 3430SDP (ES2 and ES3.1), somebody please test on 2430SDP and check the chips select for 2430SDP. Also note that: For OneNAND: in the earlier 2430SDP code the kernel partition was set to only 1MB instead of 2MB on 3430SDP. If people want the old partition sizes back on 2430SDP, please provide a patch. For NAND: 'U-Boot', 'Boot Env' and 'Kernel' partitions sizes increased by few blocks to provide few spare blocks for NAND bab block management in u-boot. If people want old partition sizes, please provide a patch. Signed-off-by: Vimal Singh Cc: Tony Lindgren --- arch/arm/mach-omap2/Makefile|2 + arch/arm/mach-omap2/board-2430sdp.c |2 + arch/arm/mach-omap2/board-3430sdp.c |2 + arch/arm/mach-omap2/board-sdp-flash.c | 327 +++ arch/arm/plat-omap/include/plat/board-sdp.h | 15 ++ arch/arm/plat-omap/include/plat/gpmc.h |2 + 6 files changed, 350 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-sdp-flash.c create mode 100644 arch/arm/plat-omap/include/plat/board-sdp.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 03cb4fc..627f500 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_OMAP_IOMMU) += $(iommu-y) obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \ + board-sdp-flash.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ @@ -66,6 +67,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \ + board-sdp-flash.o \ mmc-twl4030.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index db9374b..5676ab9 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -38,6 +38,7 @@ #include #include +#include #include "mmc-twl4030.h" #define SDP2430_CS0_BASE 0x0400 @@ -205,6 +206,7 @@ static void __init omap_2430sdp_init(void) twl4030_mmc_init(mmc); usb_musb_init(); board_smc91x_init(); + sdp_flash_init(); /* Turn off secondary LCD backlight */ ret = gpio_request(SECONDARY_LCD_GPIO, "Secondary LCD backlight"); diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index a3c1271..4497ded 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -41,6 +41,7 @@ #include #include +#include #include "sdram-qimonda-hyb18m512160af-6.h" #include "mmc-twl4030.h" @@ -511,6 +512,7 @@ static void __init omap_3430sdp_init(void) omap_serial_init(); usb_musb_init(); board_smc91x_init(); + sdp_flash_init(); enable_board_wakeup_source(); usb_ehci_init(&ehci_pdata); } diff --git a/arch/arm/mach-omap2/board-sdp-flash.c b/arch/arm/mach-omap2/board-sdp-flash.c new file mode 100644 index 000..a19327d --- /dev/null +++ b/arch/arm/mach-omap2/board-sdp-flash.c @@ -0,0 +1,327 @@ +/* + * arch/arm/mach-omap2/board-sdp-flash.c + * + * Copyright (C) 2009 Nokia Corporation + * Copyright (C) 2007 Texas Instruments + * + * Modified from mach-omap2/board-3430sdp-flash.c + * Author: Vimal Singh + * + * 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 +#include +#include +#include +#include + +#include +#include +#include +#include + +#define REG_FPGA_REV 0x10 +#define REG_FPGA_DIP_SWITCH_INPUT2 0x60 +#define MAX_SUPPORTED_GPMC_CONFIG 3 + +/* various memory sizes */ +#define FLASH_SIZE_SDPV1 SZ_64M +#define FLASH_SIZE_SDPV2 SZ_128M + +#define FLASH_BASE_SDPV1 0x0400 /* NOR flash (64 Meg aligned) */ +#define FLASH_BASE_SDPV2 0x1000 /* NOR flash (256 Meg aligned) */ + +#define DEBUG_BASE 0x0800 /* debug board */ + +#define PDC_NOR1 +#define
[PATCH-v4 0/4] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards
I posted a patch series for this sometime back and did not get any respose.. :( http://marc.info/?l=linux-omap&m=125258227301958&w=2 This time again I am posting these patches, with one more patch added in series, after re-basing the patches on top of LO master head. This patch series adds flash support for NAND (in sdp, zoom2 and ldp), OneNAND and NOR (in sdp) Tested on Zoom2 by Vikram, On SDP by Vimal [PATCH-v4 1/4] OMAP2/3: Add support for flash on SDP boards [PATCH-v4 2/4] OMAP3: Add support for NAND on ZOOM2/LDP boards [PATCH-v4 3/4] OMAP: Zoom2: Enable NAND and JFFS2 support in defconfig [PATCH 4/4] OMAP: 3430SDP: Enable NAND in defconfig arch/arm/configs/omap_3430sdp_defconfig | 574 +++-- arch/arm/configs/omap_zoom2_defconfig| 334 ++ arch/arm/mach-omap2/Makefile |2 arch/arm/mach-omap2/board-2430sdp.c |2 arch/arm/mach-omap2/board-3430sdp.c |2 arch/arm/mach-omap2/board-ldp.c |2 arch/arm/mach-omap2/board-sdp-flash.c| 327 ++ arch/arm/mach-omap2/board-zoom-flash.c | 196 arch/arm/mach-omap2/board-zoom2.c|2 arch/arm/plat-omap/include/plat/board-sdp.h | 15 arch/arm/plat-omap/include/plat/board-zoom.h | 36 + arch/arm/plat-omap/include/plat/gpmc.h |2 arch/arm/plat-omap/include/plat/nand.h |2 14 files changed, 1095 insertions(+), 403 deletions(-) -- Regards, Vimal Singh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] Added board-3630.c file.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Monday, October 26, 2009 4:40 PM
To: Pais, Allen; linux-omap@vger.kernel.org
Subject: RE: [PATCH 1/2] Added board-3630.c file.
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Pais, Allen
> Sent: Monday, October 26, 2009 2:43 AM
> To: linux-omap@vger.kernel.org
> Subject: [PATCH 1/2] Added board-3630.c file.
>
> From 553ee2299d0ea6493e8587e7cc832361646f81a7 Mon Sep 17 00:00:00 2001
> From: Allen Pais
> Date: Mon, 26 Oct 2009 12:50:17 +0530
> Subject: [PATCH 1/2] Added board-3630.c file.
>
> The following sequence of patch set is to adds minimal OMAP3630 board
> support to OMAP GIT.
> This patch is tested on TI's OMAP3630 SDP.
>
> OMAP 3630 is an ARM Cortex A8 based Multimedia Application processor.
> For more information please visit:
> http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateI
> d=61
> 23&navigation
> Id=12836&contentId=52606
>
> Signed-off-by: Allen Pais
> ---
> arch/arm/mach-omap2/board-3630sdp.c | 188
> +++
> 1 files changed, 188 insertions(+), 0 deletions(-) create mode
> 100644 arch/arm/mach-omap2/board-3630sdp.c
>
> diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-
> omap2/board-3630sdp.c new file mode 100644 index 000..d3ddbd1
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-3630sdp.c
> @@ -0,0 +1,188 @@
> +/*
> + * linux/arch/arm/mach-omap2/board-3630sdp.c
> + * Copyright (C) 2007 Texas Instruments
2007 I don't recollect 3630 in 2007.
> + * Modified from mach-omap2/board-generic.c
> + * Initial code: Allen Pais
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include #include
> +#include #include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "mmc-twl4030.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +/* 3630SDP has Qwerty keyboard*/
> +static int board_keymap[] = {
> + KEY(0, 0, KEY_E),
> + KEY(1, 0, KEY_R),
> + KEY(2, 0, KEY_T),
> + KEY(3, 0, KEY_HOME),
> + KEY(6, 0, KEY_I),
> + KEY(7, 0, KEY_LEFTSHIFT),
> + KEY(0, 1, KEY_D),
> + KEY(1, 1, KEY_F),
> + KEY(2, 1, KEY_G),
> + KEY(3, 1, KEY_SEND),
> + KEY(6, 1, KEY_K),
> + KEY(7, 1, KEY_ENTER),
> + KEY(0, 2, KEY_X),
> + KEY(1, 2, KEY_C),
> + KEY(2, 2, KEY_V),
> + KEY(3, 2, KEY_END),
> + KEY(6, 2, KEY_DOT),
> + KEY(7, 2, KEY_CAPSLOCK),
> + KEY(0, 3, KEY_Z),
> + KEY(1, 3, KEY_KPPLUS),
> + KEY(2, 3, KEY_B),
> + KEY(3, 3, KEY_F1),
> + KEY(6, 3, KEY_O),
> + KEY(7, 3, KEY_SPACE),
> + KEY(0, 4, KEY_W),
> + KEY(1, 4, KEY_Y),
> + KEY(2, 4, KEY_U),
> + KEY(3, 4, KEY_F2),
> + KEY(4, 4, KEY_VOLUMEUP),
> + KEY(6, 4, KEY_L),
> + KEY(7, 4, KEY_LEFT),
> + KEY(0, 5, KEY_S),
> + KEY(1, 5, KEY_H),
> + KEY(2, 5, KEY_J),
> + KEY(3, 5, KEY_F3),
> + KEY(5, 5, KEY_VOLUMEDOWN),
> + KEY(6, 5, KEY_M),
> + KEY(4, 5, KEY_ENTER),
> + KEY(7, 5, KEY_RIGHT),
> + KEY(0, 6, KEY_Q),
> + KEY(1, 6, KEY_A),
> + KEY(2, 6, KEY_N),
> + KEY(3, 6, KEY_BACKSPACE),
> + KEY(6, 6, KEY_P),
> + KEY(7, 6, KEY_UP),
> + KEY(6, 7, KEY_SELECT),
> + KEY(7, 7, KEY_DOWN),
> + KEY(0, 7, KEY_PROG1), /*MACRO 1 */
> + KEY(1, 7, KEY_PROG2), /*MACRO 2 */
> + KEY(2, 7, KEY_PROG3), /*MACRO 3 */
> + KEY(3, 7, KEY_PROG4), /*MACRO 4 */
> + 0
> +};
NAK. Could we follow the same issue with zoom2 -> break the keypad into a
Separate one and use it instead? Same for all reused zoom2 components..
[Allen] Yes, we should do that. Not only for keypad but also
For display panel and touch screen so that sdp3630, zoom3 and
Zoom2 could use the same code, without having to duplicate
Code.
> +
> +static struct matrix_keymap_data board_map_data = {
> + .keymap = board_keymap,
> + .keymap_size= ARRAY_SIZE(board_keymap),
> +};
> +
> +static struct twl4030_keypad_data sdp3630_kp_twl4030_data = {
> + .keymap_data= &board_map_data,
> + .rows = 8,
> + .cols = 8,
> + .rep= 1,
> +};
> +
> +static struct omap_board_config_kernel sdp3630_config[] __initdata =
> +{ };
> +
> +
> +static int sdp3630_batt_table[] = {
> +/* 0 C*/
> +30800, 29500, 28300, 27100,
> +26000, 24900, 23900, 22900, 22000, 21100, 20300, 19400, 18700, 17900,
> +17200, 16500, 15900, 15300, 14700, 14100, 13600, 13100, 12600, 12100,
> +11600, 11200, 10800, 10400, 1, 9630, 9280, 8950, 8620, 8310,
> +8020, 7730, 7460, 7200, 6950, 6710, 6470, 6250, 6040, 5830,
RE: [PATCH] [OMAP] GPIO Module is reset during initialization
snippet- >> i guess cpu_relax() is better here. >> >> I guess cpu_relax is not required because this part of code is called >> only >> >> from >> >> board file during boot-up. Hence this would be the only code to be >> >> executed. >> What is your opinion on this? >Cpu_relax is still the better way of doing it. Please clarify why. >> >>>allows the kernel to do somethin else while we also ensure we have a 5 >> >>>usec guarenteed delay before giving up.. >> >> Doesn't modulo operation cost more in terms of performance? Any >> specific >> >> reason for specific 5 microseconds? >> >You could replace it with >> operator if you like and use 2^x multiples.. >> >I am just sticking 5 us there based on your original code.. >> >so the same logic over here I suppose.. unless I missed something? >> I was using attempts as 5, as my intension was to attempt only 5 times and >> not >> in terms of usec as I could not find any details in any document for >> maximum >> time for the bit to get set/reset. According to your code, it would >> attempt to read >> the register 25 times with a delay of 5 microseconds min during worst case >> scenario. >Please find the h/w timeout value and resubmit the patch.. As of now, I do not have any information on these details. Please share any details if you can. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] Added board-3630.c file.
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Pais, Allen
> Sent: Monday, October 26, 2009 2:43 AM
> To: linux-omap@vger.kernel.org
> Subject: [PATCH 1/2] Added board-3630.c file.
>
> From 553ee2299d0ea6493e8587e7cc832361646f81a7 Mon Sep 17 00:00:00 2001
> From: Allen Pais
> Date: Mon, 26 Oct 2009 12:50:17 +0530
> Subject: [PATCH 1/2] Added board-3630.c file.
>
> The following sequence of patch set is to adds minimal OMAP3630 board
> support to OMAP GIT.
> This patch is tested on TI's OMAP3630 SDP.
>
> OMAP 3630 is an ARM Cortex A8 based Multimedia Application processor. For
> more
> information please visit:
> http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=61
> 23&navigation
> Id=12836&contentId=52606
>
> Signed-off-by: Allen Pais
> ---
> arch/arm/mach-omap2/board-3630sdp.c | 188
> +++
> 1 files changed, 188 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/board-3630sdp.c
>
> diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-
> omap2/board-3630sdp.c
> new file mode 100644
> index 000..d3ddbd1
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-3630sdp.c
> @@ -0,0 +1,188 @@
> +/*
> + * linux/arch/arm/mach-omap2/board-3630sdp.c
> + * Copyright (C) 2007 Texas Instruments
2007 I don't recollect 3630 in 2007.
> + * Modified from mach-omap2/board-generic.c
> + * Initial code: Allen Pais
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "mmc-twl4030.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +/* 3630SDP has Qwerty keyboard*/
> +static int board_keymap[] = {
> + KEY(0, 0, KEY_E),
> + KEY(1, 0, KEY_R),
> + KEY(2, 0, KEY_T),
> + KEY(3, 0, KEY_HOME),
> + KEY(6, 0, KEY_I),
> + KEY(7, 0, KEY_LEFTSHIFT),
> + KEY(0, 1, KEY_D),
> + KEY(1, 1, KEY_F),
> + KEY(2, 1, KEY_G),
> + KEY(3, 1, KEY_SEND),
> + KEY(6, 1, KEY_K),
> + KEY(7, 1, KEY_ENTER),
> + KEY(0, 2, KEY_X),
> + KEY(1, 2, KEY_C),
> + KEY(2, 2, KEY_V),
> + KEY(3, 2, KEY_END),
> + KEY(6, 2, KEY_DOT),
> + KEY(7, 2, KEY_CAPSLOCK),
> + KEY(0, 3, KEY_Z),
> + KEY(1, 3, KEY_KPPLUS),
> + KEY(2, 3, KEY_B),
> + KEY(3, 3, KEY_F1),
> + KEY(6, 3, KEY_O),
> + KEY(7, 3, KEY_SPACE),
> + KEY(0, 4, KEY_W),
> + KEY(1, 4, KEY_Y),
> + KEY(2, 4, KEY_U),
> + KEY(3, 4, KEY_F2),
> + KEY(4, 4, KEY_VOLUMEUP),
> + KEY(6, 4, KEY_L),
> + KEY(7, 4, KEY_LEFT),
> + KEY(0, 5, KEY_S),
> + KEY(1, 5, KEY_H),
> + KEY(2, 5, KEY_J),
> + KEY(3, 5, KEY_F3),
> + KEY(5, 5, KEY_VOLUMEDOWN),
> + KEY(6, 5, KEY_M),
> + KEY(4, 5, KEY_ENTER),
> + KEY(7, 5, KEY_RIGHT),
> + KEY(0, 6, KEY_Q),
> + KEY(1, 6, KEY_A),
> + KEY(2, 6, KEY_N),
> + KEY(3, 6, KEY_BACKSPACE),
> + KEY(6, 6, KEY_P),
> + KEY(7, 6, KEY_UP),
> + KEY(6, 7, KEY_SELECT),
> + KEY(7, 7, KEY_DOWN),
> + KEY(0, 7, KEY_PROG1), /*MACRO 1 */
> + KEY(1, 7, KEY_PROG2), /*MACRO 2 */
> + KEY(2, 7, KEY_PROG3), /*MACRO 3 */
> + KEY(3, 7, KEY_PROG4), /*MACRO 4 */
> + 0
> +};
NAK. Could we follow the same issue with zoom2 -> break the keypad into a
Separate one and use it instead? Same for all reused zoom2 components..
> +
> +static struct matrix_keymap_data board_map_data = {
> + .keymap = board_keymap,
> + .keymap_size= ARRAY_SIZE(board_keymap),
> +};
> +
> +static struct twl4030_keypad_data sdp3630_kp_twl4030_data = {
> + .keymap_data= &board_map_data,
> + .rows = 8,
> + .cols = 8,
> + .rep= 1,
> +};
> +
> +static struct omap_board_config_kernel sdp3630_config[] __initdata = {
> +};
> +
> +
> +static int sdp3630_batt_table[] = {
> +/* 0 C*/
> +30800, 29500, 28300, 27100,
> +26000, 24900, 23900, 22900, 22000, 21100, 20300, 19400, 18700, 17900,
> +17200, 16500, 15900, 15300, 14700, 14100, 13600, 13100, 12600, 12100,
> +11600, 11200, 10800, 10400, 1, 9630, 9280, 8950, 8620, 8310,
> +8020, 7730, 7460, 7200, 6950, 6710, 6470, 6250, 6040, 5830,
> +5640, 5450, 5260, 5090, 4920, 4760, 4600, 4450, 4310, 4170,
> +4040, 3910, 3790, 3670, 3550
> +};
> +
> +static struct twl4030_bci_platform_data sdp3630_bci_data = {
> + .battery_tmp_tbl= sdp3630_batt_table,
> + .tblsize= ARRAY_SIZE(sdp3630_batt_table),
> +};
> +
> +static struct twl4030_usb_data sdp3630_usb_data = {
> + .usb_mode = T2_USB_MODE_ULPI,
> +};
> +
> +static void __init omap_sdp3630_init_irq(void)
>
RE: [PATCH 2/2] Accomodate the board file change in Kconfig
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Pais, Allen > Sent: Monday, October 26, 2009 2:43 AM > To: linux-omap@vger.kernel.org > Subject: [PATCH 2/2] Accomodate the board file change in Kconfig > > From 0599ed35fde00cd84681e5d8f9a57a797fae1270 Mon Sep 17 00:00:00 2001 > From: Allen Pais > Date: Mon, 26 Oct 2009 12:51:02 +0530 > Subject: [PATCH 2/2] Accomodate the board file change in Kconfig > > > Signed-off-by: Allen Pais > --- > arch/arm/mach-omap2/Kconfig |4 > arch/arm/mach-omap2/Makefile |1 + > 2 files changed, 5 insertions(+), 0 deletions(-) > Please merge this to patch 1/2 I think we could have this as part of the 1/2 Which was to introduce 3630sdp support. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [OMAP] GPIO Module is reset during initialization
> -Original Message-
> From: Varadarajan, Charu Latha
> Sent: Monday, October 26, 2009 5:52 AM
> To: Menon, Nishanth; m...@felipebalbi.com
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH] [OMAP] GPIO Module is reset during initialization
>
> -snippet
>
> && attemp)
>
> > +udelay(1);
>
> i guess cpu_relax() is better here.
> >> I guess cpu_relax is not required because this part of code is called
> only
> >> from
> >> board file during boot-up. Hence this would be the only code to be
> >> executed.
> What is your opinion on this?
Cpu_relax is still the better way of doing it.
>
> > +attempt++;
> >
> > attempt--;
> >
> cant we improve this code as following:
> >>>{
> >>>u8 attempts = 25;
> >>>/* Software Reset of GPIO module */
> >>>__raw_writel(0x0002, bank->base
> >>>+ OMAP24XX_GPIO_SYSCONFIG);
> >>>/* wait for reset to be done */
> >>>while (((__raw_readl(bank->base +
> >>>OMAP24XX_GPIO_SYSSTATUS) & 0x1) == 0)
> >>>&& attempts) {
> >>>cpu_relax();
> >>>if (attempts % 5)
> >>>udelay(1);
> >>>attempts--;
> >>>}
> >>>
> >>>allows the kernel to do somethin else while we also ensure we have a 5
> >>>usec guarenteed delay before giving up..
> >> Doesn't modulo operation cost more in terms of performance? Any
> specific
> >> reason for specific 5 microseconds?
> >You could replace it with >> operator if you like and use 2^x multiples..
> >I am just sticking 5 us there based on your original code..
> >so the same logic over here I suppose.. unless I missed something?
> I was using attempts as 5, as my intension was to attempt only 5 times and
> not
> in terms of usec as I could not find any details in any document for
> maximum
> time for the bit to get set/reset. According to your code, it would
> attempt to read
> the register 25 times with a delay of 5 microseconds min during worst case
> scenario.
Please find the h/w timeout value and resubmit the patch..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [OMAP] GPIO Module is reset during initialization
-snippet
&& attemp)
> +udelay(1);
i guess cpu_relax() is better here.
>> I guess cpu_relax is not required because this part of code is called only
>> from
>> board file during boot-up. Hence this would be the only code to be
>> executed.
What is your opinion on this?
> +attempt++;
>
> attempt--;
>
cant we improve this code as following:
>>>{
>>>u8 attempts = 25;
>>>/* Software Reset of GPIO module */
>>>__raw_writel(0x0002, bank->base
>>>+ OMAP24XX_GPIO_SYSCONFIG);
>>>/* wait for reset to be done */
>>>while (((__raw_readl(bank->base +
>>>OMAP24XX_GPIO_SYSSTATUS) & 0x1) == 0)
>>>&& attempts) {
>>>cpu_relax();
>>>if (attempts % 5)
>>>udelay(1);
>>>attempts--;
>>>}
>>>
>>>allows the kernel to do somethin else while we also ensure we have a 5
>>>usec guarenteed delay before giving up..
>> Doesn't modulo operation cost more in terms of performance? Any specific
>> reason for specific 5 microseconds?
>You could replace it with >> operator if you like and use 2^x multiples..
>I am just sticking 5 us there based on your original code..
>so the same logic over here I suppose.. unless I missed something?
I was using attempts as 5, as my intension was to attempt only 5 times and not
in terms of usec as I could not find any details in any document for maximum
time for the bit to get set/reset. According to your code, it would attempt to
read
the register 25 times with a delay of 5 microseconds min during worst case
scenario.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [OMAP] GPIO Module disable if all pins inactive
sinipped > bank->>gpio_status |= 1 << offset; Why to touch gpio_status if not used (for other than 34xx/24xx/44xx >> cases)? >>>either the gpio_status should be under a #ifdef for 34xx when defining >>>or it should be usable by all. what it does now is do both. >> gpio_status is not used under #ifdef for 34xx. It is used only with >> cpu_is_omap >> (34xx/24xx/44xx). Should we use both #ifdef and cpu_is_omap together? Why? >> But I don't see that approach in LO. For eg., usage of dbck_enable_mask is >> used only with cpu_is_omap and is not declared under #ifdef. > >Please see [1] saved_datain is an example of why I think gpio.c could go thru >a cleanup ;) already in #ifdef in line 1908, in line 1925, we add a new #ifdef >under a #ifdef :D.. err... > >Ok this piece of code is not perfect.. Looking onto lines 1908 & 1925, I accept that the gpio.c code is not perfect. But they are nothing to do with my patch. I guess this is the same at many places in most of the drivers and someone has to take up the job of cleaning up. >Regards, >Nishanth Menon >.[1] >http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/plat-omap/gpio.c;h=487bea7b5605fe366064d792d0c9cc8aed1eac63;hb=0bbf5337f2f2957775051a3caf60b66d3306c815#l174 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [OMAP] GPIO Module disable if all pins inactive
> From: Varadarajan, Charu Latha
> Sent: Monday, October 26, 2009 4:07 AM
>
> #endif
> + if (cpu_is_omap24xx() || cpu_is_omap34xx() ||
> cpu_is_omap44xx()) {
> + if (!bank->>gpio_status) {
> + ctrl = __raw_readl(bank->>base +
> OMAP24XX_GPIO_CTRL);
> + /* Module is enabled, clocks are not gated */
> + ctrl &= 0xFFFE;
> + __raw_writel(ctrl, bank->>base +
> OMAP24XX_GPIO_CTRL);
> + }
> + bank->>gpio_status |= 1 << offset;
> + }
> >>> why do this every time a gpio is enabled? why not do this iff gpio was
> >>> never used before.. how about the following:
> >> The module is enabled only when gpio_status indicates that no GPIO
> >> in that module is currently active and the GPIO being requested is the
> 1st one
> >> to be active in that module.
> >> Each module would be disabled in free() API when all GPIOs in a
> particular module
> >> becomes inactive. The module is re-enabled in request() API when a GPIO
> is
> >> requested from the module that was previously disabled.
> >Thanks.
> Welcome
> >>> if (!bank->>gpio_status && (cpu_is_omap24xx() || cpu_is_omap34xx() ||
> >>> cpu_is_omap44xx())) {
> >>>u32 ctrl = __raw_readl(bank->>base + OMAP24XX_GPIO_CTRL);
> >>>/* Module is enabled, clocks are not gated */
> >>>ctrl &= 0xFFFE;
> >>>__raw_writel(ctrl, bank->>base + OMAP24XX_GPIO_CTRL);
> >>> }
> >>> bank->>gpio_status |= 1 << offset;
> >> Why to touch gpio_status if not used (for other than 34xx/24xx/44xx
> cases)?
> >either the gpio_status should be under a #ifdef for 34xx when defining
> >or it should be usable by all. what it does now is do both.
> gpio_status is not used under #ifdef for 34xx. It is used only with
> cpu_is_omap
> (34xx/24xx/44xx). Should we use both #ifdef and cpu_is_omap together? Why?
> But I don't see that approach in LO. For eg., usage of dbck_enable_mask is
> used only with cpu_is_omap and is not declared under #ifdef.
Please see [1] saved_datain is an example of why I think gpio.c could go thru a
cleanup ;) already in #ifdef in line 1908, in line 1925, we add a new #ifdef
under a #ifdef :D.. err...
Ok this piece of code is not perfect..
Regards,
Nishanth Menon
[1]
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/plat-omap/gpio.c;h=487bea7b5605fe366064d792d0c9cc8aed1eac63;hb=0bbf5337f2f2957775051a3caf60b66d3306c815#l174
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [OMAP] GPIO Module is reset during initialization
> From: Varadarajan, Charu Latha
> Sent: Monday, October 26, 2009 4:26 AM
> To: Menon, Nishanth; m...@felipebalbi.com
>
> >Felipe Balbi had written, on 10/23/2009 05:56 PM, the following:
> >> On Fri, Oct 23, 2009 at 09:25:29PM +0530, ch...@ti.com wrote:
> >>> From: Charulatha V
> >>>
> >>> During initialization, GPIO module is reset using soft reset bit
> >>> of SYSCONFIG register
> >>>
> >>> Signed-off-by: Charulatha V
> >>> ---
> >>> arch/arm/plat-omap/gpio.c | 12 +++-
> >>> 1 files changed, 11 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> >>> index 2304a5d..4579650 100644
> >>> --- a/arch/arm/plat-omap/gpio.c
> >>> +++ b/arch/arm/plat-omap/gpio.c
> >>> @@ -21,6 +21,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>>
> >>> #include
> >>> #include
> >>> @@ -1670,7 +1671,7 @@ static int __init _omap_gpio_init(void)
> >>> }
> >>> #endif
> >>> for (i = 0; i < gpio_bank_count; i++) {
> >>> -int j, gpio_count = 16;
> >>> +int j, gpio_count = 16, attempt = 0;
> >>
> >> decrementing is better, so:
> Okay
> >>
> >> attempt = 1000
> >please move attempt out of here to the {} for 3430.. Warning for OMAP1.
> Okay
> >>
> >>>
> >>> bank = &gpio_bank[i];
> >>> spin_lock_init(&bank->lock);
> >>> @@ -1698,6 +1699,15 @@ static int __init _omap_gpio_init(void)
> >>> static const u32 non_wakeup_gpios[] = {
> >>> 0xe203ffc0, 0x08700040
> >>> };
> >>> +
> >>> +/* Software Reset of GPIO module */
> >>> +__raw_writel(0x0002, bank->base +
> OMAP24XX_GPIO_SYSCONFIG);
> >>> +while (((__raw_readl(bank->base +
> OMAP24XX_GPIO_SYSSTATUS)
> >>> +& 0x1) == 0) && attempt < 5) {
> >>
> >> && attemp)
> >>
> >>> +udelay(1);
> >>
> >> i guess cpu_relax() is better here.
> I guess cpu_relax is not required because this part of code is called only
> from
> board file during boot-up. Hence this would be the only code to be
> executed.
> >>
> >>> +attempt++;
> >>>
> >>> attempt--;
> >>>
> >>cant we improve this code as following:
> >{
> >u8 attempts = 25;
> >/* Software Reset of GPIO module */
> >__raw_writel(0x0002, bank->base
> >+ OMAP24XX_GPIO_SYSCONFIG);
> >/* wait for reset to be done */
> >while (((__raw_readl(bank->base +
> >OMAP24XX_GPIO_SYSSTATUS) & 0x1) == 0)
> >&& attempts) {
> >cpu_relax();
> >if (attempts % 5)
> >udelay(1);
> >attempts--;
> >}
> >
> >allows the kernel to do somethin else while we also ensure we have a 5
> >usec guarenteed delay before giving up..
> Doesn't modulo operation cost more in terms of performance? Any specific
> reason for specific 5 microseconds?
You could replace it with >> operator if you like and use 2^x multiples.. I am
just sticking 5 us there based on your original code.. so the same logic over
here I suppose.. unless I missed something?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
> -Original Message- > From: G, Manjunath Kondaiah > Sent: Monday, October 26, 2009 3:40 AM > To: Menon, Nishanth; linux-omap@vger.kernel.org > Cc: Imberton Guilhem; Mike Chan; Nayak, Rajendra; Roger Quadros; Kalle > Jokiniemi; Reddy, Teerth; Kevin Hilman; Paul Walmsley; Hogander Jouni > Subject: RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0 > > > As per your comments for other patches when ever there is udelay usage, > cpu_relax is the better option. I see there are lot of udelay(...) calls > used in this patch. Why can't you use cpu_relax() or schedule(). > Any specific reason? > Don’t really want to do cpu_relax in irq_locked context.. if you look at the code flow, the call from cpu_idle is in irq_locked.. Further this delay is part of bring up form saved context where there is nothing else scheduled + we don’t want anything else scheduled (and causing a change in scheduling decision). So unfortunately, unlike standard drivers, this cannot use the same reasoning. Regards, Nishanth Menon
RE: [PATCH] [OMAP] GPIO Module is reset during initialization
>Felipe Balbi had written, on 10/23/2009 05:56 PM, the following:
>> On Fri, Oct 23, 2009 at 09:25:29PM +0530, ch...@ti.com wrote:
>>> From: Charulatha V
>>>
>>> During initialization, GPIO module is reset using soft reset bit
>>> of SYSCONFIG register
>>>
>>> Signed-off-by: Charulatha V
>>> ---
>>> arch/arm/plat-omap/gpio.c | 12 +++-
>>> 1 files changed, 11 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
>>> index 2304a5d..4579650 100644
>>> --- a/arch/arm/plat-omap/gpio.c
>>> +++ b/arch/arm/plat-omap/gpio.c
>>> @@ -21,6 +21,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>> #include
>>> @@ -1670,7 +1671,7 @@ static int __init _omap_gpio_init(void)
>>> }
>>> #endif
>>> for (i = 0; i < gpio_bank_count; i++) {
>>> -int j, gpio_count = 16;
>>> +int j, gpio_count = 16, attempt = 0;
>>
>> decrementing is better, so:
Okay
>>
>> attempt = 1000
>please move attempt out of here to the {} for 3430.. Warning for OMAP1.
Okay
>>
>>>
>>> bank = &gpio_bank[i];
>>> spin_lock_init(&bank->lock);
>>> @@ -1698,6 +1699,15 @@ static int __init _omap_gpio_init(void)
>>> static const u32 non_wakeup_gpios[] = {
>>> 0xe203ffc0, 0x08700040
>>> };
>>> +
>>> +/* Software Reset of GPIO module */
>>> +__raw_writel(0x0002, bank->base + OMAP24XX_GPIO_SYSCONFIG);
>>> +while (((__raw_readl(bank->base + OMAP24XX_GPIO_SYSSTATUS)
>>> +& 0x1) == 0) && attempt < 5) {
>>
>> && attemp)
>>
>>> +udelay(1);
>>
>> i guess cpu_relax() is better here.
I guess cpu_relax is not required because this part of code is called only from
board file during boot-up. Hence this would be the only code to be executed.
>>
>>> +attempt++;
>>>
>>> attempt--;
>>>
>>cant we improve this code as following:
>{
>u8 attempts = 25;
>/* Software Reset of GPIO module */
>__raw_writel(0x0002, bank->base
>+ OMAP24XX_GPIO_SYSCONFIG);
>/* wait for reset to be done */
>while (((__raw_readl(bank->base +
>OMAP24XX_GPIO_SYSSTATUS) & 0x1) == 0)
>&& attempts) {
>cpu_relax();
>if (attempts % 5)
>udelay(1);
>attempts--;
>}
>
>allows the kernel to do somethin else while we also ensure we have a 5
>usec guarenteed delay before giving up..
Doesn't modulo operation cost more in terms of performance? Any specific
reason for specific 5 microseconds? --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [OMAP] GPIO Module disable if all pins inactive
#endif
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
+ if (!bank->>gpio_status) {
+ ctrl = __raw_readl(bank->>base + OMAP24XX_GPIO_CTRL);
+ /* Module is enabled, clocks are not gated */
+ ctrl &= 0xFFFE;
+ __raw_writel(ctrl, bank->>base + OMAP24XX_GPIO_CTRL);
+ }
+ bank->>gpio_status |= 1 << offset;
+ }
>>> why do this every time a gpio is enabled? why not do this iff gpio was
>>> never used before.. how about the following:
>> The module is enabled only when gpio_status indicates that no GPIO
>> in that module is currently active and the GPIO being requested is the 1st
>> one
>> to be active in that module.
>> Each module would be disabled in free() API when all GPIOs in a particular
>> module
>> becomes inactive. The module is re-enabled in request() API when a GPIO is
>> requested from the module that was previously disabled.
>Thanks.
Welcome
>>> if (!bank->>gpio_status && (cpu_is_omap24xx() || cpu_is_omap34xx() ||
>>> cpu_is_omap44xx())) {
>>>u32 ctrl = __raw_readl(bank->>base + OMAP24XX_GPIO_CTRL);
>>>/* Module is enabled, clocks are not gated */
>>>ctrl &= 0xFFFE;
>>>__raw_writel(ctrl, bank->>base + OMAP24XX_GPIO_CTRL);
>>> }
>>> bank->>gpio_status |= 1 << offset;
>> Why to touch gpio_status if not used (for other than 34xx/24xx/44xx cases)?
>either the gpio_status should be under a #ifdef for 34xx when defining
>or it should be usable by all. what it does now is do both.
gpio_status is not used under #ifdef for 34xx. It is used only with
cpu_is_omap
(34xx/24xx/44xx). Should we use both #ifdef and cpu_is_omap together? Why?
But I don't see that approach in LO. For eg., usage of dbck_enable_mask is
used only with cpu_is_omap and is not declared under #ifdef.
>my proposal is to allow gpio_status to be usable by ALL OMAPs -> maybe
>OMAP1 also could also use it.. I cannot comment - but it does look to
>have scope of usage beyond omap2/3/4 series?
Even though OMAP1 supports the same feature, I am not including it as I
cannot test it and I am not sure about it in OMAP1. For 24xx, 34xx & 44xx,
the registers used and offsets are all the same. So the same code is reused. --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Accomodate the board file change in Kconfig
>From 0599ed35fde00cd84681e5d8f9a57a797fae1270 Mon Sep 17 00:00:00 2001 From: Allen Pais Date: Mon, 26 Oct 2009 12:51:02 +0530 Subject: [PATCH 2/2] Accomodate the board file change in Kconfig Signed-off-by: Allen Pais --- arch/arm/mach-omap2/Kconfig |4 arch/arm/mach-omap2/Makefile |1 + 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index aad194f..f555c18 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -73,6 +73,10 @@ config MACH_OMAP_3430SDP bool "OMAP 3430 SDP board" depends on ARCH_OMAP3 && ARCH_OMAP34XX +config MACH_OMAP_3630SDP + bool "OMAP 3630 SDP board" + depends on ARCH_OMAP3 && ARCH_OMAP34XX + config MACH_NOKIA_N800 bool diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 6b7702f..d6afc01 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -67,6 +67,7 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \ mmc-twl4030.o +obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ board-rx51-peripherals.o \ -- 1.5.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Added board-3630.c file.
>From 553ee2299d0ea6493e8587e7cc832361646f81a7 Mon Sep 17 00:00:00 2001
From: Allen Pais
Date: Mon, 26 Oct 2009 12:50:17 +0530
Subject: [PATCH 1/2] Added board-3630.c file.
The following sequence of patch set is to adds minimal OMAP3630 board support
to OMAP GIT.
This patch is tested on TI's OMAP3630 SDP.
OMAP 3630 is an ARM Cortex A8 based Multimedia Application processor. For more
information please visit:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigation
Id=12836&contentId=52606
Signed-off-by: Allen Pais
---
arch/arm/mach-omap2/board-3630sdp.c | 188 +++
1 files changed, 188 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-3630sdp.c
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
new file mode 100644
index 000..d3ddbd1
--- /dev/null
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -0,0 +1,188 @@
+/*
+ * linux/arch/arm/mach-omap2/board-3630sdp.c
+ * Copyright (C) 2007 Texas Instruments
+ * Modified from mach-omap2/board-generic.c
+ * Initial code: Allen Pais
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include "mmc-twl4030.h"
+#include "sdram-micron-mt46h32m32lf-6.h"
+
+/* 3630SDP has Qwerty keyboard*/
+static int board_keymap[] = {
+ KEY(0, 0, KEY_E),
+ KEY(1, 0, KEY_R),
+ KEY(2, 0, KEY_T),
+ KEY(3, 0, KEY_HOME),
+ KEY(6, 0, KEY_I),
+ KEY(7, 0, KEY_LEFTSHIFT),
+ KEY(0, 1, KEY_D),
+ KEY(1, 1, KEY_F),
+ KEY(2, 1, KEY_G),
+ KEY(3, 1, KEY_SEND),
+ KEY(6, 1, KEY_K),
+ KEY(7, 1, KEY_ENTER),
+ KEY(0, 2, KEY_X),
+ KEY(1, 2, KEY_C),
+ KEY(2, 2, KEY_V),
+ KEY(3, 2, KEY_END),
+ KEY(6, 2, KEY_DOT),
+ KEY(7, 2, KEY_CAPSLOCK),
+ KEY(0, 3, KEY_Z),
+ KEY(1, 3, KEY_KPPLUS),
+ KEY(2, 3, KEY_B),
+ KEY(3, 3, KEY_F1),
+ KEY(6, 3, KEY_O),
+ KEY(7, 3, KEY_SPACE),
+ KEY(0, 4, KEY_W),
+ KEY(1, 4, KEY_Y),
+ KEY(2, 4, KEY_U),
+ KEY(3, 4, KEY_F2),
+ KEY(4, 4, KEY_VOLUMEUP),
+ KEY(6, 4, KEY_L),
+ KEY(7, 4, KEY_LEFT),
+ KEY(0, 5, KEY_S),
+ KEY(1, 5, KEY_H),
+ KEY(2, 5, KEY_J),
+ KEY(3, 5, KEY_F3),
+ KEY(5, 5, KEY_VOLUMEDOWN),
+ KEY(6, 5, KEY_M),
+ KEY(4, 5, KEY_ENTER),
+ KEY(7, 5, KEY_RIGHT),
+ KEY(0, 6, KEY_Q),
+ KEY(1, 6, KEY_A),
+ KEY(2, 6, KEY_N),
+ KEY(3, 6, KEY_BACKSPACE),
+ KEY(6, 6, KEY_P),
+ KEY(7, 6, KEY_UP),
+ KEY(6, 7, KEY_SELECT),
+ KEY(7, 7, KEY_DOWN),
+ KEY(0, 7, KEY_PROG1), /*MACRO 1 */
+ KEY(1, 7, KEY_PROG2), /*MACRO 2 */
+ KEY(2, 7, KEY_PROG3), /*MACRO 3 */
+ KEY(3, 7, KEY_PROG4), /*MACRO 4 */
+ 0
+};
+
+static struct matrix_keymap_data board_map_data = {
+ .keymap = board_keymap,
+ .keymap_size= ARRAY_SIZE(board_keymap),
+};
+
+static struct twl4030_keypad_data sdp3630_kp_twl4030_data = {
+ .keymap_data= &board_map_data,
+ .rows = 8,
+ .cols = 8,
+ .rep= 1,
+};
+
+static struct omap_board_config_kernel sdp3630_config[] __initdata = {
+};
+
+
+static int sdp3630_batt_table[] = {
+/* 0 C*/
+30800, 29500, 28300, 27100,
+26000, 24900, 23900, 22900, 22000, 21100, 20300, 19400, 18700, 17900,
+17200, 16500, 15900, 15300, 14700, 14100, 13600, 13100, 12600, 12100,
+11600, 11200, 10800, 10400, 1, 9630, 9280, 8950, 8620, 8310,
+8020, 7730, 7460, 7200, 6950, 6710, 6470, 6250, 6040, 5830,
+5640, 5450, 5260, 5090, 4920, 4760, 4600, 4450, 4310, 4170,
+4040, 3910, 3790, 3670, 3550
+};
+
+static struct twl4030_bci_platform_data sdp3630_bci_data = {
+ .battery_tmp_tbl= sdp3630_batt_table,
+ .tblsize= ARRAY_SIZE(sdp3630_batt_table),
+};
+
+static struct twl4030_usb_data sdp3630_usb_data = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
+
+static void __init omap_sdp3630_init_irq(void)
+{
+ omap_board_config = sdp3630_config;
+ omap_board_config_size = ARRAY_SIZE(sdp3630_config);
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
+mt46h32m32lf6_sdrc_params);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+static struct twl4030_madc_platform_data sdp3630_madc_data = {
+ .irq_line = 1,
+};
+
+static struct twl4030_platform_data sdp3630_twldata = {
+ .irq_base = TWL4030_IRQ_BASE,
+ .irq_end= TWL4030_IRQ_END,
+
+ /* platform_data for children goes here */
+ .bci= &sdp3630_bci_data,
+ .
[PATCH 0/2] Introduce 3630sdp board file.
OMAP3630 is a migration in GS70 process of the OMAP3430 with some performance improvements. OMAP3630 is a high performance multimedia application processor based on the enhanced OMAP 3 Architecture integrated on a 45nm process OMAP3630's architecture is designed for 2.5G wireless terminals, 3G wireless terminals, rich multi-media featured handsets and high performance PDAs to provide best-in-class video, image and graphics processing sufficient to support: Streaming video, 2D/3D mobile gaming, Video conferencing, High resolution still image, Video capture. arch/arm/mach-omap2/board-3630sdp.c | 188 + arch/arm/mach-omap2/Kconfig |4 arch/arm/mach-omap2/Makefile|1 + ++ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
