RE: Question on OPP table handling
Hi Kevin,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Nishanth Menon
> Sent: Monday, October 05, 2009 7:19 PM
> To: linux-omap@vger.kernel.org
> Cc: Premi, Sanjeev; Kevin H
> Subject: Re: Question on OPP table handling
>
> Kevin Hilman had written, on 10/05/2009 11:56 AM, the following:
> > "Premi, Sanjeev" writes:
> >
> >>> -Original Message-
> >>> From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
> >>> Sent: Saturday, October 03, 2009 8:35 PM
> >>> To: Premi, Sanjeev
> >>> Cc: linux-omap@vger.kernel.org
> >>> Subject: Question on OPP table handling
> >>>
> >>> Sanjeev Premi said the following on 10/01/2009 01:03 PM:
> +struct omap_opp omap3_mpu_rate_table[] = {
> +{0, 0, 0},
> +/*OPP1*/
> +{S125M, VDD1_OPP1, 0x1E},
> +/*OPP2*/
> +{S250M, VDD1_OPP2, 0x26},
> +/*OPP3*/
> +{S500M, VDD1_OPP3, 0x30},
> +/*OPP4*/
> +{S550M, VDD1_OPP4, 0x36},
> +/*OPP5*/
> +{S600M, VDD1_OPP5, 0x3C},
> +};
>
> >>> For those involved,
> >>> if we wanted to convert omap3_mpu_table[] into
> >>> *omap3_mpu_table so that
> >>> we dynamically initialize it based on cpu type - what would be the
> >>> recommendations?
> >> Nishanth,
> >>
> >> Good idea!
> >>
> >> As a table, previous patch enables it (not as intent, but due to
> syntax):
> >>
> >> > +/* 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;
> >> > +};
> >>
> >> But now, I think it would be good to have an API that can fill an
> opp_table:
> >>
> >> int add_opp_definition(u8 id, u32 freq, u16 vsel);
> >>
> >> ...and, if an array is preferred, length can be set as:
> >> int set_opp_table_length (u8 max);
> >
> > I'm all for dynamic OPP setting, but not as an array. A list should
> > probably be used.
>
> Won't a list implementation cause more than necessary overhead? I agree
> that something like set_opp_table_length probably might be redundant in
> that case.
I'm aligned with Nishanth. I think a static table with the possibility to
disable some entry is good enough to deal with most of the OPPs we have on
OMAP3 and we will have to handle on OMAP4.
OPPs are defined during silicon characterization, and should not be changed
dynamically (in theory).
Do you have something in mind that might justify a dynamic management?
Regards,
Benoit
> >> If I were to extend the discussion from other thread on toggling the
> valid OPPs
> >> based on "enable_off_mode", these could be handy.
> >>
> >> int set_opp_valid(bool flag);
> >> bool is_opp_valid(void);
> >>
> >
> > Yes, we need a concept of a valid OPP, not just for OFF mode, but for
> > OSWR and possibly for a full constraint framework as well.
> Ack.
> --
> 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
--
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: Question on OPP table handling
> -Original Message- > From: Menon, Nishanth > Sent: Tuesday, October 06, 2009 2:04 PM > To: Dasgupta, Romit > Cc: Premi, Sanjeev; Cousson, Benoit; Kevin H; linux-omap@vger.kernel.org > Subject: Re: Question on OPP table handling > > Dasgupta, Romit had written, on 10/06/2009 07:00 AM, the following: > >> Couple of opinions on why a list with disabled/invalid marker might not > >> make sense as a grand unified OPP table: > >> a) it is no better than a list implementation > >> b) it is a waste of memory. > > [Romit] Put all the OPP tables for different OPPs in __initdata. Copy > the runtime detected CPU's OPP table in memory. Others get discarded! > > > I like this approach.. takers? > I think it is not enough. Some OPPs will be selected based on runtime CPU detection, but some OPPs might be disabled dynamically for some usecase depending of external parameters. Regards, Benoit -- 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: Question on OPP table handling
> -Original Message- > From: Dasgupta, Romit > Sent: Tuesday, October 06, 2009 2:14 PM > To: Cousson, Benoit; Menon, Nishanth > Cc: Premi, Sanjeev; Kevin H; linux-omap@vger.kernel.org > Subject: RE: Question on OPP table handling > > >> Dasgupta, Romit had written, on 10/06/2009 07:00 AM, the following: > >> >> Couple of opinions on why a list with disabled/invalid marker might > not > >> >> make sense as a grand unified OPP table: > >> >> a) it is no better than a list implementation > >> >> b) it is a waste of memory. > >> > [Romit] Put all the OPP tables for different OPPs in __initdata. Copy > >> the runtime detected CPU's OPP table in memory. Others get discarded! > >> > > >> I like this approach.. takers? > >> > > > >I think it is not enough. Some OPPs will be selected based on runtime CPU > >detection, but some OPPs might be disabled dynamically for some usecase > >depending of external parameters. > > [Romit] For a given SoC and type you can have only one OPP table. Isn't > that true? Yes, it is true but you might have to disable dynamically some OPP (like OPP5 and OPP4) for thermal management reason. The way the resource is handled today, you cannot force the reduction of the frequency in case of thermal issue. I agree that there might be more elegant way to deal with that, but we can take advantage of disabling dynamically any OPP to do it. -- 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: Discussion: OMAP: PM: opp table handling
>From: Pandita, Vikram > > >Proposals for OPP table handling for OMAP34xx/35xx/36xx/44xx > >Thanks to all the community members for taking time for this discussion. >This will aid upsteaming of 35xx/36xx/44xx in coming future. > >Attendees: Kevin Hilman, Paul, Nishant M, Santosh, Madhu, Benoit, Rajendra, >Benoit, Vikram > >Problem Statement: > OMAP34xx has certain opp requirements (3420/3430/3440) > OMAP35xx reuses the opp's from 34xx > OMAP36xx has a totally new set of opps > OMAP44xx has a totally new set of opps > >Solution: > Align on a common approach to take for the Opp table definitions. > >Define Separate Tables for each family as follows: >Step 1: Go with this approach: > 3420(65nm) : new arrays [defer for now] > 3430/35xx(65nm) : new arrays ** > 3440(65nm) : new arrays [defer for now] > 3630(45nm) : new arrays > Omap4(45nm) : new arrays > > * new arrays = (mpu, dsp, l3) > ** Check this valid flag. Kevin can take this base on comments > http://marc.info/?l=linux-omap&m=125512448216071&w=2 > between 3430/35xx, opp's can be managed with a flag and same >table re-used > 35xx has requirement for 720Mhz opp > >Step 2: >Kevin suggestion: >Define accessor APIs get the OPPs >Check Users of accessor API > DVFS > constraints > sysfs debug > Define accessor api's eg: > index = get_opp(VDD1_OPP1); > num = get_max_opp(VDD1); > set_opp(index); I think we should as well change the naming and use the less confusing naming we are using on OMAP3630/4430. OPPs are now named using the performance delta from the nominal frequency. OPP25, OPP50, OPP80, OPP100, OPP120... Regards, Benoit >Step 3: > Paul suggestion: > VSEL values in opp table should be in terms of voltage > Non TWL IC's need this > >Step4: > Paul suggestion: > VDD1 VDD2 dependencies for different chips > Inter-connect load predictor is absent on omap3 and hence VDD1-vdd2 >dependency > OMAP4 > interconnect loading can be measured from registers > Multi-cores dependency > >Step 5: > Paul suggestion: > Board files adding OPPs, Modifying OPPs > Eg: Pendora passing its own opp -- 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: Discussion: OMAP: PM: opp table handling
>-Original Message- >From: Menon, Nishanth > >> -Original Message- >> From: Cousson, Benoit >> Sent: Wednesday, October 14, 2009 11:06 AM >> To: Pandita, Vikram; linux-omap@vger.kernel.org >> >> >From: Pandita, Vikram >> > >> > >> >Proposals for OPP table handling for OMAP34xx/35xx/36xx/44xx >> > >> >Thanks to all the community members for taking time for this discussion. >> >This will aid upsteaming of 35xx/36xx/44xx in coming future. >> > >> >Attendees: Kevin Hilman, Paul, Nishant M, Santosh, Madhu, Benoit, >> Rajendra, >> >Benoit, Vikram >> > >> >Problem Statement: >> >OMAP34xx has certain opp requirements (3420/3430/3440) >> >OMAP35xx reuses the opp's from 34xx >> >OMAP36xx has a totally new set of opps >> >OMAP44xx has a totally new set of opps >> > >> >Solution: >> >Align on a common approach to take for the Opp table definitions. >> > >> >Define Separate Tables for each family as follows: >> >Step 1: Go with this approach: >> >3420(65nm) : new arrays [defer for now] >> >3430/35xx(65nm) : new arrays ** >> >3440(65nm) : new arrays [defer for now] >> >3630(45nm) : new arrays >> >Omap4(45nm) : new arrays >> > >> >* new arrays = (mpu, dsp, l3) >> >** Check this valid flag. Kevin can take this base on comments >> >http://marc.info/?l=linux-omap&m=125512448216071&w=2 >> >between 3430/35xx, opp's can be managed with a flag and same >> >table re-used >> >35xx has requirement for 720Mhz opp >> > >> >Step 2: >> >Kevin suggestion: >> >Define accessor APIs get the OPPs >> >Check Users of accessor API >> >DVFS >> >constraints >> >sysfs debug >> >Define accessor api's eg: >> >index = get_opp(VDD1_OPP1); >> >num = get_max_opp(VDD1); >> >set_opp(index); >> >> I think we should as well change the naming and use the less confusing >> naming we are using on OMAP3630/4430. >> OPPs are now named using the performance delta from the nominal frequency. >> OPP25, OPP50, OPP80, OPP100, OPP120... >NAK for two reasons: >a) h/w changes language of OPP definitions every other silicons -> OPP100 >is not more informative than OPP1 or OPPX for that matter - with proper >comments, even something like >/* OPP25 - 25% of nominal performance */ >#define VDD1_OPP_RELLLY_SLOW_OPP 1 >Makes sense. Well, this is your point of view, but having a define named OPP100 is a little bit more informative, for my point of view, than OPP3 especially when the same OPP was named OPP1 in previous ES. Nevermind, it was just a quick and non intrusive fix to do but the next point will make it useless. >b) if you look at discussion - we really DON'T want to use OPP definitions >anymore - we would like folks to use frequency for precisely that reason - >it is frequency that matters in the system. I agree it is even better. FYI, and if you look at the discussion, that direction is not obvious at all... There is even a get_opp(VDD1_OPP1) in the email... What part of the email is explaining that? Maybe I missed it. >c) the field for OPP idx is probably redundant once we have proper APIs in >place. Agree. Regards, Benoit >> >> >Step 3: >> >Paul suggestion: >> >VSEL values in opp table should be in terms of voltage >> >Non TWL IC's need this >> > >> >Step4: >> >Paul suggestion: >> >VDD1 VDD2 dependencies for different chips >> >Inter-connect load predictor is absent on omap3 and hence VDD1-vdd2 >> >dependency >> >OMAP4 >> >interconnect loading can be measured from registers >> >Multi-cores dependency >> > >> >Step 5: >> >Paul suggestion: >> >Board files adding OPPs, Modifying OPPs >> >Eg: Pendora passing its own opp >> >> > > >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 06/17] OMAP3: PM: Added next state check for IVA2, USB and PER into idle loop
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
>Sent: Friday, October 16, 2009 3:16 PM
>To: Tero Kristo; linux-omap@vger.kernel.org
>Subject: RE: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB
>and PER into idle loop
>
> >From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Tero Kristo
> >Sent: Friday, October 16, 2009 5:49 AM
> >To: linux-omap@vger.kernel.org
> >Subject: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB
>and PER into idle loop
> >
> >From: Tero Kristo
> >
> >This is needed to prevent core from entering off mode if one of the IVA2,
> >USB or PER powerdomains are going to stay at least in retention state.
> >If this is not done, a powerdomain waking from RET may access core
> >domain which has just been reset.
> >
>From PRCM HW point of view, if any of non core domains do not enter OFF
>mode, then Core cannot enter off mode. So I do not understand why you want
>to do this change.
This is perfectly valid for the PRCM point of view to have the CORE OFF while
another power domain is ON. The sleep dependency is at the clock domains level.
It means that all initiators need to be mute and all targets must be in idle,
but the power domain can be ON.
Regards,
Benoit
> >Signed-off-by: Tero Kristo
> >---
> > arch/arm/mach-omap2/pm34xx.c | 36 +++-
> > 1 files changed, 31 insertions(+), 5 deletions(-)
> >
> >diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> >index 588ab79..3e5ae14 100644
> >--- a/arch/arm/mach-omap2/pm34xx.c
> >+++ b/arch/arm/mach-omap2/pm34xx.c
> >@@ -85,6 +85,13 @@ u32 voltage_off_while_idle;
> > OMAP3430_ST_DES1_MASK)
> > #define CORE_IDLEST3_ALL(\
> > OMAP3430ES2_ST_USBTLL_MASK|OMAP3430ES2_ST_CPEFUSE_MASK)
> >+#define PER_IDLEST_ALL (\
> >+OMAP3430_ST_WDT3_MASK|OMAP3430_ST_MCBSP4_MASK|\
> >+OMAP3430_ST_MCBSP3_MASK|OMAP3430_ST_MCBSP2_MASK|\
> >+OMAP3430_ST_GPT9_MASK|OMAP3430_ST_GPT8_MASK|\
> >+OMAP3430_ST_GPT7_MASK|OMAP3430_ST_GPT6_MASK|\
> >+OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
> >+OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
> >
> > struct power_state {
> > struct powerdomain *pwrdm;
> >@@ -103,7 +110,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
> >
> > static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> > static struct powerdomain *core_pwrdm, *per_pwrdm;
> >-static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
> >+static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm,
>*usb_pwrdm;
> >
> > static struct prm_setup_vc prm_setup = {
> > .clksetup = 0xff,
> >@@ -428,6 +435,8 @@ void omap_sram_idle(void)
> > int per_next_state = PWRDM_POWER_ON;
> > int core_next_state = PWRDM_POWER_ON;
> > int dss_state = PWRDM_POWER_ON;
> >+int iva2_state = PWRDM_POWER_ON;
> >+int usb_state = PWRDM_POWER_ON;
> > int core_prev_state, per_prev_state;
> > u32 sdrc_pwr = 0;
> > int per_state_modified = 0;
> >@@ -463,14 +472,28 @@ void omap_sram_idle(void)
> > if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
> > pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
> >
> >+/* Get powerdomain state data */
> >+core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
> >+dss_state = pwrdm_read_pwrst(dss_pwrdm);
> >+iva2_state = pwrdm_read_pwrst(iva2_pwrdm);
> >+usb_state = pwrdm_read_pwrst(usb_pwrdm);
> >+per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
> >+
> >+/* Check if PER domain can enter OFF or not */
> >+if (per_next_state == PWRDM_POWER_OFF) {
> >+if ((cm_read_mod_reg(OMAP3430_PER_MOD, CM_IDLEST) &
> >+PER_IDLEST_ALL) != PER_IDLEST_ALL) {
> >+per_next_state = PWRDM_POWER_RET;
> >+pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
> >+per_state_modified = 1;
> >+}
> >+}
> > /*
> > * Check whether core will enter idle or not. This is needed
> > * because I/O pad wakeup will fail if core stays on and PER
> > * enters off. This will also prevent unnecessary core context
> > * save / restore.
> > */
> >-core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
> >-dss_state = pwrdm_read_pwrst(dss_pwrdm);
> > if (core_next_state < PWRDM_POWER_ON) {
> > core_saved_state = core_next_state;
> > if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1) & CORE_IDLEST1_ALL)
> >@@ -482,14 +505,16 @@ void omap_sram_idle(void)
> > core_next_state = PWRDM_POWER_ON;
> > pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_ON);
> > } else if (core_next_state == PWRDM_POWER_OFF &&
> >- dss_state == PWRDM_POWER_ON) {
> >+
RE: [PATCH 03/17] PM: Block CORE off when DSS is active
Hi Tero,
>
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Tero Kristo
>Sent: Friday, October 16, 2009 12:49 PM
>To: linux-omap@vger.kernel.org
>Cc: Kalle Jokiniemi
>Subject: [PATCH 03/17] PM: Block CORE off when DSS is active
>
>From: Kalle Jokiniemi
>
>If CORE power domain is allowed to reach off state
>while display is active, the display will go blank.
>Fixed by adding a check in idle loop.
What is root cause? I guess it is due to extra latency required to wakeup from
OFF?
In that case, it should be better to use the omap_pm_set_max_dev_wakeup_lat()
function and set a latency constraint to the CORE.
On the other hand, I remember a discussion between Kevin and Tomi saying that
this API might not be fully functional yet.
Regards,
Benoit
>Signed-off-by: Kalle Jokiniemi
>Signed-off-by: Jouni Hogander
>---
> arch/arm/mach-omap2/pm34xx.c |9 -
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>index e8704a6..52a3f2b 100644
>--- a/arch/arm/mach-omap2/pm34xx.c
>+++ b/arch/arm/mach-omap2/pm34xx.c
>@@ -103,7 +103,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
>
> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> static struct powerdomain *core_pwrdm, *per_pwrdm;
>-static struct powerdomain *cam_pwrdm, *iva2_pwrdm;
>+static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
>
> static struct prm_setup_vc prm_setup = {
> .clksetup = 0xff,
>@@ -427,6 +427,7 @@ void omap_sram_idle(void)
> int mpu_next_state = PWRDM_POWER_ON;
> int per_next_state = PWRDM_POWER_ON;
> int core_next_state = PWRDM_POWER_ON;
>+ int dss_state = PWRDM_POWER_ON;
> int core_prev_state, per_prev_state;
> u32 sdrc_pwr = 0;
> int per_state_modified = 0;
>@@ -469,6 +470,7 @@ void omap_sram_idle(void)
>* save / restore.
>*/
> core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
>+ dss_state = pwrdm_read_pwrst(dss_pwrdm);
> if (core_next_state < PWRDM_POWER_ON) {
> core_saved_state = core_next_state;
> if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1) & CORE_IDLEST1_ALL)
>@@ -479,6 +481,10 @@ void omap_sram_idle(void)
> CORE_IDLEST3_ALL) != CORE_IDLEST3_ALL) {
> core_next_state = PWRDM_POWER_ON;
> pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_ON);
>+ } else if (core_next_state == PWRDM_POWER_OFF &&
>+ dss_state == PWRDM_POWER_ON) {
>+ core_next_state = PWRDM_POWER_RET;
>+ pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_RET);
> }
> }
>
>@@ -1234,6 +1240,7 @@ static int __init omap3_pm_init(void)
> core_pwrdm = pwrdm_lookup("core_pwrdm");
> cam_pwrdm = pwrdm_lookup("cam_pwrdm");
> iva2_pwrdm = pwrdm_lookup("iva2_pwrdm");
>+ dss_pwrdm = pwrdm_lookup("dss_pwrdm");
>
> omap_push_sram_idle();
> #ifdef CONFIG_SUSPEND
>--
>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] OMAP3: DVFS: No sdrc AC timing changes during core dvfs
Hi Richard, >From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >ow...@vger.kernel.org] On Behalf Of Woodruff, Richard > >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@vger.kernel.org] On Behalf Of Paul Walmsley >> Sent: Tuesday, October 20, 2009 8:21 PM > >> > This patch removes the SDRC AC timings changes done during core dvfs. >> > Updating AC timing CTRL values for SDRC during DVFS is seen to be a >risk, >> > while the RFR CTRL value is safe to be updated. >> > >> > Signed-off-by: Rajendra Nayak >> >> just wanted to let you know, I haven't forgotten about this one. Am >trying >> to get an answer from others as to whether AC timing register changes are >> completely unsafe, in which case your patch is probably the best way to >> move forward; or whether we can make the changes when no initiators are >> touching SDRAM. > >It is not guaranteed safe to write actim registers on the fly to an active >part. It is safe to do RFR as it is buffered and sent out at a safe time. I think that what Paul is suggesting is to change the ACTIM after ensuring that the DDR is in self-refresh. In that case it is perfectly valid; it is just tricky to ensure that all initiators are in mute before doing that. Regards, Benoit >A few years back before omap3 as part of omap2 lessons learned this issue >was highlighted but design was not able to change. Recently implementation >review at rtl provided the above points. > >I'm not aware of anyone seeing a crash but recommendation for safety is to >not. > >Regards, >Richard W. > >-- >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 Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -- 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
Hi Nishanth,
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
>
> Refactor the smart reflex implementation.
[snip]
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
> omap2/smartreflex.c
> new file mode 100644
> index 000..d506896
> --- /dev/null
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -0,0 +1,1604 @@
> +/*
> + * linux/arch/arm/mach-omap3/smartreflex.c
> + *
> + * OMAP34XX SmartReflex Voltage Control
> + *
> + * Copyright (C) 2009 Texas Instruments, Inc.
> + * Nishanth Menon
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + * Kalle Jokiniemi
> + *
> + * Copyright (C) 2007 Texas Instruments, Inc.
> + * Lesly A M
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "prm.h"
> +#include "smartreflex.h"
> +#include "prm-regbits-34xx.h"
> +
> +/* MCUDISACK is expected to happen within 1uSec. */
> +#define COUNT_TIMEOUT_MCUDISACK 200
> +
> +/* VPINIDLE is expected to happen within 100uSec. Typical is 2uSec */
> +#define COUNT_TIMEOUT_VPINIDLE 200
> +
> +/* Time taken for setting the device - worst case as FS I2C
> + * Depends on SMPSWAITIME MIN/MAX Typical is 200uSec
> + */
> +#define COUNT_TIMEOUT_TRANSDONE_SET 400
> +
> +/* Time to clear out multiple transdone events typical is 3uSec */
> +#define COUNT_TIMEOUT_TRANSDONE_CLR 50
> +
> +/* Time For VCBypass mode for TWL4030 derivative chip. */
> +#define COUNT_TIMEOUT_TWL4030_VCBYPASS 500
> +
> +/* How many retries to do for I2C errors seen on bus for Forceupdate? */
> +#define COUNT_RETRY_SMPSNOACK4
> +
> +#define SR_REGADDR(offset) (sr->srbase_addr + (offset))
> +
> +/* Which function to use for setting voltage */
> +#ifdef CONFIG_OMAP_VC_BYPASS_UPDATE
> +#define SR_CHOSEN_VOLTAGE_UPDATE_MECH sr_vc_bypass
> +#else
> +#define SR_CHOSEN_VOLTAGE_UPDATE_MECH sr_vp_forceupdate
> +#endif
> +
> +#ifdef CONFIG_OMAP_PM_NONE
> +struct omap_opp *mpu_opps;
> +struct omap_opp *dsp_opps;
> +struct omap_opp *l3_opps;
> +#endif
> +
> +static ssize_t omap_sr_vdd_autocomp_show(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + char *buf);
> +static ssize_t omap_sr_vdd_autocomp_store(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + const char *buf, size_t n);
> +/* Structure for Voltage processor */
> +struct omap_sr_vp {
> + /* Store the commonly used register offsets.
> + * this saves a if condition decision
> + */
> + u16 prm_vpx_status_offset;
> + u16 prm_vpx_config_offset;
> + u16 prm_vpx_stepmin_offset;
> + u16 prm_vpx_stepmax_offset;
> + u16 prm_vpx_limito_offset;
> + u32 prm_vpx_vlimito_timeout;
> + u8 prm_vpx_vlimito_shift;
> + u16 prm_vpx_voltage_offset;
> + u16 prm_vc_cmd_val_offset;
> + /* Store the defaults
> + * allowing us to save OCP read
> + * operation
> + */
> + u32 vpconfig_value;
> + u32 vpstepmin_value;
> + u32 vpstepmax_value;
> + u32 vplimito_value;
> + u32 vpenable_mask;
> + u32 irqmask_trans_done;
> + u32 irqmask_smps_noack;
> +};
> +
> +/* Structure for Smart Reflex */
> +struct omap_sr {
> + u8 srid;
> + u8 prcm_vdd;
> + char *vdd_name;
> + struct kobj_attribute autocom_attr;
> + struct omap_opp **omap_opp;
> + /* SR activity marker */
> + u8 is_sr_reset;
> + u8 is_autocomp_active;
> + u32 req_opp_no;
> + u32 sr_config_value;
> + u32 sr_errconfig_value;
> + u32 sr_n_mod_mask;
> + u8 sr_n_mod_shift;
> + u32 sr_p_mod_mask;
> + u8 sr_p_mod_shift;
> + struct clk *fclk;
> + struct clk *iclk;
> + void __iomem *srbase_addr;
> + char *iclk_name;
> + char *fclk_name;
> + /* Voltage processor for the specific SR module */
> + struct omap_sr_vp vp;
> + /* This will contain the register offset on
> + * boot, replaced with the actual value
> + * as part of init routine
> + */
> + u8 num_opp;
> + u8 opp_boundary;
> + u32 opp_nvalue[];
> +};
> +
> +/* A superset of all SRs in the system ordered by SRID */
> +struct omap_sr_list {
> + u8 num_sr;
> + struct omap_sr *sr_list[];
> +};
> +
> +/* Definitions for 3430 Silicon */
> +/* Smart Reflex 1 structure */
> +static __initdata struct omap_sr omap34xx_sr1 = {
> + /* *INDENT-OFF* */
> + .srid = SR1,
> + .prcm_vdd = PRCM_VDD1,
> +
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;
>
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
RE: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions
Hi Romit, > Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Dasgupta, Romit > > Paul/Kevin, > As Madhu explained it looks like there are instances > where we forcibly need to bump up to a higher CPU + L3 frequencies (VDD1 + > VDD2 scaling). I understand that this should be done by cpufreq governors > but here is reason that I think the current cpufreq governors won't be > able to handle. > > Large latency response: > > The sampling intervals for the cpufreq governors are quite large and > thus the latency for the frequency change to occur is large. This was seen > in Android UI responsiveness. The initial response of the UI seems to be > quite sluggish until after a while when the cpufreq governors would catch > up to the required MIPS. I know that Patrick (Cc'd) did some experiments > with conservative governor but my understanding is that it still has this > basic problem. In fact, this is Mike who started that analysis. We discussed that internally and our point is that if the CPUFreq ondemand or conservative heuristic is not able to increase quickly enough the CPU need to handle correctly the UI, we have to somehow improve or modify the governor in order to provide it a extra information in term of constraint maybe in order to increase immediately the frequency. This should not be done in the low level omap_pm code; this is not the right level to do that. The issue is in the ondemand and must be fixed there. Regards, Benoit > Tied to the above is necessity for high MIPS for short duration: > > I also presume that there might be situations where we need very high MIPS > but for a very very short interval of time. This would never bump up the > frequency as it would more or less be ignored by the cpufreq governors. > > Please let me know what you think. > Thanks, > -Romit > > > > -Original Message- > > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > > Sent: Thursday, October 29, 2009 4:15 AM > > To: Chikkature Rajashekar, Madhusudhan > > Cc: 'Paul Walmsley'; Dasgupta, Romit; 'linux-omap@vger.kernel.org' > > Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource > > framework functions > > > > "Madhusudhan" writes: > > > > >> -Original Message- > > >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > >> ow...@vger.kernel.org] On Behalf Of Paul Walmsley > > >> Sent: Wednesday, October 28, 2009 1:38 PM > > >> To: Kevin Hilman > > >> Cc: Dasgupta\, Romit; linux-om...@vger.kernel.org > > >> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource > > >> framework functions > > >> > > >> On Tue, 13 Oct 2009, Kevin Hilman wrote: > > >> > > >> > "Dasgupta, Romit" writes: > > >> > > > >> > > (Tested on Zoom2). > > >> > > > > >> > > 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using > > their > > >> own > > >> > > struct device *. This is a problem because invoking these > functions > > >> from > > >> > > different clients would result in setting of the resource level > as > > >> requested by > > >> > > the last caller. Fixes this by introducing a struct device * to > the > > >> parameter > > >> > > list for these functions. > > >> > > Signed-off-by: Romit Dasgupta > > >> > > > >> > > > >> > This looks like the right fix to me. > > >> > > > >> > Paul, any comments? > > >> > > >> > > >> Wait a minute, I am retracting my ack. > > >> > > >> > > >> Romit, the only caller of omap_pm_dsp_set_min_opp() should be > > DSPBridge > > >> and the only caller of omap_pm_cpu_set_freq() should be CPUFreq. So > the > > >> struct device * pointer is not necessary, unless I am missing > something. > > >> Can you please explain what you're trying to do? > > >> > > > I believe that omap_pm_cpu_set_freq() can be called by drivers to > setup the > > > optimal vdd1 opp, right? For example MMC works at opp1 but the > > performance > > > is certainly better at opp3.When ondemand is enabled drivers need to > put > > > certain constraints on vdd1 opp otherwise performance will be hurt. So, > if > > > the API takes care of device level calls then drivers can call this fn. > > > > So, the root use case is a power vs. performance policy decision. And > > using the proposed solution, a single driver gets to make a system > > wide policy decision. I don't like this. > > > > For your MMC usecase, I think we need some clarifications. > > > > What exactly does "better" performance mean. Is it better throughput > > that is needed? or is it really the MPU side that is not > > running/responding fast enough. > > > > If it's throughput, then omap_pm_set_min_bus_tput() should be used. > > > > If it's the MPU, what exactly is the problem with ondemand. Is it > > that it doesn't respond fast enough? Or that it never switches t
RE: [PATCH 2/9 v2] omap3: pm: introduce opp accessor functions
Hi Nishanth,
> From: Menon, Nishanth
> Sent: Saturday, November 21, 2009 4:01 AM
[...]
> /**
> * struct omap_opp_def - OMAP OPP Definition
> * @enabled: True/false - is this OPP enabled/disabled by default
> * @freq:Frequency in hertz corresponding to this OPP
> * @m_volt: Nominal voltage in millivolts corresponding to this OPP
> *
> * OMAP SOCs from OMAP3 onwards have a standard set of tuples consisting
> * of frequency and voltage pairs that the device will support. This is
> * Operating Point. However, the actual definitions of OMAP Operating
> Point
> * varies over silicon within the same family of devices. For a specific
> * domain, you can have a set of {frequency, voltage} pairs and this is
> denoted
> * by an array of omap_opp_def. As the kernel boots and more information
The OPP term is not necessarily something new to OMAP3; OMAP2420/2430 already
supported 2 OPPs (100% and 50%) and to some extend OMAP1610/1710 were also able
to run at a lowest OPP (50%).
To be more accurate, you should explain that the OPP is relative to a voltage
domain and that all IPs in that voltage domain will have potentially their own
OPPs depending of the voltage.
> is
> * available, a set of these are activated based on the precise nature of
> * device the kernel boots up on.
> *
> * NOTE: A disabled opp from the omap_opp_def table may be enabled as
> part of
Are you sure you want to allow that? What if you re-enable none supported OPPs
like a speed-binning OPP on a regular device?
> * runtime logic. It is discouraged to enable/disable the OPP unless
> they are
> * done as part of OPP registration sequence.
Why is it discouraged? We should have as well the capability to enable/disable
dynamically and temporarily an OPP (thermal management, frequency avoidance,
select different OPP sets...).
You should differentiate OPPs disabled at boot time because they are not
supported by the platform and the ones disabled at runtime. It will avoid that
you potentially re-enable a forbidden OPP.
Why don't you remove them during the opp_init phase?
> */
> struct omap_opp_def {
> bool enabled;
> unsigned long freq;
> u16 m_volt;
It might be better to use an u32 and store the voltage in microvolt considering
that the T2 and Phoenix have a 12.5 mV accuracy step. Moreover, this is what
the regulator framework is currently using, it will avoid the *1000 operation,
which is not that a big deal, I agree...
> };
>
> /**
> * opp_init - Initialize an OPP table from the initial table definition
> * @oppl:Returned back to caller as the opp list to reference the OPP
> * @opp_defs:Array of omap_opp_def to describe the OPP. This list
> should be
> * 0 terminated.
> *
> * This function creates the internal datastructure representing the
> OPP list
> * from an initial definition table. this handle is then used for further
> * validation, search, modification operations on the OPP list.
> *
> * This function returns 0 and the pointer to the allocated list
> through oppl if
> * success, else corresponding error value. Caller should NOT free the
> oppl.
> * opps_defs can be freed after use.
> */
> int opp_init(struct omap_opp **oppl, const struct omap_opp_def *opp_defs);
>
> /**
> * opp_enable - Enable or disable a specific OPP
You'd better provide two APIs opp_enable and opp_disable or find a better name
for that one, like opp_state or opp_set_state.
> * @opp: pointer to opp
> * @freq:frequency in hertz
> * @enable: true/false to enable/disable that specific OPP
> *
> * Enables/disables a provided freq in the opp list. If the operation
> is valid,
> * this returns 0, else the corresponding error value.
> *
> * OPP used here is from the the opp_is_valid/opp_has_freq or other
> search
> * functions
> */
> int opp_enable(const struct omap_opp *opp, const unsigned int freq);
>
> #endif/* __ASM_ARM_OMAP_OPP_H */
>
Regards,
Benoit
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
--
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/9 v2] omap3: pm: introduce opp accessor functions
>From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
>
>Hi Benoit,
>
>Thanks for your detailed review comments. few views follows
>
>Cousson, Benoit said the following on 11/21/2009 10:07 AM:
>[...]
>>> /**
>>> * struct omap_opp_def - OMAP OPP Definition
>>> * @enabled: True/false - is this OPP enabled/disabled by default
>>> * @freq:Frequency in hertz corresponding to this OPP
>>> * @m_volt: Nominal voltage in millivolts corresponding to this OPP
>>> *
>>> * OMAP SOCs from OMAP3 onwards have a standard set of tuples
>consisting
>>> * of frequency and voltage pairs that the device will support. This is
>>> * Operating Point. However, the actual definitions of OMAP Operating
>>> Point
>>> * varies over silicon within the same family of devices. For a
>specific
>>> * domain, you can have a set of {frequency, voltage} pairs and this is
>>> denoted
>>> * by an array of omap_opp_def. As the kernel boots and more
>information
>>>
>>
>> The OPP term is not necessarily something new to OMAP3; OMAP2420/2430
>already supported 2 OPPs (100% and 50%) and to some extend OMAP1610/1710
>were also able to run at a lowest OPP (50%).
>>
>> To be more accurate, you should explain that the OPP is relative to a
>voltage domain and that all IPs in that voltage domain will have
>potentially their own OPPs depending of the voltage.
>>
>>
>Thanks for explaining the history. yep, will fix up.
>>> is
>>> * available, a set of these are activated based on the precise nature
>of
>>> * device the kernel boots up on.
>>> *
>>> * NOTE: A disabled opp from the omap_opp_def table may be enabled as
>>> part of
>>>
>>
>> Are you sure you want to allow that? What if you re-enable none supported
>OPPs like a speed-binning OPP on a regular device?
>>
>Yes, we want to allow this. here is why: we provide a list of ALL opps
>supported on that family of devices of which the common opp entries
>(across the specific family of SOCs for which the table are enabled).
>yes, there are multiple ways of doing this, one of which is to have
>enable/disable opp OR to use a add function etc.. we can scale this
>function as needed in the future as our experience with more dynamic
>silicon decisions become solid. here are specific examples:
>cpu_is_3630() will probably register all OPPs for 3630 including speed
>binned one which will be by default disabled, on detecting the
>speedbinned variants, OPP will be specifically enabled.
OK, I still had in mind the proposal to copy the relevant OPP from a const
table in initdata to the actual omap_opp_def table. In that case only the
valid OPPs will be in the table. It will prevent anybody to reactivate a
speed-binned OPP.
BTW, since you build the omap_opp_def at boot time, why do you want to keep
all possible OPPs for the SoC family an not keep only the relevant ones for
the specific SoC?
>Now opp.[ch] is meant to be core functions with control of some of the
>functions from elsewhere, in kernel space with un exported functions, I
>do not expect to write "dumb proof code", instead I would expect to
>write smart optimized code and allow other smart people's smart code use
>it optimally ;).. if we screw up here (e.g. enable a wrong OPP), we need
>code fixing and with this framwork it would now be easy to track and fix
>as OPP access are centralized.
>
>
>>
>>> * runtime logic. It is discouraged to enable/disable the OPP unless
>>> they are
>>> * done as part of OPP registration sequence.
>>>
>>
>> Why is it discouraged? We should have as well the capability to
>enable/disable dynamically and temporarily an OPP (thermal management,
>frequency avoidance, select different OPP sets...).
>>
>> You should differentiate OPPs disabled at boot time because they are not
>supported by the platform and the ones disabled at runtime. It will avoid
>that you potentially re-enable a forbidden OPP.
>>
>> Why don't you remove them during the opp_init phase?
>>
>Discouraged IMHO you may impact rest of the today's system such as
>cpufreq heuristics etc.. But, I agree with you, this is a current
>limitation which is not what I should reflect in the comment - will
>remove that statement. btw, it is smarter for the higher layers to make
>dynamic decisions of temp frequency avoidance without having to resort
>to enable/disable OPP IMHO.
I do agree, but in that case the opp_enable API should be limited to the
opp_init phase and thus not expose at all.
You should then clarify the scope of that API and e
RE: hwmod and PER going idle before WFI
Hi Kevin,
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Kevin Hilman
>
>Hi Paul,
>
>In working with the UART conversion to hwmod, I noticed something I
>don't see when not using hwmod for managing the UARTs.
>
>Namely, in the idle path for PER we do disable the PER UART (via
>omap_uart_prepare_for_idle(2)) and then the GPIO context is saved via
>omap3_per_save_context();
>
>When switching to use omap_hwmod, I noticed via crashes and then via
>lauterbach that as soon as UART3 clocks are disabled, PER goes idle.
>This causes the subsequent GPIO context save to fault since PER has
>gone idle.
>
>I seem to remember having a similar problem before when the problem
>was in the management of autodeps cause by a mis-merge.
>
>The patch below is a hack/workaround that just moves the UART idle after
>the GPIO context save because I haven't found the root cause yet.
>
>Any ideas what might be happening here?
This is probably due to the PER HW supervised mode and the fact that there is
no sleep dependency by default between MPU and PER or between CORE and PER.
As soon as the latest peripherals inside the PER power domain is going to idle,
the clock domain and thus the power domain can transition to the next power
state, even if the CPU is running.
It can by avoided by enabling the dependency but then you will prevent the PER
to go to OFF mode even if not used.
What was changed to trigger that behavior now?
Regards,
Benoit
>Kevin
>
>
>commit 5f3cbd67a54ae8b8cecbbd9ec3f55ffe07625e88
>Author: Kevin Hilman
>Date: Mon Nov 23 11:05:02 2009 -0800
>
>temp: OMAP3: PM: GPIO: disable PER UART after GPIO save
>
>FIXME: GPIO core needs to use clock API to prevent this.
>
>When PER UARTs are disabled in idle path and no GPIOs are in use,
>the PER block may go idle. This causes the GPIO context save
>that happens right after UART disabling to fail with data aborts
>when accessing the GPIO regs in PER.
>
>diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>index 627a509..da32764 100644
>--- a/arch/arm/mach-omap2/pm34xx.c
>+++ b/arch/arm/mach-omap2/pm34xx.c
>@@ -398,7 +398,6 @@ void omap_sram_idle(void)
> per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
> core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
> if (per_next_state < PWRDM_POWER_ON) {
>- omap_uart_prepare_idle(2);
> omap2_gpio_prepare_for_idle(per_next_state);
> if (per_next_state == PWRDM_POWER_OFF) {
> if (core_next_state == PWRDM_POWER_ON) {
>@@ -408,6 +407,7 @@ void omap_sram_idle(void)
> } else
> omap3_per_save_context();
> }
>+ omap_uart_prepare_idle(2);
> }
>
> if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
>--
>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
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
--
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 v2 0/7] OMAP4: mux: Add the OMAP4430 ES1 & ES2 support
Hi Tony, On 10/20/2010 1:06 AM, Tony Lindgren wrote: * Benoit Cousson [101019 15:14]: Hi Tony, Upon Nishanth request, here is the updated version... It takes into account your proposal to store partition information in a partition structure instead of inside every pad entries. The mechanism relies on the uniqueness of the pad name in each partition to find the correct partition during iteration. OK, using the offset defines won't be unique necessarily.. They should. The defines are all based on pad names that are all unique. Assuming HW folks didn't messed up the spec... Removed as well some cpu_is_xxx calls from the core code by adding a couple of flags during partition init. That's great. Please note that due to low level access to mux api from the RX51 board code, I have to disable the mux change to build properly with omap2plus_defconfig. Look like you do have some idea to fix that :-) I was thinking of: - brute force approach that consist of keeping all the data after init, and thus allowing removing the __init in the omap_mux_init_signal API - or adding some flag in the pad entry to keep them after init . Well I was thinking we just register a board specific dynamic mux table and then call that when hitting retention or off and restore after that. Still need to think about that a bit more, I don't know if we want the automatic muxing of gpio pins still in addition to that. OK, you were thinking of the MMC remux case only. That might be enough for the moment, because the other needs I heard about does not seems to be in mainline anyway (USB or modem link). Boot tested on SDP4430 with ES1.0& ES2.0 with omap2plus_defconfig. Still require some real driver to use that mux API in order to validate it. You can test by echoing wrong values after booting via /sys to mess up the MMC data lines and then type sync :) I played with debugfs a little bit but was trying to avoid messing up with pins already used... in fact I should do the opposite. That's a nice technique... The series is on top of lo/master (2.6.36-rc8) and is available here: git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v2 For pulling anything in, the git branches need to be based on something that's immutable. So preferrably v2.6.35 or some recent -rc tag in this case. Or rebase it on v2.6.36 after that's been released. In that case only the ES1 can be there. ES2 support will be in 2.6.37 only. That's why I have a dependency with lo/master. Do you want to split the series in two parts? Thanks, Benoit -- 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/5] 32k sync timer meets hwmod
Hi Felipe, Just one minor comment about the subjects. On 10/19/2010 11:22 AM, Felipe Balbi wrote: Hi all, Converted 32k-sync timer to platform_driver and now using pm_runtime and hwmod. Tested on 3430 by me and 4430 by Tarun If someone could test on 2430 and 2420, I would be really glad. Felipe Balbi (5): arm: omap1/2/3/4: convert 32k-sync driver to a platform_driver arm: omap: counter-32k: convert to pm_runtime API clocksource: move omap 32k timer to drivers/clocksource arm: omap: introduce 32k timer hwmod for omap2/3/4 arm: omap: 32k: move to omap_device_build 32k-sync, counter-32k, 32k timer, and then 32k... That's a lot of different names for that IP :) You should maybe stick to counter-32k and add a comment saying that the synctimer32k name was so bad, that we renamed it counter-32k. Thanks, Benoit arch/arm/mach-omap1/devices.c | 24 +++ arch/arm/mach-omap2/clock2420_data.c |2 +- arch/arm/mach-omap2/clock2430_data.c |2 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/devices.c | 36 + arch/arm/mach-omap2/omap_hwmod_2420_data.c | 52 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 52 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 51 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61 arch/arm/plat-omap/Makefile|2 +- arch/arm/plat-omap/counter_32k.c | 183 -- drivers/clocksource/Makefile |1 + drivers/clocksource/omap-32k.c | 231 13 files changed, 512 insertions(+), 187 deletions(-) delete mode 100644 arch/arm/plat-omap/counter_32k.c create mode 100644 drivers/clocksource/omap-32k.c -- 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 4/5] arm: omap: introduce 32k timer hwmod for omap2/3/4
On 10/19/2010 11:22 AM, Balbi, Felipe wrote:
Add 32k timer hwmod to the database.
Signed-off-by: Felipe Balbi
Could you add my sign-off as well on this one for the OMAP4 part?
Thanks,
Benoit
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 52 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 52 +++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 51 +++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61
4 files changed, 216 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..05b9d2a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -557,6 +557,57 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags = HWMOD_16BIT_REG,
};
+/*
+ * 'counter' class
+ * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
+ */
+
+static struct omap_hwmod_class omap2420_counter_hwmod_class = {
+ .name = "counter",
+};
+
+/* counter_32k */
+static struct omap_hwmod omap2420_counter_32k_hwmod;
+static struct omap_hwmod_addr_space omap2420_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x48004000,
+ .pa_end = 0x48000fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup -> counter_32k */
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
+ .master =&omap2420_l4_wkup_hwmod,
+ .slave =&omap2420_counter_32k_hwmod,
+ .clk= "l4_ck",
+ .addr = omap2420_counter_32k_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_counter_32k_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* counter_32k slave ports */
+static struct omap_hwmod_ocp_if *omap2420_counter_32k_slaves[] = {
+ &omap2420_l4_wkup__counter_32k,
+};
+
+static struct omap_hwmod omap2420_counter_32k_hwmod = {
+ .name = "counter_32k",
+ .class =&omap2420_counter_hwmod_class,
+ .main_clk = "sync_32k_ick",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_GPT1_SHIFT,
+ },
+ },
+ .slaves = omap2420_counter_32k_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_counter_32k_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
&omap2420_l3_main_hwmod,
&omap2420_l4_core_hwmod,
@@ -569,6 +620,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
&omap2420_uart3_hwmod,
&omap2420_i2c1_hwmod,
&omap2420_i2c2_hwmod,
+ &omap2420_counter_32k_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..96e9b12 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -569,6 +569,57 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/*
+ * 'counter' class
+ * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
+ */
+
+static struct omap_hwmod_class omap2430_counter_hwmod_class = {
+ .name = "counter",
+};
+
+/* counter_32k */
+static struct omap_hwmod omap2430_counter_32k_hwmod;
+static struct omap_hwmod_addr_space omap2430_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x48004000,
+ .pa_end = 0x48000fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup -> counter_32k */
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
+ .master =&omap2430_l4_wkup_hwmod,
+ .slave =&omap2430_counter_32k_hwmod,
+ .clk= "l4_ck",
+ .addr = omap2430_counter_32k_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_counter_32k_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* counter_32k slave ports */
+static struct omap_hwmod_ocp_if *omap2430_counter_32k_slaves[] = {
+ &omap2430_l4_wkup__counter_32k,
+};
+
+static struct omap_hwmod omap2430_counter_32k_hwmod = {
+ .name = "counter_32k",
+ .class =&omap2430_counter_hwmod_class,
+ .main_clk = "sync_32k_ick",
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_GPT1_SHIFT,
+ },
+ },
+ .slaves = omap2430_counter_32k_
Re: [PATCH] OMAP: hmwod: Update the sysc_cache in case module context is lost
On 10/21/2010 12:13 PM, Nayak, Rajendra wrote: Hi Kevin, What the patch does is reprogram's the sysc value (from the cache) whenever its lost. So its infact saved in the cache and restored when needed. Otherwise, all this patch does is refresh the _sysc_cache with completely unknown contents. It also somewhat defeats the purpose of having a cache. If you're going to read SYSC in order to determine whether or not you can avoid a write, you might as well just blindly write. I thought of this and dismissed it thinking I would end up with a read/or/write and instead a read always to avoid write is better. But now looking back again, it does make sense to still keep the cache to avoid a read (since a read has significantly more latency than write) and do a blind write always. Does that make sense? That seems indeed better. The point is that cache is already a location for the "save" part. So writing blindly will do the restore with always the good value. It is anyway faster than trying to check if we lost context or not through PRM registers. Benoit -- 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 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Hi Thara,
On 9/22/2010 4:45 PM, Gopinath, Thara wrote:
This patch adds debug support to the voltage and smartreflex drivers.
This means a whole bunch of voltage processor and smartreflex
parameters are now visible through the pm debugfs. By default
only a read of these parameters are permitted. If you need to
write into them then
echo 1> /pm_debug/enable_sr_vp_debug
The voltage parameters can be viewed at
/pm_debug/voltage/vdd_/
and the smartreflex parameters can be viewed at
/pm_debug/smartreflex/sr_/
Can we start getting rid of this pm_debug miscellaneous directory?
Like powerdomain and clockdomain debug stuff, I think that voltage
domain layer deserve its own entry in the debugfs top level directory.
I do not see the need to add a extra level a directory for that.
Moreover smartreflex should be under voltage entry and not in the same
level as voltage.
/sys/kernel/debug/voltage/vdd_/smartreflex/
Regards,
Benoit
where is mpu or core for OMAP3.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/pm-debug.c| 15 ++
arch/arm/mach-omap2/smartreflex.c | 40 +-
arch/arm/mach-omap2/voltage.c | 210 -
arch/arm/plat-omap/include/plat/smartreflex.h |1 -
arch/arm/plat-omap/include/plat/voltage.h |5 +
5 files changed, 264 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 390f1c6..879efb2 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "prm.h"
#include "cm.h"
@@ -586,6 +587,18 @@ static int option_set(void *data, u64 val)
omap3_pm_off_mode_enable(val);
}
+ if (option ==&enable_sr_vp_debug&& val)
+ pr_notice("Beware that enabling this option will allow user "
+ "to override the system defined vp and sr parameters "
+ "All the updated parameters will take effect next "
+ "time smartreflex is enabled. Also this option "
+ "disables the automatic vp errorgain and sr errormin "
+ "limit changes as per the voltage. Users will have "
+ "to explicitly write values into the debug fs "
+ "entries corresponding to these if they want to see "
+ "them changing according to the VDD voltage\n");
+
+
return 0;
}
@@ -642,6 +655,8 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file("wakeup_timer_milliseconds",
S_IRUGO | S_IWUGO, d,&wakeup_timer_milliseconds,
&pm_dbg_option_fops);
+ (void) debugfs_create_file("enable_sr_vp_debug", S_IRUGO | S_IWUGO, d,
+ &enable_sr_vp_debug,&pm_dbg_option_fops);
pm_dbg_main_dir = d;
pm_dbg_init_done = 1;
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7fc3138..b5a7878 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -558,8 +558,13 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long
volt)
return -ENODATA;
}
- /* errminlimit is opp dependent and hence linked to voltage */
- sr->err_minlimit = volt_data->sr_errminlimit;
+ /*
+* errminlimit is opp dependent and hence linked to voltage
+* if the debug option is enabled, the user might have over ridden
+* this parameter so do not get it from voltage table
+*/
+ if (!enable_sr_vp_debug)
+ sr->err_minlimit = volt_data->sr_errminlimit;
/* Enable the clocks */
if (!sr->sr_enable) {
@@ -811,9 +816,34 @@ static int omap_sr_autocomp_store(void *data, u64 val)
return 0;
}
+static int omap_sr_params_show(void *data, u64 *val)
+{
+ u32 *param = data;
+
+ *val = *param;
+ return 0;
+}
+
+static int omap_sr_params_store(void *data, u64 val)
+{
+ if (enable_sr_vp_debug) {
+ u32 *option = data;
+ *option = val;
+ } else {
+ pr_notice("%s: DEBUG option not enabled!\n \
+ echo 1> pm_debug/enable_sr_vp_debug - to enable\n",
+ __func__);
+ }
+
+ return 0;
+}
+
DEFINE_SIMPLE_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show,
omap_sr_autocomp_store, "%llu\n");
+DEFINE_SIMPLE_ATTRIBUTE(sr_params_fops, omap_sr_params_show,
+ omap_sr_params_store, "%llu\n");
+
static int __init omap_smartreflex_probe(struct platform_device *pdev)
{
struct omap_sr *sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
@@ -907,6 +937,12 @@ static int __init omap_smartreflex_probe(struct
platform_device *pdev)
(void) debugfs_create_file("autocomp
Re: [PATCH v3 01/11] OMAP: PM: Export the main pm debugfs directory
On 9/22/2010 4:45 PM, Gopinath, Thara wrote:
This patch makes generic pm_debug directory global
so that other drivers can include it and use it to create
sub-entries.
That should not be needed, if we expose voltage debugfs entry in the top
level directly.
Benoit
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/pm-debug.c |3 +++
arch/arm/mach-omap2/pm.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index af00c17..390f1c6 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -42,6 +42,7 @@ u32 enable_off_mode;
u32 sleep_while_idle;
u32 wakeup_timer_seconds;
u32 wakeup_timer_milliseconds;
+struct dentry *pm_dbg_main_dir;
#define DUMP_PRM_MOD_REG(mod, reg)\
regs[reg_count].name = #mod "." #reg; \
@@ -641,6 +642,8 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file("wakeup_timer_milliseconds",
S_IRUGO | S_IWUGO, d,&wakeup_timer_milliseconds,
&pm_dbg_option_fops);
+
+ pm_dbg_main_dir = d;
pm_dbg_init_done = 1;
return 0;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index f3ba1e6..c06cedd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -55,6 +55,7 @@ extern int omap2_pm_debug;
#define omap2_pm_dump(mode, resume, us) do {} while (0);
#define omap2_pm_wakeup_on_timer(seconds, milliseconds) do {} while (0);
#define omap2_pm_debug0
+#define pm_dbg_main_dir0
#endif
#if defined(CONFIG_CPU_IDLE)
--
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 08/11] OMAP4: Adding dev atrributes to OMAP4 smartreflex hwmod data
Hi Kevin, Sorry for that late reply, I missed that email a little bit. On 10/14/2010 8:56 PM, Kevin Hilman wrote: On Sat, 2010-09-25 at 18:21 +0530, Thara Gopinath wrote: diff --git a/arch/arm/plat-omap/include/plat/control.h b/arch/arm/plat-omap/include/plat/control.h index 042eb6e..1e8f6ec 100644 --- a/arch/arm/plat-omap/include/plat/control.h +++ b/arch/arm/plat-omap/include/plat/control.h @@ -181,6 +181,18 @@ #define OMAP3630_CONTROL_FUSE_OPP50_VDD2 (OMAP2_CONTROL_GENERAL + 0x0128) #define OMAP3630_CONTROL_FUSE_OPP100_VDD2 (OMAP2_CONTROL_GENERAL + 0x012C) +/* 44xx control efuse offsets */ +#define OMAP44XX_CONTROL_FUSE_IVA_OPP500x22C +#define OMAP44XX_CONTROL_FUSE_IVA_OPP100 0x22F +#define OMAP44XX_CONTROL_FUSE_IVA_OPPTURBO 0x232 +#define OMAP44XX_CONTROL_FUSE_IVA_OPPNITRO 0x235 +#define OMAP44XX_CONTROL_FUSE_MPU_OPP500x240 +#define OMAP44XX_CONTROL_FUSE_MPU_OPP100 0x243 +#define OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO 0x246 +#define OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO 0x249 +#define OMAP44XX_CONTROL_FUSE_CORE_OPP50 0x254 +#define OMAP44XX_CONTROL_FUSE_CORE_OPP100 0x257 + These names are not consistent with the TRM (ES2.x NDA TRM vL). e.g. rather than MPU_OPP50, OPP1, the TRM has MPU_0, MPU_1. However, the TRM is confusing here too since the register names are MPU_0, MPU_1, etc. but the field names in the register descriptions use OPP50, OPP100, etc. What a mess. We need a consistent naming for these. Benoit? It is indeed a mess... these names are the latest ones used in the HW spec. But we are still wondering how to name that in the future. OPP_LOW, OPP_MID, OPP_HIGH, OPP_TURBO and OPP_NITRO are now considered but I'm not sure it is really better. Honestly I do prefer the OPP50, OPP100, OPP130, OPP166 that are providing the percentage wrt nominal frequency and that can scale easily. If we do introduce a OPP between OPP_MID and OPP_HIGH, I'm not sure anybody will be able to find a proper name whereas OPP_80 is straightforward. In anycase, that will never match the HW spec or the TRM :-( Benoit Also, based on the TRM, the offsets here don't look quite right. e.g. there is no MPU OPP at 0x240, so the OMAP4 the code reading these is using reserved/undocumented bits for the first OPP. Also, the single byte offsets here could use a better explanation, not necessarily here but in the omap4 code that reads the nvalues. I expected that these would be single byte aligned to compact the address space and remove some unused space, but no, they seem to be arbitrarily shifted around. 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 v2 08/11] OMAP4: Adding dev atrributes to OMAP4 smartreflex hwmod data
On 9/25/2010 2:51 PM, Gopinath, Thara wrote:
This patch adds dev attributes for smartreflex modules
in the OMAP4 hwmod database. This patch also updates the
smartreflex rev in the smartreflex class data structure
in the OMAP4 hwmod database.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 56
arch/arm/plat-omap/include/plat/control.h | 12 ++
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ba3c215..82657b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,8 @@
#include
#include
+#include
+#include
#include "omap_hwmod_common_data.h"
@@ -474,6 +476,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_smartreflex_sysc = {
static struct omap_hwmod_class omap44xx_smartreflex_hwmod_class = {
.name = "smartreflex",
.sysc =&omap44xx_smartreflex_sysc,
+ .rev = 2,
};
/* smartreflex_core */
@@ -505,6 +508,22 @@ static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_core_slaves[] = {
&omap44xx_l4_cfg__smartreflex_core,
};
+static u32 omap44xx_sr_core_efuse_offs[] = {
+ OMAP44XX_CONTROL_FUSE_CORE_OPP50, OMAP44XX_CONTROL_FUSE_CORE_OPP100,
+};
+
+static u32 omap44xx_sr_core_test_nvalues[] = {
+ 0x0, 0x0
+};
At first, I thought it was a good idea to put such data here, but now
after the discussion about timer hwmod data, I realize I was wrong.
These informations belong to omap_volt_data. For each OPP you should
provide the efuse offset an the SW nvalues.
BTW, you should not call them test Nvalues, these are perfectly valid
and can be potentially used in production. There are just not as
optimized as a efuse Nvalue.
Benoit
+
+static struct omap_sr_dev_data omap44xx_sr_core_dev_attr = {
+ .efuse_nvalues_offs = omap44xx_sr_core_efuse_offs,
+ .test_sennenable= 0x1,
+ .test_senpenable= 0x1,
+ .test_nvalues = omap44xx_sr_core_test_nvalues,
+ .vdd_name = "core"
+};
+
static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
.name = "smartreflex_core",
.class =&omap44xx_smartreflex_hwmod_class,
@@ -518,6 +537,7 @@ static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
},
.slaves = omap44xx_smartreflex_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_smartreflex_core_slaves),
+ .dev_attr =&omap44xx_sr_core_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -550,6 +570,23 @@ static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_iva_slaves[] = {
&omap44xx_l4_cfg__smartreflex_iva,
};
+static u32 omap44xx_sr_iva_efuse_offs[] = {
+ OMAP44XX_CONTROL_FUSE_IVA_OPP50, OMAP44XX_CONTROL_FUSE_IVA_OPP100,
+ OMAP44XX_CONTROL_FUSE_IVA_OPPTURBO,
+};
+
+static u32 omap44xx_sr_iva_test_nvalues[] = {
+ 0x0, 0x0, 0x0, 0x0
+};
+
+static struct omap_sr_dev_data omap44xx_sr_iva_dev_attr = {
+ .efuse_nvalues_offs = omap44xx_sr_iva_efuse_offs,
+ .test_sennenable= 0x1,
+ .test_senpenable= 0x1,
+ .test_nvalues = omap44xx_sr_iva_test_nvalues,
+ .vdd_name = "iva"
+};
+
static struct omap_hwmod omap44xx_smartreflex_iva_hwmod = {
.name = "smartreflex_iva",
.class =&omap44xx_smartreflex_hwmod_class,
@@ -563,6 +600,7 @@ static struct omap_hwmod omap44xx_smartreflex_iva_hwmod = {
},
.slaves = omap44xx_smartreflex_iva_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_smartreflex_iva_slaves),
+ .dev_attr =&omap44xx_sr_iva_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -595,6 +633,23 @@ static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_mpu_slaves[] = {
&omap44xx_l4_cfg__smartreflex_mpu,
};
+static u32 omap44xx_sr_mpu_efuse_offs[] = {
+ OMAP44XX_CONTROL_FUSE_MPU_OPP50, OMAP44XX_CONTROL_FUSE_MPU_OPP100,
+ OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO,
+};
+
+static u32 omap44xx_sr_mpu_test_nvalues[] = {
+ 0x0, 0x0, 0x0, 0x0
+};
+
+static struct omap_sr_dev_data omap44xx_sr_mpu_dev_attr = {
+ .efuse_nvalues_offs = omap44xx_sr_mpu_efuse_offs,
+ .test_sennenable= 0x1,
+ .test_senpenable= 0x1,
+ .test_nvalues = omap44xx_sr_mpu_test_nvalues,
+ .vdd_name = "mpu"
+};
+
static struct omap_hwmod omap44xx_smartreflex_mpu_hwmod = {
.name = "smartreflex_mpu",
.class =&omap44xx_smartreflex_hwmod_class,
@@ -608,6 +663,7 @@ static struct omap_hwmod omap44xx_smartreflex_mpu_hwmod = {
},
.slaves = omap44xx_smartreflex_mpu_slaves,
.slaves_cnt = ARRAY_SIZE(om
Re: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
On 10/28/2010 5:27 PM, Gopinath, Thara wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Thursday, October 28, 2010 11:09 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
Thara,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Thara Gopinath
Sent: Wednesday, October 27, 2010 9:41 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson,
Benoit; Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
SmartReflex modules do adaptive voltage control for real-time
voltage adjustments. With Smartreflex the power supply voltage
can be adapted to the silicon performance(manufacturing process,
temperature induced performance, age induced performance etc).
There are differnet classes of smartreflex implementation.
Class-0: Manufacturing Test Calibration
Class-1: Boot-Time Software Calibration
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration
Class-4: Fully Integrated Power Management
OMAP3 has two smartreflex modules one associated with VDD MPU and the
other associated with VDD CORE.
This patch adds support for smartreflex driver. The driver
is designed
for Class-1 , Class-2 and Class-3 support and is a platform driver.
Smartreflex driver can be enabled through a Kconfig option
"SmartReflex support" under "System type"->"TI OMAP
implementations" menu.
Smartreflex autocompensation feature can be enabled runtime through
a debug fs option.
To enable smartreflex autocompensation feature
echo 1> /debug/voltage/vdd_/smartreflex/autocomp
To disable smartreflex autocompensation feature
echo 0> /debug/voltage/vdd_/smartreflex/autocomp
where X can be mpu, core , iva etc.
This patch contains code originally in linux omap pm branch.
Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/smartreflex.c | 975
+
arch/arm/plat-omap/Kconfig| 36 +
arch/arm/plat-omap/include/plat/smartreflex.h | 271 +++
4 files changed, 1283 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/smartreflex.c
create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h
<>
+static int __init omap_sr_probe(struct platform_device *pdev)
+{
+ struct omap_sr *sr_info = kzalloc(sizeof(struct
omap_sr), GFP_KERNEL);
+ struct omap_device *odev = to_omap_device(pdev);
Patch3 should be ordered before patch2 in your series. Otherwise,
this would fail during a git-bisect.
Again why ?? All patches individually compile and boot.
+ struct omap_sr_data *pdata = pdev->dev.platform_data;
+ struct resource *mem, *irq;
+ struct dentry *vdd_dbg_dir, *dbg_dir;
+ int ret = 0;
+
+ if (!sr_info) {
+ dev_err(&pdev->dev, "%s: unable to allocate sr_info\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "%s: platform data
missing\n", __func__);
+ return -EINVAL;
+ }
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(&pdev->dev, "%s: no mem resource\n", __func__);
+ ret = -ENODEV;
+ goto err_free_devinfo;
+ }
+
+ irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+
+ pm_runtime_enable(&pdev->dev);
+
+ sr_info->pdev = pdev;
+ sr_info->srid = pdev->id;
+ sr_info->voltdm = pdata->voltdm;
+ sr_info->autocomp_active = false;
+ sr_info->ip_type = odev->hwmods[0]->class->rev;
I am not sure if it is okay to get hwmods-info in the driver.
To avoid too many indirections, it can be obtained before
omap_device_build() of the device and passed to the driver.
mmm. yep we could do it also. Maybe Kevin/Benoit needs to confirm the
correct way of doing this.
Yep, I fully agree with Charu. You'd better copy that information at
omap_device build time. Getting hwmod internal stuff directly is bad.
Benoit
Regards
Thara
+ sr_info->base = ioremap(mem->start, resource_size(mem));
+ if (!sr_info->base) {
+ dev_err(&pdev->dev, "%s: ioremap fail\n", __func__);
+ ret = -ENOMEM;
+ goto err_release_region;
+
Re: [PATCH v2 08/11] OMAP4: Adding dev atrributes to OMAP4 smartreflex hwmod data
Hi Kevin,
On 11/2/2010 10:10 AM, Kevin Hilman wrote:
"Cousson, Benoit" writes:
On 9/25/2010 2:51 PM, Gopinath, Thara wrote:
This patch adds dev attributes for smartreflex modules
in the OMAP4 hwmod database. This patch also updates the
smartreflex rev in the smartreflex class data structure
in the OMAP4 hwmod database.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 56
arch/arm/plat-omap/include/plat/control.h | 12 ++
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ba3c215..82657b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,8 @@
#include
#include
+#include
+#include
#include "omap_hwmod_common_data.h"
@@ -474,6 +476,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_smartreflex_sysc = {
static struct omap_hwmod_class omap44xx_smartreflex_hwmod_class = {
.name = "smartreflex",
.sysc =&omap44xx_smartreflex_sysc,
+ .rev = 2,
};
/* smartreflex_core */
@@ -505,6 +508,22 @@ static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_core_slaves[] = {
&omap44xx_l4_cfg__smartreflex_core,
};
+static u32 omap44xx_sr_core_efuse_offs[] = {
+ OMAP44XX_CONTROL_FUSE_CORE_OPP50, OMAP44XX_CONTROL_FUSE_CORE_OPP100,
+};
+
+static u32 omap44xx_sr_core_test_nvalues[] = {
+ 0x0, 0x0
+};
At first, I thought it was a good idea to put such data here, but now
after the discussion about timer hwmod data, I realize I was wrong.
These informations belong to omap_volt_data. For each OPP you should
provide the efuse offset an the SW nvalues.
BTW, you should not call them test Nvalues, these are perfectly valid
and can be potentially used in production. There are just not as
optimized as a efuse Nvalue.
Just to clarify...
Benoit, what's your opinion of my comment that these values don't belong
in the volt_data.
Or maybe it is just volt_data that should be renamed, because all the
data in it are SR / VP related:
{.volt_nominal = 975000, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C},
So the efuse info belongs to it as well.
At the end the volt_data at voltage management level is just a list of
supported voltages. Does it make sense to add an id instead of keeping
the voltage as an index?
volt_data should be:
{.volt_nominal = 975000},
and then volt_sr_vp_data will be:
{.volt_nominal = 975000, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C,
efuse_stuff...},
or with an id:
{.id = 0, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C, efuse_stuff...},
I do agree that we have to split that in two structures, but I'm not
sure the id is really needed here?
Regards,
Benoit
--
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 06/13] OMAP3: DMA: hwmod: add system DMA
Hi Manjunath,
On 11/3/2010 8:59 AM, G, Manjunath Kondaiah wrote:
Kevin/Benoit,
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G,
Manjunath Kondaiah
Sent: Tuesday, October 26, 2010 6:55 PM
Add OMAP3 DMA hwmod structures.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 93
1 files changed, 93 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ed6bf4a..4a5231c 100644
[...]
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id= 1,
+ .module_bit =
OMAP3430_ST_SDMA_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit=
OMAP3430_ST_SDMA_SHIFT,
Looks like the .module_offs field is missing here. Since
ST_SDMA bit belongs to CM_IDLEST1_CORE register, .module_offs should
be CORE_MOD.
But, it is observed that, using .module_offs results in warning dump
during bootup. This is due to, ST_SDMA bit in standby mode. Since
there is no fclk for DMA, this bit will never change till DMA channel
is requested for data transfer.
We might have to bypass calling "omap2_cm_wait_module_ready" in
"_wait_target_ready" in omap_hwmod.c
With exising flags, we can use "HWMOD_NO_IDLEST" flag, but this
flag has different meaning. How about using new flag like
"HWMOD_NO_FCLK_OPCLK" and if it is set, return without calling
"omap2_cm_wait_module_ready"
Any better suggestion to handle this issue?
Well, yes, use HWMOD_NO_IDLEST and remove idlest_reg_id &
idlest_idle_bit entries in the omap2 structure.
ST_SDMA is the standby status of the SDMA, but there is no idle status
on that IP, so you cannot do anything.
The standby will just reflect the activity of the master port of the
DMA, but it will give you no information about the slave port and thus
we do not have any module ready information.
Regards,
Benoit
--
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 06/13] OMAP3: DMA: hwmod: add system DMA
On 11/4/2010 3:01 AM, G, Manjunath Kondaiah wrote:
Hi Benoit,
From: Cousson, Benoit
Sent: Thursday, November 04, 2010 9:59 AM
Hi Manjunath,
On 11/3/2010 8:59 AM, G, Manjunath Kondaiah wrote:
Kevin/Benoit,
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G,
Manjunath Kondaiah
Sent: Tuesday, October 26, 2010 6:55 PM
Add OMAP3 DMA hwmod structures.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 93
1 files changed, 93 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ed6bf4a..4a5231c 100644
[...]
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id= 1,
+ .module_bit =
OMAP3430_ST_SDMA_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit=
OMAP3430_ST_SDMA_SHIFT,
Looks like the .module_offs field is missing here. Since
ST_SDMA bit belongs to CM_IDLEST1_CORE register, .module_offs should
be CORE_MOD.
But, it is observed that, using .module_offs results in warning dump
during bootup. This is due to, ST_SDMA bit in standby mode. Since
there is no fclk for DMA, this bit will never change till
DMA channel
is requested for data transfer.
We might have to bypass calling "omap2_cm_wait_module_ready" in
"_wait_target_ready" in omap_hwmod.c
With exising flags, we can use "HWMOD_NO_IDLEST" flag, but this
flag has different meaning. How about using new flag like
"HWMOD_NO_FCLK_OPCLK" and if it is set, return without calling
"omap2_cm_wait_module_ready"
Any better suggestion to handle this issue?
Well, yes, use HWMOD_NO_IDLEST and remove idlest_reg_id&
idlest_idle_bit entries in the omap2 structure.
ST_SDMA is the standby status of the SDMA, but there is no
idle status
on that IP, so you cannot do anything.
The standby will just reflect the activity of the master port of the
DMA, but it will give you no information about the slave port
and thus
we do not have any module ready information.
Thanks for the feedback.
This change is introduced as per kevin's review comment at:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34278.html
Well this register is confusing, because he uses the same naming
convention but with a difference meaning:
ST_SDMA: System DMA standby status.
- 0x0: System DMA is active.
- 0x1: System DMA is in standby mode.
I am ok to use "HWMOD_NO_IDLEST" if kevin also agrees
He will... Otherwise I will throw him into the New England Aquarium like
Linus :-)
Benoit
--
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 1/7] OMAP2: hwmod data: add mailbox data
Hi Omar,
On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote:
hwmod data for omap2430 and 2420.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 67
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 66 +++
2 files changed, 133 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..76ad991 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -557,6 +557,72 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags = HWMOD_16BIT_REG,
};
+/* mailbox */
+
+static struct omap_hwmod_class_sysconfig omap2420_mailbox_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_mailbox_hwmod_class = {
+ .name = "mailbox",
+ .sysc =&omap2420_mailbox_sysc,
+};
+
+static struct omap_hwmod omap2420_mailbox_hwmod;
+
+static struct omap_hwmod_addr_space omap2420_mailbox_addrs[] = {
+ {
+ .pa_start = OMAP24XX_MAILBOX_BASE,
+ .pa_end = OMAP24XX_MAILBOX_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l4_core -> mailbox */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mailbox = {
+ .master =&omap2420_l4_core_hwmod,
+ .slave =&omap2420_mailbox_hwmod,
+ .addr = omap2420_mailbox_addrs,
+ .clk= "mailboxes_ick",
Could you try to be consistent with the omap4 format? it is easier to
diff between Soc version: .clk is before .addr.
+ .addr_cnt = ARRAY_SIZE(omap2420_mailbox_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mailbox slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mailbox_slaves[] = {
+ &omap2420_l4_core__mailbox,
+};
+
+static struct omap_hwmod_irq_info omap2420_mailbox_irqs[] = {
+ { .name = "dsp", .irq = INT_24XX_MAIL_U0_MPU, },
+ { .name = "iva", .irq = INT_24XX_MAIL_U3_MPU, },
+};
+
+static struct omap_hwmod omap2420_mailbox_hwmod = {
+ .name = "mailbox",
+ .class =&omap2420_mailbox_hwmod_class,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MAILBOXES_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
+ },
+ },
Same things with the format, put that after irqs_cnt and before slaves.
+ .mpu_irqs = omap2420_mailbox_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mailbox_irqs),
+ .slaves = omap2420_mailbox_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_mailbox_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
&omap2420_l3_main_hwmod,
&omap2420_l4_core_hwmod,
@@ -569,6 +635,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
&omap2420_uart3_hwmod,
&omap2420_i2c1_hwmod,
&omap2420_i2c2_hwmod,
Add a blank line between each class. OK it was not done for i2c, but it
should.
All the comments are applicable to the 2430 and 3430 data as well.
Thanks,
Benoit
+ &omap2420_mailbox_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..991bd5b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -569,6 +569,71 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/* mailbox */
+
+static struct omap_hwmod_class_sysconfig omap2430_mailbox_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_mailbox_hwmod_class = {
+ .name = "mailbox",
+ .sysc =&omap2430_mailbox_sysc,
+};
+
+static struct omap_hwmod omap2430_mailbox_hwmod;
+
+static struct omap_hwmod_addr_space omap2430_mailbox_addrs[] = {
+ {
+ .pa_start = OMAP24XX_MAILBOX_BASE,
+ .pa
Re: [PATCH v2 3/7] OMAP4: hwmod data: add mailbox data
I don't know why, but this patch has nothing to do with my original one.
Can you stick to the original code?
Of course, if you have valid comments or need to add extra data, you
can, but in this case, I do not see any needed change.
On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote:
From: Benoit Cousson
hwmod data for omap4 mailbox.
Signed-off-by: Benoit Cousson
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 63
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0d5c6eb..f7525e3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1043,6 +1043,66 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/* mailbox */
The original comment is missing.
+
+static struct omap_hwmod_class_sysconfig omap44xx_mailbox_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_mailbox_hwmod_class = {
+ .name = "mailbox",
+ .sysc =&omap44xx_mailbox_sysc,
+};
+
+static struct omap_hwmod omap44xx_mailbox_hwmod;
+
+static struct omap_hwmod_addr_space omap44xx_mailbox_addrs[] = {
+ {
+ .pa_start = OMAP44XX_MAILBOX_BASE,
If that physical address is not used elsewhere, and it should be the
case, there is no need to create a define for it. That's why the
physical address was directly used here.
There is no added value to create a define for that.
+ .pa_end = OMAP44XX_MAILBOX_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l4_cfg -> mailbox */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mailbox = {
+ .master =&omap44xx_l4_cfg_hwmod,
+ .slave =&omap44xx_mailbox_hwmod,
+ .clk= "l4_div_ck",
+ .addr = omap44xx_mailbox_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mailbox_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mailbox slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_mailbox_slaves[] = {
+ &omap44xx_l4_cfg__mailbox,
+};
+
+static struct omap_hwmod_irq_info omap44xx_mailbox_irqs[] = {
+ { .name = "mbox", .irq = 26 + OMAP44XX_IRQ_GIC_START, },
+};
+
+static struct omap_hwmod omap44xx_mailbox_hwmod = {
+ .name = "mailbox",
+ .class =&omap44xx_mailbox_hwmod_class,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4CFG_MAILBOX_CLKCTRL,
+ },
+ },
+ .mpu_irqs = omap44xx_mailbox_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_mailbox_irqs),
The order is different than the previous one.
Benoit
+ .slaves = omap44xx_mailbox_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_mailbox_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
&omap44xx_dmm_hwmod,
@@ -1077,6 +1137,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_uart2_hwmod,
&omap44xx_uart3_hwmod,
&omap44xx_uart4_hwmod,
+
+ /* mailbox */
+ &omap44xx_mailbox_hwmod,
NULL,
};
--
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 4/7] omap: mailbox: initial hwmod support
Hi Felipe,
On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote:
From: Felipe Contreras
hwmod support for omap mailbox module.
Signed-off-by: Felipe Contreras
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/devices.c | 100 ++--
1 files changed, 15 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index eaf3799..d977572 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -141,95 +141,25 @@ static inline void omap_init_camera(void)
#endif
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-
-#define MBOX_REG_SIZE 0x120
-
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap2_mbox_resources[] = {
- {
- .start = OMAP24XX_MAILBOX_BASE,
- .end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = INT_24XX_MAIL_U0_MPU,
- .flags = IORESOURCE_IRQ,
- .name = "dsp",
- },
- {
- .start = INT_24XX_MAIL_U3_MPU,
- .flags = IORESOURCE_IRQ,
- .name = "iva",
- },
-};
-static int omap2_mbox_resources_sz = ARRAY_SIZE(omap2_mbox_resources);
-#else
-#define omap2_mbox_resources NULL
-#define omap2_mbox_resources_sz0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct resource omap3_mbox_resources[] = {
- {
- .start = OMAP34XX_MAILBOX_BASE,
- .end= OMAP34XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = INT_24XX_MAIL_U0_MPU,
- .flags = IORESOURCE_IRQ,
- .name = "dsp",
- },
-};
-static int omap3_mbox_resources_sz = ARRAY_SIZE(omap3_mbox_resources);
-#else
-#define omap3_mbox_resources NULL
-#define omap3_mbox_resources_sz0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-
-#define OMAP4_MBOX_REG_SIZE0x130
-static struct resource omap4_mbox_resources[] = {
- {
- .start = OMAP44XX_MAILBOX_BASE,
- .end= OMAP44XX_MAILBOX_BASE +
- OMAP4_MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP44XX_IRQ_MAIL_U0,
- .flags = IORESOURCE_IRQ,
- .name = "mbox",
- },
-};
-static int omap4_mbox_resources_sz = ARRAY_SIZE(omap4_mbox_resources);
-#else
-#define omap4_mbox_resources NULL
-#define omap4_mbox_resources_sz0
-#endif
-
-static struct platform_device mbox_device = {
- .name = "omap-mailbox",
- .id = -1,
-};
-
static inline void omap_init_mbox(void)
{
- if (cpu_is_omap24xx()) {
- mbox_device.resource = omap2_mbox_resources;
- mbox_device.num_resources = omap2_mbox_resources_sz;
- } else if (cpu_is_omap34xx()) {
- mbox_device.resource = omap3_mbox_resources;
- mbox_device.num_resources = omap3_mbox_resources_sz;
- } else if (cpu_is_omap44xx()) {
- mbox_device.resource = omap4_mbox_resources;
- mbox_device.num_resources = omap4_mbox_resources_sz;
- } else {
- pr_err("%s: platform not supported\n", __func__);
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+
+ oh = omap_hwmod_lookup("mailbox");
+ if (!oh) {
+ pr_err("%s: unable to find hwmod\n", __func__);
+ return;
+ }
+
+ od = omap_device_build("omap-mailbox", -1, oh,
If possible, it will be better to use the "omap_" prefix in order to
start having some consitency in the omap devices name.
Today, we have a little bit of a mess:
i2c_omap.1
omap2_mcspi.1
omap-mcbsp.1
mmci-omap-hs.0
musb_hdrc
omap-aes
omap-sham
omap_hdq.0
omap_rng
omap_wdt
omapdss
Thanks,
Benoit
+ NULL, 0,
+ NULL, 0,
+ 0);
+ if (!od) {
+ pr_err("%s: could not build device\n", __func__);
return;
}
- platform_device_register(&mbox_device);
}
#else
static inline void omap_init_mbox(void) { }
--
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 5/7] omap: mailbox: add omap_device latency information
On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote:
From: Felipe Contreras
So that we can enable the main clock.
Why not going directly to the runtime PM interface? It will save you
some effort, because most of this code is useless with runtime PM.
Moreover, even without runtime PM, you should not need at all the
SYSCONFIG stuff you still have in this driver.
36 /* SYSCONFIG: register bit definition */
37 #define AUTOIDLE(1 << 0)
38 #define SOFTRESET (1 << 1)
39 #define SMARTIDLE (2 << 3)
40 #define OMAP4_SOFTRESET (1 << 0)
41 #define OMAP4_NOIDLE(1 << 2)
42 #define OMAP4_SMARTIDLE (2 << 2)
That patch seems to me the perfect place to get rid of that.
Thanks,
Benoit
Signed-off-by: Felipe Contreras
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/devices.c | 18 --
arch/arm/mach-omap2/mailbox.c | 21 +
arch/arm/plat-omap/include/plat/mailbox.h |6 ++
3 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d977572..dafc23a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "mux.h"
#include "control.h"
@@ -141,10 +142,19 @@ static inline void omap_init_camera(void)
#endif
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
+static struct omap_device_pm_latency mbox_latencies[] = {
+ [0] = {
+ .activate_func = omap_device_enable_clocks,
+ .deactivate_func = omap_device_enable_clocks,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
static inline void omap_init_mbox(void)
{
struct omap_hwmod *oh;
struct omap_device *od;
+ struct omap_mbox_platform_data pdata;
oh = omap_hwmod_lookup("mailbox");
if (!oh) {
@@ -152,10 +162,14 @@ static inline void omap_init_mbox(void)
return;
}
+ pdata.device_enable = omap_device_enable;
+ pdata.device_disable = omap_device_idle;
+
od = omap_device_build("omap-mailbox", -1, oh,
- NULL, 0,
- NULL, 0,
+ &pdata, sizeof(pdata),
+ mbox_latencies, ARRAY_SIZE(mbox_latencies),
0);
+
if (!od) {
pr_err("%s: could not build device\n", __func__);
return;
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 40ddeca..bf598a3 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -52,6 +52,7 @@
#define OMAP4_MBOX_NR_REGS(OMAP4_MBOX_REG_SIZE / sizeof(u32))
static void __iomem *mbox_base;
+static struct platform_device *mbox_pdev;
struct omap_mbox2_fifo {
unsigned long msg;
@@ -70,8 +71,6 @@ struct omap_mbox2_priv {
unsigned long irqdisable;
};
-static struct clk *mbox_ick_handle;
-
static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq);
@@ -90,14 +89,10 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
{
u32 l;
unsigned long timeout;
+ struct omap_mbox_platform_data *pdata = mbox_pdev->dev.platform_data;
- mbox_ick_handle = clk_get(NULL, "mailboxes_ick");
- if (IS_ERR(mbox_ick_handle)) {
- printk(KERN_ERR "Could not get mailboxes_ick: %ld\n",
- PTR_ERR(mbox_ick_handle));
- return PTR_ERR(mbox_ick_handle);
- }
- clk_enable(mbox_ick_handle);
+ if (pdata->device_enable)
+ pdata->device_enable(mbox_pdev);
if (cpu_is_omap44xx()) {
mbox_write_reg(OMAP4_SOFTRESET, MAILBOX_SYSCONFIG);
@@ -143,9 +138,9 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
static void omap2_mbox_shutdown(struct omap_mbox *mbox)
{
- clk_disable(mbox_ick_handle);
- clk_put(mbox_ick_handle);
- mbox_ick_handle = NULL;
+ struct omap_mbox_platform_data *pdata = mbox_pdev->dev.platform_data;
+ if (pdata->device_disable)
+ pdata->device_disable(mbox_pdev);
}
/* Mailbox FIFO handle functions */
@@ -427,6 +422,8 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (!mbox_base)
return -ENOMEM;
+ mbox_pdev = pdev;
+
ret = omap_mbox_register(&pdev->dev, list);
if (ret) {
iounmap(mbox_base);
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..59443b1 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -11,6 +11,7 @@
typedef u32 mbox_msg_t;
struct omap_mbox;
+struct platform_device;
typedef int __bitwise omap_mbox_irq_t;
#define IRQ_TX ((__forc
Re: [PATCH v2 6/7] omap: mailbox: fix detection for previously supported chips
On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote:
Fix the mailbox detection for OMAP3630 and 2430, also minor
cleanup on conditional ifdef's that could affect it.
Given that 2430 has an iva too include it, as the same steps
for omap3 apply.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/mailbox.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index bf598a3..5e9ea0f 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -276,7 +276,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
/* FIXME: the following structs should be filled automatically by the user id
*/
-#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP2)
/* DSP */
static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -301,7 +301,7 @@ struct omap_mbox mbox_dsp_info = {
};
#endif
-#if defined(CONFIG_ARCH_OMAP3430)
+#if defined(CONFIG_ARCH_OMAP3)
Ideally you should get rid of all the CONFIG_ARCH_OMAPXXX or cpu_is_omap
in that code. This is a driver, it should be generic.
If you have to handle differences between OMAP version, please do that
in the devices, not in the driver.
This patch just contains a few of them, but the original mailbox.c file
is full of that kind of test.
I know that you are not the original writer of this code, but since the
clean it, it will be good to remove all the legacy code.
Thanks,
Benoit
struct omap_mbox *omap3_mboxes[] = {&mbox_dsp_info, NULL };
#endif
@@ -389,15 +389,19 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (false)
;
-#if defined(CONFIG_ARCH_OMAP3430)
- else if (cpu_is_omap3430()) {
+#if defined(CONFIG_ARCH_OMAP3)
+ else if (cpu_is_omap34xx()) {
list = omap3_mboxes;
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
}
#endif
-#if defined(CONFIG_ARCH_OMAP2420)
- else if (cpu_is_omap2420()) {
+#if defined(CONFIG_ARCH_OMAP2)
+ else if (cpu_is_omap2430()) {
+ list = omap2_mboxes;
+
+ list[0]->irq = platform_get_irq_byname(pdev, "dsp");
+ } else if (cpu_is_omap2420()) {
list = omap2_mboxes;
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
--
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 7/7] omap: mailbox: remove unreachable return
On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote: Remove unreachable return statement. Signed-off-by: Omar Ramirez Luna --- arch/arm/mach-omap2/mailbox.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 5e9ea0f..335eb2b 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -434,8 +434,6 @@ static int __devinit omap2_mbox_probe(struct platform_device *pdev) return ret; } Please add a blank line here. Otherwise you can add: Acked-by: Benoit Cousson Thanks, Benoit return 0; - - return ret; } static int __devexit omap2_mbox_remove(struct platform_device *pdev) -- 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/6] omap: iommu: hwmod support and code reorganization
s/ducati/ipu/ s/tesla/dsp/ Please do not use internal codename for the changelog or even for the code. On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote: Boot tested on omap 3430 and 3630, functionality on iva2 only. Introduced hwmod data and support for omap3 (iva2 mmu& isp mmu) and omap4 (ducati mmu& tesla mmu). Minor cleanup due to this changes. There is an issue (present without patches too): Doing a cycle of insmod-rmmod to iommu module and then full insmod of bridgedriver (with all dependencies) causes the next read of iommu registers to dump an unhandled fault log; this, because when rmmod of iommu is called it tries to clean the iommu tables and flush any old entry prior to removing the driver, however these reads/writes are attempted while the MMU is under reset and will timeout on the L3 IVA target agent, which will leave MMU unusable until the proper restore sequence to clear this L3 error is executed. Fix would be to move page table allocation to iommu get and its correspondent free to iommu put, however it will fall entirely under iommu user responsibility, as it needs to clear the mmu reset bit, before calling iommu functions that read/write into mmu registers (which should apply only for first boot or on baseimage reload); trading this restriction in order to keep the same generic iommu code for all omap iommu devices. This issue has been seen on omap3 iva2 mmu, same restriction should I'm still not really understanding that issue. In theory, the reset is deasserted when the omap_device is enabled and will be re-asserted when the omap_device will be disable. Why is the mmu already under reset when the iommu is trying to clean the tables? Could please describe the complete sequence? Benoit apply for tesla mmu. For discussion: should iommu handle mmu reset source directly? This register is grouped into an IVA PRM register which handles sequencer, iva2 mmu and dsp resets. As mentioned iommu handles cam, iva2 mmu (OMAP3) and tesla, ducati mmu (OMAP4), only tesla and iva2 should suffer from this restriction and according changes should be needed to handle both cases on mach-omap2 code. This also affects hwmod, since, if defined, it tries to read SYSC registers at boot time when registering the hwmod and causing the same issue. Omar Ramirez Luna (6): omap: iommu: remove redundant clock usage OMAP3: hwmod data: Add mmu for iva2 and isp OMAP4: hwmod data: add mmu hwmod for ducati and tesla omap: iommu: intial hwmod support omap: iommu: hwmod device enable/disable routines omap: iommu: code reorganization and cleanup arch/arm/mach-omap2/omap-iommu.c | 168 +--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 103 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 105 + arch/arm/plat-omap/include/plat/iommu.h| 19 +++- arch/arm/plat-omap/include/plat/omap34xx.h |2 + arch/arm/plat-omap/iommu.c | 64 --- 6 files changed, 299 insertions(+), 162 deletions(-) -- 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/7] omap: mailbox: hwmod support and dependent cleanup patches
On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote: hwmod support for omap2 and omap3 chips, plus cleanups. Tested on 3430 and 3630 ** v2 ** - Added omap4 hwmod support. - Moved "mailbox_ick" from hwmod to hwmod_if (omap 2/3) - Declared sysc classes for omap 2/3 ** v1 ** 1. omap: mailbox: initial hwmod support for omap3 Changes were made to: - Rebase to latest code. - Detect the hwmod by filling prcm union for omap2, without this it was unable to build the hwmod at runtime. - Replace magic number for defines. - Use ioremap again instead of relying on the one made by hwmod, as noted in http://patchwork.kernel.org/patch/101661/ 2. omap: mailbox: initial hwmod support for omap2 Was only compiled tested!! Unfortunately I don't have the HW for it. 4. omap: mailbox: fix detection for previously supported chips Original patch was using features framework, but when compiled as a module it was breaking, this patch uses cpu_is_omap34xx macro instead. This is meant as a short term solution until proper cleanup is done, as suggested in: http://marc.info/?l=linux-arm-kernel&m=128534253231481&w=2 Benoit Cousson (1): OMAP4: hwmod data: add mailbox data Felipe Contreras (3): OMAP3: hwmod data: add mailbox data omap: mailbox: initial hwmod support omap: mailbox: add omap_device latency information Could you please try to use a consistent naming in the subject? You use OMAP3, OMAP4, OMAP2 so it should be OMAP and not omap. Thanks, Benoit Omar Ramirez Luna (3): OMAP2: hwmod data: add mailbox data omap: mailbox: fix detection for previously supported chips omap: mailbox: remove unreachable return arch/arm/mach-omap2/devices.c | 104 +++- arch/arm/mach-omap2/mailbox.c | 39 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 67 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 66 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 66 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 63 + arch/arm/plat-omap/include/plat/mailbox.h |6 ++ 7 files changed, 311 insertions(+), 100 deletions(-) -- 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/6] omap: iommu: hwmod support and code reorganization
On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote: Boot tested on omap 3430 and 3630, functionality on iva2 only. Introduced hwmod data and support for omap3 (iva2 mmu& isp mmu) and omap4 (ducati mmu& tesla mmu). Minor cleanup due to this changes. There is an issue (present without patches too): Doing a cycle of insmod-rmmod to iommu module and then full insmod of bridgedriver (with all dependencies) causes the next read of iommu registers to dump an unhandled fault log; this, because when rmmod of iommu is called it tries to clean the iommu tables and flush any old entry prior to removing the driver, however these reads/writes are attempted while the MMU is under reset and will timeout on the L3 IVA target agent, which will leave MMU unusable until the proper restore sequence to clear this L3 error is executed. Fix would be to move page table allocation to iommu get and its correspondent free to iommu put, however it will fall entirely under iommu user responsibility, as it needs to clear the mmu reset bit, before calling iommu functions that read/write into mmu registers (which should apply only for first boot or on baseimage reload); trading this restriction in order to keep the same generic iommu code for all omap iommu devices. This issue has been seen on omap3 iva2 mmu, same restriction should apply for tesla mmu. For discussion: should iommu handle mmu reset source directly? This register is grouped into an IVA PRM register which handles sequencer, iva2 mmu and dsp resets. As mentioned iommu handles cam, iva2 mmu (OMAP3) and tesla, ducati mmu (OMAP4), only tesla and iva2 should suffer from this restriction and according changes should be needed to handle both cases on mach-omap2 code. This also affects hwmod, since, if defined, it tries to read SYSC registers at boot time when registering the hwmod and causing the same issue. Omar Ramirez Luna (6): omap: iommu: remove redundant clock usage OMAP3: hwmod data: Add mmu for iva2 and isp OMAP4: hwmod data: add mmu hwmod for ducati and tesla omap: iommu: intial hwmod support omap: iommu: hwmod device enable/disable routines omap: iommu: code reorganization and cleanup Could you please try to use a consistent naming in the subjects? OMAP3, OMAP4, OMAP2 --> OMAP and not omap. Thanks, Benoit arch/arm/mach-omap2/omap-iommu.c | 168 +--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 103 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 105 + arch/arm/plat-omap/include/plat/iommu.h| 19 +++- arch/arm/plat-omap/include/plat/omap34xx.h |2 + arch/arm/plat-omap/iommu.c | 64 --- 6 files changed, 299 insertions(+), 162 deletions(-) -- 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/6] omap: iommu: remove redundant clock usage
On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote:
iommu driver is meant to provide control of mmu hardware blocks
A dot is missing here, and a capital letter should follow.
its current users (MMUs) are part of larger subsystems and do not
have a dedicated clock as the one they use is shared with the
entire subsystem, it doesn't make sense to enable/disable on each
register read/write operation as the driver using its interface
should also be handling the same clock.
iommu should only enable/disable the clock on mmu request/free from
the driver wanting to use it.
Mmm, I'm not necessarily convinced by that explanation.
If in a next revision, we change the clock partitioning and provide a
dedicated clock for the mmu, it will not work anymore.
I don't thing you should assume anything about the current partitioning.
That being said, when you will change that code to switch to runtime PM,
you will end up managing the module state in the ISR context.
Regards,
Benoit
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/iommu.c | 38 +-
1 files changed, 5 insertions(+), 33 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 6cd151b..de992c8 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -108,7 +108,6 @@ static int iommu_enable(struct iommu *obj)
err = arch_iommu->enable(obj);
- clk_disable(obj->clk);
return err;
}
@@ -117,8 +116,6 @@ static void iommu_disable(struct iommu *obj)
if (!obj)
return;
- clk_enable(obj->clk);
-
arch_iommu->disable(obj);
clk_disable(obj->clk);
@@ -237,20 +234,16 @@ static struct cr_regs __iotlb_read_cr(struct iommu *obj,
int n)
**/
int load_iotlb_entry(struct iommu *obj, struct iotlb_entry *e)
{
- int err = 0;
struct iotlb_lock l;
struct cr_regs *cr;
if (!obj || !obj->nr_tlb_entries || !e)
return -EINVAL;
- clk_enable(obj->clk);
-
iotlb_lock_get(obj,&l);
if (l.base == obj->nr_tlb_entries) {
dev_warn(obj->dev, "%s: preserve entries full\n", __func__);
- err = -EBUSY;
- goto out;
+ return -EBUSY;
}
if (!e->prsvd) {
int i;
@@ -262,8 +255,7 @@ int load_iotlb_entry(struct iommu *obj, struct iotlb_entry
*e)
if (i == obj->nr_tlb_entries) {
dev_dbg(obj->dev, "%s: full: no entry\n", __func__);
- err = -EBUSY;
- goto out;
+ return -EBUSY;
}
iotlb_lock_get(obj,&l);
@@ -273,10 +265,8 @@ int load_iotlb_entry(struct iommu *obj, struct iotlb_entry
*e)
}
cr = iotlb_alloc_cr(obj, e);
- if (IS_ERR(cr)) {
- clk_disable(obj->clk);
+ if (IS_ERR(cr))
return PTR_ERR(cr);
- }
iotlb_load_cr(obj, cr);
kfree(cr);
@@ -287,9 +277,8 @@ int load_iotlb_entry(struct iommu *obj, struct iotlb_entry
*e)
if (++l.vict == obj->nr_tlb_entries)
l.vict = l.base;
iotlb_lock_set(obj,&l);
-out:
- clk_disable(obj->clk);
- return err;
+
+ return 0;
}
EXPORT_SYMBOL_GPL(load_iotlb_entry);
@@ -305,8 +294,6 @@ void flush_iotlb_page(struct iommu *obj, u32 da)
int i;
struct cr_regs cr;
- clk_enable(obj->clk);
-
for_each_iotlb_cr(obj, obj->nr_tlb_entries, i, cr) {
u32 start;
size_t bytes;
@@ -324,7 +311,6 @@ void flush_iotlb_page(struct iommu *obj, u32 da)
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
- clk_disable(obj->clk);
if (i == obj->nr_tlb_entries)
dev_dbg(obj->dev, "%s: no page for %08x\n", __func__, da);
@@ -359,15 +345,11 @@ void flush_iotlb_all(struct iommu *obj)
{
struct iotlb_lock l;
- clk_enable(obj->clk);
-
l.base = 0;
l.vict = 0;
iotlb_lock_set(obj,&l);
iommu_write_reg(obj, 1, MMU_GFLUSH);
-
- clk_disable(obj->clk);
}
EXPORT_SYMBOL_GPL(flush_iotlb_all);
@@ -382,9 +364,7 @@ EXPORT_SYMBOL_GPL(flush_iotlb_all);
*/
void iommu_set_twl(struct iommu *obj, bool on)
{
- clk_enable(obj->clk);
arch_iommu->set_twl(obj, on);
- clk_disable(obj->clk);
}
EXPORT_SYMBOL_GPL(iommu_set_twl);
@@ -395,12 +375,8 @@ ssize_t iommu_dump_ctx(struct iommu *obj, char *buf,
ssize_t bytes)
if (!obj || !buf)
return -EINVAL;
- clk_enable(obj->clk);
-
bytes = arch_iommu->dump_ctx(obj, buf, bytes);
- clk_disable(obj->clk);
-
return bytes;
}
EXPORT_SYMBOL_GPL(iommu_dump_ctx);
@@ -412,7 +388,6 @@ static int __dump_tlb_entries(struct iommu *obj, struct
cr_regs *crs, int num)
struct cr_regs tmp;
struct cr_regs *p = crs;
-
Re: [PATCH 2/6] OMAP3: hwmod data: Add mmu for iva2 and isp
On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote:
Add mmu hwmod data for iva2 and isp.
s/iva2/iva/
If you do need the version information, you should use the rev field in
the hwmod class.
All the comments about the structure fields order I did on your mailbox
series will apply here as well.
Benoit
Plus a define for the iva2 base register.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 103
arch/arm/plat-omap/include/plat/iommu.h|8 ++
arch/arm/plat-omap/include/plat/omap34xx.h |2 +
3 files changed, 113 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 60d977e..ff80efc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "omap_hwmod_common_data.h"
@@ -801,6 +802,106 @@ static struct omap_hwmod omap3xxx_mailbox_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* mmu */
+
+static struct omap_hwmod_class omap3xxx_mmu_hwmod_class = {
+ .name = "mmu",
+};
+
+/* isp mmu */
+
+static struct omap_hwmod omap3xxx_isp_mmu_hwmod;
+
+static struct omap_hwmod_addr_space omap3xxx_isp_mmu_addrs[] = {
+ {
+ .pa_start = OMAP3430_ISP_MMU_BASE,
+ .pa_end = OMAP3430_ISP_MMU_BASE + SZ_256 - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l4_core -> isp mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__isp_mmu = {
+ .master =&omap3xxx_l4_core_hwmod,
+ .slave =&omap3xxx_isp_mmu_hwmod,
+ .addr = omap3xxx_isp_mmu_addrs,
+ .clk= "cam_ick",
+ .addr_cnt = ARRAY_SIZE(omap3xxx_isp_mmu_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* isp mmu slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_isp_mmu_slaves[] = {
+ &omap3xxx_l4_core__isp_mmu,
+};
+
+static struct omap_hwmod_irq_info omap3xxx_isp_mmu_irqs[] = {
+ { .name = "isp", .irq = INT_24XX_CAM_IRQ, },
+};
+
+static struct omap_mmu_dev_attr isp_mmu_dev_attr = {
+ .nr_tlb_entries = 8,
+};
+
+static struct omap_hwmod omap3xxx_isp_mmu_hwmod = {
+ .name = "isp",
+ .class =&omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_isp_mmu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_isp_mmu_irqs),
+ .slaves = omap3xxx_isp_mmu_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_isp_mmu_slaves),
+ .dev_attr =&isp_mmu_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
+/* iva2 mmu */
+
+static struct omap_hwmod omap3xxx_iva2_mmu_hwmod;
+
+static struct omap_hwmod_addr_space omap3xxx_iva2_mmu_addrs[] = {
+ {
+ .pa_start = OMAP34XX_IVA2_MMU_BASE,
+ .pa_end = OMAP34XX_IVA2_MMU_BASE + SZ_256 - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l3_main -> iva2 mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l3_main__iva2_mmu = {
+ .master =&omap3xxx_l3_main_hwmod,
+ .slave =&omap3xxx_iva2_mmu_hwmod,
+ .addr = omap3xxx_iva2_mmu_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_iva2_mmu_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* iva2 mmu slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_iva2_mmu_slaves[] = {
+ &omap3xxx_l3_main__iva2_mmu,
+};
+
+static struct omap_hwmod_irq_info omap3xxx_iva2_mmu_irqs[] = {
+ { .name = "iva2", .irq = INT_24XX_DSP_MMU, },
+};
+
+static struct omap_mmu_dev_attr iva2_mmu_dev_attr = {
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap3xxx_iva2_mmu_hwmod = {
+ .name = "iva2",
+ .class =&omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_iva2_mmu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_iva2_mmu_irqs),
+ .main_clk = "iva2_ck",
+ .slaves = omap3xxx_iva2_mmu_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_iva2_mmu_slaves),
+ .dev_attr =&iva2_mmu_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_l3_main_hwmod,
&omap3xxx_l4_core_hwmod,
@@ -817,6 +918,8 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_i2c2_hwmod,
&omap3xxx_i2c3_hwmod,
&omap3xxx_mailbox_hwmod,
+ &omap3xxx_isp_mmu_hwmod,
+ &omap3xxx_iva2_mmu_hwmod,
NULL,
};
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 33c7d41..91a75a5 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm
Re: [PATCH 3/6] OMAP4: hwmod data: add mmu hwmod for ducati and tesla
On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote:
Add mmu hwmod data for ducati and tesla.
s/ducati/ipu/
s/tesla/dsp/
Please do not use internal codename.
Here again, you completely changed the omap4 existing data for (almost)
nothing.
I agree, the original code was not considering the mmu as a hwmod but
only the core of the subsystem: mmu + cache.
But as far as I can see, you just added a new mmu class, a dev_attr, and
the hwmod remain almost the same.
Otherwise, you replaced the proper names by the bad one, and you removed
important data (hw reset for ex).
Please start from the original code and fix what is missing or wrong but
do not re-write everything.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 105
1 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f7525e3..1d5eace 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include "omap_hwmod_common_data.h"
@@ -1103,6 +1104,106 @@ static struct omap_hwmod omap44xx_mailbox_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/* mmu */
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = "mmu",
+};
That change is OK. The remaining part seems to be completely broken.
+
+/* ducati mmu */
+
+static struct omap_hwmod omap44xx_ducati_mmu_hwmod;
+
+static struct omap_hwmod_addr_space omap44xx_ducati_mmu_addrs[] = {
+ {
+ .pa_start = OMAP4_MMU1_BASE,
+ .pa_end = OMAP4_MMU1_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l3_main_1 -> ducati mmu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_1__ducati_mmu = {
+ .master =&omap44xx_l3_main_1_hwmod,
+ .slave =&omap44xx_ducati_mmu_hwmod,
+ .addr = omap44xx_ducati_mmu_addrs,
+ .clk= "dpll_mpu_m2_ck",
Are you sure of that?
Benoit
+ .addr_cnt = ARRAY_SIZE(omap44xx_ducati_mmu_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* ducati mmu slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_ducati_mmu_slaves[] = {
+ &omap44xx_l3_main_1__ducati_mmu,
+};
+
+static struct omap_hwmod_irq_info omap44xx_ducati_mmu_irqs[] = {
+ { .name = "ducati", .irq = 100 + OMAP44XX_IRQ_GIC_START, },
+};
+
+static struct omap_mmu_dev_attr ducati_mmu_dev_attr = {
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_ducati_mmu_hwmod = {
+ .name = "ducati",
+ .class =&omap44xx_mmu_hwmod_class,
+ .mpu_irqs = omap44xx_ducati_mmu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_ducati_mmu_irqs),
+ .slaves = omap44xx_ducati_mmu_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_ducati_mmu_slaves),
+ .dev_attr =&ducati_mmu_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
+/* tesla mmu */
+
+static struct omap_hwmod omap44xx_tesla_mmu_hwmod;
+
+static struct omap_hwmod_addr_space omap44xx_tesla_mmu_addrs[] = {
+ {
+ .pa_start = OMAP4_MMU2_BASE,
+ .pa_end = OMAP4_MMU2_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l3_main_1 -> tesla mmu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_1__tesla_mmu = {
+ .master =&omap44xx_l3_main_1_hwmod,
+ .slave =&omap44xx_tesla_mmu_hwmod,
+ .addr = omap44xx_tesla_mmu_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_tesla_mmu_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* tesla mmu slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_tesla_mmu_slaves[] = {
+ &omap44xx_l3_main_1__tesla_mmu,
+};
+
+static struct omap_hwmod_irq_info omap44xx_tesla_mmu_irqs[] = {
+ { .name = "tesla", .irq = 28 + OMAP44XX_IRQ_GIC_START, },
+};
+
+static struct omap_mmu_dev_attr tesla_mmu_dev_attr = {
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_tesla_mmu_hwmod = {
+ .name = "tesla",
+ .class =&omap44xx_mmu_hwmod_class,
+ .mpu_irqs = omap44xx_tesla_mmu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_tesla_mmu_irqs),
+ .main_clk = "dsp_fck",
+ .slaves = omap44xx_tesla_mmu_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_tesla_mmu_slaves),
+ .dev_attr =&tesla_mmu_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
&omap44xx_dmm_hwmod,
@@ -1140,6 +1241,10 @@ static __in
Re: [PATCH 4/6] omap: iommu: intial hwmod support
On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote:
Use the defined hwmod data according to the devices
present on omap3 and omap4.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap-iommu.c| 77 ---
arch/arm/plat-omap/include/plat/iommu.h |2 +-
arch/arm/plat-omap/iommu.c |2 +-
3 files changed, 21 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..65460ef 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -14,12 +14,11 @@
#include
#include
+#include
+#include
struct iommu_device {
- resource_size_t base;
- int irq;
struct iommu_platform_data pdata;
- struct resource res[2];
};
static struct iommu_device *devices;
static int num_iommu_devices;
@@ -27,128 +26,90 @@ static int num_iommu_devices;
#ifdef CONFIG_ARCH_OMAP3
static struct iommu_device omap3_devices[] = {
You should not need that at all, you are just duplicating the data that
are already in hwmod, and then you are going to create real platform_device.
{
- .base = 0x480bd400,
- .irq = 24,
.pdata = {
.name = "isp",
- .nr_tlb_entries = 8,
.clk_name = "cam_ick",
},
},
#if defined(CONFIG_MPU_BRIDGE_IOMMU)
{
- .base = 0x5d00,
- .irq = 28,
.pdata = {
.name = "iva2",
- .nr_tlb_entries = 32,
.clk_name = "iva2_ck",
},
},
#endif
};
#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
#else
#define omap3_devices NULL
#define NR_OMAP3_IOMMU_DEVICES0
-#define omap3_iommu_pdev NULL
#endif
#ifdef CONFIG_ARCH_OMAP4
static struct iommu_device omap4_devices[] = {
{
- .base = OMAP4_MMU1_BASE,
- .irq = OMAP44XX_IRQ_DUCATI_MMU,
.pdata = {
.name = "ducati",
- .nr_tlb_entries = 32,
.clk_name = "ducati_ick",
},
},
#if defined(CONFIG_MPU_TESLA_IOMMU)
{
- .base = OMAP4_MMU2_BASE,
- .irq = INT_44XX_DSP_MMU,
.pdata = {
.name = "tesla",
- .nr_tlb_entries = 32,
.clk_name = "tesla_ick",
},
},
#endif
};
#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
#else
#define omap4_devices NULL
#define NR_OMAP4_IOMMU_DEVICES0
-#define omap4_iommu_pdev NULL
#endif
Most of that previous code should not exist anymore with hwmod.
All the information you will need should be in hwmod data.
-static struct platform_device **omap_iommu_pdev;
-
static int __init omap_iommu_init(void)
{
- int i, err;
- struct resource res[] = {
- { .flags = IORESOURCE_MEM },
- { .flags = IORESOURCE_IRQ },
- };
+ int i;
if (cpu_is_omap34xx()) {
devices = omap3_devices;
- omap_iommu_pdev = omap3_iommu_pdev;
num_iommu_devices = NR_OMAP3_IOMMU_DEVICES;
} else if (cpu_is_omap44xx()) {
devices = omap4_devices;
- omap_iommu_pdev = omap4_iommu_pdev;
num_iommu_devices = NR_OMAP4_IOMMU_DEVICES;
} else
return -ENODEV;
for (i = 0; i< num_iommu_devices; i++) {
Don't do that, just iterate over the hwmod class using
omap_hwmod_for_each_by_class. Please have a look at the drivers with
multiple devices that are already using hwmod (i2c, uart...).
- struct platform_device *pdev;
- const struct iommu_device *d =&devices[i];
+ struct omap_hwmod *oh;
+ struct omap_device *od;
- pdev = platform_device_alloc("omap-iommu", i);
- if (!pdev) {
- err = -ENOMEM;
- goto err_out;
+ oh = omap_hwmod_lookup(devices[i].pdata.name);
+ if (!oh) {
+ pr_err("%s: hwmod not found\n", __func__);
+ return -ENODEV;
}
- res[0].start = d->base;
- res[0].end = d->base + MMU_REG_SIZE - 1;
- res[1].start = res[1].end = d->irq;
+ devices[i].pdata.mmu_attr =
+ (struct omap_mmu_dev_attr *)oh->dev_attr;
You need to create your pdata here, and attached it to the device.
- err = platform_device_add_r
Re: [PATCH 5/6] omap: iommu: hwmod device enable/disable routines
You should use runtime PM directly. That omap_device step is useless.
Moreover, this patch should be merged with the previous one.
Benoit
On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote:
Use omap device enable/disable routines.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap-iommu.c| 16 +++-
arch/arm/plat-omap/include/plat/iommu.h |7 +--
arch/arm/plat-omap/iommu.c | 24 +++-
3 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 65460ef..0a76bce 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -28,14 +28,12 @@ static struct iommu_device omap3_devices[] = {
{
.pdata = {
.name = "isp",
- .clk_name = "cam_ick",
},
},
#if defined(CONFIG_MPU_BRIDGE_IOMMU)
{
.pdata = {
.name = "iva2",
- .clk_name = "iva2_ck",
},
},
#endif
@@ -51,14 +49,12 @@ static struct iommu_device omap4_devices[] = {
{
.pdata = {
.name = "ducati",
- .clk_name = "ducati_ick",
},
},
#if defined(CONFIG_MPU_TESLA_IOMMU)
{
.pdata = {
.name = "tesla",
- .clk_name = "tesla_ick",
},
},
#endif
@@ -69,6 +65,14 @@ static struct iommu_device omap4_devices[] = {
#define NR_OMAP4_IOMMU_DEVICES0
#endif
+static struct omap_device_pm_latency iommu_latencies[] = {
+ [0] = {
+ .activate_func = omap_device_enable_clocks,
+ .deactivate_func = omap_device_enable_clocks,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST
+ },
+};
+
static int __init omap_iommu_init(void)
{
int i;
@@ -94,10 +98,12 @@ static int __init omap_iommu_init(void)
devices[i].pdata.mmu_attr =
(struct omap_mmu_dev_attr *)oh->dev_attr;
+ devices[i].pdata.device_enable = omap_device_enable;
+ devices[i].pdata.device_disable = omap_device_idle;
od = omap_device_build("omap-iommu", i, oh,
&devices[i].pdata, sizeof(devices[i].pdata),
- NULL, 0,
+ iommu_latencies, ARRAY_SIZE(iommu_latencies),
0);
if (!od) {
pr_err("%s: error device build failed\n", __func__);
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 9650309..fd8ffeb 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -13,6 +13,8 @@
#ifndef __MACH_IOMMU_H
#define __MACH_IOMMU_H
+struct platform_device;
+
struct iotlb_entry {
u32 da;
u32 pa;
@@ -28,7 +30,6 @@ struct iotlb_entry {
struct iommu {
const char *name;
struct module *owner;
- struct clk *clk;
void __iomem*regbase;
struct device *dev;
@@ -109,8 +110,10 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
- const char *clk_name;
struct omap_mmu_dev_attr *mmu_attr;
+
+ int (*device_enable)(struct platform_device *pdev);
+ int (*device_disable)(struct platform_device *pdev);
};
#if defined(CONFIG_ARCH_OMAP1)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 0fc9d90..36b1b63 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -100,11 +100,17 @@ EXPORT_SYMBOL_GPL(iommu_arch_version);
static int iommu_enable(struct iommu *obj)
{
int err;
+ struct iommu_platform_data *pdata;
+ struct platform_device *pdev;
if (!obj)
return -EINVAL;
- clk_enable(obj->clk);
+ pdev = container_of(obj->dev, struct platform_device, dev);
+ pdata = obj->dev->platform_data;
+
+ if (pdata->device_enable)
+ pdata->device_enable(pdev);
err = arch_iommu->enable(obj);
@@ -113,12 +119,19 @@ static int iommu_enable(struct iommu *obj)
static void iommu_disable(struct iommu *obj)
{
+ struct iommu_platform_data *pdata;
+ struct platform_device *pdev;
+
if (!obj)
return;
arch_iommu->disable(obj);
- clk_disable(obj->clk);
+ pdev = container_of(obj->dev, struct platform_device, dev);
+ pdata = obj->dev->platform_data;
+
+ if (pdata->device_enable)
+ pdata->device_disable(pdev);
}
/*
@@ -886,10 +899,6 @@ static int __devinit omap_iommu_probe(struct
platform_device *pdev)
if (!obj)
return -ENOMEM;
- obj->
Re: [PATCH 6/6] omap: iommu: code reorganization and cleanup
On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote:
Since omap-iommu is now using hwmod, there are structures and
arrays that can be cleaned up to increase the readability of
the code.
This patch should be merged with the previous one as well.
I do not see the need to split in 3 patches these changes.
It will be much readable and will avoid people, like me, doing comment
on a piece of code you will remove 2 patches later.
That cleanup must be done when the hwmod is introduced since that code
was already useless at that time.
I can understand the phased approach when you have huge changes to do,
but in that case, that does not worth it. It make the review even more
painful.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap-iommu.c| 95 +++
arch/arm/plat-omap/include/plat/iommu.h |2 +-
2 files changed, 34 insertions(+), 63 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 0a76bce..135474b 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -17,53 +17,17 @@
#include
#include
-struct iommu_device {
- struct iommu_platform_data pdata;
+static char *omap3_devices[] = {
+ "isp",
+ "iva2",
+ NULL,
};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .pdata = {
- .name = "isp",
- },
- },
-#if defined(CONFIG_MPU_BRIDGE_IOMMU)
- {
- .pdata = {
- .name = "iva2",
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .pdata = {
- .name = "ducati",
- },
- },
-#if defined(CONFIG_MPU_TESLA_IOMMU)
- {
- .pdata = {
- .name = "tesla",
- },
- },
-#endif
+
+static char *omap4_devices[] = {
+ "ducati",
+ "tesla",
+ NULL,
Not needed if you iterate over the class.
Benoit
--
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 3/7] OMAP4: hwmod data: add mailbox data
Hi Omar,
On 11/7/2010 10:07 AM, Ramirez Luna, Omar wrote:
On Sat, Nov 6, 2010 at 12:18 PM, Cousson, Benoit wrote:
I don't know why, but this patch has nothing to do with my original one.
Can you stick to the original code?
no, apart from the ordering of structure members, that I will change,
If you do want to change a patch already submitted to loml, the least
you can do is to comment on the mailing list, and afaik, you didn't
provide any comment on this code.
So do not change it without any explanation or any rational.
That's the most basic rule of the patch submission / review process in
Linux.
since keeping the order of the original structure doesn't fly, I don't
see anything that needs to be changed.
- The magic numbers replaced for the defines, afaik it gives more clarity.
No, since these are not magic numbers but physical address or dma number
or irq channel.
That does not give any more clarity to add a define, and in fact it adds
an extra level of indirection for nothing.
The hwmod file is "the" unique HW definition files. So all the
information that used to be scattered all over various header files will
have to be there.
You should considered this file as a global SoC HW definition file.
- mailbox irq has a name.
Which is in the structure anyway, so again no need to add a define.
All the structure that are populated hrer are all unique to every IP, so
having that kind of assignment does not seems very useful to me.
omap44xx_mailbox_irq = OMAP44XX_MAILBOX_IRQ;
whereas that:
omap44xx_mailbox_irq = 20;
Give you a little be more information, because you do not have have to
read the TRM or another header file to get the real number.
FYI, that was discussed at least 6 months ago during the submission of
the early hwmod series.
- overall defining block was improved:
class
ocp_if
slave ports
hwmod
If you see, each dependent reference is right before the structure
that is using it, which at least to me establishes some order, as of
today this ordering doesn't exists.
e.g. you are defining some hwmod and some how you are populating all
the members, if you are looking at your omap_hwmod struct and want to
see the irqs defined you need to scroll beyond the supposed first
reference in omap_hwmod (right now above ocp_if)
So what? If you have any issue with the original order, please feel free
to comment on the original patch.
In case you didn't notice, all the OMAP4 data are following the same
pattern. So any change to the structure should be applied everywhere.
I do not have any issue to improve the overall readability if that make
sense for everybody, but again, please comment first.
On 11/5/2010 9:17 PM, Ramirez Luna, Omar wrote:
+/* mailbox */
The original comment is missing.
/*
* 'mailbox' class
* mailbox module allowing communication between the on-chip processors
* useusing a queued mailbox-interrupt mechanism.
*/
I don't think it adds anything to the patch, should we start
commenting on the functionality of the drivers for each hwmod?
In that case, it does not hurt since this file is the C file version of
the TRM. You might not care because you know what that module is doing,
but most people don't.
+
+static struct omap_hwmod omap44xx_mailbox_hwmod;
+
+static struct omap_hwmod_addr_space omap44xx_mailbox_addrs[] = {
+ {
+ .pa_start = OMAP44XX_MAILBOX_BASE,
If that physical address is not used elsewhere, and it should be the case,
there is no need to create a define for it. That's why the physical address
was directly used here.
There is no added value to create a define for that.
yes there is, apart from readability where '0x4a0f4000' doesn't say much
It says everything... when you use a debugger, what kind of information
OMAP44XX_MAILBOX_BASE will give you? Nothing, you will have to check
again the TRM or the define to get the real useful information.
for me at least, if reviewing I need to open the TRM check if that is
the address and move on, with the define you know that someone have
checked the address before (when creating the define)
And what if the define is wrong??? You have as well to check the TRM...
FYI, that file is automatically generated from the HW data, so it has a
much lower probably to contain wrong data. Especially compared to a
manually written header file done from a buggy TRM.
Regards,
Benoit
--
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 6/7] omap: mailbox: fix detection for previously supported chips
On 11/7/2010 10:15 AM, Ramirez Luna, Omar wrote: On Sat, Nov 6, 2010 at 1:11 PM, Cousson, Benoit wrote: -#if defined(CONFIG_ARCH_OMAP3430) +#if defined(CONFIG_ARCH_OMAP3) Ideally you should get rid of all the CONFIG_ARCH_OMAPXXX or cpu_is_omap in that code. This is a driver, it should be generic. If you have to handle differences between OMAP version, please do that in the devices, not in the driver. This patch just contains a few of them, but the original mailbox.c file is full of that kind of test. I know that you are not the original writer of this code, but since the clean it, it will be good to remove all the legacy code. I mentioned it in the cover-letter, I should have put it here too, my bad. This is meant as a short term solution until proper cleanup is done, as suggested in: http://marc.info/?l=linux-arm-kernel&m=128534253231481&w=2 OK, sorry I didn't realized that this email thread was about the mailbox. I'm glad to see that both Paul and Nishant are aligned with me. Does nobody care that the driver is not working right now for some chips (since it was working before!!) and are willing to wait for more time until the proper cleanup is done? Sorry again, but removing these tests didn't not seems to be a huge task for my point of view. Anyway, if you want to do another phase and if everybody agree on that, that's OK for me as well. For me it is a hassle, because if I need to do something on 3630 I have to merge this patch, then apply what I'm working into, then remove the patch, apply everything again to see no dependencies are there, then send. Yeah, sometime life really sucks :-) Benoit -- 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/6] omap: iommu: hwmod support and code reorganization
On 11/7/2010 10:43 AM, Ramirez Luna, Omar wrote: On Sat, Nov 6, 2010 at 1:31 PM, Cousson, Benoit wrote: s/ducati/ipu/ s/tesla/dsp/ Please do not use internal codename for the changelog or even for the code. I picked this terminology from the driver, I didn't want to cause confusion, agree to the change. On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote: Boot tested on omap 3430 and 3630, functionality on iva2 only. Introduced hwmod data and support for omap3 (iva2 mmu&isp mmu) and omap4 (ducati mmu&tesla mmu). Minor cleanup due to this changes. There is an issue (present without patches too): Doing a cycle of insmod-rmmod to iommu module and then full insmod of bridgedriver (with all dependencies) causes the next read of iommu registers to dump an unhandled fault log; this, because when rmmod of iommu is called it tries to clean the iommu tables and flush any old entry prior to removing the driver, however these reads/writes are attempted while the MMU is under reset and will timeout on the L3 IVA target agent, which will leave MMU unusable until the proper restore sequence to clear this L3 error is executed. Fix would be to move page table allocation to iommu get and its correspondent free to iommu put, however it will fall entirely under iommu user responsibility, as it needs to clear the mmu reset bit, before calling iommu functions that read/write into mmu registers (which should apply only for first boot or on baseimage reload); trading this restriction in order to keep the same generic iommu code for all omap iommu devices. This issue has been seen on omap3 iva2 mmu, same restriction should I'm still not really understanding that issue. In theory, the reset is deasserted when the omap_device is enabled and will be re-asserted when the omap_device will be disable. Probably I'm missing the bits telling hwmod to handle its reset bit, I will recheck. After reading the other patches of that series, this is what I realized as well. You need the entries with hw reset information to make that works. Why is the mmu already under reset when the iommu is trying to clean the tables? However, the driver disables the device on a call named iommu_put (where, from your comment, reset should be re-asserted ), and cleans the TLBs and page tables on removal of the driver (after iommu_put). Could please describe the complete sequence? I'm assuming the dependencies are installed. on boot up: 1. insmod iommu.ko - device_enable is not called, unless a call to iommu_get is given, this will mean that the driver has one user and thus device_enable is called (however right now it doesn't matter if you call iommu_get or not) 2. rmmod iommu.ko - remove function will try to cleanup the TLBs writing into MMU registers, since MMU is on reset it will trigger a timeout on its TA. 3. insmod bridgedriver.ko - it is dependent on iommu.ko so it should have been installed before. Whenever bridge calls iommu_get, the external abort will be caused due to a read to MMU. As I commented, cleaning the page tables could be moved from driver's remove function to iommu_put, if omap device enable/disable is handling the reset bit probably this issue shouldn't be hit. Yep, I think so as well. Regards, Benoit -- 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/6] OMAP3: hwmod data: Add mmu for iva2 and isp
On 11/7/2010 11:00 AM, Ramirez Luna, Omar wrote: On Sat, Nov 6, 2010 at 2:15 PM, Cousson, Benoit wrote: On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote: Add mmu hwmod data for iva2 and isp. s/iva2/iva/ Where this terminology can be found? I'm basing this naming on what was there or TRM. For omap3 there is no such thing as iva, it is iva2. IVA2 means IVA v2, before we had an IVA (v1) then IVA v1.1... The goal is to use the same name for the IP with similar functionality across OMAPs version in order to have generic code in the driver. IVA, IVA2, IVAHD are all doing similar things, so the only way to identify the same functionality is by using the same name. Thanks to the rev field, you can differentiate the various version during device creation. That will allow you to query the hwmod on every version of OMAPs using the same "iva" name. Otherwise you will have to use the cpu_is_omap_XXX to select iva, iva2 or ivahd depending of the SoC. Does that make sense to you? Benoit -- 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 3/6] OMAP4: hwmod data: add mmu hwmod for ducati and tesla
On 11/7/2010 11:18 AM, Ramirez Luna, Omar wrote:
On Sat, Nov 6, 2010 at 3:47 PM, Cousson, Benoit wrote:
On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote:
Add mmu hwmod data for ducati and tesla.
s/ducati/ipu/
s/tesla/dsp/
Please do not use internal codename.
Tried to avoid confusion with what was originally in the driver, agree
with the change.
Here again, you completely changed the omap4 existing data for (almost)
nothing.
I agree, the original code was not considering the mmu as a hwmod but only
the core of the subsystem: mmu + cache.
But as far as I can see, you just added a new mmu class, a dev_attr, and the
hwmod remain almost the same.
Otherwise, you replaced the proper names by the bad one, and you removed
important data (hw reset for ex).
Please start from the original code and fix what is missing or wrong but do
not re-write everything.
I wrote this one from scratch, I didn't see that there were pieces to
handle some stuff since the code is buried in a private tree.
Not true at all... It was sent to l-o:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32854.html
And stored in a supposedly private tree, which appears to be public:
http://dev.omapzoom.org/?p=swarch/linux-omap-adv.git;a=summary
I cared to dug up the mailbox one, but completely missed this one.
+/* mmu */
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = "mmu",
+};
That change is OK. The remaining part seems to be completely broken.
+
+/* ducati mmu */
+
+static struct omap_hwmod omap44xx_ducati_mmu_hwmod;
+
+static struct omap_hwmod_addr_space omap44xx_ducati_mmu_addrs[] = {
+ {
+ .pa_start = OMAP4_MMU1_BASE,
+ .pa_end = OMAP4_MMU1_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l3_main_1 ->ducati mmu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_1__ducati_mmu = {
+ .master =&omap44xx_l3_main_1_hwmod,
+ .slave =&omap44xx_ducati_mmu_hwmod,
+ .addr = omap44xx_ducati_mmu_addrs,
+ .clk= "dpll_mpu_m2_ck",
Are you sure of that?
No, this was supposed to be the hwmod main_clk... the ocp_if clk
should be l3_div.
I will add these changes and the ones you mention as "mmu + cache",
and see how it goes from there.
Please do not do any change on that code base, just use the original
code and update it if needed.
Benoit
--
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 3/6] OMAP4: hwmod data: add mmu hwmod for ducati and tesla
On 11/9/2010 12:48 AM, Ramirez Luna, Omar wrote: On Mon, Nov 8, 2010 at 5:21 PM, Cousson, Benoit wrote: I wrote this one from scratch, I didn't see that there were pieces to handle some stuff since the code is buried in a private tree. Not true at all... It was sent to l-o: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32854.html I did review v3 of this patch set, care to point the exact place for mmu hwmod on this patch set. It seems [v2 5/7] had mailbox, but I don't think v3 made it to the list. The patch itself may did not reach the list due to his size, that's why I added the link to the GIT. Both dsp and ipu contain the mmu + cache related information. static struct omap_hwmod omap44xx_dsp_hwmod static struct omap_hwmod omap44xx_ipu_hwmod At that time I didn't know how that stuff was supposed to be used by the driver. I already changed the structure a little bit based on Hari's comment, so if you do need mmu entry only, since that structure seems to handle only that, it might makes sense to rename them in order to consider them part of the mmu class. It should be then mmu_dsp and mmu_ipu, because in that case, it will represent the mmu class instances for the dsp and the ipu. I'm perfectly fine to update that part if needed. Regards, Benoit And stored in a supposedly private tree, which appears to be public: http://dev.omapzoom.org/?p=swarch/linux-omap-adv.git;a=summary I took whatever was in: http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.11 Please do not do any change on that code base, just use the original code and update it if needed. Will do, as taken from the tree you mention. Regards, Omar -- 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/6] [v2] omap:mailbox-enhancements and fixes
Hi Hari, On 11/10/2010 1:45 PM, Hari Kanigeri wrote: Thanks to Rene Sapiens and Omar Ramirez for their inputs on initial patch set. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37278.html The patch set addresses the following review comments from Rene and Omar. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37626.html https://patchwork.kernel.org/patch/255091/ https://patchwork.kernel.org/patch/255081/ Following patches are changed because of above review comments: omap:mailbox-send message in process context omap:mailbox-add notification support for multiple readers Following patch is dropped from initial patch set omap:mailbox-resolve multiple receiver problem The patch set is tested on omap4 SDP board. Fernando Guzman Lugo (1): mailbox: change full flag per mailbox queue instead of global Hari Kanigeri (5): omap:mailbox: fix rx interrupt disable in omap4 omap:mailbox-fix checkpatch warnings That one is weird? How can you submit a patch that fix checkpatch? In theory you should not send any patch that generate checkpatch error or warning. omap:mailbox-send message in process context omap:mailbox-add notification support for multiple readers omap:clocks44x-add dummy clock for mailbox We are trying to enforce some consistency in the subjects name so you should name your patches like that: OMAP: mailbox: fix rx interrupt disable in omap4 OMAP: mailbox: fix checkpatch warnings OMAP: mailbox: send message in process context OMAP: mailbox: add notification support for multiple readers OMAP4: clocks: add dummy clock for mailbox Regards, Benoit -- 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/6] [v2] omap:mailbox-enhancements and fixes
Hari, I forgot one comment. Since this series is a v2, every patches subject should contain the [PATCH v2 x/6]. FYI, patchwork will not track the cover letter, so we will miss that version information in the real patches. I forgot as well this subject: mailbox: change full flag per mailbox queue instead of global Should be OMAP: mailbox: change full flag per mailbox queue instead of global Since it is purely omap stuff. Regards, Benoit On 11/10/2010 1:45 PM, Hari Kanigeri wrote: Thanks to Rene Sapiens and Omar Ramirez for their inputs on initial patch set. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37278.html The patch set addresses the following review comments from Rene and Omar. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37626.html https://patchwork.kernel.org/patch/255091/ https://patchwork.kernel.org/patch/255081/ Following patches are changed because of above review comments: omap:mailbox-send message in process context omap:mailbox-add notification support for multiple readers Following patch is dropped from initial patch set omap:mailbox-resolve multiple receiver problem The patch set is tested on omap4 SDP board. Fernando Guzman Lugo (1): mailbox: change full flag per mailbox queue instead of global Hari Kanigeri (5): omap:mailbox: fix rx interrupt disable in omap4 omap:mailbox-fix checkpatch warnings omap:mailbox-send message in process context omap:mailbox-add notification support for multiple readers omap:clocks44x-add dummy clock for mailbox arch/arm/mach-omap2/clock44xx_data.c |1 + arch/arm/mach-omap2/mailbox.c |5 +- arch/arm/plat-omap/include/plat/mailbox.h |8 +- arch/arm/plat-omap/mailbox.c | 127 + 4 files changed, 83 insertions(+), 58 deletions(-) -- 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/6] [v2] omap:mailbox-enhancements and fixes
On 11/10/2010 5:56 PM, Hari Kanigeri wrote: Benoit, Thanks for your comments. On Wed, Nov 10, 2010 at 10:40 AM, Cousson, Benoit wrote: Hi Hari, On 11/10/2010 1:45 PM, Hari Kanigeri wrote: Thanks to Rene Sapiens and Omar Ramirez for their inputs on initial patch set. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37278.html The patch set addresses the following review comments from Rene and Omar. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37626.html https://patchwork.kernel.org/patch/255091/ https://patchwork.kernel.org/patch/255081/ Following patches are changed because of above review comments: omap:mailbox-send message in process context omap:mailbox-add notification support for multiple readers Following patch is dropped from initial patch set omap:mailbox-resolve multiple receiver problem The patch set is tested on omap4 SDP board. Fernando Guzman Lugo (1): mailbox: change full flag per mailbox queue instead of global Hari Kanigeri (5): omap:mailbox: fix rx interrupt disable in omap4 omap:mailbox-fix checkpatch warnings That one is weird? How can you submit a patch that fix checkpatch? Why weird if the patch is fixing the checkpatch warnings that were already present in the code ? OK, so you meant that this is fixing some already existing warnings in mainline code? My point was that checkpatch is supposed to check patch... but it's true that is can check the code as well. I was assuming that all the code in mainline is supposed to be already checkpatch proof :-) It seems that this is not the case. It might be interesting to run it on every plat-omap / mach-omap files... Thanks, Benoit The other option is to leave the checkpatch warnings in the code :) In theory you should not send any patch that generate checkpatch error or warning. omap:mailbox-send message in process context omap:mailbox-add notification support for multiple readers omap:clocks44x-add dummy clock for mailbox We are trying to enforce some consistency in the subjects name so you should name your patches like that: Good point, thanks for pointing about consistency. I wasn't aware about the rule to use OMAP in caps. I will fix it. Thank you, Best regards, Hari -- 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/6] [v2] omap:mailbox-enhancements and fixes
On 11/10/2010 5:56 PM, Hari Kanigeri wrote: [...] Good point, thanks for pointing about consistency. I wasn't aware about the rule to use OMAP in caps. Well, I'm not sure there is any rule like that, it is just what was mostly used so far. My point was more about the text after the omap. Benoit -- 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/6] [v2] OMAP: mailbox: enhancements and fixes
On 11/10/2010 7:00 PM, Hari Kanigeri wrote: Resending correcting the subject format based on Benoit's comment and fixing the over-indentation pointed out by Sergei. Pure nitpicking: That's a pretty fast update... but then it should be a v3 :-) Why does the cover letter not use the same format? [PATCH 0/6] [v2] instead of [PATCH v2 0/6] Thanks, Benoit Thanks to Rene Sapiens and Omar Ramirez for their inputs on initial patch set. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37278.html The patch set addresses the following review comments from Rene and Omar. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37626.html https://patchwork.kernel.org/patch/255091/ https://patchwork.kernel.org/patch/255081/ Following patches are changed because of above review comments: omap:mailbox-send message in process context omap:mailbox-add notification support for multiple readers Following patch is dropped from initial patch set omap:mailbox-resolve multiple receiver problem The patch set is tested on omap4 SDP board. Fernando Guzman Lugo (1): OMAP: mailbox: change full flag per mailbox queue instead of global Hari Kanigeri (5): OMAP: mailbox: fix rx interrupt disable in omap4 OMAP: mailbox: fix checkpatch warnings OMAP: mailbox: send message in process context OMAP: mailbox: add notification support for multiple readers OMAP4: clocks: add dummy clock for mailbox arch/arm/mach-omap2/clock44xx_data.c |1 + arch/arm/mach-omap2/mailbox.c |5 +- arch/arm/plat-omap/include/plat/mailbox.h |8 +- arch/arm/plat-omap/mailbox.c | 127 + 4 files changed, 83 insertions(+), 58 deletions(-) -- 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/6] [v2] OMAP: mailbox: enhancements and fixes
On 11/10/2010 9:16 PM, Hari Kanigeri wrote: Benoit, Resending correcting the subject format based on Benoit's comment and fixing the over-indentation pointed out by Sergei. Pure nitpicking: That's a pretty fast update... but then it should be a v3 :-) Have to do it fast to keep your attention :). Since you are saying it is pure nitpicking I will leave it at v2 unless you insist. Yeah, that's fine for me. Benoit -- 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 v2 4/7] OMAP4: mux: Add CBL package data for OMAP4430 ES1
Hi Tony,
On 11/11/2010 2:56 AM, Tony Lindgren wrote:
* Benoit Cousson [101019 15:14]:
Add data for OMAP4430 generated from HW pinout& register database.
The data set is split in two partitions for both core and wkup.
We should drop patch 3/7 and merge the following patch to your
4/7 patch.
OK
Basically let's keep the omap_mux_read/write around for now,
by adding omap_mux_get for dealing with the partition
information.
Thanks for that.
I'll send the update today.
Regards,
Benoit
Regards,
Tony
From: Tony Lindgren
Date: Wed, 10 Nov 2010 09:55:47 -0800
Subject: [PATCH] omap: mux: Fix support for partitions for dynamic muxing
Revert some parts of Benoit's patch to not make
omap_mux_read/write static at this point.
We may need to do remuxing for system wide idle states,
and also for driver specific idle states.
So we still need to have omap_mux_read/write around for
the platform level driver code.
Also add omap_mux_get for getting the partition data so
platform level device code can use it.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 3fec4d6..3fda20d 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -293,6 +293,8 @@ static struct omap_board_mux rx51_mmc2_off_mux[] = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+static struct omap_mux_partition *partition;
+
/*
* Current flows to eMMC when eMMC is off and the data lines are pulled up,
* so pull them down. N.B. we pull 8 lines because we are using 8 lines.
@@ -300,9 +302,9 @@ static struct omap_board_mux rx51_mmc2_off_mux[] = {
static void rx51_mmc2_remux(struct device *dev, int slot, int power_on)
{
if (power_on)
- omap_mux_write_array(rx51_mmc2_on_mux);
+ omap_mux_write_array(partition, rx51_mmc2_on_mux);
else
- omap_mux_write_array(rx51_mmc2_off_mux);
+ omap_mux_write_array(partition, rx51_mmc2_off_mux);
}
static struct omap2_hsmmc_info mmc[] __initdata = {
@@ -922,7 +924,11 @@ void __init rx51_peripherals_init(void)
rx51_init_wl1251();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
- omap2_hsmmc_init(mmc);
+
+ partition = omap_mux_get("core");
+ if (partition)
+ omap2_hsmmc_init(mmc);
+
platform_device_register(&rx51_charger_device);
}
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 9b9128e..6d91bb8 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -49,7 +49,19 @@ struct omap_mux_entry {
static LIST_HEAD(mux_partitions);
static DEFINE_MUTEX(muxmode_mutex);
-static u16 omap_mux_read(struct omap_mux_partition *partition, u16 reg)
+struct omap_mux_partition * omap_mux_get(const char *name)
+{
+ struct omap_mux_partition *partition;
+
+ list_for_each_entry(partition,&mux_partitions, node) {
+ if (!strcmp(name, partition->name))
+ return partition;
+ }
+
+ return NULL;
+}
+
+u16 omap_mux_read(struct omap_mux_partition *partition, u16 reg)
{
if (partition->flags& OMAP_MUX_REG_8BIT)
return __raw_readb(partition->base + reg);
@@ -57,7 +69,7 @@ static u16 omap_mux_read(struct omap_mux_partition
*partition, u16 reg)
return __raw_readw(partition->base + reg);
}
-static void omap_mux_write(struct omap_mux_partition *partition, u16 val,
+void omap_mux_write(struct omap_mux_partition *partition, u16 val,
u16 reg)
{
if (partition->flags& OMAP_MUX_REG_8BIT)
@@ -66,7 +78,7 @@ static void omap_mux_write(struct omap_mux_partition
*partition, u16 val,
__raw_writew(val, partition->base + reg);
}
-static void omap_mux_write_array(struct omap_mux_partition *partition,
+void omap_mux_write_array(struct omap_mux_partition *partition,
struct omap_board_mux *board_mux)
{
while (board_mux->reg_offset != OMAP_MUX_TERMINATOR) {
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index dad32f6..6656043 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -186,6 +186,40 @@ u16 omap_mux_get_gpio(int gpio);
void omap_mux_set_gpio(u16 val, int gpio);
/**
+ * omap_mux_get() - get a mux partition by name
+ * @name: Name of the mux partition
+ *
+ */
+struct omap_mux_partition * omap_mux_get(const char *name);
+
+/**
+ * omap_mux_read() - read mux register
+ * @partition: Mux partition
+ * @mux_offset:Offset of the mux register
+ *
+ */
+u16 omap_mux_read(struct omap_mux_partition *p, u16 mux_offset);
+
+/**
+ * omap_mux_write() - write mux register
+ * @partition: Mux partition
+ * @val: New mux register value
+ * @
Re: [RFC v2 3/7] OMAP: mux: Add support for control module split in several partitions
On 11/11/2010 5:35 PM, Tony Lindgren wrote:
* Benoit Cousson [101019 15:14]:
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
+
+/**
+ * struct mux_partition - contain partition related information
+ * @name: name of the current partition
+ * @flags: flags specific to this partition
+ * @phys: physical address
+ * @size: partition size
+ * @base: virtual address after ioremap
+ * @muxmodes: list of nodes that belong to a partition
+ * @node: list node for the partitions linked list
+ */
+struct omap_mux_partition {
+ const char *name;
+ u32 flags;
+ u32 phys;
+ u32 size;
+ void __iomem*base;
+ struct list_headmuxmodes;
+ struct list_headnode;
+};
With the omap_mux_parition..
/**
* struct omap_mux - data for omap mux register offset and it's value
* @reg_offset: mux register offset from the mux base
* @gpio: GPIO number
+ * @id:Partition identifier
* @muxnames: available signal modes for a ball
*/
struct omap_mux {
@@ -82,6 +114,7 @@ struct omap_mux {
char*muxnames[OMAP_MUX_NR_MODES];
#ifdef CONFIG_DEBUG_FS
char*balls[OMAP_MUX_NR_SIDES];
+ struct omap_mux_partition *partition;
#endif
#endif
};
@@ -89,6 +122,7 @@ struct omap_mux {
/**
* struct omap_ball - data for balls on omap package
* @reg_offset: mux register offset from the mux base
+ * @id:Partition identifier
* @balls:available balls on the package
*/
struct omap_ball {
@@ -100,6 +134,7 @@ struct omap_ball {
* struct omap_board_mux - data for initializing mux registers
* @reg_offset: mux register offset from the mux base
* @mux_value:desired mux value to set
+ * @id:Partition identifier
*/
struct omap_board_mux {
u16 reg_offset;
..I think the above changes are no longer needed.
Oops yep, I forgot to remove the @id in the kerneldoc.
I was about to send the next revision, maybe I should wait a little bit
more.
Thanks,
Benoit
--
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 v2 4/7] OMAP4: mux: Add CBL package data for OMAP4430 ES1
On 11/11/2010 5:38 PM, Tony Lindgren wrote: * Cousson, Benoit [10 04:24]: Hi Tony, On 11/11/2010 2:56 AM, Tony Lindgren wrote: * Benoit Cousson [101019 15:14]: Add data for OMAP4430 generated from HW pinout& register database. The data set is split in two partitions for both core and wkup. We should drop patch 3/7 and merge the following patch to your 4/7 patch. OK Oops, sorry got the patch numbers wrong, the patch numbers should be 2/7 and 3/7. Well you probably figured that out already :) Well, yes, it took me some time, but I figured it out :-) Benoit -- 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 v2 0/7] OMAP4: mux: Add the OMAP4430 ES1 & ES2 support
On 11/11/2010 5:53 PM, Tony Lindgren wrote: * Cousson, Benoit [101020 13:43]: On 10/20/2010 1:06 AM, Tony Lindgren wrote: * Benoit Cousson [101019 15:14]: It takes into account your proposal to store partition information in a partition structure instead of inside every pad entries. The mechanism relies on the uniqueness of the pad name in each partition to find the correct partition during iteration. OK, using the offset defines won't be unique necessarily.. They should. The defines are all based on pad names that are all unique. Assuming HW folks didn't messed up the spec... Just for the record to avoid confusion.. What I meant is the offset values from the partition base are not unique even if the define names are unique: /* ctrl_module_pad_core registers offset */ #define OMAP4_CTRL_MODULE_PAD_GPMC_AD0_OFFSET 0x0040 #define OMAP4_CTRL_MODULE_PAD_GPMC_AD1_OFFSET 0x0042 #define OMAP4_CTRL_MODULE_PAD_GPMC_AD2_OFFSET 0x0044 ... /* ctrl_module_pad_wkup registers offset */ #define OMAP4_CTRL_MODULE_PAD_SIM_IO_OFFSET 0x0040 #define OMAP4_CTRL_MODULE_PAD_SIM_CLK_OFFSET0x0042 #define OMAP4_CTRL_MODULE_PAD_SIM_RESET_OFFSET 0x0044 ... So now we have to use either a unique pad name, or a combination of partition + offset. Yes. Hence the need for the omap_mux_get you've just done in order to access the low level API. Benoit -- 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/7] OMAP: mux: Add support for control module split in several partitions
Hi Tony,
On 11/15/2010 9:03 PM, Tony Lindgren wrote:
* Benoit Cousson [10 13:26]:
Starting on OMAP4, the pin mux configuration is located in two
different partitions of the control module (CODE_PAD and WKUP_PAD).
The first one is inside the core power domain whereas the second
one is inside the wakeup.
- Add the capability to add any number of partition during board init
time depending of Soc partitioning.
- Add some init flags as well in order to avoid explicit Soc version
check inside the mux core code.
- Add a comment with mux0 mode on top of omap_mux/board/
if the current mux mode is not the default one.
Here's one more patch that I'd like to merge into this patch to avoid
repeating the partition for each mux entry.
The memory vendors will not like you ;-)
Assuming no more comments, I'll queue these for 2.6.38 merge window.
I'll update the series and re-post tomorrow.
Thanks,
Benoit
Regards,
Tony
From: Tony Lindgren
Date: Mon, 15 Nov 2010 11:52:20 -0800
Subject: [PATCH] omap: mux: Save memory for struct omap_mux
There's no need to repeat the partition for each mux entry.
We can look up the partition for debugfs.
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -348,14 +348,37 @@ static const struct file_operations
omap_mux_dbg_board_fops = {
.release= single_release,
};
+static struct omap_mux_partition * omap_mux_get_partition(struct omap_mux *mux)
+{
+ struct omap_mux_partition *partition;
+
+ list_for_each_entry(partition,&mux_partitions, node) {
+ struct list_head *muxmodes =&partition->muxmodes;
+ struct omap_mux_entry *e;
+
+ list_for_each_entry(e, muxmodes, node) {
+ struct omap_mux *m =&e->mux;
+
+ if (m == mux)
+ return partition;
+ }
+ }
+
+ return NULL;
+}
+
static int omap_mux_dbg_signal_show(struct seq_file *s, void *unused)
{
struct omap_mux *m = s->private;
- struct omap_mux_partition *partition = m->partition;
+ struct omap_mux_partition *partition;
const char *none = "NA";
u16 val;
int mode;
+ partition = omap_mux_get_partition(m);
+ if (!partition)
+ return 0;
+
val = omap_mux_read(partition, m->reg_offset);
mode = val& OMAP_MUX_MODE7;
@@ -391,6 +414,7 @@ static ssize_t omap_mux_dbg_signal_write(struct file *file,
struct omap_mux *m;
unsigned long val;
int buf_size, ret;
+ struct omap_mux_partition *partition;
if (count> OMAP_MUX_MAX_ARG_CHAR)
return -EINVAL;
@@ -411,7 +435,11 @@ static ssize_t omap_mux_dbg_signal_write(struct file *file,
seqf = file->private_data;
m = seqf->private;
- omap_mux_write(m->partition, (u16)val, m->reg_offset);
+ partition = omap_mux_get_partition(m);
+ if (!partition)
+ return -ENODEV;
+
+ omap_mux_write(partition, (u16)val, m->reg_offset);
*ppos += count;
return count;
@@ -440,7 +468,6 @@ static void __init omap_mux_dbg_create_entry(
list_for_each_entry(e,&partition->muxmodes, node) {
struct omap_mux *m =&e->mux;
- m->partition = partition;
(void)debugfs_create_file(m->muxnames[0], S_IWUGO, mux_dbg_dir,
m,&omap_mux_dbg_signal_fops);
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -121,7 +121,6 @@ struct omap_mux {
char*muxnames[OMAP_MUX_NR_MODES];
#ifdef CONFIG_DEBUG_FS
char*balls[OMAP_MUX_NR_SIDES];
- struct omap_mux_partition *partition;
#endif
#endif
};
--
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/5] OMAP4: mux: Initialise OMAP4 mux pins.
Hi Sricharan, On 11/15/2010 8:38 AM, R, Sricharan wrote: This series updates the core device drivers to use mux framework for OMAP4 SDP and PANDA board. It's generated against the linux-omap master branch. It has a dependency on the Benoit's omap4 mux data series. http://www.spinics.net/lists/linux-omap/msg38995.html I've just realized that this is not the latest one, here it is: http://www.spinics.net/lists/linux-omap/msg40039.html Regards, Benoit sricharan (5): OMAP4: hsmmc: Initialise the mmc mux pins OMAP4: usb-musb: Initialise the usb mux pins. OMAP4: mcbsp: Initialise the mcbsp mux pins OMAP4: board-4430sdp: Initialise the mcspi mux pins OMAP4: serial: Initialise the uart mux pins arch/arm/mach-omap2/board-4430sdp.c | 20 arch/arm/mach-omap2/devices.c | 83 +++ arch/arm/mach-omap2/mcbsp.c | 33 +- arch/arm/mach-omap2/serial.c| 38 arch/arm/mach-omap2/usb-musb.c | 41 + 5 files changed, 214 insertions(+), 1 deletions(-) While doing some internal reviews, there were few debates about existing mux framework usage. I am summarising that discussion here and would like to hear more on this from the community. 1. PAD configuration for all pins should be done in a central place(board file) Pros: a. All pins configured in a central place. Easy to ensure coverage and maintenance. Single place to look for all mux related settings b. Drivers, unless they have run time pad configuration requirements need not worry about muxing. Cons: a. Adds a lot of duplicate data in different board files assuming most of the pins will be connected the same way across different boards. 2. Do PAD configuration independently for each module Pros: a. Avoids repetition of similar data for different boards. b. Gives a knowledge of how pins are configured for a module to the respective owners. c. Pads are not initialised unless they are really needed. Cons: a. Can become difficult to maintain if lot of data tend to be different across boards. -- 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 2/7] OMAP: mux: Add support for control module split in several partitions
Hi Tony, On 11/16/2010 5:41 PM, Tony Lindgren wrote: * Cousson, Benoit [101115 13:36]: Hi Tony, On 11/15/2010 9:03 PM, Tony Lindgren wrote: * Benoit Cousson [10 13:26]: Starting on OMAP4, the pin mux configuration is located in two different partitions of the control module (CODE_PAD and WKUP_PAD). The first one is inside the core power domain whereas the second one is inside the wakeup. - Add the capability to add any number of partition during board init time depending of Soc partitioning. - Add some init flags as well in order to avoid explicit Soc version check inside the mux core code. - Add a comment with mux0 mode on top of omap_mux/board/ if the current mux mode is not the default one. Here's one more patch that I'd like to merge into this patch to avoid repeating the partition for each mux entry. The memory vendors will not like you ;-) Assuming no more comments, I'll queue these for 2.6.38 merge window. I'll update the series and re-post tomorrow. Thanks, no need to post them again, I already have them queued locally, they will hit for-next and linux-omap master today. OK, but I already did it because there is a checkpatch issue in your first patch and I received another patch from Dan to add __func__ in the pr_xxx macros. I can repost, or you can get the update in my GIT (ctrl-wip/mux-omap4-v4). BTW, next time you do a git branch, please base it on Linus recent -rc tag instead of linux-omap master branch. We don't want the history of linux-omap master branch merged to the mainline tree.. Euh, this is what I already did for this series. Quoting myself: "The series is based on mainline (2.6.37-rc1) and is available here: git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v3" Did I messed up something? Regards, Benoit -- 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 5/8] OMAP2+: hwmod: rename omap_hwmod_mutex to _hwmod_list_mutex
Hi Paul,
Funny, I was about to send you a RFC to get rid of that mutex :-)
Today that mutex is preventing us to be re-entrant during hwmod lookup
and for_each_by_class iteration, and we'd like to in order to manage
link between 2 hwmods.
The context is the link between mcbsp and sidetone on OMAP3. Since this
module are tightly coupled, I was suggesting to Kishon to add the
sidetone reference directly in the mcbsp hwmod in order to create a
omap_device that will handle the 2 hwmods at the same time.
Since we are using the iteration to get all the hwmod that belongs to
the mcbsp class we cannot call the lookup function to get the sidetone
hwmod at that time.
For the moment we need to do 2 iteration and use intermediate storage to
workaround that.
After checking the purpose of the mutex, I was wondering if this is
useful. For the moment the creation of the hwmod list is done only at
init time, and nothing is supposed to change that at runtime except the
unregister function.
So I've started to get rid of this function, then of the mutex and I
added the __init to all these registration functions to avoid the usage
at runtime. It will save a little bit of memory as well.
Thanks to that we can now use the omap_hwmod_lookup inside the
omap_hwmod_for_each_by_class.
Does that make sense to you?
I can send you the patches if you want.
Regards,
Benoit
On 11/16/2010 11:18 AM, Paul Walmsley wrote:
This trivial patch renames omap_hwmod_mutex to _hwmod_list_mutex to indicate
clearly that it is only used for hwmod list manipulation operations.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 12a0b9a..0e85278 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -156,7 +156,8 @@
/* omap_hwmod_list contains all registered struct omap_hwmods */
static LIST_HEAD(omap_hwmod_list);
-static DEFINE_MUTEX(omap_hwmod_mutex);
+/* _hwmod_list_mutex protects the list of registered hwmods */
+static DEFINE_MUTEX(_hwmod_list_mutex);
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
static struct omap_hwmod *mpu_oh;
@@ -874,7 +875,7 @@ static void _shutdown_sysc(struct omap_hwmod *oh)
* @name: find an omap_hwmod by name
*
* Return a pointer to an omap_hwmod by name, or NULL if not found.
- * Caller must hold omap_hwmod_mutex.
+ * Caller must hold _hwmod_list_mutex.
*/
static struct omap_hwmod *_lookup(const char *name)
{
@@ -1502,7 +1503,7 @@ int omap_hwmod_register(struct omap_hwmod *oh)
(oh->_state != _HWMOD_STATE_UNKNOWN))
return -EINVAL;
- mutex_lock(&omap_hwmod_mutex);
+ mutex_lock(&_hwmod_list_mutex);
pr_debug("omap_hwmod: %s: registering\n", oh->name);
@@ -1528,7 +1529,7 @@ int omap_hwmod_register(struct omap_hwmod *oh)
ret = 0;
ohr_unlock:
- mutex_unlock(&omap_hwmod_mutex);
+ mutex_unlock(&_hwmod_list_mutex);
return ret;
}
@@ -1546,9 +1547,9 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name)
if (!name)
return NULL;
- mutex_lock(&omap_hwmod_mutex);
+ mutex_lock(&_hwmod_list_mutex);
oh = _lookup(name);
- mutex_unlock(&omap_hwmod_mutex);
+ mutex_unlock(&_hwmod_list_mutex);
return oh;
}
@@ -1574,13 +1575,13 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod
*oh, void *data),
if (!fn)
return -EINVAL;
- mutex_lock(&omap_hwmod_mutex);
+ mutex_lock(&_hwmod_list_mutex);
list_for_each_entry(temp_oh,&omap_hwmod_list, node) {
ret = (*fn)(temp_oh, data);
if (ret)
break;
}
- mutex_unlock(&omap_hwmod_mutex);
+ mutex_unlock(&_hwmod_list_mutex);
return ret;
}
@@ -1663,10 +1664,10 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
pr_debug("omap_hwmod: %s: unregistering\n", oh->name);
- mutex_lock(&omap_hwmod_mutex);
+ mutex_lock(&_hwmod_list_mutex);
iounmap(oh->_mpu_rt_va);
list_del(&oh->node);
- mutex_unlock(&omap_hwmod_mutex);
+ mutex_unlock(&_hwmod_list_mutex);
return 0;
}
@@ -2125,7 +2126,7 @@ int omap_hwmod_read_hardreset(struct omap_hwmod *oh,
const char *name)
* @user: arbitrary context data to pass to the callback function
*
* For each omap_hwmod of class @classname, call @fn. Takes
- * omap_hwmod_mutex to prevent the hwmod list from changing during the
+ * _hwmod_list_mutex to prevent the hwmod list from changing during the
* iteration. If the callback function returns something other than
* zero, the iterator is terminated, and the callback function's return
* value is passed back to the caller. Returns 0 upon success, -EINVAL
@@ -2145,7 +2146,7
Re: [PATCH 2/7] OMAP: mux: Add support for control module split in several partitions
On 11/16/2010 6:37 PM, Tony Lindgren wrote: * Cousson, Benoit [101116 08:53]: Hi Tony, On 11/16/2010 5:41 PM, Tony Lindgren wrote: * Cousson, Benoit [101115 13:36]: Hi Tony, On 11/15/2010 9:03 PM, Tony Lindgren wrote: * Benoit Cousson[10 13:26]: Starting on OMAP4, the pin mux configuration is located in two different partitions of the control module (CODE_PAD and WKUP_PAD). The first one is inside the core power domain whereas the second one is inside the wakeup. - Add the capability to add any number of partition during board init time depending of Soc partitioning. - Add some init flags as well in order to avoid explicit Soc version check inside the mux core code. - Add a comment with mux0 mode on top of omap_mux/board/ if the current mux mode is not the default one. Here's one more patch that I'd like to merge into this patch to avoid repeating the partition for each mux entry. The memory vendors will not like you ;-) Assuming no more comments, I'll queue these for 2.6.38 merge window. I'll update the series and re-post tomorrow. Thanks, no need to post them again, I already have them queued locally, they will hit for-next and linux-omap master today. OK, but I already did it because there is a checkpatch issue in your first patch and I received another patch from Dan to add __func__ in the pr_xxx macros. I can repost, or you can get the update in my GIT (ctrl-wip/mux-omap4-v4). OK, if they're changed maybe repost the whole series one more time, and then I'll merge in your branch assuming no more comments. BTW, next time you do a git branch, please base it on Linus recent -rc tag instead of linux-omap master branch. We don't want the history of linux-omap master branch merged to the mainline tree.. Euh, this is what I already did for this series. Quoting myself: "The series is based on mainline (2.6.37-rc1) and is available here: git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v3" Did I messed up something? No, mux-omap4-v4 branch looks OK. I guess what I tried pulling was something older. The v2 was done before the 2.6.37-rc1 and was dependent of the ES2 support that's why it was based on l-o/master. Starting on v3, I rebased everything on mainline. I'll post the v4 revision. Benoit -- 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: prcm: switch to a chained IRQ handler mechanism
Hi Thomas,
On 11/17/2010 1:16 PM, Thomas Petazzoni wrote:
From: Thomas Petazzoni
[...]
static int __init omap3_pm_init(void)
That code is purely OMAP3 specific, do you think it might scale well on
OMAP4?
BTW, you should maybe change the subject with "OMAP3: prcm: ..." to
reflect that.
{
struct power_state *pwrst, *tmp;
struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm;
- int ret;
+ int ret, i;
if (!cpu_is_omap34xx())
return -ENODEV;
@@ -1013,19 +1053,34 @@ static int __init omap3_pm_init(void)
* supervised mode for powerdomains */
prcm_setup_regs();
- ret = request_irq(INT_34XX_PRCM_MPU_IRQ,
- (irq_handler_t)prcm_interrupt_handler,
- IRQF_DISABLED, "prcm", NULL);
+ for (i = OMAP_PRCM_IRQ_BASE; i< OMAP_PRCM_IRQ_END; i++) {
+ set_irq_chip(i,&prcm_irq_chip);
+ set_irq_handler(i, handle_level_irq);
+ set_irq_flags(i, IRQF_VALID);
+ }
+
+ set_irq_chained_handler(INT_34XX_PRCM_MPU_IRQ, prcm_irq_handler);
+
+ ret = request_irq(INT_34XX_PRCM_WKUP_EN, _prcm_int_handle_wakeup,
+ IRQF_NO_SUSPEND, "prcm_wkup", NULL);
if (ret) {
printk(KERN_ERR "request_irq failed to register for 0x%x\n",
OK, I know, this is not your code, but it might be good to get rid of
the "printk(KERN_ERR..." and use pr_err instead.
- INT_34XX_PRCM_MPU_IRQ);
+ INT_34XX_PRCM_WKUP_EN);
goto err1;
}
+ ret = request_irq(INT_34XX_PRCM_IO_EN, _prcm_int_handle_wakeup,
+ IRQF_NO_SUSPEND, "prcm_io", NULL);
+ if (ret) {
+ printk(KERN_ERR "request_irq failed to register for 0x%x\n",
+ INT_34XX_PRCM_IO_EN);
+ goto err2;
+ }
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR "Failed to setup powerdomains\n");
- goto err2;
+ goto err3;
}
(void) clkdm_for_each(clkdms_setup, NULL);
@@ -1033,7 +1088,7 @@ static int __init omap3_pm_init(void)
mpu_pwrdm = pwrdm_lookup("mpu_pwrdm");
if (mpu_pwrdm == NULL) {
printk(KERN_ERR "Failed to get mpu_pwrdm\n");
- goto err2;
+ goto err3;
}
neon_pwrdm = pwrdm_lookup("neon_pwrdm");
@@ -1080,7 +1135,9 @@ static int __init omap3_pm_init(void)
err1:
return ret;
err2:
- free_irq(INT_34XX_PRCM_MPU_IRQ, NULL);
+ free_irq(INT_34XX_PRCM_WKUP_EN, NULL);
+err3:
+ free_irq(INT_34XX_PRCM_IO_EN, NULL);
list_for_each_entry_safe(pwrst, tmp,&pwrst_list, node) {
list_del(&pwrst->node);
kfree(pwrst);
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 65e20a6..6c5eb1c 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -363,7 +363,43 @@
#define OMAP_MAX_GPIO_LINES 192
#define IH_GPIO_BASE (128 + IH2_BASE)
#define IH_MPUIO_BASE (OMAP_MAX_GPIO_LINES + IH_GPIO_BASE)
-#define OMAP_IRQ_END (IH_MPUIO_BASE + 16)
+#define OMAP_MPUIO_IRQ_END (IH_MPUIO_BASE + 16)
+
+/* 32 IRQs for the PRCM */
+#define OMAP_PRCM_IRQ_BASE (OMAP_MPUIO_IRQ_END)
+#define INT_34XX_PRCM_WKUP_EN (OMAP_PRCM_IRQ_BASE + 0)
+#define INT_34XX_PRCM_EVGENON_EN (OMAP_PRCM_IRQ_BASE + 2)
+#define INT_34XX_PRCM_EVGENOFF_EN (OMAP_PRCM_IRQ_BASE + 3)
+#define INT_34XX_PRCM_TRANSITION_EN(OMAP_PRCM_IRQ_BASE + 4)
+#define INT_34XX_PRCM_CORE_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 5)
+#define INT_34XX_PRCM_PERIPH_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 6)
+#define INT_34XX_PRCM_MPU_DPLL_RECAL_EN_EN (OMAP_PRCM_IRQ_BASE + 7)
+#define INT_34XX_PRCM_IVA2_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 8)
+#define INT_34XX_PRCM_IO_EN(OMAP_PRCM_IRQ_BASE + 9)
+#define INT_34XX_PRCM_VP1_OPPCHANGEDONE_EN (OMAP_PRCM_IRQ_BASE + 10)
+#define INT_34XX_PRCM_VP1_MINVDD_EN(OMAP_PRCM_IRQ_BASE + 11)
+#define INT_34XX_PRCM_VP1_MAXVDD_EN(OMAP_PRCM_IRQ_BASE + 12)
+#define INT_34XX_PRCM_VP1_NOSMPSACK_EN (OMAP_PRCM_IRQ_BASE + 13)
+#define INT_34XX_PRCM_VP1_EQVALUE_EN (OMAP_PRCM_IRQ_BASE + 14)
+#define INT_34XX_PRCM_VP1_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 15)
+#define INT_34XX_PRCM_VP2_OPPCHANGEDONE_EN (OMAP_PRCM_IRQ_BASE + 16)
+#define INT_34XX_PRCM_VP2_MINVDD_EN(OMAP_PRCM_IRQ_BASE + 17)
+#define INT_34XX_PRCM_VP2_MAXVDD_EN(OMAP_PRCM_IRQ_BASE + 18)
+#define INT_34XX_PRCM_VP2_NOSMPSACK_EN (OMAP_PRCM_IRQ_BASE + 19)
+#define INT_34XX_PRCM_VP2_EQVALUE_EN (OMAP_PRCM_IRQ_BASE + 20)
+#define INT_34XX_PRCM_VP2_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 21)
+#define INT_34XX_PRCM_VC_SAERR_EN (OMAP_PRCM_
Re: [PATCH] omap: prcm: switch to a chained IRQ handler mechanism
On 11/17/2010 5:16 PM, Kevin Hilman wrote: "Cousson, Benoit" writes: [...] +#define OMAP_MPUIO_IRQ_END (IH_MPUIO_BASE + 16) + +/* 32 IRQs for the PRCM */ +#define OMAP_PRCM_IRQ_BASE (OMAP_MPUIO_IRQ_END) +#define INT_34XX_PRCM_WKUP_EN (OMAP_PRCM_IRQ_BASE + 0) +#define INT_34XX_PRCM_EVGENON_EN (OMAP_PRCM_IRQ_BASE + 2) +#define INT_34XX_PRCM_EVGENOFF_EN (OMAP_PRCM_IRQ_BASE + 3) +#define INT_34XX_PRCM_TRANSITION_EN(OMAP_PRCM_IRQ_BASE + 4) +#define INT_34XX_PRCM_CORE_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 5) +#define INT_34XX_PRCM_PERIPH_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 6) +#define INT_34XX_PRCM_MPU_DPLL_RECAL_EN_EN (OMAP_PRCM_IRQ_BASE + 7) +#define INT_34XX_PRCM_IVA2_DPLL_RECAL_EN (OMAP_PRCM_IRQ_BASE + 8) +#define INT_34XX_PRCM_IO_EN(OMAP_PRCM_IRQ_BASE + 9) +#define INT_34XX_PRCM_VP1_OPPCHANGEDONE_EN (OMAP_PRCM_IRQ_BASE + 10) +#define INT_34XX_PRCM_VP1_MINVDD_EN(OMAP_PRCM_IRQ_BASE + 11) +#define INT_34XX_PRCM_VP1_MAXVDD_EN(OMAP_PRCM_IRQ_BASE + 12) +#define INT_34XX_PRCM_VP1_NOSMPSACK_EN (OMAP_PRCM_IRQ_BASE + 13) +#define INT_34XX_PRCM_VP1_EQVALUE_EN (OMAP_PRCM_IRQ_BASE + 14) +#define INT_34XX_PRCM_VP1_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 15) +#define INT_34XX_PRCM_VP2_OPPCHANGEDONE_EN (OMAP_PRCM_IRQ_BASE + 16) +#define INT_34XX_PRCM_VP2_MINVDD_EN(OMAP_PRCM_IRQ_BASE + 17) +#define INT_34XX_PRCM_VP2_MAXVDD_EN(OMAP_PRCM_IRQ_BASE + 18) +#define INT_34XX_PRCM_VP2_NOSMPSACK_EN (OMAP_PRCM_IRQ_BASE + 19) +#define INT_34XX_PRCM_VP2_EQVALUE_EN (OMAP_PRCM_IRQ_BASE + 20) +#define INT_34XX_PRCM_VP2_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 21) +#define INT_34XX_PRCM_VC_SAERR_EN (OMAP_PRCM_IRQ_BASE + 22) +#define INT_34XX_PRCM_VC_RAERR_EN (OMAP_PRCM_IRQ_BASE + 23) +#define INT_34XX_PRCM_VC_TIMEOUT_ERR_EN(OMAP_PRCM_IRQ_BASE + 24) +#define INT_34XX_PRCM_SND_PERIPH_RECAL_EN (OMAP_PRCM_IRQ_BASE + 25) +#define INT_36XX_PRCM_ABB_LDO_TRANXDONE_EN (OMAP_PRCM_IRQ_BASE + 26) +#define INT_36XX_PRCM_VC_VP1_ACK_EN(OMAP_PRCM_IRQ_BASE + 27) +#define INT_36XX_PRCM_VC_BYPASS_ACK_EN (OMAP_PRCM_IRQ_BASE + 28) +#define OMAP_PRCM_NR_IRQS 32 +#define OMAP_PRCM_IRQ_END (OMAP_PRCM_IRQ_BASE + \ + OMAP_PRCM_NR_IRQS) We are in the process of getting rid of all the IRQ defines thanks to hwmod. Maybe we should consider moving that to hwmod data? I'm not sure exactly how we will handle that case but it might worth considering it. What hwmod would these be attached to? I guess that would mean creating a hwmod for the PRM, and attatching the IRQs there? Yep. I already have that in some of my secret branches, because, I'd like at some point to leverage hwmod data even for infrastructure code (prcm, control module). Taht being said, is hwmod the right place for these "virtual" IRQs? These IRQs are internal to that IP, and not really integration IRQs. Well, yes, that's why I was wondering as well if hwmod data is the right place. Anyway, we should probably consider a table with the same kind of information hwmod is using in order to have a flexible management for every OMAPs. If we do want to make that code OMAP generic, we will probably have to. That being said, that patch is already a good improvement compared to the previous solution. So maybe we should do that in several phases. Kevin, Any thoughts on that? I think this needs some more discussion, and probably a separate phase since we don't currently have hwmods for PRM or CM, at least on OMAP3. That part is easy to fix... We just have to "create" them :-) Benoit -- 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 MUX framework changes
Hi Tony, On 11/18/2010 6:57 PM, Tony Lindgren wrote: Hi Dan, [...] Can you please make this into a separate patch. And instead of indenting the code more, just do something like: if (!partition) return -EINVAL; Do you want me to merge that in my current OMAP4 series branch? Regards, Benoit -- 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/5] OMAP4: mux: Initialise OMAP4 mux pins.
On 11/18/2010 8:06 PM, Tony Lindgren wrote: * sricharan [101114 23:26]: This series updates the core device drivers to use mux framework for OMAP4 SDP and PANDA board. It's generated against the linux-omap master branch. It has a dependency on the Benoit's omap4 mux data series. 2. Do PAD configuration independently for each module Pros: a. Avoids repetition of similar data for different boards. b. Gives a knowledge of how pins are configured for a module to the respective owners. c. Pads are not initialised unless they are really needed. Cons: a. Can become difficult to maintain if lot of data tend to be different across boards. For the common modules, we should have generic platform init code using hwmod. And that init code is the logical place to do the muxing. We also need to consider that the pin muxing is board specific. So in cases where the are alternative signal paths, we need to pass the signal names from board-*.c file to the platform driver init code. What about the omap_board_mux array in board file? Do you want to get rid of it, or is the plan is to use that for pads that does not belong to any driver or pads that are purely board specific? Regards, Benoit -- 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] OMAP4: clocks: add dummy clock for mailbox
Hi Hari,
On 11/18/2010 8:20 PM, Kanigeri, Hari wrote:
In omap4, there is no explicit configuration register to enable mailbox clocks.
Defining dummy clock for mailbox clock module to keep the mailbox driver
backward compatible with previous omaps.
Signed-off-by: Hari Kanigeri
---
arch/arm/mach-omap2/clock44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index e10db7a..bdd9b85 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2687,6 +2687,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "uart3_ick", &dummy_ck, CK_443X),
CLK(NULL, "uart4_ick", &dummy_ck, CK_443X),
CLK("omap_wdt", "ick",&dummy_ck,
CK_443X),
+ CLK(NULL, "mailboxes_ick", &dummy_ck, CK_443X),
};
int __init omap4xxx_clk_init(void)
OK, that one is easy but... I will still have to update the script to
generate it, so:
Acked-by: Benoit Cousson
Regards,
Benoit
--
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 1/5] OMAP: mailbox: change full flag per mailbox queue instead of global
On 11/18/2010 8:15 PM, Kanigeri, Hari wrote:
From: Fernando Guzman Lugo
As pointed by Ohad Ben-Cohen, the variable rq_full flag is a
global variable, so if there are multiple mailbox users
there will be conflics. Now there is a full flag per
mailbox queue.
Version 2:
- Rebase to the latest.
Version 3:
You should not put the patch revisions here, because it will stay in the
changelog when it will be in GIT.
You'd better put that in the cover-letter or after the ---.
Everything after --- will not be taken into account in the changelog.
Regards,
Benoit
- Remove spin_lock protection. When the full flag is
true the interrupt for that mailbox is disabled. So there
is no race condition if full flag is modified before
calling omap_mbox_enable_irq.
Reported-by: Ohad Ben-Cohen
Signed-off-by: Fernando Guzman Lugo
Signed-off-by: Hari Kanigeri
---
arch/arm/plat-omap/include/plat/mailbox.h |1 +
arch/arm/plat-omap/mailbox.c |7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..13f2ef3 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -48,6 +48,7 @@ struct omap_mbox_queue {
struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
+ bool full;
};
struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..9ce3570 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -33,7 +33,6 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
-static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -148,6 +147,10 @@ static void mbox_rx_work(struct work_struct *work)
if (mq->callback)
mq->callback((void *)msg);
+ if (mq->full) {
+ mq->full = false;
+ omap_mbox_enable_irq(mq->mbox, IRQ_RX);
+ }
}
}
@@ -170,7 +173,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(&mq->fifo)< sizeof(msg))) {
omap_mbox_disable_irq(mbox, IRQ_RX);
- rq_full = true;
+ mq->full = true;
goto nomem;
}
--
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 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
On 11/18/2010 8:15 PM, Hari Kanigeri wrote: disabling rx interrupt on omap4 is different than its pre-decessors. The bit in OMAP4_MAILBOX_IRQENABLE_CLR should be set to disable the interrupts instead of clearing the bit. Signed-off-by: Hari Kanigeri --- arch/arm/mach-omap2/mailbox.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 42dbfa4..82b5ced 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -195,7 +195,10 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox, struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox->priv; u32 l, bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit; l = mbox_read_reg(p->irqdisable); - l&= ~bit; + if (cpu_is_omap44xx()) Since it is not omap version specific but IP version specific, you should not use cpu_is_ to do that. Moreover cpu_is calls should be used during init only. You can use the rev field in hwmod_class in order to detect the IP version. Smartreflex series for 3630 is already using that kind of mechanism. You will have to copy that revision information into pdata struct and then use that here. Benoit + l |= bit; + else + l&= ~bit; mbox_write_reg(l, p->irqdisable); } -- 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 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
On 11/19/2010 3:22 PM, Kanigeri, Hari wrote: Felipe, On Fri, Nov 19, 2010 at 2:32 AM, Felipe Balbi wrote: On Thu, Nov 18, 2010 at 06:07:40PM -0600, Kanigeri, Hari wrote: Benoit, On Thu, Nov 18, 2010 at 5:28 PM, Cousson, Benoit wrote: On 11/18/2010 8:15 PM, Hari Kanigeri wrote: disabling rx interrupt on omap4 is different than its pre-decessors. The bit in OMAP4_MAILBOX_IRQENABLE_CLR should be set to disable the interrupts instead of clearing the bit. Signed-off-by: Hari Kanigeri --- arch/arm/mach-omap2/mailbox.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 42dbfa4..82b5ced 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -195,7 +195,10 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox, struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox->priv; u32 l, bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit; l = mbox_read_reg(p->irqdisable); - l&= ~bit; + if (cpu_is_omap44xx()) Since it is not omap version specific but IP version specific, you should not use cpu_is_ to do that. Moreover cpu_is calls should be used during init only. You can use the rev field in hwmod_class in order to detect the IP version. Smartreflex series for 3630 is already using that kind of mechanism. You will have to copy that revision information into pdata struct and then use that here. I see your point, but since mailbox hwmod patches from Omar are still under review I didn't find any other option than to enable this This is critical functionality that I want to include in and not wait till the hwmod patches are accepted. OK, I didn't see that your series was supposed to be done before Omar's one. Please let me know if there is any other way of approaching this problem ? how about you read the IP revision yourself during probe ? Or pass in a flag like I said on the other email ? I like your proposal of reading the IP revision in probe. I will send a revised patch for this. Most of the time, we do not want to use the IP revision because it is un-accurate and does not reflect the change we'd like to track. For example some time a minor change in the RTL that will not impact the SW at all might trigger a change in the IP revision, whereas on the other hand a major bug fix that will impact the SW is not capture in the IP revision... yeah, that's bad, but this can happen. That's why we are relying on a rev field in the hwmod. Meanwhile, you can do the cpu_is check at init time, then fill a pdata attribute with a revision parameter, and use that revision parameter in the omap2_mbox_disable_irq. When hwmod will be there you will just extract that information from the hwmod rev field. Regards, Benoit -- 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 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
On 11/22/2010 11:08 AM, Balbi, Felipe wrote: On Fri, Nov 19, 2010 at 03:50:02PM +0100, Cousson, Benoit wrote: Most of the time, we do not want to use the IP revision because it is un-accurate and does not reflect the change we'd like to track. For example some time a minor change in the RTL that will not impact the SW at all might trigger a change in the IP revision, whereas on the other hand a major bug fix that will impact the SW is not capture in the IP revision... yeah, that's bad, but this can happen. That's why we are relying on a rev field in the hwmod. But then, what's inside this rev field ? Is it some internal revision of hwmod or do you read from the hw ? So far we are using a artificial SW IP revision that reflect the difference we'd like to highlight v1, v2. Benoit -- 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 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
On 11/22/2010 12:51 PM, Felipe Balbi wrote: Hi, On Mon, Nov 22, 2010 at 05:46:53AM -0600, Kanigeri, Hari wrote: > From the dmtimer stuff, it looks like the driver defines the version types, which hwmod uses to define the rev field. /* timer ip constants */ #define OMAP_TIMER_IP_LEGACY0x1 #define OMAP_TIMER_IP_VERSION_2 0x2 in that case, it's the same as if you pass in a flag via platform_data. You might as well call it rev, then the diff when converting to hwmod will be smaller maybe :-p Yes, this is exactly what I was proposing to Hari. For the moment create the pdata field that will be populated at init time using the cpu_is. During the hwmod migration, the value will be extracted from the hwmod rev field. Benoit -- 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: [PATCHv4 1/14] OMAP2+: dmtimer: add device names to flck nodes
Hi Tarun,
On 11/20/2010 3:39 AM, Tarun Kanti DebBarma wrote:
From: Thara Gopinath
Add device name to OMAP2 dmtimer fclk nodes so that the fclk nodes can be
retrieved by doing a clk_get with the corresponding device pointers or
device names.
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/mach-omap2/clock2420_data.c | 58 +++--
arch/arm/mach-omap2/clock2430_data.c | 58 +++--
arch/arm/mach-omap2/clock3xxx_data.c | 46 --
arch/arm/mach-omap2/clock44xx_data.c | 42 ++--
4 files changed, 161 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 21f8562..d2e90ae 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1803,27 +1803,27 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, "gpt1_ick",&gpt1_ick, CK_242X),
CLK(NULL, "gpt1_fck",&gpt1_fck, CK_242X),
Why is the timer1 not using a clockdev with device name?
+ CLK("omap-timer.1", "fck",&gpt1_fck, CK_242X),
It is the case for all the other platforms.
Thanks,
Benoit
CLK(NULL, "gpt2_ick",&gpt2_ick, CK_242X),
- CLK(NULL, "gpt2_fck",&gpt2_fck, CK_242X),
+ CLK("omap-timer.2", "fck",&gpt2_fck, CK_242X),
CLK(NULL, "gpt3_ick",&gpt3_ick, CK_242X),
- CLK(NULL, "gpt3_fck",&gpt3_fck, CK_242X),
+ CLK("omap-timer.3", "fck",&gpt3_fck, CK_242X),
CLK(NULL, "gpt4_ick",&gpt4_ick, CK_242X),
- CLK(NULL, "gpt4_fck",&gpt4_fck, CK_242X),
+ CLK("omap-timer.4", "fck",&gpt4_fck, CK_242X),
CLK(NULL, "gpt5_ick",&gpt5_ick, CK_242X),
- CLK(NULL, "gpt5_fck",&gpt5_fck, CK_242X),
+ CLK("omap-timer.5", "fck",&gpt5_fck, CK_242X),
CLK(NULL, "gpt6_ick",&gpt6_ick, CK_242X),
- CLK(NULL, "gpt6_fck",&gpt6_fck, CK_242X),
+ CLK("omap-timer.6", "fck",&gpt6_fck, CK_242X),
CLK(NULL, "gpt7_ick",&gpt7_ick, CK_242X),
- CLK(NULL, "gpt7_fck",&gpt7_fck, CK_242X),
+ CLK("omap-timer.7", "fck",&gpt7_fck, CK_242X),
CLK(NULL, "gpt8_ick",&gpt8_ick, CK_242X),
- CLK(NULL, "gpt8_fck",&gpt8_fck, CK_242X),
+ CLK("omap-timer.8", "fck",&gpt8_fck, CK_242X),
CLK(NULL, "gpt9_ick",&gpt9_ick, CK_242X),
- CLK(NULL, "gpt9_fck",&gpt9_fck, CK_242X),
+ CLK("omap-timer.9", "fck",&gpt9_fck, CK_242X),
CLK(NULL, "gpt10_ick",&gpt10_ick, CK_242X),
- CLK(NULL, "gpt10_fck",&gpt10_fck, CK_242X),
+ CLK("omap-timer.10","fck",&gpt10_fck, CK_242X),
CLK(NULL, "gpt11_ick",&gpt11_ick, CK_242X),
- CLK(NULL, "gpt11_fck",&gpt11_fck, CK_242X),
+ CLK("omap-timer.11","fck",&gpt11_fck, CK_242X),
CLK(NULL, "gpt12_ick",&gpt12_ick, CK_242X),
- CLK(NULL, "gpt12_fck",&gpt12_fck, CK_242X),
+ CLK("omap-timer.12","fck",&gpt12_fck, CK_242X),
CLK("omap-mcbsp.1", "ick",&mcbsp1_ick,CK_242X),
CLK("omap-mcbsp.1", "fck",&mcbsp1_fck,CK_242X),
CLK("omap-mcbsp.2", "ick",&mcbsp2_ick,CK_242X),
@@ -1878,6 +1878,42 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, "pka_ick",&pka_ick, CK_242X),
CLK(NULL, "usb_fck",&usb_fck, CK_242X),
CLK("musb_hdrc","fck",&osc_ck,CK_242X),
+ CLK("omap-timer.1", "32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.2", "32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.3", "32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.4", "32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.5", "32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.6", "32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.7", "32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.8", "32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.9", "32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.10","32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.11","32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.12","32k_ck",&func_32k_ck, CK_243X),
+ CLK("omap-timer.1", "sys_ck",&sys_ck,CK_243X),
+ CLK("omap-timer.2", "sys_ck",&sys_ck,CK_243X),
+ CLK("omap-timer.3", "sys_ck",&sys_ck,CK_243X),
+ CLK("omap-timer.4", "sys_ck",&sys_ck,CK_243X),
+ CLK("omap-timer.5", "sys_ck",&sys_ck,CK_243X),
+ CLK("omap-timer.6", "sys_ck",&sys_ck,CK_243X),
+ CLK("omap-timer.7", "sys
Re: [PATCHv4 1/14] OMAP2+: dmtimer: add device names to flck nodes
On 11/23/2010 9:36 AM, DebBarma, Tarun Kanti wrote:
Benoit,
-Original Message-
From: Cousson, Benoit
Sent: Monday, November 22, 2010 11:03 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Gopinath, Thara
Subject: Re: [PATCHv4 1/14] OMAP2+: dmtimer: add device names to flck
nodes
Hi Tarun,
On 11/20/2010 3:39 AM, Tarun Kanti DebBarma wrote:
From: Thara Gopinath
Add device name to OMAP2 dmtimer fclk nodes so that the fclk nodes can
be
retrieved by doing a clk_get with the corresponding device pointers or
device names.
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/mach-omap2/clock2420_data.c | 58
+++--
arch/arm/mach-omap2/clock2430_data.c | 58
+++--
arch/arm/mach-omap2/clock3xxx_data.c | 46 --
arch/arm/mach-omap2/clock44xx_data.c | 42 ++--
4 files changed, 161 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-
omap2/clock2420_data.c
index 21f8562..d2e90ae 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1803,27 +1803,27 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, "gpt1_ick",&gpt1_ick, CK_242X),
CLK(NULL, "gpt1_fck",&gpt1_fck, CK_242X),
Why is the timer1 not using a clockdev with device name?
+ CLK("omap-timer.1", "fck",&gpt1_fck, CK_242X),
It is the case for all the other platforms.
Ok, this is done at later patch when we switch to platform driver.
This is done in this way because gptimer driver would not recognize
Clock access using device name until the complete switch-over happens.
This is to keep each patch compiled and booting.
OK, I've just the the patch (#12) where it happens. In that case, you
should just add some disclaimer in the changelog.
Benoit
--
Tarun
CLK(NULL, "gpt2_ick",&gpt2_ick, CK_242X),
- CLK(NULL, "gpt2_fck",&gpt2_fck, CK_242X),
+ CLK("omap-timer.2", "fck",&gpt2_fck, CK_242X),
CLK(NULL, "gpt3_ick",&gpt3_ick, CK_242X),
- CLK(NULL, "gpt3_fck",&gpt3_fck, CK_242X),
+ CLK("omap-timer.3", "fck",&gpt3_fck, CK_242X),
CLK(NULL, "gpt4_ick",&gpt4_ick, CK_242X),
- CLK(NULL, "gpt4_fck",&gpt4_fck, CK_242X),
+ CLK("omap-timer.4", "fck",&gpt4_fck, CK_242X),
CLK(NULL, "gpt5_ick",&gpt5_ick, CK_242X),
- CLK(NULL, "gpt5_fck",&gpt5_fck, CK_242X),
+ CLK("omap-timer.5", "fck",&gpt5_fck, CK_242X),
CLK(NULL, "gpt6_ick",&gpt6_ick, CK_242X),
- CLK(NULL, "gpt6_fck",&gpt6_fck, CK_242X),
+ CLK("omap-timer.6", "fck",&gpt6_fck, CK_242X),
CLK(NULL, "gpt7_ick",&gpt7_ick, CK_242X),
- CLK(NULL, "gpt7_fck",&gpt7_fck, CK_242X),
+ CLK("omap-timer.7", "fck",&gpt7_fck, CK_242X),
CLK(NULL, "gpt8_ick",&gpt8_ick, CK_242X),
- CLK(NULL, "gpt8_fck",&gpt8_fck, CK_242X),
+ CLK("omap-timer.8", "fck",&gpt8_fck, CK_242X),
CLK(NULL, "gpt9_ick",&gpt9_ick, CK_242X),
- CLK(NULL, "gpt9_fck",&gpt9_fck, CK_242X),
+ CLK("omap-timer.9", "fck",&gpt9_fck, CK_242X),
CLK(NULL, "gpt10_ick",&gpt10_ick, CK_242X),
- CLK(NULL, "gpt10_fck",&gpt10_fck, CK_242X),
+ CLK("omap-timer.10","fck",&gpt10_fck, CK_242X),
CLK(NULL, "gpt11_ick",&gpt11_ick, CK_242X),
- CLK(NULL, "gpt11_fck",&gpt11_fck, CK_242X),
+ CLK("omap-timer.11","fck",&gpt11_fck, CK_242X),
CLK(NULL, "gpt12_ick",&gpt12_ick, CK_242X),
- CLK(NULL, "gpt12_fck",&gpt12_fck, CK_242X),
+ CLK("omap-timer.12","fck",&gpt12_fck, CK_242X),
CLK("omap-mcbsp.1", "ick",&mcbsp1_ick,CK_242X),
CLK("omap-mcbsp.1", "fck",&mcbsp1_fck,CK_242X),
CLK("omap-mcbsp.2", "ick",&mcbsp2_ick,CK_242X),
@@ -1878,6 +1878,42 @@ static struct omap_clk omap2420_clks[] =
Re: [PATCHv4 2/14] OMAP: dmtimer: infrastructure to support hwmod
On 11/20/2010 3:39 AM, DebBarma, Tarun Kanti wrote:
(1) Add new fields and data structures to support dmtimer conversion
to platform driver.
(2) Constants to identify IP revision so that Highlander IP in OMAP 4
can be distinguished.
(3) field to identify OMAP4 abe timers.
(4) Interface function to support early boot.
Signed-off-by: Tarun Kanti DebBarma
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/dmtimer.h | 32 +
arch/arm/plat-omap/dmtimer.c |8 +++
arch/arm/plat-omap/include/plat/dmtimer.h | 19 +
3 files changed, 59 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/dmtimer.h
diff --git a/arch/arm/mach-omap2/dmtimer.h b/arch/arm/mach-omap2/dmtimer.h
new file mode 100644
index 000..4d4493b
--- /dev/null
+++ b/arch/arm/mach-omap2/dmtimer.h
@@ -0,0 +1,32 @@
+/**
+ * OMAP Dual-Mode Timers - early initialization interface
+ *
+ * function interface called first to start dmtimer early initialization.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Tarun Kanti DebBarma
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Thara Gopinath
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef __ASM_ARCH_DMTIMER_H
+#define __ASM_ARCH_DMTIMER_H
+
+/*
+ * dmtimer is required during early part of boot sequence even before
+ * device model and pm_runtime if fully up and running. this function
+ * provides hook to omap2_init_common_hw() which is triggered from
+ * start_kernel()->init_irq() of kernel initialization sequence.
+ */
+void __init omap2_dm_timer_early_init(void);
+
+#endif
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 1d706cf..10daa9d 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -3,6 +3,12 @@
*
* OMAP Dual-Mode Timers
*
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Tarun Kanti DebBarma
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Thara Gopinath
You can remove the copyright and put Thara's name below yours.
It should be the case for other field as well.
+ *
* Copyright (C) 2005 Nokia Corporation
* OMAP2 support by Juha Yrjola
* API improvements and OMAP2 clock framework support by Timo Teras
@@ -151,6 +157,7 @@
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR<< WPSHIFT))
struct omap_dm_timer {
+ int id;
unsigned long phys_base;
int irq;
#ifdef CONFIG_ARCH_OMAP2PLUS
@@ -160,6 +167,7 @@ struct omap_dm_timer {
unsigned reserved:1;
unsigned enabled:1;
unsigned posted:1;
+ struct platform_device *pdev;
};
What that structure is used for? Is it some legacy structure that will
be removed in next patches? It seems to be a wrapper on top of the
device that should not be used anymore after platform_driver migration.
static int dm_timer_count;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index dfa3aff..2bb837e 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -3,6 +3,11 @@
*
* OMAP Dual-Mode Timers
*
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Tarun Kanti DebBarma
+ * Thara Gopinath
Add a blank line here.
+ * Platform device conversion and hwmod support.
+ *
* Copyright (C) 2005 Nokia Corporation
* Author: Lauri Leukkunen
* PWM and clock framwork support by Timo Teras.
@@ -29,6 +34,8 @@
#ifndef __ASM_ARCH_DMTIMER_H
#define __ASM_ARCH_DMTIMER_H
+#include
+
/* clock sources */
#define OMAP_TIMER_SRC_SYS_CLK0x00
#define OMAP_TIMER_SRC_32_KHZ 0x01
@@ -44,11 +51,23 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW 0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPAR0x02
+/* timer ip constants */
Maybe you should have a better comment here?
Something closer to your changelog: IP revision identifier so that
Highlander IP in OMAP 4 can be distinguished.
+#define OMAP_TIMER_IP_VERSION_10x1
+#define OMAP_TIMER_IP_VERSION_20x2
+
struct omap_dm_timer;
extern struct omap_dm_timer *gptimer_wakeup;
extern struct sys_timer omap_timer;
struct clk;
+struct dmtimer_platform_data {
+ int (*set_timer_src) (struct platform_device *pdev, int source);
+ int timer_ip_type;
+ u8 func_offst;
+ u8 intr_offst;
You can probably keep "offset"
Re: [PATCHv4 7/14] OMAP: dmtimer: use list instead of static array
On 11/20/2010 3:39 AM, Tarun Kanti DebBarma wrote:
Convert dmtimers static array in functions into list structure.
Please note that the static arrays will be completely removed
in subsequent patches when dmtimer is converted to platform driver.
Why do you still need to keep your own list of timers?
The driver already contains a list of devices.
You even have some iterator available in the kernel:
driver_for_each_device or driver_find_device.
You could probably get rid of all that stuff for my point of view.
Benoit
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/plat-omap/dmtimer.c | 67 +++---
1 files changed, 37 insertions(+), 30 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 10daa9d..124fd21 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -168,6 +168,7 @@ struct omap_dm_timer {
unsigned enabled:1;
unsigned posted:1;
struct platform_device *pdev;
+ struct list_head node;
};
static int dm_timer_count;
@@ -290,7 +291,8 @@ static struct omap_dm_timer *dm_timers;
static const char **dm_source_names;
static struct clk **dm_source_clocks;
-static spinlock_t dm_timer_lock;
+static LIST_HEAD(omap_timer_list);
+static DEFINE_SPINLOCK(dm_timer_lock);
/*
* Reads timer registers in posted and non-posted mode. The posted mode bit
@@ -340,7 +342,7 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
u32 l;
- if (!cpu_class_is_omap2() || timer !=&dm_timers[0]) {
+ if (!cpu_class_is_omap2() || timer->id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
@@ -371,23 +373,24 @@ static void omap_dm_timer_prepare(struct omap_dm_timer
*timer)
struct omap_dm_timer *omap_dm_timer_request(void)
{
- struct omap_dm_timer *timer = NULL;
+ struct omap_dm_timer *timer = NULL, *t;
unsigned long flags;
- int i;
spin_lock_irqsave(&dm_timer_lock, flags);
- for (i = 0; i< dm_timer_count; i++) {
- if (dm_timers[i].reserved)
+ list_for_each_entry(t,&omap_timer_list, node) {
+ if (t->reserved)
continue;
- timer =&dm_timers[i];
+ timer = t;
timer->reserved = 1;
break;
}
spin_unlock_irqrestore(&dm_timer_lock, flags);
- if (timer != NULL)
+ if (timer)
omap_dm_timer_prepare(timer);
+ else
+ pr_debug("%s: free timer not available.\n", __func__);
return timer;
}
@@ -395,23 +398,23 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_request);
struct omap_dm_timer *omap_dm_timer_request_specific(int id)
{
- struct omap_dm_timer *timer;
+ struct omap_dm_timer *timer = NULL, *t;
unsigned long flags;
spin_lock_irqsave(&dm_timer_lock, flags);
- if (id<= 0 || id> dm_timer_count || dm_timers[id-1].reserved) {
- spin_unlock_irqrestore(&dm_timer_lock, flags);
- printk("BUG: warning at %s:%d/%s(): unable to get timer %d\n",
- __FILE__, __LINE__, __func__, id);
- dump_stack();
- return NULL;
+ list_for_each_entry(t,&omap_timer_list, node) {
+ if (t->id == id&& !t->reserved) {
+ timer = t;
+ timer->reserved = 1;
+ break;
+ }
}
-
- timer =&dm_timers[id-1];
- timer->reserved = 1;
spin_unlock_irqrestore(&dm_timer_lock, flags);
- omap_dm_timer_prepare(timer);
+ if (timer)
+ omap_dm_timer_prepare(timer);
+ else
+ pr_debug("%s: timer%d not available.\n", __func__, id);
return timer;
}
@@ -474,24 +477,29 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
*/
__u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
{
- int i;
+ int i = 0;
+ struct omap_dm_timer *timer = NULL;
+ unsigned long flags;
/* If ARMXOR cannot be idled this function call is unnecessary */
if (!(inputmask& (1<< 1)))
return inputmask;
/* If any active timer is using ARMXOR return modified mask */
- for (i = 0; i< dm_timer_count; i++) {
+ spin_lock_irqsave(&dm_timer_lock, flags);
+ list_for_each_entry(timer,&omap_timer_list, node) {
u32 l;
- l = omap_dm_timer_read_reg(&dm_timers[i], OMAP_TIMER_CTRL_REG);
+ l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
if (l& OMAP_TIMER_CTRL_ST) {
if (((omap_readl(MOD_CONF_CTRL_1)>> (i * 2))& 0x03)
== 0)
inputmask&= ~(1<< 1);
else
inputmask&= ~(1<< 2);
}
Re: [PATCHv4 11/14] OMAP2+: dmtimer: convert to platform devices
On 11/20/2010 3:39 AM, Tarun Kanti DebBarma wrote:
From: Thara Gopinath
Add routines to converts dmtimers to platform devices. The device data
is obtained from hwmod database of respective platform and is registered
to device model after successful binding to driver. It also provides
provision to access timers during early boot when pm_runtime framework
is not completely up and running.
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
[p-bas...@ti.com: pm_runtime logic]
Signed-off-by: Partha Basak
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/dmtimer.c | 296 +
2 files changed, 297 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/dmtimer.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ce7b1f0..148f4d7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \
-common.o
+common.o dmtimer.o
omap-2-3-common = irq.o sdrc.o prm2xxx_3xxx.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-omap2/dmtimer.c
new file mode 100644
index 000..b5951b1
--- /dev/null
+++ b/arch/arm/mach-omap2/dmtimer.c
@@ -0,0 +1,296 @@
+/**
+ * OMAP2PLUS Dual-Mode Timers - platform device registration
+ *
+ * Contains first level initialization routines which extracts timers
+ * information from hwmod database and registers with linux device model.
+ * It also has low level function to chnage the timer input clock source.
typo.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Tarun Kanti DebBarma
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Thara Gopinath
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#undef DEBUG
I guess, that undef should not be there?
+
+#include
+#include
+#include
+#include
+#include
+
+#include
Do you still need that?
+#include
+#include
Why do you need powerdomain in that file?
+#include
+#include
+#include
+
+static int early_timer_count __initdata = 1;
+
+/**
+ * omap2_dm_timer_set_src - change the timer input clock source
+ * @pdev: timer platform device pointer
+ * @timer_clk: current clock source
+ * @source:array index of parent clock source
+ */
+static int omap2_dm_timer_set_src(struct platform_device *pdev, int source)
+{
+ int ret;
+ struct dmtimer_platform_data *pdata = pdev->dev.platform_data;
+ struct clk *fclk = clk_get(&pdev->dev, "fck");
+ struct clk *new_fclk;
+ char *fclk_name = "32k_ck"; /* default name */
+
+ switch(source) {
+ case OMAP_TIMER_SRC_SYS_CLK:
+ fclk_name = "sys_ck";
+ break;
+
+ case OMAP_TIMER_SRC_32_KHZ:
+ fclk_name = "32k_ck";
+ break;
+
+ case OMAP_TIMER_SRC_EXT_CLK:
+ if (pdata->timer_ip_type == OMAP_TIMER_IP_VERSION_1) {
+ fclk_name = "alt_ck";
+ break;
+ }
+ dev_dbg(&pdev->dev, "%s:%d: invalid clk src.\n",
+ __func__, __LINE__);
+ return -EINVAL;
+ }
Do you really have to maintain the source enum? Cannot you just pass the
char* to this API?
It will avoid that code, and make that API much more flexible if we have
to add extra clock source in the future.
If the clock does not exist in a particular Soc, the clk_get will fail
and that's all you have to know.
+
+
+ if (IS_ERR_OR_NULL(fclk)) {
+ dev_dbg(&pdev->dev, "%s:%d: clk_get() FAILED\n",
+ __func__, __LINE__);
+ return -EINVAL;
+ }
+
+ new_fclk = clk_get(&pdev->dev, fclk_name);
+ if (IS_ERR_OR_NULL(new_fclk)) {
+ dev_dbg(&pdev->dev, "%s:%d: clk_get() %s FAILED\n",
+ __func__, __LINE__, fclk_name);
+ clk_put(fclk);
+ return -EINVAL;
+ }
+
+ ret = clk_set_parent(fclk, new_fclk);
+ if (IS_ERR_VALUE(ret)) {
+ dev_dbg(&pdev->dev, "%s:clk_set_parent() to %s FAILED\n",
+ __func__, fclk_name);
+ ret = -EINVAL;
+ }
+
+ clk_put(new_fclk);
+ clk_put(fclk);
+
+ return ret;
+}
+
+struct omap_device_pm_latency omap2_dmtimer_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwm
Re: [PATCH v4 2/3] omap4: opp: add OPP table data
Hi Nishanth,
On 11/23/2010 4:19 PM, Menon, Nishanth wrote:
Kevin Hilman had written, on 11/22/2010 06:09 PM, the following:
Nishanth Menon writes:
Kevin Hilman wrote, on 11/22/2010 05:19 PM:
Nishanth Menon writes:
This patch adds OPP tables for OMAP4. New file has been added to keep
the OMAP4 opp tables and the registration of these tables with the
generic opp framework by OMAP SoC OPP interface.
[...]
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 66e12be..48a553f 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -131,4 +131,5 @@ static int __init omap_init_opp_table(struct omap_opp_def
*opp_def,
/* omap3 opps */
#include "opp3xxx_data.c"
-
+/* omap4 opps */
+#include "opp4xxx_data.c"
I'm not sure I like the including of C files. Any reason you prefer
this to just adding them to the Makefile? e.g. opp24xx_dta.c are
compiled in via Makefile and these two are included.
I dont buy it. I am seeing us go around in circles for this:
http://marc.info/?l=linux-omap&m=128986880406272&w=2
a) we dont want others to use specifics implemented in opp.c in other
files (e.g. board files)
not sure how this is prevented.
The approach is as follows:
the #defines and struct definitions are in opp.c
opp{3,4}xxx_data.c use the same - by itself wont build because they need
the defines in opp.c
that way, there is no possibility of clean hacks possible except to
follow the current mechanism for a future omap silicon
The main objective was to restrict the potential of board developers
from hacking the default OPP table - which would be possible by exposing
the headers for board files - which as Thomas rightly pointed out in the
thread I pointed out, opens up a possibility for board files to
include them as well and re-instantiate the table again..
b) we have many similar usage in linux kernel - so this usage is not
first time.
c) opp2xx usage is very different from opp3/4 usage
I'm not going to insist on one way or the other, just stating my
preference for not including C files from C files without good
justification. You've stated your reasons, I guess Tony can decide.
okay by me - will post a v5 after seeing the final decision on that front :)
FYI, Paul changed the clock and hwmod data files from include to C
files, because Russell didn't like at all the include of data file.
Why cannot we handle the opp data the same way we are managing clock,
hwmod or even pad mux data for various Soc?
Regards,
Benoit
--
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 v4 2/3] omap4: opp: add OPP table data
On 11/23/2010 11:56 PM, Menon, Nishanth wrote:
Cousson, Benoit had written, on 11/23/2010 04:33 PM, the following:
Hi Nishanth,
On 11/23/2010 4:19 PM, Menon, Nishanth wrote:
Kevin Hilman had written, on 11/22/2010 06:09 PM, the following:
Nishanth Menon writes:
Kevin Hilman wrote, on 11/22/2010 05:19 PM:
Nishanth Menonwrites:
This patch adds OPP tables for OMAP4. New file has been added to keep
the OMAP4 opp tables and the registration of these tables with the
generic opp framework by OMAP SoC OPP interface.
[...]
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 66e12be..48a553f 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -131,4 +131,5 @@ static int __init omap_init_opp_table(struct
omap_opp_def *opp_def,
/* omap3 opps */
#include "opp3xxx_data.c"
-
+/* omap4 opps */
+#include "opp4xxx_data.c"
I'm not sure I like the including of C files. Any reason you prefer
this to just adding them to the Makefile? e.g. opp24xx_dta.c are
compiled in via Makefile and these two are included.
I dont buy it. I am seeing us go around in circles for this:
http://marc.info/?l=linux-omap&m=128986880406272&w=2
a) we dont want others to use specifics implemented in opp.c in other
files (e.g. board files)
not sure how this is prevented.
The approach is as follows:
the #defines and struct definitions are in opp.c
opp{3,4}xxx_data.c use the same - by itself wont build because they need
the defines in opp.c
that way, there is no possibility of clean hacks possible except to
follow the current mechanism for a future omap silicon
The main objective was to restrict the potential of board developers
from hacking the default OPP table - which would be possible by exposing
the headers for board files - which as Thomas rightly pointed out in the
thread I pointed out, opens up a possibility for board files to
include them as well and re-instantiate the table again..
[...]
FYI, Paul changed the clock and hwmod data files from include to C
files, because Russell didn't like at all the include of data file.
Why cannot we handle the opp data the same way we are managing clock,
hwmod or even pad mux data for various Soc?
Objective:
I do not want folks to start creating their own custom "default" OPP
tables for silicon and registering with OPP framework. intent is to have
the default OPP tables in one place - here.
Solution I followed:
make the following:
a) struct omap_opp_def
b) OPP_INITIALIZER
c) omap_init_opp_table
not available for anyone other than opp.c - they are defined in opp.c
and not available externally.
If these were in a header, I am inviting failure of my objective. yes, I
could review it when posted to l-o and NAK it, but wont prevent private
trees from basically(IMHO) misusing the framework
Options available:
a) v1,2,3 of the series basically used a header opp{3,4}xxx_data .h
in v3, I received a comment (IMHO rightly so) that a header defining a
static array implies capability for some other file to include the
header and misuse it (basically headers are meant to share data structs
between x and y - if you dont intend to do that, then put it in a c file)
b) in v4, I converted the data header to a .c and included the data.c in
opp.c.
NOTE:
a) padconf, hwmod, clock are designed to be reused by rest of
mach-omap2. opp defines are meant to be isolated. I dont really have a
preference c or header file for the data, just that I want to, by design
"make any hacks attempts - *really ugly*"
Mmm, I'm not convince that this will prevent anybody to do dirty stuff
anyway.
Doing "dirty" stuff to avoid even more dirty stuff is kind of a weird
approach... for my point of view at least...
And no, this is not that different than the hwmod data or clock data...
These data are never manipulated directly by anybody but the core code.
b) Inclusion of c in c files are not uniquely introduced here.
$ find . -iname "*.c"|xargs grep "#include"| grep -v "\.h"|grep
":#include"|wc -l
558
That does not mean that we have to keep doing it.
There are probably much more lines of code that does not stick to the
CodingStyle ;-)
Hope this clarifies.
Yes, but that still does not justify that for my point of view.
Benoit
--
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 v7 00/11] OMAP: GPIO: Implement GPIO as a platform device
Hi Charu, On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote: Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO module uses hwmod FW. Tested on OMAP2430, OMAP44430, OMAP3430 SDP boards, OMAP4430 Blaze board How did you get some top secret samples of the ultra new *44430* device running at 16.5 GHz? That device should not be released publicly before 10 years ;-) Benoit and zoom3 board. Verified that this patch series does not break the OMAP1 build. Version History: --- v7 Series: - Use gpio iclks as main_clk in OMAP3& OMAP4 - Implement GPIO as a platform device (use hwmod FW for OMAP2+) and the implementation is similar to current GPIO code. Does not modify the gpio suspend/ resume/ prepare for odle and resume after idle code and these modifications would be done in a separate patch series. This was suggested by Kevin in another internal email thread. v6 Series: Some links for v6 series: https://patchwork.kernel.org/patch/189742/ https://patchwork.kernel.org/patch/189822/ https://patchwork.kernel.org/patch/189832/ Comments Fixed in v6: -use PM runtime APIs for gpio in cpu idle/resume after idle path when interrupts are enabled. -Do not use omap_device_* calls in the gpio driver -Use clock alias names for debounce clocks while using clock framework APIs to do clk_get. -do a kfree of pdata after doing omap_device_build() -use PM runtime APIs during probe before and after accessing gpio registers -Remove sysconfig register access from GPIO driver -Use ARRAY_SIZE instead on size_of in OMAP1 gpio_init v5 Series: Some links for v5 series: https://patchwork.kernel.org/patch/117790/ https://patchwork.kernel.org/patch/117789/ https://patchwork.kernel.org/patch/117788/ https://patchwork.kernel.org/patch/117785/ https://patchwork.kernel.org/patch/117796/ Comments Fixed in v5: - Use dev_pm_ops instead of sys_dev_class - Use runtime suspend/resume hooks for GPIO device - extend the usage of mod_usage flag to all cpu classes.(Earlier it was used only for OMAP2+) - Make gpio_context as part of gpio_bank structure v4 Series: Some links for v4 series: https://patchwork.kernel.org/patch/107411/ Comments Fixed in v4: - Remove gpio_bank_count from dev_attr field and derive it from hwmod class iteration count - Add TODOs for future omap gpio code cleanup related activity - Rename gpio's platform_data 'method' to 'bank_type' - Rename gpio's platform_data 'gpio_bank_bits' to 'gpio_bank_width' - Add 'rev' field to gpio class in hwmod datbase and get 'bank_type' based on 'rev' field - Filename removed from file description when a new file is created v3 Series: Some of the v3 links: https://patchwork.kernel.org/patch/106224/ Comments Fixed in v3: - .module_offs populated in hwmod structures - If not defined CONFIG_PM_RUNTIME is not handled in GPIO driver - No changes to mach-omap2/clock-data.c to handle clocks by dev ptr as it is taken care using clock get by name in hwmod& omap_device layer - Using "ick" instead of "arm_gpio_ck" for OMAP15xx clock - SoC base addresses moved to plat-omap/omap.h that should be used only by the omap_hwmod__data.c file - OMAP2/3 hwmod structures naming convention changed as it is followed in OMAP4 - omap24xx_gpio_init() uses cpu_is_omap24xx() instead of separate checks for 2420& 2430 in OMAP2 specific init call (mach-omap layer) - Reason for using postcore_initcall is added to patch description - Comments added for usage of dbck_flag and other elements in dev_attr structure - Uses dev_dbg() and dev_err() instead of pr_dbg() and pr_err() - Corrects the gpio clock details in OMAP4 hwmod database v2 series: Some important links to patch v2 series and comments: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30262.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28787.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30263.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30295.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30259.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28933.html Comments Fixed in V2: - GPIO dev attr was added for SoC specific chip info (eg., gpio bank count) - Removed omap_gpio_init() usage from board files - platform_get_resource() used instead of pdata->base for OMAP2+ base addresses - postcore_initcall used for gpio init instead of making GPIO as an early platform device. SoC specific gpio_init needs to be done before machine_init functions access gpio APIs. Hence making SoC specific gpio_init as postcore_initcall. - getting gpio dbck is moved to omap_set_gpio_debounce() instead of doing it in probe v1 series: Some important links to patch v1 series and comments: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26934.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27860.html http://www.mail-archive.com/linux-omap@vger.kernel.org/m
Re: [PATCH v7 05/11] OMAP2420: hwmod data: Add GPIO
On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:
Add GPIO hwmod data for OMAP2420
Signed-off-by: Charulatha V
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 229
arch/arm/plat-omap/include/plat/gpio.h |5 +
2 files changed, 234 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..c951061 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
Do you still need that header file?
#include "omap_hwmod_common_data.h"
@@ -38,6 +39,10 @@ static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_gpio1_hwmod;
+static struct omap_hwmod omap2420_gpio2_hwmod;
+static struct omap_hwmod omap2420_gpio3_hwmod;
+static struct omap_hwmod omap2420_gpio4_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -557,6 +562,224 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags = HWMOD_16BIT_REG,
};
+/* l4_wkup -> gpio1 */
+static struct omap_hwmod_addr_space omap2420_gpio1_addr_space[] = {
+ {
+ .pa_start = 0x48018000,
+ .pa_end = 0x480181ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio1 = {
+ .master =&omap2420_l4_wkup_hwmod,
+ .slave =&omap2420_gpio1_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2420_gpio1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> gpio2 */
+static struct omap_hwmod_addr_space omap2420_gpio2_addr_space[] = {
+ {
+ .pa_start = 0x4801a000,
+ .pa_end = 0x4801a1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio2 = {
+ .master =&omap2420_l4_wkup_hwmod,
+ .slave =&omap2420_gpio2_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2420_gpio2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> gpio3 */
+static struct omap_hwmod_addr_space omap2420_gpio3_addr_space[] = {
+ {
+ .pa_start = 0x4801c000,
+ .pa_end = 0x4801c1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio3 = {
+ .master =&omap2420_l4_wkup_hwmod,
+ .slave =&omap2420_gpio3_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2420_gpio3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> gpio4 */
+static struct omap_hwmod_addr_space omap2420_gpio4_addr_space[] = {
+ {
+ .pa_start = 0x4801e000,
+ .pa_end = 0x4801e1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio4 = {
+ .master =&omap2420_l4_wkup_hwmod,
+ .slave =&omap2420_gpio4_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2420_gpio4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* gpio dev_attr */
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .bank_width = 32,
+ .dbck_flag = false,
+};
+
+static struct omap_hwmod_class_sysconfig omap242x_gpio_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type1,
+};
+
+/*
+ * 'gpio' class
+ * general purpose io module
+ */
+static struct omap_hwmod_class omap242x_gpio_hwmod_class = {
+ .name = "gpio",
+ .sysc =&omap242x_gpio_sysc,
+ .rev = 0,
+};
+
+/* gpio1 */
+static struct omap_hwmod_irq_info omap242x_gpio1_irqs[] = {
+ { .name = "gpio_mpu_irq", .irq = 29 }, /* INT_24XX_GPIO_BANK1 */
+};
+
+static struct omap_hwmod_ocp_if *omap2420_gpio1_slaves[] = {
+ &omap2420_l4_wkup__gpio1,
+};
+
+static struct omap_hwmod omap2420_gpio1_hwmod = {
+ .name = "gpio1",
+ .mpu_irqs =
Re: [PATCH v7 06/11] OMAP2430: hwmod data: Add GPIO
On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:
Add GPIO hwmod data for OMAP2430
Signed-off-by: Charulatha V
Acked-by: Benoit Cousson
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 279
1 files changed, 279 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..397471c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
Just check if that include is still needed.
Benoit
#include "omap_hwmod_common_data.h"
@@ -38,6 +39,11 @@ static struct omap_hwmod omap2430_iva_hwmod;
static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
static struct omap_hwmod omap2430_wd_timer2_hwmod;
+static struct omap_hwmod omap2430_gpio1_hwmod;
+static struct omap_hwmod omap2430_gpio2_hwmod;
+static struct omap_hwmod omap2430_gpio3_hwmod;
+static struct omap_hwmod omap2430_gpio4_hwmod;
+static struct omap_hwmod omap2430_gpio5_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -569,6 +575,272 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/* l4_wkup -> gpio1 */
+static struct omap_hwmod_addr_space omap2430_gpio1_addr_space[] = {
+ {
+ .pa_start = 0x4900C000,
+ .pa_end = 0x4900C1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio1 = {
+ .master =&omap2430_l4_wkup_hwmod,
+ .slave =&omap2430_gpio1_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2430_gpio1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> gpio2 */
+static struct omap_hwmod_addr_space omap2430_gpio2_addr_space[] = {
+ {
+ .pa_start = 0x4900E000,
+ .pa_end = 0x4900E1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio2 = {
+ .master =&omap2430_l4_wkup_hwmod,
+ .slave =&omap2430_gpio2_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2430_gpio2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> gpio3 */
+static struct omap_hwmod_addr_space omap2430_gpio3_addr_space[] = {
+ {
+ .pa_start = 0x4901,
+ .pa_end = 0x490101ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio3 = {
+ .master =&omap2430_l4_wkup_hwmod,
+ .slave =&omap2430_gpio3_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2430_gpio3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> gpio4 */
+static struct omap_hwmod_addr_space omap2430_gpio4_addr_space[] = {
+ {
+ .pa_start = 0x49012000,
+ .pa_end = 0x490121ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio4 = {
+ .master =&omap2430_l4_wkup_hwmod,
+ .slave =&omap2430_gpio4_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2430_gpio4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_core -> gpio5 */
+static struct omap_hwmod_addr_space omap2430_gpio5_addr_space[] = {
+ {
+ .pa_start = 0x480B6000,
+ .pa_end = 0x480B61ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__gpio5 = {
+ .master =&omap2430_l4_core_hwmod,
+ .slave =&omap2430_gpio5_hwmod,
+ .clk= "gpio5_ick",
+ .addr = omap2430_gpio5_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio5_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* gpio dev_attr */
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .bank_width = 32,
+ .dbck_flag = false,
+};
+
+static struct omap_hwmod_class_sysconfig omap243x_gpio_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOI
Re: [PATCH v7 07/11] OMAP3: hwmod data: Add GPIO
On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:
Add GPIO hwmod data for OMAP3
Signed-off-by: Charulatha V
Signed-off-by: Rajendra Nayak
Acked-by: Benoit Cousson
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 360
1 files changed, 360 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index a8bed84..9ca2206 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include "omap_hwmod_common_data.h"
@@ -45,6 +46,12 @@ static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
static struct omap_hwmod omap3xxx_i2c1_hwmod;
static struct omap_hwmod omap3xxx_i2c2_hwmod;
static struct omap_hwmod omap3xxx_i2c3_hwmod;
+static struct omap_hwmod omap3xxx_gpio1_hwmod;
+static struct omap_hwmod omap3xxx_gpio2_hwmod;
+static struct omap_hwmod omap3xxx_gpio3_hwmod;
+static struct omap_hwmod omap3xxx_gpio4_hwmod;
+static struct omap_hwmod omap3xxx_gpio5_hwmod;
+static struct omap_hwmod omap3xxx_gpio6_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -739,6 +746,351 @@ static struct omap_hwmod omap3xxx_i2c3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* l4_wkup -> gpio1 */
+static struct omap_hwmod_addr_space omap3xxx_gpio1_addrs[] = {
+ {
+ .pa_start = 0x4831,
+ .pa_end = 0x483101ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__gpio1 = {
+ .master =&omap3xxx_l4_wkup_hwmod,
+ .slave =&omap3xxx_gpio1_hwmod,
+ .addr = omap3xxx_gpio1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio2 */
+static struct omap_hwmod_addr_space omap3xxx_gpio2_addrs[] = {
+ {
+ .pa_start = 0x4905,
+ .pa_end = 0x490501ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio2 = {
+ .master =&omap3xxx_l4_per_hwmod,
+ .slave =&omap3xxx_gpio2_hwmod,
+ .addr = omap3xxx_gpio2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio3 */
+static struct omap_hwmod_addr_space omap3xxx_gpio3_addrs[] = {
+ {
+ .pa_start = 0x49052000,
+ .pa_end = 0x490521ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio3 = {
+ .master =&omap3xxx_l4_per_hwmod,
+ .slave =&omap3xxx_gpio3_hwmod,
+ .addr = omap3xxx_gpio3_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio3_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio4 */
+static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
+ {
+ .pa_start = 0x49054000,
+ .pa_end = 0x490541ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio4 = {
+ .master =&omap3xxx_l4_per_hwmod,
+ .slave =&omap3xxx_gpio4_hwmod,
+ .addr = omap3xxx_gpio4_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio4_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio5 */
+static struct omap_hwmod_addr_space omap3xxx_gpio5_addrs[] = {
+ {
+ .pa_start = 0x49056000,
+ .pa_end = 0x490561ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio5 = {
+ .master =&omap3xxx_l4_per_hwmod,
+ .slave =&omap3xxx_gpio5_hwmod,
+ .addr = omap3xxx_gpio5_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio5_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per -> gpio6 */
+static struct omap_hwmod_addr_space omap3xxx_gpio6_addrs[] = {
+ {
+ .pa_start = 0x49058000,
+ .pa_end = 0x490581ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio6 = {
+ .master =&omap3xxx_l4_per_hwmod,
+ .slave =&omap3xxx_gpio6_hwmod,
+ .addr = omap3xxx_gpio6_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio6_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/*
+ * 'gpio' class
+ * general purpose io module
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_gpio_sysc
Re: [PATCH v7 09/11] OMAP2+: GPIO: device registration
On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:
Use omap_device_build() API to do platform_device_register of
GPIO devices. For OMAP2+ chips, the device specific data defined
in the centralized hwmod database will be used.
gpio_init needs to be done before machine_init functions access
gpio APIs. Hence gpio_init is made as a postcore_initcall.
Signed-off-by: Charulatha V
Reviewed-by: Basak, Partha
Acked-by: Benoit Cousson
---
arch/arm/mach-omap2/gpio.c | 103
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio.c
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
new file mode 100644
index 000..e5c9b6a
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
@@ -0,0 +1,104 @@
+/*
+ * OMAP2+ specific gpio initialization
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author:
+ * Charulatha V
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static struct omap_device_pm_latency omap_gpio_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
+{
+ struct omap_device *od;
+ struct omap_gpio_platform_data *pdata;
+ struct omap_gpio_dev_attr *dev_attr;
+ char *name = "omap_gpio";
+ int id;
+
+ /*
+* extract the device id from name field available in the
+* hwmod database and use the same for constructing ids for
+* gpio devices.
+* CAUTION: Make sure the name in the hwmod database does
+* not change. If changed, make corresponding change here
+* or make use of static variable mechanism to handle this.
+*/
+ sscanf(oh->name, "gpio%d",&id);
+
+ pdata = kzalloc(sizeof(struct omap_gpio_platform_data), GFP_KERNEL);
+ if (!pdata) {
+ pr_err("gpio%d: Memory allocation failed\n", id);
+ return -ENOMEM;
+ }
+
+ dev_attr = (struct omap_gpio_dev_attr *)oh->dev_attr;
+ pdata->bank_width = dev_attr->bank_width;
+ pdata->dbck_flag = dev_attr->dbck_flag;
+ pdata->virtual_irq_start = IH_GPIO_BASE + 32 * (id - 1);
+
+ switch (oh->class->rev) {
+ case 0:
+ case 1:
+ pdata->bank_type = METHOD_GPIO_24XX;
+ break;
+ case 2:
+ pdata->bank_type = METHOD_GPIO_44XX;
+ break;
+ default:
+ WARN(1, "Invalid gpio bank_type\n");
+ kfree(pdata);
+ return -EINVAL;
+ }
+
+ od = omap_device_build(name, id - 1, oh, pdata,
+ sizeof(*pdata), omap_gpio_latency,
+ ARRAY_SIZE(omap_gpio_latency),
+ false);
+ kfree(pdata);
+
+ if (IS_ERR(od)) {
+ WARN(1, "Cant build omap_device for %s:%s.\n",
+ name, oh->name);
+ return PTR_ERR(od);
+ }
+
+ gpio_bank_count++;
+ return 0;
+}
+
+/*
+ * gpio_init needs to be done before
+ * machine_init functions access gpio APIs.
+ * Hence gpio_init is a postcore_initcall.
+ */
+static int __init omap2_gpio_init(void)
+{
+ return omap_hwmod_for_each_by_class("gpio", omap2_gpio_dev_init,
+ NULL);
+}
+postcore_initcall(omap2_gpio_init);
--
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 v7 05/11] OMAP2420: hwmod data: Add GPIO
On 11/25/2010 5:36 AM, Varadarajan, Charulatha wrote: Benoit, On Thu, Nov 25, 2010 at 03:43, Cousson, Benoit wrote: On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote: Add GPIO hwmod data for OMAP2420 Signed-off-by: Charulatha V [...] diff --git a/arch/arm/plat-omap/include/plat/gpio.h b/arch/arm/plat-omap/include/plat/gpio.h That change should not necessarily be there, it is not directly related to the subject. Maybe that should be in an extra patch just before that one. I merged these two patches because of a comment to introduce new variables/structures only in the patch where they are used. Since "omap_gpio_dev_attr" is being used by hwmod DB I merged these two patches. Do you think that hwmod DB patches should not be merged with other patches? Not necessarily, maybe you can just update the changelog and the subject to indicate that you add a new structure as well in this patch. Benoit -- 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 v7 05/11] OMAP2420: hwmod data: Add GPIO
On 11/25/2010 5:36 AM, Varadarajan, Charulatha wrote:
Benoit,
On Thu, Nov 25, 2010 at 03:43, Cousson, Benoit wrote:
On 11/23/2010 3:56 PM, Varadarajan, Charulatha wrote:
Add GPIO hwmod data for OMAP2420
Signed-off-by: Charulatha V
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 229
arch/arm/plat-omap/include/plat/gpio.h |5 +
2 files changed, 234 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..c951061 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
Do you still need that header file?
Yes, for the gpio_dev_attr
I'm still confused, gpio_dev_attr just contains an int and a bool:
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .bank_width = 32,
+ .dbck_flag = false,
+};
Benoit
#include "omap_hwmod_common_data.h"
@@ -38,6 +39,10 @@ static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_gpio1_hwmod;
+static struct omap_hwmod omap2420_gpio2_hwmod;
+static struct omap_hwmod omap2420_gpio3_hwmod;
+static struct omap_hwmod omap2420_gpio4_hwmod;
/* L3 ->L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -557,6 +562,224 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags = HWMOD_16BIT_REG,
};
+/* l4_wkup ->gpio1 */
+static struct omap_hwmod_addr_space omap2420_gpio1_addr_space[] = {
+ {
+ .pa_start = 0x48018000,
+ .pa_end = 0x480181ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio1 = {
+ .master =&omap2420_l4_wkup_hwmod,
+ .slave =&omap2420_gpio1_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2420_gpio1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup ->gpio2 */
+static struct omap_hwmod_addr_space omap2420_gpio2_addr_space[] = {
+ {
+ .pa_start = 0x4801a000,
+ .pa_end = 0x4801a1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio2 = {
+ .master =&omap2420_l4_wkup_hwmod,
+ .slave =&omap2420_gpio2_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2420_gpio2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup ->gpio3 */
+static struct omap_hwmod_addr_space omap2420_gpio3_addr_space[] = {
+ {
+ .pa_start = 0x4801c000,
+ .pa_end = 0x4801c1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio3 = {
+ .master =&omap2420_l4_wkup_hwmod,
+ .slave =&omap2420_gpio3_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2420_gpio3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup ->gpio4 */
+static struct omap_hwmod_addr_space omap2420_gpio4_addr_space[] = {
+ {
+ .pa_start = 0x4801e000,
+ .pa_end = 0x4801e1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio4 = {
+ .master =&omap2420_l4_wkup_hwmod,
+ .slave =&omap2420_gpio4_hwmod,
+ .clk= "gpios_ick",
+ .addr = omap2420_gpio4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* gpio dev_attr */
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .bank_width = 32,
+ .dbck_flag = false,
+};
+
<>
};
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
That change should not necessarily be there, it is not directly related to
the subject.
Maybe that should be in an extra patch just before that one.
I merged these two patches because of a comment to introduce
new variables/structures only in the patch where they are used.
Since "omap_gpio_dev_attr" is being used by hwmod DB I merged
these two patches. Do you think that hwmod DB patches should not
be merg
Re: [PATCH 6/7] [RFC] OMAP: hwmod: SYSCONFIG register modification for MCBSP
Hi Kishon,
Sorry, for the delay.
On 11/22/2010 4:59 PM, ABRAHAM, KISHON VIJAY wrote:
Resending the mail in plain text format..
On Mon, Nov 22, 2010 at 9:20 PM, ABRAHAM, KISHON VIJAY wrote:
On Mon, Oct 11, 2010 at 11:48 AM, ABRAHAM, KISHON VIJAY wrote:
On Friday 08 October 2010 01:12 PM, Cousson, Benoit wrote:
Hi Kishon,
On 10/5/2010 6:37 PM, ABRAHAM, KISHON VIJAY wrote:
MCBSP 2 and 3 in OMAP3 has sidetone feature which requires
autoidle to be disabled before starting the sidetone. Also SYSCONFIG
register has to be set with smart idle or no idle depending on the
dma op mode (threshold or element sync). For doing these operations
dynamically at runtime, hwmod API'S are used to modify SYSCONFIG
register
directly.
OK, it looks like we don't have the choice... But for the
implementation, please discussed with Manju on that, He is doing the
similar thing for the smartstandby issue on SDMA.
OK.
Looks like we have a problem when we write an API similar to the one
written
by Manju (omap_hwmod_set_master_standbymode()) [1]. In the case of McBSP,
I have to modify omap_hwmod_set_slave_idlemode() (which is already
existing),
to include something like
+if (sf& SYSC_HAS_SIDLEMODE) {
+if (idlemode)
+idlemode = HWMOD_IDLEMODE_NO;
+else
+idlemode = (oh->flags&
HWMOD_SWSUP_SIDLE) ?
+HWMOD_IDLEMODE_NO :
HWMOD_IDLEMODE_SMART;
+}
How to you enable HWMOD_IDLEMODE_FORCE mode in that case?
Then an API like omap_device_require_no_idle() and
omap_device_release_no_idle()
would be written similar to omap_device_require_no_mstandby and
omap_device_release_no_mstandby() (see [1]) that calls
omap_hwmod_set_slave_idlemode() with true/false. Passing true to
omap_hwmod_set_slave_idlemode() will write SIDLE bits with
HWMOD_IDLEMODE_NO and false to it will write
HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART depending on
HWMOD_SWSUP_SIDLE to SIDLE bits.
This works fine for McBSP since only two modes come to play here
(HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART).
But omap_hwmod_set_slave_idlemode() API is used by UART
(serial.c Please refer [2]) which writes SIDLE bits to
HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART/ and
HWMOD_IDLEMODE_FORCE.
That code should not be there. It was a temporary hacks that should be
replaced eventually with a clean omap_device API like the one you are
currently implementing.
There are a bunch of direct access to omap_hwmod struct that need to be
removed as well.
Modifying omap_hwmod_set_slave_idlemode() will require
1) serial.c to be modified to call functions like
'omap_device_require_no_idle(),
omap_device_release_no_idle()' and
'omap_device_require_force_idle() and
omap_device_release_force_idle()' instead of
omap_hwmod_set_slave_idlemode() which is currently present.
Yep, you're right.
There are 2 problems associated with it
1) The first problem is having a single API like
omap_hwmod_set_slave_idlemode() to
set two different values like HWMOD_IDLEMODE_NO or
HWMOD_IDLEMODE_FORCE (intended to be called by
omap_device_require_no_idle()
and omap_device_require_force_idle() respectively). According to the
new design
omap_hwmod_set_slave_idlemode() is intended to take only true/false
as
arguments.
2) The second problem is having the release API's
(omap_device_release_no_idle() and
omap_device_release_force_idle()) to restore the SYSCONFIG to the
previous state.
Remember, this was not problem for McBSP since only two modes were
needed.
And what about 3 APIs?
omap_device_force_idle
omap_device_no_idle
omap_device_smart_idle
It is probably much more appropriate than a require / release in that case?
Regards,
Benoit
--
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 6/7] [RFC] OMAP: hwmod: SYSCONFIG register modification for MCBSP
+ Govindraj
Hi Partha,
On 12/1/2010 8:14 AM, Basak, Partha wrote:
From: Cousson, Benoit
Sent: Tuesday, November 30, 2010 9:33 PM
Hi Kishon,
Sorry, for the delay.
On 11/22/2010 4:59 PM, ABRAHAM, KISHON VIJAY wrote:
Resending the mail in plain text format..
On Mon, Nov 22, 2010 at 9:20 PM, ABRAHAM, KISHON VIJAY
wrote:
On Mon, Oct 11, 2010 at 11:48 AM, ABRAHAM, KISHON
VIJAY wrote:
On Friday 08 October 2010 01:12 PM, Cousson, Benoit wrote:
Hi Kishon,
On 10/5/2010 6:37 PM, ABRAHAM, KISHON VIJAY wrote:
MCBSP 2 and 3 in OMAP3 has sidetone feature which requires
autoidle to be disabled before starting the sidetone. Also
SYSCONFIG
register has to be set with smart idle or no idle depending on
the
dma op mode (threshold or element sync). For doing these
operations
dynamically at runtime, hwmod API'S are used to modify SYSCONFIG
register
directly.
OK, it looks like we don't have the choice... But for the
implementation, please discussed with Manju on that, He is doing
the
similar thing for the smartstandby issue on SDMA.
OK.
Looks like we have a problem when we write an API similar to
the one written
by Manju (omap_hwmod_set_master_standbymode()) [1]. In the
case of McBSP,
I have to modify omap_hwmod_set_slave_idlemode() (which is
already existing),
to include something like
+if (sf& SYSC_HAS_SIDLEMODE) {
+if (idlemode)
+idlemode = HWMOD_IDLEMODE_NO;
+else
+idlemode = (oh->flags&
HWMOD_SWSUP_SIDLE) ?
+HWMOD_IDLEMODE_NO :
HWMOD_IDLEMODE_SMART;
+}
How to you enable HWMOD_IDLEMODE_FORCE mode in that case?
Then an API like omap_device_require_no_idle() and
omap_device_release_no_idle()
would be written similar to omap_device_require_no_mstandby
and
omap_device_release_no_mstandby() (see [1]) that calls
omap_hwmod_set_slave_idlemode() with true/false. Passing true
to
omap_hwmod_set_slave_idlemode() will write SIDLE bits with
HWMOD_IDLEMODE_NO and false to it will write
HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART depending on
HWMOD_SWSUP_SIDLE to SIDLE bits.
This works fine for McBSP since only two modes come to play
here
(HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART).
But omap_hwmod_set_slave_idlemode() API is used by UART
(serial.c Please refer [2]) which writes SIDLE bits to
HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART/ and
HWMOD_IDLEMODE_FORCE.
That code should not be there. It was a temporary hacks that should be
replaced eventually with a clean omap_device API like the one you are
currently implementing.
There are a bunch of direct access to omap_hwmod struct that need to be
removed as well.
Modifying omap_hwmod_set_slave_idlemode() will require
1) serial.c to be modified to call functions like
'omap_device_require_no_idle(),
omap_device_release_no_idle()' and
'omap_device_require_force_idle() and
omap_device_release_force_idle()' instead of
omap_hwmod_set_slave_idlemode() which is currently
present.
Yep, you're right.
There are 2 problems associated with it
1) The first problem is having a single API like
omap_hwmod_set_slave_idlemode() to
set two different values like HWMOD_IDLEMODE_NO or
HWMOD_IDLEMODE_FORCE (intended to be called by
omap_device_require_no_idle()
and omap_device_require_force_idle() respectively).
According to the new design
omap_hwmod_set_slave_idlemode() is intended to take only
true/false as
arguments.
2) The second problem is having the release API's
(omap_device_release_no_idle() and
omap_device_release_force_idle()) to restore the
SYSCONFIG to the previous state.
Remember, this was not problem for McBSP since only two
modes were needed.
And what about 3 APIs?
omap_device_force_idle
omap_device_no_idle
omap_device_smart_idle
Want to reiterate Paul Walmsley's comments on Manju's DMA email dated 11/11/2010
2. Rather than just using a single omap_device_mstandby() function call,
I'd rather see something like omap_device_require_no_standby() and
omap_device_release_no_standby(). omap_device_require_no_standby() would
force the initiator port into no-standby.
omap_device_release_no_standby() would return the initiator port
MSTANDBYMODE to whatever the state should be (this depends on whether
HWMOD_SWSUP_MSTDBY is set). I'd rather not have the drivers manage the
contents of the MSTANDBYMODE bits directly. Then you should be able to
drop _get_master_standbymode() and omap_hwmod_g
Re: [PATCH v6] OMAP2+: PM: omap device: API's for handling mstandby mode
Hi Adrian and Manju, On 12/2/2010 8:58 AM, Adrian Hunter wrote: On 02/12/10 08:12, ext G, Manjunath Kondaiah wrote: * Adrian Hunter [2010-12-01 22:16:44 +0200]: On 01/12/10 20:47, ext G, Manjunath Kondaiah wrote: [...] Also, there is a mutex but don't these functions get called sometimes in interrupt context? I feel we should leave this to caller of these API's. The caller should make sure that, he disables interrupts if it is used in interrupt context. How does that help? It seems to me that a mutex cannot be used for this. That mutex is the one that was protecting the hwmod list and should not be used, we do have a per-hwmod mutex. But it will disappear soon, Paul already submitted a patch to replace it by a spinlock (8297db801c424f95ef3ebfbd28e62b94798d35dd) Please note that the goal of this API is to not be used at all :-) It is there because of dirty HW bugs in several IPs. So I'm fine to limit its usability and to prevent its usage everywhere. Thanks to the spinlock it will anyway no longer be an issue. Thanks, Benoit -- 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 v7] OMAP2+: PM: omap device: API's for handling mstandby mode
On 12/2/2010 2:59 PM, G, Manjunath Kondaiah wrote: Certain errata in OMAP2+ processors will require forcing master standby to "no standby" mode before completing on going operation. Without this, the results will be unpredictable. Since current implementation of PM run time framework does not support changing sysconfig settings during middle of the on going operation, these API's will support the same. One API will force the device's sysconfig mstandby mode settings to "no standby" and other API will release "no standby" mode and sets it to "smart standby" or "no standby? depending on HWMOD_SWSUP_MSTANDBY value. The hwmod API "omap_hwmod_set_master_standbymode" will use no_stdby_cnt(introduced in omap_hwmod structure) for controlling access to sysconfig register settings in case of overlapping request/release API's are called. It also disables interrupts during syconfig register access. These API's should be used by device drivers only incase of erratum applicable to their modules if there is no other methods to resolve. These API's are required for multiple DMA errata which require putting DMA controller in no mstandby mode before stopping dma. The applicable errata: 1. Erratum ID: i557(Applicable for omap36xx all ES versions) The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared through config port while in Standby. 2. Erratum ID: i541 sDMA FIFO draining does not finish. Applicable to all omap2+ except omap4. 3. Erratum ID:i88 The sDMA to be put in no mstandby mode before disabling the channel after completing the data transfer operation. Applicable only for OMAP3430 ES1.0 Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in omap_hwmod.h Signed-off-by: G, Manjunath Kondaiah Cc: Kevin Hilman Cc: Paul Walmsley Cc: linux-arm-ker...@lists.infradead.org You have to CC lakml during send-email, but it should not be in the changelog. On the other hand, it is a good practice to add all the authors of the file you change in CC. --- v3: Review comments incorporated for: https://patchwork.kernel.org/patch/282212/ v4: added mutex changes https://patchwork.kernel.org/patch/338611/ v5: typo fixes for errata and erratum https://patchwork.kernel.org/patch/352481/ v6: fixed oh increment bug and also mutex(missing in v5) https://patchwork.kernel.org/patch/372231/ v7: replaced mutex lock with spin lock. Added use count for controlling access to sysconfig registers in case if overlapping request/release API's are used. I'm not sure it should be done here. I'd rather keep that code in the DMA, since this is the only user of that feature. These hwmod APIs are rather low level and should never be used except for workaround. So I'd prefer keeping this API simple and not sexy at all in order to prevent people to abuse it. Regards, Benoit -- 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 v7] OMAP2+: PM: omap device: API's for handling mstandby mode
On 12/3/2010 10:47 AM, G, Manjunath Kondaiah wrote: * Cousson, Benoit [2010-12-03 09:38:35 +0100]: [...] v7: replaced mutex lock with spin lock. Added use count for controlling access to sysconfig registers in case if overlapping request/release API's are used. I'm not sure it should be done here. I'd rather keep that code in the DMA, since this is the only user of that feature. Are you referring to spin lock or usage count? The spinlock is needed, I was referring to the usage count. That being said, the API proposed by Paul (request/release ) sound like a get/put, so maybe he had that kind of usage in mind. I'm still not convince it should be done at hwmod API level. Paul, Any thoughts on that? Regards, Benoit -- 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] Correct definition of register of OMAP4_RM_RSTST and OMAP4_RM_RSTTIME
Hi Paul, On 12/7/2010 5:04 PM, Paul Walmsley wrote: Hello, On Tue, 7 Dec 2010, MING ZHOU wrote: Since we need to reconfigure Reset time for OMAP4, we found the OMAP4 register definition for reset time is wrong according to spec of OMAP4. And we verified this by reading default value of register. We found the offset definition of Reset time and Reset Test register should be switched. After correcting this bug, we verified by changing the value of reset time register, the pulse generated for reset is also changed as expected on scope. Thanks, will queue this for 2.6.38 since it looks like there are no in-tree users in 2.6.37. These defines are not needed anymore, it is legacy stuff done before we generated the whole prm44xx.h. Here are the entries in the prm44xx.h, line 574. /* PRM.DEVICE_PRM register offsets */ #define OMAP4_PRM_RSTCTRL_OFFSET0x #define OMAP4_PRM_RSTST_OFFSET 0x0004 #define OMAP4_PRM_RSTTIME_OFFSET0x0008 We'd better get rid of these old entries in prm.h Regards, Benoit -- 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 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
On 12/7/2010 2:25 AM, Paul Walmsley wrote: [...] + * + * XXX This file needs to be updated to align on one of "OMAP4", "OMAP44XX", + * or "OMAP4430". Yep, I was thinking to change that as well. My first thought was OMAP4 to get a shorter name, but when we will introduce OMAP4440, we might have some new entries, that will looks ugly close to OMAP4. So at the end I will prefer OMAP44XX for the moment and we might renamed to OMAP4430 or OMAP4440 for the entries that will diverge. Do you want to change that for 2.6.38? It will require some sync with the various users of these defines, but that should be doable. Regards, Benoit -- 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 v8 01/11] OMAP: GPIO: prepare for platform driver
Salut Kevin,
On 12/9/2010 8:18 PM, Kevin Hilman wrote:
Hi Charu,
"Varadarajan, Charulatha" writes:
Prepare for implementing GPIO as a platform driver.
Modifies omap_gpio_init() to make use of omap_gpio_chip_init()
and omap_gpio_mod_init(). omap_gpio_mod_init() does the module init
by clearing the status register and initializing the GPIO control register.
omap_gpio_chip_init() initializes the chip request, free, get, set and
other function pointers and sets the gpio irq handler.
This is only to reorganize the code so that the "omap gpio platform driver
implementation patch" looks cleaner and better to review.
Signed-off-by: Charulatha V
I just noticed while testing on 36xx/Zoom3 that GPIO wakeups are no
longer working after this series.
The problem seems to be that for OMAP2+, this series removed manual
SYSCONFIG register setting in favor of using omap_hwmod (which is good),
however some of the SYSCONFIG values, specifically, in the current code,
the ENAWAKEUP bit was set in each bank, but this is no longer the
default with omap_hwmod.
That part is strange, because Rajendra did a patch to enable the wakeup
bit during _omap_hwmod_enable as soon as the idlemode is set to smartidle.
/* If slave port is in SMARTIDLE, also enable wakeup */
if ((sf & SYSC_HAS_SIDLEMODE) && (s_idlemode == HWMOD_IDLEMODE_SMART))
_enable_wakeup(oh);
The _disable_wakeup is never called, so in theory once it is set, it
should remain enabled.
Does that mean that this the GPIO is not in smartidle anymore in your case?
Regards,
Benoit
-#ifdef CONFIG_ARCH_OMAP2PLUS
- if ((bank->method == METHOD_GPIO_24XX) ||
- (bank->method == METHOD_GPIO_44XX)) {
- static const u32 non_wakeup_gpios[] = {
- 0xe203ffc0, 0x08700040
- };
-
- if (cpu_is_omap44xx()) {
- __raw_writel(0x, bank->base +
- OMAP4_GPIO_IRQSTATUSCLR0);
- __raw_writew(0x0015, bank->base +
- OMAP4_GPIO_SYSCONFIG);
- __raw_writel(0x, bank->base +
-OMAP4_GPIO_DEBOUNCENABLE);
- /*
-* Initialize interface clock ungated,
-* module enabled
-*/
- __raw_writel(0, bank->base + OMAP4_GPIO_CTRL);
- } else {
- __raw_writel(0x, bank->base +
- OMAP24XX_GPIO_IRQENABLE1);
- __raw_writel(0x, bank->base +
- OMAP24XX_GPIO_IRQSTATUS1);
- __raw_writew(0x0015, bank->base +
- OMAP24XX_GPIO_SYSCONFIG);
Here bit 2 (ENAWAKEUP) is set, and is not reconfigured anywhere in this
series. Same for OMAP4 above.
Here's a quick fix to preserve current functionality (will post
w/changelog shortly), but it shows that GPIO wakeups were not fully
tested with this series. In the future, along with reporting what
platforms it was testing on, it would be very helpful to include a
summary of how the series was tested.
Thanks,
Kevin
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 413de18..05a123f 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -75,6 +75,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
return -EINVAL;
}
+ omap_hwmod_enable_wakeup(oh);
od = omap_device_build(name, id - 1, oh, pdata,
sizeof(*pdata), omap_gpio_latency,
ARRAY_SIZE(omap_gpio_latency),
--
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 v8 01/11] OMAP: GPIO: prepare for platform driver
On 12/9/2010 11:19 PM, Kevin Hilman wrote:
"Cousson, Benoit" writes:
Salut Kevin,
On 12/9/2010 8:18 PM, Kevin Hilman wrote:
Hi Charu,
"Varadarajan, Charulatha" writes:
Prepare for implementing GPIO as a platform driver.
Modifies omap_gpio_init() to make use of omap_gpio_chip_init()
and omap_gpio_mod_init(). omap_gpio_mod_init() does the module init
by clearing the status register and initializing the GPIO control register.
omap_gpio_chip_init() initializes the chip request, free, get, set and
other function pointers and sets the gpio irq handler.
This is only to reorganize the code so that the "omap gpio platform driver
implementation patch" looks cleaner and better to review.
Signed-off-by: Charulatha V
I just noticed while testing on 36xx/Zoom3 that GPIO wakeups are no
longer working after this series.
The problem seems to be that for OMAP2+, this series removed manual
SYSCONFIG register setting in favor of using omap_hwmod (which is good),
however some of the SYSCONFIG values, specifically, in the current code,
the ENAWAKEUP bit was set in each bank, but this is no longer the
default with omap_hwmod.
That part is strange, because Rajendra did a patch to enable the
wakeup bit during _omap_hwmod_enable as soon as the idlemode is set to
smartidle.
/* If slave port is in SMARTIDLE, also enable wakeup */
if ((sf& SYSC_HAS_SIDLEMODE)&& (s_idlemode == HWMOD_IDLEMODE_SMART))
_enable_wakeup(oh);
The _disable_wakeup is never called, so in theory once it is set, it
should remain enabled.
Does that mean that this the GPIO is not in smartidle anymore in your case?
Looks like a bug in the patch that added automatic wakeup enables.
Basically, wakeups are enabled, but are promptly disabled if
SYSC_HAS_AUTOIDLE. Here's the code:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh->flags& HWMOD_SET_DEFAULT_CLOCKACT)&&
(sf& SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact,&v);
_write_sysconfig(v, oh);
OK, so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf& SYSC_HAS_SIDLEMODE)&& !(oh->flags& HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here we enabled them directly in SYSC (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf& SYSC_HAS_AUTOIDLE) {
idlemode = (oh->flags& HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode,&v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled.
A quick patch (below) shows that if I update 'v' after enabling wakeups,
the problem is fixed.
I'll cook up a cleaner patch for this, but I think the solution is
probably to change _enable_wakeup() to take the 'v' argument and modify
it instead of directly writing SYSCONFIG. That will make it more like
all the other helper functions.
Funny, I did a patch that does that yesterday just because the wakeup
enable on some OMAP4 IPs does require changing the idlemode as well.
So I added a new _set_enawakeup API to use the same programming model.
+static int _set_enawakeup(struct omap_hwmod *oh, u8 enawakeup, u32 *v)
{
- u32 v, wakeup_mask;
+ u32 wakeup_mask;
+ u8 wakeup_shift;
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP))
@@ -401,10 +402,44 @@ static int _enable_wakeup(struct omap_hwmod *oh)
return -EINVAL;
}
- wakeup_mask = (0x1 << oh->class->sysc->sysc_fields->enwkup_shift);
+ wakeup_shift = oh->class->sysc->sysc_fields->enwkup_shift;
+ wakeup_mask = 0x1 << wakeup_shift;
+
+ *v &= ~wakeup_mask;
+ *v |= enawakeup << wakeup_shift;
+
+ return 0;
+}
+
That does not solve the issue I was trying to fix with the McPDM driver,
that's why I didn't send it yet, but that might be enough for the GPIO.
Regards,
Benoit
Kevin
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 12856eb..adcb1fc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -791,8 +791,10 @@ static void _enable_sysc(struct omap_hwmod *oh)
_write_sysconfig(v, oh);
/* If slave is in SMARTIDLE, also enable wakeup */
- if ((sf& SYSC_HAS_SIDLEMODE)&& !(oh->flags&
Re: [PATCH 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
Salut Paul, On 12/8/2010 7:47 AM, Paul Walmsley wrote: Salut Benoît, On Tue, 7 Dec 2010, Cousson, Benoit wrote: Salut Paul, On 12/7/2010 2:25 AM, Paul Walmsley wrote: Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files so they match their underlying OMAP hardware modules. Add clockdomain offset information. Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the SCRM, scrm44xx.h. SCRM register offsets still need to be added; TI should do this. And we did it :-) Even better :-) I sent it last week along with clock data series: https://patchwork.kernel.org/patch/373751/ OK, I've just realized that it was a little bit hidden in the clock data patch, and maybe we should have been sent two patches. Sorry for that. Do you want to take it in that series, or should I re-sent the clock data one? I guess it's better done in the clock series; that should avoid a branch dependency between the PRCM patchsets and the clock patch sets. One thing that would be nice on the scrm44xx.h file is to keep the _OFFSET macros. It would be nice in the long run to get rid of the absolute addressing macros in case someone decides to shuffle around the IP block addresses again... can you update your clock series with that change? OK, this is done. I've just posted it. Regards, Benoit -- 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/5] OMAP4: hwmod data fixes and update
On 12/10/2010 1:36 AM, Kevin Hilman wrote: Benoit Cousson writes: Hi Paul, Here is a small set of OMAP4 hwmod data updates. Re-order properly the data that were a little bit shuffled during the previous merge window. Add the new reset flags introduced in 2.6.37 and that were not used in the hwmod data. The OMAP2 and OMAP3 fixes should come soon. Fix some missing field in the GPIO OMAP4 hwmod data that I missed during the review. IVA and DSP are added just to allow the processors device creation at boot time and avoid the warnings. Thanks to Charu for testing the GPIO / WD_TIMER changes. Thanks to Govindraj for testing the UART changes. The series is based on lo/for-next (v2.6.37-rc5-66-ga2814df) and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/hwmod_data Please note that there is a slight dependency with the following patch due to the name change of the iva fclk: OMAP4: clock data: Add missing DPLL x2 clock node https://patchwork.kernel.org/patch/396612/ Tested on sdp4430 + ES2.0/ES2.1. As with the other series, I tried to pull this into my pm-core for testing with all the other PM stuff we have baking for 2.6.38. Unfortunately, this series has conflicts with Paul's pwrdm_prcm_[ab]_2.6.38 branches. Could you rebase this on Paul's pwrdm_prcm_b_2.6.38 branch? OK, I will rebase all my series on top of that one. Regards, Benoit -- 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 1/2] I2C: i2c-omap: Change device name: i2c_omap -> omap_i2c
On 12/9/2010 11:18 PM, aaro.koski...@nokia.com wrote: Hi, Kevin Hilman [khil...@deeprootsystems.com]: Ben Dooks writes: Renaming stuff like this is going to have an impact on the userspace as anyone looking through /sys's driver heirarchy is going to miss the old name... It all depends if you really want to go ahead with this... Yes, we are aware of the userspace impact, but this name change makes all devices on OMAP have consistent names and actually improves the ability to have userspace tools have consistent naming as well. So there are no imporant users, or if there is, they are prepared for this change? Well, I do not know any user of that today. Do you have some in mind? Benoit -- 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/5] OMAP4: hwmod data fixes and update
On 12/10/2010 1:36 AM, Kevin Hilman wrote: Benoit Cousson writes: [...] As with the other series, I tried to pull this into my pm-core for testing with all the other PM stuff we have baking for 2.6.38. Unfortunately, this series has conflicts with Paul's pwrdm_prcm_[ab]_2.6.38 branches. Could you rebase this on Paul's pwrdm_prcm_b_2.6.38 branch? - for_2.6.38/clock is now rebased on top of pwrdm_prcm_b_2.6.38 - for_2.6.38/hwmod_data is rebased on top of for_2.6.38/clock Regards, Benoit -- 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
