Re: FW: [RFC][PATCH]: Adding support for omap-serail driver
Hi, > > FWIW, as the author of much of the PM hacker in mach-omap2/serial.c, I > agree with Tao. > > The only reason for the PM hackery in mach-omap2/serial.c is because > of the limitations of the 8250 driver. > I have an query, We have following functionality in serial.c: 1.) Enabling and disabling uart clocks. 2.) Adding rx wakeup capabilities. 3.) Preparing UARTs for idle mode. 4.) Context save and restore. What functionality should be retained in serial.c file? AFAIK currently no serial driver has incorporated their platform specific PM functionality like context_save and restore into their serial driver, shouldn't these things be retained into */mach-omap2/serial.c ? --- Regards, Govindraj.R -- 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: [RFC] OMAP3 : PM : Handle variable length OPP tables
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Friday, September 11, 2009 12:00 AM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [RFC] OMAP3 : PM : Handle variable length OPP tables
>
> "Premi, Sanjeev" writes:
>
> > Hi all,
> >
> > There is no generic function to translate an OPP to FREQ
> and vice versa.
> > Came across the problem while trying to submit a follow-up
> to earlier
> > patch for change in mpurate via bootargs.
> >
> > The function get_opp in resource34xx.c, but it is always
> called with an
> > explicit addition of MAX_VDDn_OPP e.g.
> >
> > opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk->rate);
> > opp = get_opp(l3_opps + MAX_VDD2_OPP, clk->rate);
> >
> > This is 'addition' is required as there is no encapsulation of the
> > MIN and MAX VDDs associated to the table.
> >
> > The patch below fixes this issue; buy creating a 'table' object with
> > necessary information. It can also help in getting rid of the
> > empty {0, 0, 0} at index 0 of each OPP table.
> >
> > At the moment, it does not break any functionality in
> resource34xx.c;
> > migration to this encapsulation can be taken as next step.
> >
> > This code is bare 'git-diff' for early comments. Formal
> patch to follow...
> >
> > Best regards,
> > Sanjeev
>
> Is the goal of the min and max fields so you could have some OPPs
> in the table that aren't valid for some SoCs? IOW, the 'max' value
> might be higher on newer SoCs with higher OPPs.
The goal is to have get_*() functions where caller shouldn't be aware
of the MAX_ for the table. Considering table as an object, it should
be able to provide its own length.
Reason to use min and max was to maintain current functionality as is.
Else, simple 'length' should be sufficient.
>
> What if you want a list of OPPs, but want to remove one from the
> middle of the list? The min/max approach doesn't work here.
>
> What about a also extending the struct omap_opp to have some sort of
> valid field.
This doesn't help in eliminating the addition of MAX value for each
function call.
>
> Kevin
>
> >
> > diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h
> b/arch/arm/plat-omap/include/mach/omap-pm.h
> > index 583e540..2357784 100644
> > --- a/arch/arm/plat-omap/include/mach/omap-pm.h
> > +++ b/arch/arm/plat-omap/include/mach/omap-pm.h
> > @@ -33,6 +33,20 @@ struct omap_opp {
> > u16 vsel;
> > };
> >
> > +/* struct omap_opp_table - View OPP table as an object
> > + * @min: Minimum OPP id
> > + * @max: Maximim OPP id
> > + * @opps: Pointer to array defining the OPPs.
> > + *
> > + * An OPP table has varied length. Knowing minimum and maximum
> > + * OPP ids allow easy traversal.
> > + */
> > +struct omap_opp_table {
> > + u8 min;
> > + u8 max;
> > + struct omap_opp* opps;
> > +};
> > +
> > extern struct omap_opp *mpu_opps;
> > extern struct omap_opp *dsp_opps;
> > extern struct omap_opp *l3_opps;
> > diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> > index fec7d00..c90b1af 100644
> > --- a/arch/arm/mach-omap2/pm.c
> > +++ b/arch/arm/mach-omap2/pm.c
> > @@ -33,6 +33,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "prm-regbits-34xx.h"
> > #include "pm.h"
> > @@ -281,3 +282,50 @@ static int __init omap_pm_init(void)
> > return error;
> > }
> > late_initcall(omap_pm_init);
> > +
> > +/*
> > + * Get frequency corresponding to an OPP
> > + */
> > +int opp_to_freq(unsigned int* freq, struct omap_opp_table*
> table, u8 opp)
> > +{
> > +int i, found=0;
> > +
> > +if (table && table->opps) {
> > +for (i=table->min; table->opps[i].opp_id
> <= table->max; i++)
> > +if (table->opps[i].opp_id == opp) {
> > +found = 1;
> > +break;
> > +}
> > +
> > +if (found) {
> > +*freq = table->opps[i].rate;
> > +return 1;
> > +}
> > +}
> > +
> > +return 0;
> > +}
> > +
> > +/*
> > + * Get OPP corresponding to a frequency
> > + */
> > +int freq_to_opp(u8* opp, struct omap_opp_table* table,
> unsigned long freq)
> > +{
> > +int i, found=0;
> > +
> > +if (table && table->opps) {
> > +for (i=table->min; table->opps[i].opp_id
> <= table->max; i++)
> > +if (table->opps[i].rate == freq) {
> > +found = 1;
> > +break;
> > +}
> > +
> > +if (found) {
> > +*opp = table->opps[i].opp_id;
> > +return 1;
> > +}
> > +}
> > +
> > +return 0;
> > +}
> > +
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> linux-omap" in
> > the body of a message t
Re: [PATCH] [ARM] omap: resource: Make resource_refresh() thread safe.
Kevin Hilman wrote:
Mike Chan writes:
Need to lock the res_mutex when traversing the res_list.
Signed-off-by: Mike Chan
Looks good, thanks.
This patch causes a hang for me when transitioning to OFF mode. This
was tested on the Android 2.6.29 tree and is 100% reproducible. The
moment a user runs 'echo 1 > /sys/power/enable_off_mode' the board hangs
without any further output.
Reverting the patch allows me to hit OFF mode again. I haven't yet
tested this on vanilla 2.6.29 or latest L-O.
Mike
Pushed to PM branch and pm-2.6.29.
Kevin
---
arch/arm/plat-omap/resource.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/resource.c b/arch/arm/plat-omap/resource.c
index 25072cd..4631912 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -234,11 +234,13 @@ int resource_refresh(void)
struct shared_resource *resp = NULL;
int ret = 0;
+ down(&res_mutex);
list_for_each_entry(resp, &res_list, node) {
ret = update_resource_level(resp);
if (ret)
break;
}
+ up(&res_mutex);
return ret;
}
--
1.5.4.5
--
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 V3 28/30] omap_hsmmc: ensure all clock enables and disables are paired
On Wed, 09 Sep 2009 15:00:03 +0300 Adrian Hunter wrote: > >From baf6574a1b5e7c4fdc4a66d9e038efeee75ea1a0 Mon Sep 17 00:00:00 2001 > From: Adrian Hunter > Date: Sun, 31 May 2009 19:27:36 +0300 > Subject: [PATCH] omap_hsmmc: ensure all clock enables and disables are paired > This patch hasn't been updated with omap_hsmmc-ensure-all-clock-enables-and-disables-are-paired-fix-for-the-db-clock-failure-message.patch, and omap_hsmmc-ensure-all-clock-enables-and-disables-are-paired-fix-for-the-db-clock-failure-message.patch is not present in the v3 patchset. What's up with that? I went through the patchset seeing what you'd done. mmc-add-host-capabilities-for-sd-only-and-mmc-only.patch and omap_hsmmc-pass-host-capabilities-for-sd-only-and-mmc-only.patch were dropped. arm-omap-rx51-set-mmc-capabilities-and-power-saving-flag.patch was significantly altered (I queued a delta for that). omap_hsmmc-make-use-of-new-mmc_cap_nonremovable-host-capability.patch was changed a bit to fix rejects (I think). -- 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: Is there anyway to know the way OMAP got reset
> Not sure about the OMAP5912, but at least on the OMAP3430, there > is a register (PRM_RSTST) that can logs the global reset sources. > Reading this register after the reset should tell you the cause of > the last reset. > > Maybe there is something similar in the OMAP5912. You can look at the ARM_SYSST register on the 5912. This should tell you the source on the reset (external, watchdog, software, etc) that occured. Jon-- 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: Is there anyway to know the way OMAP got reset
Suresh Rajashekara wrote: > > Is there anyway on OMAP systems (or in general in embedded systems) to > know a way in which the processor was reset, after the reset. > > I am using a system based on OMAP5912 OSK and its getting reset for no > known reason. Not sure about the OMAP5912, but at least on the OMAP3430, there is a register (PRM_RSTST) that can logs the global reset sources. Reading this register after the reset should tell you the cause of the last reset. Maybe there is something similar in the OMAP5912. - Anand -- 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
Is there anyway to know the way OMAP got reset
Is there anyway on OMAP systems (or in general in embedded systems) to know a way in which the processor was reset, after the reset. I am using a system based on OMAP5912 OSK and its getting reset for no known reason. Thanks in advance, Suresh -- 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 00/18] OMAP: DSS2: Intro
> -Original Message- > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > Sent: Thursday, September 03, 2009 4:30 PM > To: ext Andrew Morton > Cc: Artem Bityutskiy; t...@atomide.com; Hiremath, Vaibhav; Syed > Mohammed, Khasim; sako...@gmail.com; linux-ker...@vger.kernel.org; > linux-omap@vger.kernel.org > Subject: Re: [PATCH 00/18] OMAP: DSS2: Intro > > Hi, > > On Thu, 2009-09-03 at 00:11 +0200, ext Andrew Morton wrote: > > On Tue, 01 Sep 2009 10:10:19 +0300 > > Artem Bityutskiy wrote: > > > > > Andrew, > > > > > > could you please help with merging this piece of (well written) > code? > > > Could you give your blessing to include it into linux-next now, > and > > > merge this during the next merge window? > > > > I'll merge them (after I've looked through them, which I'll do > now). > > > > But there are more rejects than I'm prepared to cope with. The > various > > arch/arm files have undergone some changes in linux-next which > yield > > more breakage than I'm prepared to try to fix. For example, > > arch/arm/mach-omap2/board-3430sdp.c:sdp3430_config[] ends up being > an > > empty array! > > I rebased the patches on top of linux-next. The tree is at > http://gitorious.org/linux-omap-dss2/linux , in branch linux-next- > dss. > > The only conflict was in board-3430sdp, and yes, sdp3430_config is > supposed to end up as an empty array. > [Hiremath, Vaibhav] I have refreshed OMAp3EVM patch support on top of l-o master, as of now I have shared it under http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-video.git;a=summary under ti_display branch, and will be posting to L-O once DSS2 gets accepted. > > Then there's the matter of these patches, already in -mm: > > > > omapfb-add-support-for-the-apollon-lcd.patch > > omapfb-add-support-for-mipi-dcs-compatible-lcds.patch > > omapfb-add-support-for-the-amstrad-delta-lcd.patch > > omapfb-add-support-for-the-2430sdp-lcd.patch > > omapfb-add-support-for-the-omap2evm-lcd.patch > > omapfb-add-support-for-the-3430sdp-lcd.patch > > omapfb-add-support-for-the-omap3-evm-lcd.patch > > omapfb-add-support-for-the-omap3-beagle-dvi-output.patch > > omapfb-add-support-for-the-gumstix-overo-lcd.patch > > omapfb-add-support-for-the-zoom-mdk-lcd.patch > > omapfb-add-support-for-rotation-on-the-blizzard-lcd-ctrl.patch > > n770-enable-lcd-mipi-dcs-in-kconfig.patch > > omapfb-dispc-various-typo-fixes.patch > > omapfb-dispc-disable-iface-clocks-along-with-func-clocks.patch > > omapfb-dispc-enable-wake-up-capability.patch > > omapfb-dispc-allow-multiple-external-irq-handlers.patch > > omapfb-suspend-resume-only-if-fb-device-is-already- > initialized.patch > > omapfb-fix-coding-style-remove-dead-line.patch > > omapfb-add-fb-manual-update-option-to-kconfig.patch > > omapfb-hwa742-fix-pointer-to-be-const.patch > > These are not in linux-next, I think. They are for the old OMAP > display > subsystem, and may cause some conflicts with DSS2. I think those > patches > should go in also, as the old driver is used for OMAP1 and fo all > the > other boards that have not been ported to use DSS2. > > Should I rebase DSS2 on top of -mm and solve the conflicts? If so, > where > can I find your tree? > [Hiremath, Vaibhav] Andrew, We have not heard anything back on this, when are you planning to merge DSS2? Actually other development patches are gating because of this, like V4L2 driver on top of DSS2. Thanks, Vaibhav > Tomi > > -- 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: [RFC] OMAP3 : PM : Handle variable length OPP tables
"Premi, Sanjeev" writes:
> Hi all,
>
> There is no generic function to translate an OPP to FREQ and vice versa.
> Came across the problem while trying to submit a follow-up to earlier
> patch for change in mpurate via bootargs.
>
> The function get_opp in resource34xx.c, but it is always called with an
> explicit addition of MAX_VDDn_OPP e.g.
>
> opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk->rate);
> opp = get_opp(l3_opps + MAX_VDD2_OPP, clk->rate);
>
> This is 'addition' is required as there is no encapsulation of the
> MIN and MAX VDDs associated to the table.
>
> The patch below fixes this issue; buy creating a 'table' object with
> necessary information. It can also help in getting rid of the
> empty {0, 0, 0} at index 0 of each OPP table.
>
> At the moment, it does not break any functionality in resource34xx.c;
> migration to this encapsulation can be taken as next step.
>
> This code is bare 'git-diff' for early comments. Formal patch to follow...
>
> Best regards,
> Sanjeev
Is the goal of the min and max fields so you could have some OPPs
in the table that aren't valid for some SoCs? IOW, the 'max' value
might be higher on newer SoCs with higher OPPs.
What if you want a list of OPPs, but want to remove one from the
middle of the list? The min/max approach doesn't work here.
What about a also extending the struct omap_opp to have some sort of
valid field.
Kevin
>
> diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h
> b/arch/arm/plat-omap/include/mach/omap-pm.h
> index 583e540..2357784 100644
> --- a/arch/arm/plat-omap/include/mach/omap-pm.h
> +++ b/arch/arm/plat-omap/include/mach/omap-pm.h
> @@ -33,6 +33,20 @@ struct omap_opp {
> u16 vsel;
> };
>
> +/* struct omap_opp_table - View OPP table as an object
> + * @min: Minimum OPP id
> + * @max: Maximim OPP id
> + * @opps: Pointer to array defining the OPPs.
> + *
> + * An OPP table has varied length. Knowing minimum and maximum
> + * OPP ids allow easy traversal.
> + */
> +struct omap_opp_table {
> + u8 min;
> + u8 max;
> + struct omap_opp* opps;
> +};
> +
> extern struct omap_opp *mpu_opps;
> extern struct omap_opp *dsp_opps;
> extern struct omap_opp *l3_opps;
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index fec7d00..c90b1af 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
>
> #include "prm-regbits-34xx.h"
> #include "pm.h"
> @@ -281,3 +282,50 @@ static int __init omap_pm_init(void)
> return error;
> }
> late_initcall(omap_pm_init);
> +
> +/*
> + * Get frequency corresponding to an OPP
> + */
> +int opp_to_freq(unsigned int* freq, struct omap_opp_table* table, u8 opp)
> +{
> +int i, found=0;
> +
> +if (table && table->opps) {
> +for (i=table->min; table->opps[i].opp_id <= table->max; i++)
> +if (table->opps[i].opp_id == opp) {
> +found = 1;
> +break;
> +}
> +
> +if (found) {
> +*freq = table->opps[i].rate;
> +return 1;
> +}
> +}
> +
> +return 0;
> +}
> +
> +/*
> + * Get OPP corresponding to a frequency
> + */
> +int freq_to_opp(u8* opp, struct omap_opp_table* table, unsigned long freq)
> +{
> +int i, found=0;
> +
> +if (table && table->opps) {
> +for (i=table->min; table->opps[i].opp_id <= table->max; i++)
> +if (table->opps[i].rate == freq) {
> +found = 1;
> +break;
> +}
> +
> +if (found) {
> +*opp = table->opps[i].opp_id;
> +return 1;
> +}
> +}
> +
> +return 0;
> +}
> +
> --
> 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 1/1] PM : cpuidle - update statistics for correct state
Sanjeev Premi writes:
> When 'enable_off_mode' is 0, the target power state for MPU
> and Core is locally changed to PWRDM_POWER_RET but, the
> statistics are updated for idle state originally selected
> by the governor.
>
> This patch 'invalidates' the idle states that lead either of
> MPU or Core to PWRDM_POWER_OFF state when 'enable_off_mode'
> is '0'. The states are valid once 'enable_off_mode' is set
> to '1'.
>
> Signed-off-by: Sanjeev Premi
This is a good start, but doesn't actually fix the problem. This is
because the 'valid' field is an OMAP specific field and is not checked
in any of our 'enter_idle' hooks.
It works in your test case because the code snippet you mentioned in
PATCH 0/0 still modifies the target state.
What we need is for the enter_idle_bm() enter function to check the
.valid flag. If it's not valid, then keep dropping states until it
finds a valid flag or it hits the safe state.
Kevin
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 34 +++---
> arch/arm/mach-omap2/pm.h |2 ++
> arch/arm/mach-omap2/pm34xx.c |2 ++
> 3 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> b/arch/arm/mach-omap2/cpuidle34xx.c
> index 7bbec90..19273b3 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -104,13 +104,6 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
> local_irq_disable();
> local_fiq_disable();
>
> - if (!enable_off_mode) {
> - if (mpu_state < PWRDM_POWER_RET)
> - mpu_state = PWRDM_POWER_RET;
> - if (core_state < PWRDM_POWER_RET)
> - core_state = PWRDM_POWER_RET;
> - }
> -
> pwrdm_set_next_pwrst(mpu_pd, mpu_state);
> pwrdm_set_next_pwrst(core_pd, core_state);
>
> @@ -254,6 +247,31 @@ void omap_init_power_states(void)
> CPUIDLE_FLAG_CHECK_BM;
> }
>
> +/**
> + * omap3_cpuidle_update_states - Update the cpuidle states.
> + *
> + * Currently, this function toggles the validity of idle states based upon
> + * the flag 'enable_off_mode'. When the flag is set all states are valid.
> + * Else, states leading to OFF state set to be invalid.
> + */
> +void omap3_cpuidle_update_states(void)
> +{
> + int i;
> +
> + for (i = OMAP3_STATE_C1; i < OMAP3_MAX_STATES; i++) {
> + if (enable_off_mode) {
> + omap3_power_states[i].valid = 1;
> + }
> + else {
> + if ((omap3_power_states[i].mpu_state
> + == PWRDM_POWER_OFF)
> + || (omap3_power_states[i].core_state
> + == PWRDM_POWER_RET))
> + omap3_power_states[i].valid = 0;
> + }
> + }
> +}
> +
> struct cpuidle_driver omap3_idle_driver = {
> .name = "omap3_idle",
> .owner =THIS_MODULE,
> @@ -303,6 +321,8 @@ int omap3_idle_init(void)
> return -EINVAL;
> dev->state_count = count;
>
> + omap3_cpuidle_update_states();
> +
> if (cpuidle_register_device(dev)) {
> printk(KERN_ERR "%s: CPUidle register device failed\n",
> __func__);
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 498f55d..d18fe49 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -86,6 +86,8 @@ extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
> extern void save_secure_ram_context(u32 *addr);
> extern void omap3_save_scratchpad_contents(void);
>
> +extern void omap3_cpuidle_update_states(void);
> +
> extern unsigned int omap24xx_idle_loop_suspend_sz;
> extern unsigned int omap34xx_suspend_sz;
> extern unsigned int save_secure_ram_context_sz;
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 9ce651a..6ebb4d1 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -968,6 +968,8 @@ void omap3_pm_off_mode_enable(int enable)
> else
> state = PWRDM_POWER_RET;
>
> + omap3_cpuidle_update_states();
> +
> #ifdef CONFIG_OMAP_PM_SRF
> resource_lock_opp(VDD1_OPP);
> resource_lock_opp(VDD2_OPP);
> --
> 1.6.2.2
>
> --
> 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: [RFC] Common mechanism to identify Si revision
Olof Johansson writes: > On Thu, Sep 03, 2009 at 04:14:28PM +0530, Premi, Sanjeev wrote: >> Hi, >> >> Currently there are multiple mechanisms for identifying the si revisions. >> >> Most places the comparison is against omap_rev() as a whole number. Example: >> >> arch/arm/mach-omap2/board-3430sdp.c:695:if (omap_rev() > >> OMAP3430_REV_ES1_0) >> arch/arm/mach-omap2/board-3430sdp.c:728:if (omap_rev() > >> OMAP3430_REV_ES1_0) >> >> Then, there are custom macros. Example (cpu.h): >> >> #define CHIP_GE_OMAP3430ES3_1(CHIP_IS_OMAP3430ES3_1) >> #define CHIP_GE_OMAP3430ES3 (CHIP_IS_OMAP3430ES3_0 | \ >> CHIP_GE_OMAP3430ES3_1) >> #define CHIP_GE_OMAP3430ES2 (CHIP_IS_OMAP3430ES2 | \ >> CHIP_GE_OMAP3430ES3) >> >> The problem with comparing against a whole number is that comparison is >> invalid >> for another processor series. E.g. OMAP3430 and OMAP3517. >> >> Here, I am proposing a common mechanism to identify the si revision; that >> focuses >> on the revision bits alone. (See code below) >> >> The usage would then be (example): >> >>if (omap_rev() > OMAP3430_REV_ES1_0) >> >> To >> >>if (cpu_is_omap34xx() && OMAP_REV_GT(OMAP_ES_1_0) > > What's the purpose of most of these checks in the first place? I can > see two immediate needs: > > 1) To check for various errata and do appropriate workarounds > > 2) To check if the current chip has a certain feature > > Both of these could just as well be abstracted away such that you use > tests on the form: > > if (OMAP_HAS_ERRATA_FOO) ... > > or: > if (OMAP_FEATURE_FOO) ... > > And then move the actual checking of a feature into the header file > where the errata/feature setups are defined. > > > There's two major benefits to this: > > 1) Readability. No need to sit and look up in a manual why there's a > check for version X here. > (and/or no need to add a specific comment about it). > > 2) Keeping changes centralized. If there's a new revision or chip, > there's just one header file to update, not 20 different source files. > > For example, a bunch of the checks in pm34xx.c would be nicer to have as: > > if (OMAP_HAS_USBHOST()) > I tend to agree with Olaf here and am in favor of the new 'features' patch that Sanjeev has already proposed. That doesn't mean that I'm opposed to this change in principle, but would rather see most of the omap_rev() and cpu_is_* checks disappear in favor of more generic omap_has_feature() checks. 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
V3 - mmc and omap_hsmmc patches
Hi Adrian, >[PATCH V3 0/30] mmc and omap_hsmmc patches What is the reason for V3? What is the difference between V2 and V3 series? Regards, Madhu -- 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: several OMAP newbie questions
Cliff Brake writes: > On Tue, Sep 1, 2009 at 6:34 AM, Mike Rapoport wrote: > >> 3) If I'm not much mistaken, board specific pin mux configuration has to deal >> with arch/arm/plat-omap/include/mach/mux.h and arch/arm/mach-omap2/mux.c. For >> instance, if my board uses ULPI pins that have not been defined already, I >> need >> to patch those file with my pin mux definitions. Am I right here, or have I >> missed something? > > It seems to me there should be a global mux configuration per CPU, but > should be configurable per board, group of boards, etc. What I would > like is a set of routines can be used to configure the mux that is > then called by the board files (similar to PXA). Especially once we > get into supporting multiple base boards with things like beagle and > overo, it would be nice to have have all this logic both places > (kernel/uboot), but maybe its needed there anyway. There is lots of agreement around the various shortcomings of the current mux framework for OMAP. All that's missing is someone to step up and do the work. :/ I started a new wiki topic at elinux.org for linux-omap wishlist items: http://elinux.org/OMAP_wishlist here I created a pin-mux section where we could start to keep track of the important features needed in a new mux framework. Adding pointers summaries to some other platforms might be useful here as well. This will help us get a start so when someone is ready to step up and do the work, we'll have a starting point. 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: FW: [RFC][PATCH]: Adding support for omap-serail driver
"HU TAO-TGHK48" writes:
> Resend to linux-omap
>
> -Original Message-
> From: HU TAO-TGHK48
> Sent: Monday, August 31, 2009 7:50 PM
> To: 'vimal singh'; linux-omap@vger.kernel.org; LKML;
> linux-ser...@vger.kernel.org
> Cc: Ye Yuan.Bo-A22116; Chen Xiaolong-A21785
> Subject: RE: [RFC][PATCH]: Adding support for omap-serail driver
>
>
> 1. Shall we cleanup PM related stuff in arch/arm/mach-omap2/serial.c as
> well?
> Originally serail.c register UART IRQ to decide if UART idle for a
> while and is able to enter low power mode (e.g. retention).
> To work with original 8250 driver, it is probably the only way since
> 8250 is not aware of OMAP PM.
>
> However it would be more reasonable to merge PM stuff to
> omap-serial.c. since the new driver is already OMAP specific
>
> 2. There is an issue for DMA with current implementation in serial.c
> When Rx DMA is active NO Rx IRQ will be generated.
> So serial.c will easily set uart->can_sleep with "1" even there is
> Rx DMA ongoing
> + if ((iir & 0x4) && up->use_dma) {
> + up->ier &= ~UART_IER_RDI;
> + serial_out(up, UART_IER, up->ier
>
>In my view, the best way is to do the idle detection in
> omap_serial.c.
FWIW, as the author of much of the PM hacker in mach-omap2/serial.c, I
agree with Tao.
The only reason for the PM hackery in mach-omap2/serial.c is because
of the limitations of the 8250 driver.
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
[PATCH] OMAP3: PM: Enable GPIO module-level wakeups
Currently, only GPIOs in the wakeup domain (GPIOs in bank 0) are enabled as wakups. This patch also enables GPIOs in the PER powerdomain (banks 2-6) to be used as possible wakeup sources. In addition, this patch ensures that all GPIO wakeups can wakeup the MPU using the PM_MPUGRPSEL_ registers. NOTE: this doesn't enable the individual GPIOs as wakeups, this simply enables the per-bank wakeups at the powerdomain level. This problem was discovered by Mike Chan when preventing the CORE powerdomain from going into retention/off. When CORE was allowed to hit retention, GPIO wakeups via IO pad were working fine, but when CORE remained on, GPIO module-level wakeups were not working properly. To test, prevent CORE from going inactive/retention/off, thus preventing the IO chain from being armed: # echo 3 > /debug/pm_debug/core_pwrdm/suspend This ensures that GPIO wakeups happen via module-level wakeups and not via IO pad. Tested on 3430SDP using the touchscreen GPIO (gpio 2, in WKUP) Tested on Zoom2 using the QUART interrup GPIO (gpio 102, in PER) Also, c.f. OMAP PM wiki for troubleshooting GPIO wakeup issues: http://elinux.org/OMAP_Power_Management Reported-by: Mike Chan Signed-off-by: Kevin Hilman --- arch/arm/mach-omap2/pm34xx.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 3d62b06..8166118 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -918,6 +918,16 @@ static void __init prcm_setup_regs(void) prm_write_mod_reg(OMAP3430_IO_EN | OMAP3430_WKUP_EN, OCP_MOD, OMAP3_PRM_IRQENABLE_MPU_OFFSET); + /* Enable GPIO wakeups in PER */ + prm_write_mod_reg(OMAP3430_EN_GPIO2 | OMAP3430_EN_GPIO3 | + OMAP3430_EN_GPIO4 | OMAP3430_EN_GPIO5 | + OMAP3430_EN_GPIO6, OMAP3430_PER_MOD, PM_WKEN); + /* and allow them to wake up MPU */ + prm_write_mod_reg(OMAP3430_GRPSEL_GPIO2 | OMAP3430_EN_GPIO3 | + OMAP3430_GRPSEL_GPIO4 | OMAP3430_EN_GPIO5 | + OMAP3430_GRPSEL_GPIO6, + OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL); + /* Don't attach IVA interrupts */ prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL); prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1); -- 1.6.4 -- 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
Odd crashes after 2.6.31-rc5
I've been working with the linux-omap kernel, and after 2.6.31-rc5 I
started seeing some strange crashes. A back trace is given here:
[ 46.620941] Unable to handle kernel paging request at virtual
address 512a
[ 46.628295] pgd = c71f4000
[ 46.631042] [512a] *pgd=878a6031, *pte=, *ppte=
[ 46.637451] Internal error: Oops: 17 [#1]
[ 46.641510] Modules linked in:
[ 46.644592] CPU: 0Not tainted (2.6.31-rc8-omap1 #24)
[ 46.650024] PC is at sysfs_open_file+0x6c/0x240
[ 46.654602] LR is at sysfs_open_file+0x54/0x240
[ 46.659149] pc : []lr : []psr: 2013
[ 46.659179] sp : c711be78 ip : fp :
[ 46.670715] r10: c780c1a0 r9 : 00020001 r8 : c743b8a0
[ 46.675964] r7 : c7863428 r6 : c0026980 r5 : c782bd20 r4 : c04de406
[ 46.682556] r3 : 5126 r2 : 0001 r1 : r0 : c7863428
[ 46.689117] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 46.696289] Control: 10c5387d Table: 871f4019 DAC: 0015
[ 46.702056] Process udevadm (pid: 520, stack limit = 0xc711a2e8)
[ 46.708099] Stack: (0xc711be78 to 0xc711c000)
[ 46.712493] be60:
c782bd20
[ 46.720886] be80: c743b8a0 c00e7024 c7439138 c780c1a0
c009b9bc c743b8a0 c782bd20
[ 46.729248] bea0: c78c9320 00020001 ff9c 0022 c711bef0
c009bc40 c78c9320
[ 46.737640] bec0: 00020002 c00a8f18
c01b1130 00d0 000280d0
[ 46.746032] bee0: c7ae6000 c04a50a8 c04a51b8 c780c1a0
c7439138 c711bf44 c7972608
[ 46.754425] bf00: 0003 c7407618 0101 0001
0001eb30 c01f0404
[ 46.762817] bf20: c7b4e4a0 c7b4e4b8 0003 c05e8e00
c782bda0 00020002
[ 46.771179] bf40: c782bd20 0003 c78e82c0 c78e82c8
c78e82c4 00020001
[ 46.779571] bf60: ff9c 0003 c786c000 c711a000
0001eb30 c009b7ec
[ 46.787963] bf80: c009b650 0001 bee01168
0005 c002c084 c711a000
[ 46.796356] bfa0: 00026df0 c002bf00 0001 bee01168
00020001 3100
[ 46.804718] bfc0: 0001 bee01168 0005 00026df4
00027008 00026df0 0001eb30
[ 46.813110] bfe0: 00026d00 bee01130 0001a868 400d84e8 6010
bee01168 6f79702e 34d80100
[ 46.821502] [] (sysfs_open_file+0x6c/0x240) from
[] (__dentry_open+0xbc/0x25c)
[ 46.830566] [] (__dentry_open+0xbc/0x25c) from
[] (nameidata_to_filp+0x58/0x60)
[ 46.839721] [] (nameidata_to_filp+0x58/0x60) from
[] (do_filp_open+0x598/0x82c)
[ 46.848876] [] (do_filp_open+0x598/0x82c) from
[] (do_sys_open+0x68/0x154)
[ 46.857574] [] (do_sys_open+0x68/0x154) from []
(ret_fast_syscall+0x0/0x2c)
[ 46.866363] Code: 0a10 e5963014 e353 0a3d (e5934004)
[ 46.872619] ---[ end trace 463c2798013d597e ]---
After bisecting I found the problem commit to be
e084b2d95e48b31aa45f9c49ffc6cdae8bdb21d4 ("page-allocator: preserve
PFN ordering when __GFP_COLD is set"). After reverting that commit, I
have no problems. The only thing that bothers me is that no one else
seems to have this problem.
Testing hardware: OSWALD board [1], OMAP 3530, 128Mb Ram, 256Mb NAND.
All peripherals have been disabled with no effect on the problem.
A git tree with the OSWALD added can be found at [2] if anyone is
interested, I will be submitting patches for OSWALD in the future, but
currently it is in no state to be submitted upstream (we have a very
small team).
Ben Goska
gos...@onid.oregonstate.edu
[1] - http://beaversource.oregonstate.edu/projects/cspfl/wiki
[2] - https://code.oregonstate.edu/git/oswald-kernel/?h=oswald-origin
--
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 10/10] omap mailbox: OMAP4 Mailbox-driver Patch to support tasklet implementation
From: "ext C.A, Subramaniam"
Subject: RE: [PATCH 10/10] omap mailbox: OMAP4 Mailbox-driver Patch to support
tasklet implementation
Date: Thu, 10 Sep 2009 13:46:53 +0200
>
>
> Hi Hiroshi,
>
> > -Original Message-
> > From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
> > Sent: Wednesday, September 09, 2009 2:32 PM
> > To: C.A, Subramaniam
> > Cc: linux-omap@vger.kernel.org; t...@atomide.com;
> > r...@arm.linux.org.uk; Kanigeri, Hari; Gupta, Ramesh
> > Subject: Re: [PATCH 10/10] omap mailbox: OMAP4 Mailbox-driver
> > Patch to support tasklet implementation
> >
> > Hi Subbu,
> >
> > From: "ext C.A, Subramaniam"
> > Subject: RE: [PATCH 10/10] omap mailbox: OMAP4 Mailbox-driver
> > Patch to support tasklet implementation
> > Date: Tue, 8 Sep 2009 19:43:48 +0200
> >
> > [...]
> >
> > > > As I described in the comment on [PATCH 8/10], I think
> > that it would
> > > > be better to keep "mach-omap2/mailbox.c" simple and to add some
> > > > additional logic on "plat-omap/mailbox.c".
> > > >
> > > > Would it be possbile to move this tasklet implementation to
> > > > "plat-omap/mailbox.c"?
> > >
> > > The implementation of the tasklet itself is maintained in
> > > plat-omap/mailbox.c Since, I wanted to maintain a separate
> > tasklet for
> > > each mailbox instance used to send messages from MPU, I had to
> > > associate the the tasklet to the mailbox. Hence, the
> > changes were done
> > > in mach-omap2/mailbox.c
> > >
> > > Please give your comments on this approach.
> >
> > Wouldn't just converting work_queue to tasklet work like below?
> >
> > (I havne't tested this at all, though...)
> >
> > diff --git a/arch/arm/plat-omap/include/mach/mailbox.h
> > b/arch/arm/plat-omap/include/mach/mailbox.h
> > index b7a6991..1f4e53e 100644
> > --- a/arch/arm/plat-omap/include/mach/mailbox.h
> > +++ b/arch/arm/plat-omap/include/mach/mailbox.h
> > @@ -52,6 +52,8 @@ struct omap_mbox {
> >
> > struct omap_mbox_queue *txq, *rxq;
> >
> > + struct tasklet_struct tx_tasklet;
> > +
> > struct omap_mbox_ops*ops;
> >
> > mbox_msg_t seq_snd, seq_rcv;
>
> Moved the tasklet structure to the omap_mbox_queue as follows:
This is better.
>
> @@ -40,7 +43,8 @@ struct omap_mbox_ops {
> struct omap_mbox_queue {
> spinlock_t lock;
> struct request_queue*queue;
> - struct work_struct work;
> + struct work_struct rx_work;
> + struct tasklet_struct tx_tasklet;
> int (*callback)(void *);
> struct omap_mbox*mbox;
> };
I think that "rx_/tx_" prefix may not be necessary if you add tasklet
feature in "omap_mbox_queue" as followed since "omap_mbox_queue" can
be considered as s/w queue which can evoke workqueue/tasklet
accordingly.
+ struct work_struct work;
+ struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
};
>
> Also chagned the omap_mbox_msg_send(). Removed the struct omap_msg_tx_data.
>
>
> int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
> {
> - struct omap_msg_tx_data *tx_data;
> +
> struct request *rq;
> struct request_queue *q = mbox->txq->queue;
>
> - tx_data = kmalloc(sizeof(*tx_data), GFP_ATOMIC);
> - if (unlikely(!tx_data))
> - return -ENOMEM;
> -
> rq = blk_get_request(q, WRITE, GFP_ATOMIC);
> - if (unlikely(!rq)) {
> - kfree(tx_data);
> + if (unlikely(!rq))
> return -ENOMEM;
> - }
>
> - tx_data->msg = msg;
> - rq->end_io = omap_msg_tx_end_io;
> - blk_insert_request(q, rq, 0, tx_data);
> + blk_insert_request(q, rq, 0, (void *) msg);
> + tasklet_schedule(&mbox->txq->tx_tasklet);
>
> - schedule_work(&mbox->txq->work);
> return 0;
> }
> EXPORT_SYMBOL(omap_mbox_msg_send);
>
> > diff --git a/arch/arm/plat-omap/mailbox.c
> > b/arch/arm/plat-omap/mailbox.c index 40424ed..37267ca 100644
> > --- a/arch/arm/plat-omap/mailbox.c
> > +++ b/arch/arm/plat-omap/mailbox.c
> > @@ -184,22 +184,17 @@ int omap_mbox_msg_send(struct omap_mbox
> > *mbox, mbox_msg_t msg, void* arg) }
> > EXPORT_SYMBOL(omap_mbox_msg_send);
> >
> > -static void mbox_tx_work(struct work_struct *work)
> > +static void mbox_tx_tasklet(unsigned long data)
> > {
> > int ret;
> > struct request *rq;
> > - struct omap_mbox_queue *mq = container_of(work,
> > - struct omap_mbox_queue, work);
> > - struct omap_mbox *mbox = mq->queue->queuedata;
> > + struct omap_mbox *mbox = (struct omap_mbox *)data;
> > struct request_queue *q = mbox->txq->queue;
> >
> > while (1) {
> > struct omap_msg_tx_data *tx_data;
> >
> > - spin_lock(q->queue_lock);
> > rq = blk_fetch_request(q);
> > - spin_unlock(q->queue_lock);
> > -
> > if (!rq)
> > break;
> >
> > @@ -208,15 +203,10 @@ static void mbox_tx
RE: [PATCH 10/10] omap mailbox: OMAP4 Mailbox-driver Patch to support tasklet implementation
Hi Hiroshi,
> -Original Message-
> From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
> Sent: Wednesday, September 09, 2009 2:32 PM
> To: C.A, Subramaniam
> Cc: linux-omap@vger.kernel.org; t...@atomide.com;
> r...@arm.linux.org.uk; Kanigeri, Hari; Gupta, Ramesh
> Subject: Re: [PATCH 10/10] omap mailbox: OMAP4 Mailbox-driver
> Patch to support tasklet implementation
>
> Hi Subbu,
>
> From: "ext C.A, Subramaniam"
> Subject: RE: [PATCH 10/10] omap mailbox: OMAP4 Mailbox-driver
> Patch to support tasklet implementation
> Date: Tue, 8 Sep 2009 19:43:48 +0200
>
> [...]
>
> > > As I described in the comment on [PATCH 8/10], I think
> that it would
> > > be better to keep "mach-omap2/mailbox.c" simple and to add some
> > > additional logic on "plat-omap/mailbox.c".
> > >
> > > Would it be possbile to move this tasklet implementation to
> > > "plat-omap/mailbox.c"?
> >
> > The implementation of the tasklet itself is maintained in
> > plat-omap/mailbox.c Since, I wanted to maintain a separate
> tasklet for
> > each mailbox instance used to send messages from MPU, I had to
> > associate the the tasklet to the mailbox. Hence, the
> changes were done
> > in mach-omap2/mailbox.c
> >
> > Please give your comments on this approach.
>
> Wouldn't just converting work_queue to tasklet work like below?
>
> (I havne't tested this at all, though...)
>
> diff --git a/arch/arm/plat-omap/include/mach/mailbox.h
> b/arch/arm/plat-omap/include/mach/mailbox.h
> index b7a6991..1f4e53e 100644
> --- a/arch/arm/plat-omap/include/mach/mailbox.h
> +++ b/arch/arm/plat-omap/include/mach/mailbox.h
> @@ -52,6 +52,8 @@ struct omap_mbox {
>
> struct omap_mbox_queue *txq, *rxq;
>
> + struct tasklet_struct tx_tasklet;
> +
> struct omap_mbox_ops*ops;
>
> mbox_msg_t seq_snd, seq_rcv;
Moved the tasklet structure to the omap_mbox_queue as follows:
@@ -40,7 +43,8 @@ struct omap_mbox_ops {
struct omap_mbox_queue {
spinlock_t lock;
struct request_queue*queue;
- struct work_struct work;
+ struct work_struct rx_work;
+ struct tasklet_struct tx_tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
};
Also chagned the omap_mbox_msg_send(). Removed the struct omap_msg_tx_data.
int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
{
- struct omap_msg_tx_data *tx_data;
+
struct request *rq;
struct request_queue *q = mbox->txq->queue;
- tx_data = kmalloc(sizeof(*tx_data), GFP_ATOMIC);
- if (unlikely(!tx_data))
- return -ENOMEM;
-
rq = blk_get_request(q, WRITE, GFP_ATOMIC);
- if (unlikely(!rq)) {
- kfree(tx_data);
+ if (unlikely(!rq))
return -ENOMEM;
- }
- tx_data->msg = msg;
- rq->end_io = omap_msg_tx_end_io;
- blk_insert_request(q, rq, 0, tx_data);
+ blk_insert_request(q, rq, 0, (void *) msg);
+ tasklet_schedule(&mbox->txq->tx_tasklet);
- schedule_work(&mbox->txq->work);
return 0;
}
EXPORT_SYMBOL(omap_mbox_msg_send);
> diff --git a/arch/arm/plat-omap/mailbox.c
> b/arch/arm/plat-omap/mailbox.c index 40424ed..37267ca 100644
> --- a/arch/arm/plat-omap/mailbox.c
> +++ b/arch/arm/plat-omap/mailbox.c
> @@ -184,22 +184,17 @@ int omap_mbox_msg_send(struct omap_mbox
> *mbox, mbox_msg_t msg, void* arg) }
> EXPORT_SYMBOL(omap_mbox_msg_send);
>
> -static void mbox_tx_work(struct work_struct *work)
> +static void mbox_tx_tasklet(unsigned long data)
> {
> int ret;
> struct request *rq;
> - struct omap_mbox_queue *mq = container_of(work,
> - struct omap_mbox_queue, work);
> - struct omap_mbox *mbox = mq->queue->queuedata;
> + struct omap_mbox *mbox = (struct omap_mbox *)data;
> struct request_queue *q = mbox->txq->queue;
>
> while (1) {
> struct omap_msg_tx_data *tx_data;
>
> - spin_lock(q->queue_lock);
> rq = blk_fetch_request(q);
> - spin_unlock(q->queue_lock);
> -
> if (!rq)
> break;
>
> @@ -208,15 +203,10 @@ static void mbox_tx_work(struct
> work_struct *work)
> ret = __mbox_msg_send(mbox, tx_data->msg, tx_data->arg);
> if (ret) {
> enable_mbox_irq(mbox, IRQ_TX);
> - spin_lock(q->queue_lock);
> blk_requeue_request(q, rq);
> - spin_unlock(q->queue_lock);
> return;
> }
> -
> - spin_lock(q->queue_lock);
> __blk_end_request_all(rq, 0);
> - spin_unlock(q->queue_lock);
> }
> }
>
Changed the mbox_tx_tasklet as follows:
-static void mbox_tx_work(struct work_struct *work)
+static void mbox_tx_tasklet(unsigned long tx_data)
{
int ret;
struct request *rq;
-
[PATCH-v3 3/3] OMAP: Zoom2: Enable NAND in defconfig
From: Vimal Singh Enable NAND options by default in zoom2_defconfig file Other changes in defconfig come from make menuconfig syncup Signed-off-by: Vikram Pandita Signed-off-by: Vimal Singh --- arch/arm/configs/omap_zoom2_defconfig | 241 -- 1 files changed, 177 insertions(+), 64 deletions(-) Index: linux-omap-2.6/arch/arm/configs/omap_zoom2_defconfig === --- linux-omap-2.6.orig/arch/arm/configs/omap_zoom2_defconfig +++ linux-omap-2.6/arch/arm/configs/omap_zoom2_defconfig @@ -1,7 +1,7 @@ # # 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.31-rc9-omap1 +# Thu Sep 10 15:27:16 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -9,7 +9,6 @@ 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 +17,12 @@ 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_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 @@ -77,7 +75,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,7 +87,12 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y + +# +# Performance Counters +# CONFIG_VM_EVENT_COUNTERS=y +# CONFIG_STRIP_ASM_SYMS is not set CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set @@ -102,6 +104,10 @@ CONFIG_HAVE_OPROFILE=y 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 +120,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 @@ -141,13 +147,14 @@ CONFIG_FREEZER=y # 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_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set @@ -156,25 +163,25 @@ 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_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 # # TI OMAP Implementations @@ -203,19 +210,21 @@ CONFIG_OMAP_DM_TIMER=y # CONFIG_OMAP_LL_DEBUG_UART1 is not set # CONFIG_OMAP_LL_DEBUG_UART2 is not set CONFIG_OMAP_LL_DEBUG_UART3=y +# CONFIG_OMAP_PM_NONE is not set +CONFIG_OMAP_PM_NOOP=y CONFIG_ARCH_OMAP34XX=y CONFIG_ARCH_OMAP3430=y # # OMAP Board Type # -# CONFIG_MACH_NOKIA_RX51 is not set -# CONFIG_MACH_OMAP_LDP is not set -# CONFIG_MACH_OMAP_3430SDP is not set -# CONFIG_MACH_OMAP3EVM is not set # CONFIG_MACH_OMAP3_BEAGLE is not set +# CONFIG_MACH_OMAP_LDP is not set # CONFIG_MACH_OVERO is not set +# CONFIG_MACH_OMAP3EVM is not set # CONFIG_MACH_OMAP3_PANDORA is not set +# CONFIG_MACH_OMAP_3430SDP is not set +# CONFIG_MACH_NOKIA_RX51 is not set CONFIG_MACH_OMAP_ZOOM2=y # @@ -244,7 +253,6 @@ CONFIG_ARM_THUMB=y # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_CPU_BPREDICT_DISABLE is not set CONFIG_HAS_TLS_REG=y -# CONFIG_OUTER_CACHE is not set # CONFIG_ARM_ERRATA_430973 is not set # CONFIG_ARM_ERRATA_458693 is not set # CONFIG_ARM_ERRATA_460075 is not set @@ -272,7 +280,6 @@
[PATCH-v3 2/3] OMAP3: Add support for NAND on ZOOM2/LDP boards
Sorry I clicked on -send- button without $SUBJECT. Correcting this time.
-vimal
From: Vimal Singh
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.
In v-3: Corrected prototype of 'unlock' function pointer in structure
'omap_nand_platform_data'.
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/mach/board-zoom.h | 36
arch/arm/plat-omap/include/mach/nand.h |2
6 files changed, 240 insertions(+)
Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile
+++ linux-omap-2.6/arch/arm/mach-omap2/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_MACH_OMAP_APOLLON) += boar
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-
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
Index: linux-omap-2.6/arch/arm/mach-omap2/board-ldp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-ldp.c
+++ linux-omap-2.6/arch/arm/mach-omap2/board-ldp.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "mmc-twl4030.h"
@@ -381,6 +382,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 */
Index: linux-omap-2.6/arch/arm/mach-omap2/board-zoom-flash.c
===
--- /dev/null
+++ linux-omap-2.6/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, size_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(KERN_ERR "nand_unlock: Length must be a multiple of "
+ "nand page size!\n");
+
[no subject]
From: Vimal Singh
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.
In v-3: Corrected prototype of 'unlock' function pointer in structure
'omap_nand_platform_data'.
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/mach/board-zoom.h | 36
arch/arm/plat-omap/include/mach/nand.h |2
6 files changed, 240 insertions(+)
Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile
+++ linux-omap-2.6/arch/arm/mach-omap2/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_MACH_OMAP_APOLLON) += boar
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-
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
Index: linux-omap-2.6/arch/arm/mach-omap2/board-ldp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-ldp.c
+++ linux-omap-2.6/arch/arm/mach-omap2/board-ldp.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "mmc-twl4030.h"
@@ -381,6 +382,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 */
Index: linux-omap-2.6/arch/arm/mach-omap2/board-zoom-flash.c
===
--- /dev/null
+++ linux-omap-2.6/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, size_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(KERN_ERR "nand_unlock: Length must be a multiple of "
+ "nand page size!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* submit addres
[PATCH-v3 1/3 ] OMAP2/3: Add support for flash on SDP boards
From: Vimal Singh 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 Signed-off-by: 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/mach-omap2/board-sdp.h| 15 + arch/arm/plat-omap/include/mach/gpmc.h |2 6 files changed, 350 insertions(+) Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile === --- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile +++ linux-omap-2.6/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-om 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 \ Index: linux-omap-2.6/arch/arm/mach-omap2/board-2430sdp.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-2430sdp.c +++ linux-omap-2.6/arch/arm/mach-omap2/board-2430sdp.c @@ -38,6 +38,7 @@ #include #include +#include "board-sdp.h" #include "mmc-twl4030.h" #define SDP2430_CS0_BASE 0x0400 @@ -205,6 +206,7 @@ static void __init omap_2430sdp_init(voi 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"); Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c +++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c @@ -41,6 +41,7 @@ #include #include +#include "board-sdp.h" #include "sdram-qimonda-hyb18m512160af-6.h" #include "mmc-twl4030.h" @@ -495,6 +496,7 @@ static void __init omap_3430sdp_init(voi omap_serial_init(); usb_musb_init(); board_smc91x_init(); + sdp_flash_init(); usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61); enable_board_wakeup_source(); } Index: linux-omap-2.6/arch/arm/mach-omap2/board-sdp-flash.c === --- /dev/null +++ linux-omap-2.6/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 PDC_NAND 2 +#define PDC_ONENAND3 +#define DBG_MPDB 4 + +/* REVISIT: Does for some x, chip_sel_sdp[x] maches for 2430 SDP ? */ + +/* SDP3430
[PATCH-v3 0/3] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards
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 OMAP: Zoom2: Enable NAND and JFFS2 in defconfig OMAP2/3: Add support for flash on SDP boards OMAP3: Add support for NAND on ZOOM2/LDP boards arch/arm/omap_zoom2_defconfig | 241 +-- arch/arm/mach-omap2/Makefile|4 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/mach-omap2/board-sdp.h | 15 + arch/arm/plat-omap/include/mach/gpmc.h |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/mach/board-zoom.h | 36 ++ arch/arm/plat-omap/include/mach/nand.h |2 12 files changed, 767 insertions(+), 64 deletions(-) create mode 100644 arch/arm/mach-omap2/board-sdp-flash.c create mode 100644 arch/arm/mach-omap2/board-sdp.h create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c create mode 100644 arch/arm/plat-omap/include/mach/board-zoom.h -- 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-v2 0/3] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards
Hi Vikram, I am going to post version-3 for these patches due to below updates/fixes: PATCH 2/3: Add support for NAND on ZOOM2/LDP boards 1. prototype mismatch for 'unlock' funtion pointer in 'mach/nand.h and in 'mtd_struct' 2. typo error (Singned -> Signed) indicated by Kishore. PATCH 3/3: Zoom2: Enable NAND in defconfig 1. Disabling 'CONFIG_MTD_NAND_VERIFY_WRITE' and 'CONFIG_MTD_NAND_ECC_SMC' in from previous patch 2. Enabling CONFIG_JFFS2_FS in addition, to support NAND devices. Patch 1/3: Add support for flash on SDP boards will remain unchanged. -- Regards, Vimal Singh On Fri, Sep 4, 2009 at 12:55 AM, Vikram Pandita wrote: > 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 > > Vikram Pandita (1): > OMAP: Zoom2: Enable NAND in defconfig > > Vimal Singh (2): > OMAP2/3: Add support for flash on SDP boards > OMAP3: Add support for NAND on ZOOM2/LDP boards > > arch/arm/configs/omap_zoom2_defconfig | 224 +- > arch/arm/mach-omap2/Makefile | 4 + > 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 | 326 > ++ > arch/arm/mach-omap2/board-sdp.h | 15 ++ > arch/arm/mach-omap2/board-zoom-flash.c | 196 > arch/arm/mach-omap2/board-zoom2.c | 2 + > arch/arm/plat-omap/include/mach/board-zoom.h | 36 +++ > arch/arm/plat-omap/include/mach/gpmc.h | 2 + > arch/arm/plat-omap/include/mach/nand.h | 1 + > 12 files changed, 748 insertions(+), 64 deletions(-) > create mode 100644 arch/arm/mach-omap2/board-sdp-flash.c > create mode 100644 arch/arm/mach-omap2/board-sdp.h > create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c > create mode 100644 arch/arm/plat-omap/include/mach/board-zoom.h > > -- > 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: [RFC] Common mechanism to identify Si revision
Hello Sanjeev, On Thu, 3 Sep 2009, Premi, Sanjeev wrote: > Here, I am proposing a common mechanism to identify the si revision; that > focuses > on the revision bits alone. (See code below) > > The usage would then be (example): > >if (omap_rev() > OMAP3430_REV_ES1_0) > > To > >if (cpu_is_omap34xx() && OMAP_REV_GT(OMAP_ES_1_0) For use in structures like clock34xx.h and powerdomains34xx.h, would you propose that we use two different fields then - one for OMAP type, the other for revision restrictions? Or a different scheme? - Paul -- 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
