RE: opp layer query apis (was RE: omap3 pm: dependency between opp layer and cpufreq)
> -Original Message- > From: Gopinath, Thara > Sent: Tuesday, June 08, 2010 7:29 AM > >>-Original Message- > >>From: Menon, Nishanth > >>Sent: Tuesday, June 08, 2010 9:45 AM > >>> -Original Message- > >>> From: Gopinath, Thara > >>> Sent: Friday, June 04, 2010 3:35 PM > >> > >>> Slightly off the topic but considering we are discussing opp layer > here, I > >>> do not find API's > >>> that take the OPP type (OPP_MPU or OPP_L3) and voltage/frequency as > >>> parameters and returns back the associated frequency/voltage. I do not > >>> want to get the opp table entry every time I do this. Any chance of > >>> introducing this in the framework? I could send a patch for the same. > >>Am curios on the usage that combination of > >>opp_find_freq_exact > >>opp_find_freq_ceil > >>opp_find_freq_floor > >> > >>and opp_get_freq, opp_get_voltage is unable to cater to? Would be > interested > >>in seeing a patch for the same. > > Ok here is the need. Let us suppose I know the opp type (OPP_MPU, > OPP_L3 ...) etc and the frequency and I need to get the voltage. Today I > have to do the following > struct omap_opp *opp = > opp_find_freq_exact/opp_find_freq_floor/opp_find_freq_ceil(type, freq); > u32 volt = opp_get_voltage(opp). > > As a user of opp layer it would be much simpler for me to do > opp_get_volt(type, freq, exact/ceil/floor) as I really do not care > about the opp struct at all. The intent was we are not always sure what exact behavior the caller desires. Option1: (currently implemented) Opp_get_volt(opp_find_freq_exact/opp_find_freq_floor/opp_find_freq_ceil(type, freq) Option2: Opp_get_volt_freq_exact(freq); Opp_get_volt_freq_ceil(freq); Opp_get_volt_freq_floor(freq); The intent is if we don't really care about the opp structure, choose the nature of the search and plug it straight to get_volt. > > Now let us suppose I have the opp type and the voltage I need to put the > vdd associated with it to. Today there is no way to retrieve the frequency > from the opp layer. Why would we want to do this? > > Again as a user of the opp layer I would like to have an API > u32 freq = opp_get_freq(type, volt) A voltage could be linked to 1 or more frequencies. OPP layer functions based on some sort of unique identifier. We aligned earlier this year(jan if I recollect), that frequency is the common unique identifier, is there a Reason that this is not good enough? 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: opp layer query apis (was RE: omap3 pm: dependency between opp layer and cpufreq)
>>-Original Message- >>From: Menon, Nishanth >>Sent: Tuesday, June 08, 2010 9:45 AM >>To: Gopinath, Thara; Kevin Hilman; Nishanth Menon >>Cc: Premi, Sanjeev; Koen Kooi; linux-omap@vger.kernel.org; >>eduardo.valen...@nokia.com >>Subject: opp layer query apis (was RE: omap3 pm: dependency between opp layer >>and cpufreq) >> >>> -Original Message- >>> From: Gopinath, Thara >>> Sent: Friday, June 04, 2010 3:35 PM >>> To: Kevin Hilman; Nishanth Menon >>> Cc: Premi, Sanjeev; Menon, Nishanth; Koen Kooi; linux- >> >> >>> Slightly off the topic but considering we are discussing opp layer here, I >>> do not find API's >>> that take the OPP type (OPP_MPU or OPP_L3) and voltage/frequency as >>> parameters and returns back the associated frequency/voltage. I do not >>> want to get the opp table entry every time I do this. Any chance of >>> introducing this in the framework? I could send a patch for the same. >>Am curios on the usage that combination of >>opp_find_freq_exact >>opp_find_freq_ceil >>opp_find_freq_floor >> >>and opp_get_freq, opp_get_voltage is unable to cater to? Would be interested >>in seeing a patch for the same. Ok here is the need. Let us suppose I know the opp type (OPP_MPU, OPP_L3 ...) etc and the frequency and I need to get the voltage. Today I have to do the following struct omap_opp *opp = opp_find_freq_exact/opp_find_freq_floor/opp_find_freq_ceil(type, freq); u32 volt = opp_get_voltage(opp). As a user of opp layer it would be much simpler for me to do opp_get_volt(type, freq, exact/ceil/floor) as I really do not care about the opp struct at all. Now let us suppose I have the opp type and the voltage I need to put the vdd associated with it to. Today there is no way to retrieve the frequency from the opp layer. Again as a user of the opp layer I would like to have an API u32 freq = opp_get_freq(type, volt) Regards Thara >> >>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
opp layer query apis (was RE: omap3 pm: dependency between opp layer and cpufreq)
> -Original Message- > From: Gopinath, Thara > Sent: Friday, June 04, 2010 3:35 PM > To: Kevin Hilman; Nishanth Menon > Cc: Premi, Sanjeev; Menon, Nishanth; Koen Kooi; linux- > Slightly off the topic but considering we are discussing opp layer here, I > do not find API's > that take the OPP type (OPP_MPU or OPP_L3) and voltage/frequency as > parameters and returns back the associated frequency/voltage. I do not > want to get the opp table entry every time I do this. Any chance of > introducing this in the framework? I could send a patch for the same. Am curios on the usage that combination of opp_find_freq_exact opp_find_freq_ceil opp_find_freq_floor and opp_get_freq, opp_get_voltage is unable to cater to? Would be interested in seeing a patch for the same. 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: omap3 pm: dependency between opp layer and cpufreq
>>-Original Message- >>From: linux-omap-ow...@vger.kernel.org >>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin >>Hilman >>Sent: Thursday, June 03, 2010 5:31 AM >>To: Nishanth Menon >>Cc: Premi, Sanjeev; Menon, Nishanth; Koen Kooi; linux-omap@vger.kernel.org; >>eduardo.valen...@nokia.com >>Subject: Re: omap3 pm: dependency between opp layer and cpufreq >> >>Nishanth Menon writes: >> >>> On 05/30/2010 01:50 PM, Premi, Sanjeev wrote: >>>> >>[...] >> >>>> [sp] There is no mention of cpufreq not working; but specifically the >>>> support of bootarg "mpurate" >>which is independent of cpufreq. >>>> >>>> The bootarg mpurate has been existing since quite sometime. I am neither >>>> creating a new layer / >>replacement >>>> for cpufreq not trying to duplicate the code. The intent is simply >>>> as >>> stated below: >>>> >>>> 1) Expose OPP layer - don't hinde it under CONFIG_CPU_FREQ. >>> ok with this >>>> >>>> 2) Use OPP layer to: >>>> - Validate that the requested mpurate is defined in the OPP table for >>>> the device >>>> - And get the voltage corresponding to the OPP. >>> sounds good too >>>> >>>> 3) Ensure that right freq and voltage is set - at init time - based on the >>>> mpurate. >>> ok >>> >>>> >>>> 4) And at some poit later break the linkage between op player amd PMIC. >>>> >>> aah you mean a simple patch as follows? >>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile >>> index 2b9ebf0..bfb3d0e 100644 >>> --- a/arch/arm/plat-omap/Makefile >>> +++ b/arch/arm/plat-omap/Makefile >>> @@ -16,7 +16,8 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o >>> # XXX The OPP TWL/TPS code should only be included when a TWL/TPS >>> # PMIC is selected. >>> ifdef CONFIG_CPU_FREQ >>> -obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o >>> +obj-$(CONFIG_ARCH_OMAP3) += opp.o >>> +obj-$(CONFIG_TWL4030_CORE) += opp_twl_tps.o >>> endif >>> >>> # omap_device support (OMAP2+ only at the moment) >>> -- >>> note - opp layer was never tied to pmic -> there is pmic voltage >>> conversion apis in opp_twl_tps.c >>> >>> or is there more in your view? >>> >>>>> >>>>>> >>>>>> anyways for cpufreq to work at 720Mhz, you need to add that frequency >>>>>> and corresponding voltage to the opptable, neither exists, further >>>>>> mpurate should work with opp table as well, else >>>>>> clockframework has no >>>>>> direct mechanism to verify the valid OPPs on a runtime >>>>>> system. that was >>>>>> the intent of opp layer - to provide the rest of the users with a >>>>>> mechanism to verify, query and use opps without functional >>>>>> knowledge of >>>>>> the silicon it works on.. >>> >>> ofcourse, please feel free to post a patch for the missing frequencies. >>> >> >> >>OK, I must admit to not reading this whole thread since I've just >>restructured OPP and CPUfreq support in the PM branch. >> >>OPP support is now in the pm-opp branch (based on mainline) and >>CPUfreq support is now in the pm-cpufreq branch (based on mainline.) >> >>Please update this patch/series against one (or both) of those >>branches for more discussion. >> >>FWIW, I like the name change from cpufreq34xx --> opp34xx_data, and >>the Makefile change above makes sense. Both of these changes should >>be re-submitted against my pm-opp branch. >> Hi All, I was just going through the entire series. IMO, it is a good idea to take the opp layer out of CONFIG_CPU_FREQ considering cpu freq need not be the only layer using the opp structures. Tomorrow we could have a l3 bus governor or a constraint framework that will need to use the same framework. So it is best if the opp layer is not dependent on the cpu freq layer. Slightly off the topic but considering we are discussing opp layer here, I do not find API's that take the OPP type (OPP_MPU or OPP_L3) and voltage/frequency as parameters and returns back the associated frequency/voltage. I do not want to get the opp table entry every time I do this. Any chance of introducing this in the framework? I could send a patch for the same. Regards -- 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: omap3 pm: dependency between opp layer and cpufreq
Nishanth Menon writes: > On 05/30/2010 01:50 PM, Premi, Sanjeev wrote: >> [...] >> [sp] There is no mention of cpufreq not working; but specifically the >> support of bootarg "mpurate" which is independent of cpufreq. >> >> The bootarg mpurate has been existing since quite sometime. I am neither >> creating a new layer / replacement >> for cpufreq not trying to duplicate the code. The intent is simply >> as > stated below: >> >> 1) Expose OPP layer - don't hinde it under CONFIG_CPU_FREQ. > ok with this >> >> 2) Use OPP layer to: >> - Validate that the requested mpurate is defined in the OPP table for >> the device >> - And get the voltage corresponding to the OPP. > sounds good too >> >> 3) Ensure that right freq and voltage is set - at init time - based on the >> mpurate. > ok > >> >> 4) And at some poit later break the linkage between op player amd PMIC. >> > aah you mean a simple patch as follows? > diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile > index 2b9ebf0..bfb3d0e 100644 > --- a/arch/arm/plat-omap/Makefile > +++ b/arch/arm/plat-omap/Makefile > @@ -16,7 +16,8 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o > # XXX The OPP TWL/TPS code should only be included when a TWL/TPS > # PMIC is selected. > ifdef CONFIG_CPU_FREQ > -obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o > +obj-$(CONFIG_ARCH_OMAP3) += opp.o > +obj-$(CONFIG_TWL4030_CORE) += opp_twl_tps.o > endif > > # omap_device support (OMAP2+ only at the moment) > -- > note - opp layer was never tied to pmic -> there is pmic voltage > conversion apis in opp_twl_tps.c > > or is there more in your view? > >>> anyways for cpufreq to work at 720Mhz, you need to add that frequency and corresponding voltage to the opptable, neither exists, further mpurate should work with opp table as well, else clockframework has no direct mechanism to verify the valid OPPs on a runtime system. that was the intent of opp layer - to provide the rest of the users with a mechanism to verify, query and use opps without functional knowledge of the silicon it works on.. > > ofcourse, please feel free to post a patch for the missing frequencies. > OK, I must admit to not reading this whole thread since I've just restructured OPP and CPUfreq support in the PM branch. OPP support is now in the pm-opp branch (based on mainline) and CPUfreq support is now in the pm-cpufreq branch (based on mainline.) Please update this patch/series against one (or both) of those branches for more discussion. FWIW, I like the name change from cpufreq34xx --> opp34xx_data, and the Makefile change above makes sense. Both of these changes should be re-submitted against my pm-opp branch. 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: omap3 pm: dependency between opp layer and cpufreq
On 05/30/2010 01:50 PM, Premi, Sanjeev wrote: From: Nishanth menon [menon.nisha...@gmail.com] Sent: Friday, May 28, 2010 10:16 PM To: Premi, Sanjeev; Menon, Nishanth Cc: Koen Kooi; linux-omap@vger.kernel.org; eduardo.valen...@nokia.com; Kevin Hilman Subject: Re: omap3 pm: dependency between opp layer and cpufreq - Original message - (...) [sp] I does - via bootarg - mpurate! When kernel boots, volatge must be set properly. We cannot rely on u-boot to be settiing everything correctly. e.g. 720MHz on OMAP3530 would fail at nominal 1.2V set by u-boot. I agree, but mpurate does not seem to use the cpufreq interfaces - so is kinda a question how it interfaces back -> but note, mpurate tells us what the start freq is for the system - it still does no *dynamic* transitions - just a static startup frequency. But I agree, it assumes that if you provide mpurate, the system supposedly is operating at that frequency, aka all setups have been done for that operational frequency(including voltage) There's also a funny bug in the current (PSP) mpurate/cpufreq code. The mpurate code has a > check for 720MHz on 35xx silicon, but cpufreq doesnt. So I can do: setenv bootargs ' mpurate=720' And the kernel will say "unsupported" and not switch to 720MHz during boot. But if I do this after boot: cpufreq-set -f 720 it *will* switch to 720MHz, even if the mpurate code explicitly forbids it. I tested on all the >OMAP3 silicon I have and it will run at 720MHz fine, even if it's out of spec, so I'm happy with this bug :) :) on mainline, if you dont have the frequency in opp definitions and your board has not done an explicit opp_add, cpufreq will only set u to the nearest available freq - easy for mainline fix if someone would like to send a patch adding the OPPs and the detection logic involved for enabling them. Now, thinking aloud, the voltage setting by SR will probably occur in late_init, if mpurate is setting the clock earlier in the boot process, we might have a potential conflict in the mpurate expecting the system to be set in a certain voltage based on Sanjeev's argument, but not actually there.. we expect ondemand+cpufreq to do the job on runtime anyways. Nishanth, When setting via mpurate, we need to get the appropriate voltage corresponding to the mpurate so that right combination can be done. This is where the mapping between freq and voltage needs to be queried. And OPP layer is best placed to provide the info... without duplication. The mechanism of changing the voltage itself can vary on the PMIC. BTW, I am getting ready to submit an updated patch for mpurate. Just waiting for an early resolution to this discussion. aye, I am aware of the concept here, just questioning what does it mean by setting mpurate to the kernel - it could mean two things: a) mean this is mpurate that the system was working on (aka) - now setup the required stuff to continue to function at that rate. b) go to this rate and forget where you were running at. the job of ondemand and other governors is to adjust to an optimal OPP using cpufreq which would conflict IMHO with (b), which kinda questions if you dont use cpufreq, does mpurate mean actually (a)? 'mpurate' is usually used when cpufreq is not required. It means - set me up for the specified freq and forget it. There is no further change needed/ possible. That opens up the question - why not use cpufreq with userspace governor instead? Esp if u dont want a change in freq, ok i get the part where u'd like a single freq for the system to function at, but u also mention, mpurate is for systems that dont care abt any other dependencies. So, bit of a contradiction if it depends on scaling voltage to the right level aka u are selecting an freq from opp table. This in my mind means u shud modify mpurate to use opp layer aka another user beyond cpufreq. [sp] That what the discussion is all about. but currently the opp layer is hidden/ wrapped inside CONFIG_CPU_FREQ. > And I want to move it out. See an earlier patch that I send to this effect. http://marc.info/?l=linux-omap&m=127496850617818&w=2 ? or did i miss the link? might be good to point to the right patch.. the opp layer initially was not under CONFIG_CPU_FREQ, it was moved after debate in this list. if there is a reason to move it out, i dont see why we cant do it.. You could always argue that it can be done in u-boot; but this bootarg helps people choose target freq keeping the u-boot same. Errr. Makes me feel that u shud really be using cpufreq instead! [sp] This bootarg is meant for setting frequency. without baggage of cpufreq; so why not use it? Either way i am not completely convinced u shud be doing voltage scaling when using mpurate given ur description- [sp] So how would I run the 3530 at 720MHZ whe
RE: omap3 pm: dependency between opp layer and cpufreq
___ From: Kevin Hilman [khil...@deeprootsystems.com] Sent: Friday, May 28, 2010 11:27 PM To: Nishanth menon Cc: Premi, Sanjeev; Menon, Nishanth; Koen Kooi; linux-omap@vger.kernel.org; eduardo.valen...@nokia.com Subject: Re: omap3 pm: dependency between opp layer and cpufreq Nishanth menon writes: [...] >> 'mpurate' is usually used when cpufreq is not required. It >> means - set me up for the specified freq and forget it. There >> is no further change needed/ possible. > > That opens up the question - why not use cpufreq with userspace > governor instead? Esp if u dont want a change in freq, ok i get the > part where u'd like a single freq for the system to function at, but > u also mention, mpurate is for systems that dont care abt any other > dependencies. So, bit of a contradiction if it depends on scaling > voltage to the right level aka u are selecting an freq from opp > table. > > This in my mind means u shud modify mpurate to use opp layer aka > another user beyond cpufreq. >> >> You could always argue that it can be done in u-boot; but this >> bootarg helps people choose target freq keeping the u-boot same. > > Errr. Makes me feel that u shud really be using cpufreq instead! Either > way > i am not completely convinced u shud be doing voltage scaling when using > mpurate given ur description- if u are trying to write a new cpufreq layer, > why > not fix why cpufreq doesn't work for u and help the rest of us as well ;) Personally, I'm not opposed to supporting mpurate= (with CPUfreq disabled) as this would also have the benefit of allowing a smaller kernel if you really don't want DVFS. After getting he right voltage from the OPP layer, what interface are you planning to use to actually scale the voltage? SR? new voltage layer directly? [sp] I plan to use the existing infra only. SR is again a config option. In the current internal implementation SR is being used. But this leads to an "ugly" hack where actual setting of mpurate is delayed until SR is initialized. In other mail (in response to Nishanth) I suggested that dependency between OPP layer and PMIC needs to be broken. If done sooner, i would try to avoid using SR (as preference). I haven't yet looked at new SR layer good enough to make clear yes/no response. ~sanjeev 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: omap3 pm: dependency between opp layer and cpufreq
From: Nishanth menon [menon.nisha...@gmail.com] Sent: Friday, May 28, 2010 10:16 PM To: Premi, Sanjeev; Menon, Nishanth Cc: Koen Kooi; linux-omap@vger.kernel.org; eduardo.valen...@nokia.com; Kevin Hilman Subject: Re: omap3 pm: dependency between opp layer and cpufreq - Original message - (...) > > > > > > > [sp] I does - via bootarg - mpurate! > > > > > > > > > > > > > > When kernel boots, volatge must be set properly. > > > > > > > We cannot rely on u-boot to be settiing everything > > > > correctly. e.g. 720MHz > > > > > > > on OMAP3530 would fail at nominal 1.2V set by u-boot. > > > > > > > > > > > > I agree, but mpurate does not seem to use the cpufreq > > > > interfaces - so is > > > > > > kinda a question how it interfaces back ->but note, > > > > mpurate tells us what > > > > > > the start freq is for the system - it still does no > > > > *dynamic* transitions - > > > > > > just a static startup frequency. But I agree, it assumes > > > > that if you provide > > > > > > mpurate, the system supposedly is operating at that > > > > frequency, aka all > > > > > > setups have been done for that operational > > > > frequency(including voltage) > > > > > > > > > > There's also a funny bug in the current (PSP) > > > > mpurate/cpufreq code. The mpurate code has a > > > >> check for 720MHz on 35xx silicon, but cpufreq doesnt. > > So I can do: > > > > > > > > > > setenv bootargs 'mpurate=720' > > > > > > > > > > And the kernel will say "unsupported" and not switch to > > > > 720MHz during boot. But if I do this after boot: > > > > > > > > > > cpufreq-set -f 720 > > > > > > > > > > it *will* switch to 720MHz, even if the mpurate code > > > > explicitly forbids it. I tested on all the > > > >>OMAP3 silicon I have and it will run at 720MHz fine, even > > > > if it's out > > > > of spec, so I'm happy with this bug :) > > > > > > > > :) on mainline, if you dont have the frequency in opp > > definitions and > > > > your board has not done an explicit opp_add, cpufreq will > > > > only set u to > > > > the nearest available freq - easy for mainline fix if someone > > > > would like > > > > to send a patch adding the OPPs and the detection logic > > involved for > > > > enabling them. > > > > > > > > Now, thinking aloud, the voltage setting by SR will > > probably occur in > > > > late_init, if mpurate is setting the clock earlier in the > > > > boot process, > > > > we might have a potential conflict in the mpurate expecting > > > > the system > > > > to be set in a certain voltage based on Sanjeev's argument, but not > > > > actually there.. we expect ondemand+cpufreq to do the job > > on runtime > > > > anyways. > > > > > > Nishanth, > > > > > > When setting via mpurate, we need to get the appropriate voltage > > > corresponding to the mpurate so that right combination can be done. > > > > > > This is where the mapping between freq and voltage needs to > > be queried. > > > And OPP layer is best placed to provide the info... without > > duplication. > > > The mechanism of changing the voltage itself can vary on the PMIC. > > > > > > BTW, I am getting ready to submit an updated patch for mpurate. Just > > > waiting for an early resolution to this discussion. > > > > aye, I am aware of the concept here, just questioning what > > does it mean > > by setting mpurate to the kernel - it could mean two things: > > a) mean this is mpurate that the system was working on (aka) > > - now setup > > the required stuff to continue to function at that rate. > > b) go to this rate and forget where you were running at. > > > > the job of ondemand and other governors is to adjust to an > > optimal OPP > > using cpufreq which would conflict IMHO with (b), which kinda > > questions > > if you dont use cpufreq, does mpurate mean actually (a)? > > 'mpurate' is usually used when cpufreq is not required. It > means - set me up for
Re: omap3 pm: dependency between opp layer and cpufreq
Nishanth menon writes: [...] >> 'mpurate' is usually used when cpufreq is not required. It >> means - set me up for the specified freq and forget it. There >> is no further change needed/ possible. > > That opens up the question - why not use cpufreq with userspace > governor instead? Esp if u dont want a change in freq, ok i get the > part where u'd like a single freq for the system to function at, but > u also mention, mpurate is for systems that dont care abt any other > dependencies. So, bit of a contradiction if it depends on scaling > voltage to the right level aka u are selecting an freq from opp > table. > > This in my mind means u shud modify mpurate to use opp layer aka > another user beyond cpufreq. >> >> You could always argue that it can be done in u-boot; but this >> bootarg helps people choose target freq keeping the u-boot same. > > Errr. Makes me feel that u shud really be using cpufreq instead! Either > way > i am not completely convinced u shud be doing voltage scaling when using > mpurate given ur description- if u are trying to write a new cpufreq layer, > why > not fix why cpufreq doesn't work for u and help the rest of us as well ;) Personally, I'm not opposed to supporting mpurate= (with CPUfreq disabled) as this would also have the benefit of allowing a smaller kernel if you really don't want DVFS. After getting he right voltage from the OPP layer, what interface are you planning to use to actually scale the voltage? SR? new voltage layer directly? 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: omap3 pm: dependency between opp layer and cpufreq
> -Original Message- > From: Menon, Nishanth > Sent: Friday, May 28, 2010 7:26 PM > To: Premi, Sanjeev > Cc: Koen Kooi; linux-omap@vger.kernel.org; > eduardo.valen...@nokia.com; Kevin Hilman > Subject: Re: omap3 pm: dependency between opp layer and cpufreq > > On 05/28/2010 03:42 PM, Premi, Sanjeev wrote: > >> -Original Message- > >> From: Menon, Nishanth > >> Sent: Friday, May 28, 2010 7:03 PM > >> To: Koen Kooi > >> Cc: Premi, Sanjeev; linux-omap@vger.kernel.org; > >> eduardo.valen...@nokia.com; Kevin Hilman > >> Subject: Re: omap3 pm: dependency between opp layer and cpufreq > >> > >> On 05/28/2010 10:56 AM, Koen Kooi wrote: > >>> > >>> Op 28 mei 2010, om 09:39 heeft Menon, Nishanth het volgende > >> geschreven: > >>> > >>>>> -Original Message- > >>>>> From: Premi, Sanjeev > >>>>> Sent: Thursday, May 27, 2010 10:30 PM > >>>> > >>>> [...] > >>>> > >>>>>> > >>>>>> 3) Was there any specific need to tie the functions > >> "opp_get_voltage" > >>>>> and others to cpufreq only? > >>>>> > >>>>> yes, because without cpufreq there is no transitions in > >> the system :) > >>>>> > >>>>> [sp] I does - via bootarg - mpurate! > >>>>> > >>>>> When kernel boots, volatge must be set properly. > >>>>> We cannot rely on u-boot to be settiing everything > >> correctly. e.g. 720MHz > >>>>> on OMAP3530 would fail at nominal 1.2V set by u-boot. > >>>> > >>>> I agree, but mpurate does not seem to use the cpufreq > >> interfaces - so is > >>>> kinda a question how it interfaces back -> but note, > >> mpurate tells us what > >>>> the start freq is for the system - it still does no > >> *dynamic* transitions - > >>>> just a static startup frequency. But I agree, it assumes > >> that if you provide > >>>> mpurate, the system supposedly is operating at that > >> frequency, aka all > >>>> setups have been done for that operational > >> frequency(including voltage) > >>> > >>> There's also a funny bug in the current (PSP) > >> mpurate/cpufreq code. The mpurate code has a > >> > check for 720MHz on 35xx silicon, but cpufreq doesnt. > So I can do: > >>> > >>> setenv bootargs ' mpurate=720' > >>> > >>> And the kernel will say "unsupported" and not switch to > >> 720MHz during boot. But if I do this after boot: > >>> > >>> cpufreq-set -f 720 > >>> > >>> it *will* switch to 720MHz, even if the mpurate code > >> explicitly forbids it. I tested on all the > >> >OMAP3 silicon I have and it will run at 720MHz fine, even > >> if it's out > >> of spec, so I'm happy with this bug :) > >> > >> :) on mainline, if you dont have the frequency in opp > definitions and > >> your board has not done an explicit opp_add, cpufreq will > >> only set u to > >> the nearest available freq - easy for mainline fix if someone > >> would like > >> to send a patch adding the OPPs and the detection logic > involved for > >> enabling them. > >> > >> Now, thinking aloud, the voltage setting by SR will > probably occur in > >> late_init, if mpurate is setting the clock earlier in the > >> boot process, > >> we might have a potential conflict in the mpurate expecting > >> the system > >> to be set in a certain voltage based on Sanjeev's argument, but not > >> actually there.. we expect ondemand+cpufreq to do the job > on runtime > >> anyways. > > > > Nishanth, > > > > When setting via mpurate, we need to get the appropriate voltage > > corresponding to the mpurate so that right combination can be done. > > > > This is where the mapping between freq and voltage needs to > be queried. > > And OPP layer is best placed to provide the info... without > duplication. > > The mechanism of changing the voltage itself can vary on the PMIC. > > > > BTW, I am getting ready to submit an updated patch for mpurate. Just > > waiting for an early resolution to this discussion. > > aye, I am aware of the concept here, just quest
Re: omap3 pm: dependency between opp layer and cpufreq
On 05/28/2010 03:42 PM, Premi, Sanjeev wrote: -Original Message- From: Menon, Nishanth Sent: Friday, May 28, 2010 7:03 PM To: Koen Kooi Cc: Premi, Sanjeev; linux-omap@vger.kernel.org; eduardo.valen...@nokia.com; Kevin Hilman Subject: Re: omap3 pm: dependency between opp layer and cpufreq On 05/28/2010 10:56 AM, Koen Kooi wrote: Op 28 mei 2010, om 09:39 heeft Menon, Nishanth het volgende geschreven: -Original Message- From: Premi, Sanjeev Sent: Thursday, May 27, 2010 10:30 PM [...] 3) Was there any specific need to tie the functions "opp_get_voltage" and others to cpufreq only? yes, because without cpufreq there is no transitions in the system :) [sp] I does - via bootarg - mpurate! When kernel boots, volatge must be set properly. We cannot rely on u-boot to be settiing everything correctly. e.g. 720MHz on OMAP3530 would fail at nominal 1.2V set by u-boot. I agree, but mpurate does not seem to use the cpufreq interfaces - so is kinda a question how it interfaces back -> but note, mpurate tells us what the start freq is for the system - it still does no *dynamic* transitions - just a static startup frequency. But I agree, it assumes that if you provide mpurate, the system supposedly is operating at that frequency, aka all setups have been done for that operational frequency(including voltage) There's also a funny bug in the current (PSP) mpurate/cpufreq code. The mpurate code has a > check for 720MHz on 35xx silicon, but cpufreq doesnt. So I can do: setenv bootargs ' mpurate=720' And the kernel will say "unsupported" and not switch to 720MHz during boot. But if I do this after boot: cpufreq-set -f 720 it *will* switch to 720MHz, even if the mpurate code explicitly forbids it. I tested on all the >OMAP3 silicon I have and it will run at 720MHz fine, even if it's out of spec, so I'm happy with this bug :) :) on mainline, if you dont have the frequency in opp definitions and your board has not done an explicit opp_add, cpufreq will only set u to the nearest available freq - easy for mainline fix if someone would like to send a patch adding the OPPs and the detection logic involved for enabling them. Now, thinking aloud, the voltage setting by SR will probably occur in late_init, if mpurate is setting the clock earlier in the boot process, we might have a potential conflict in the mpurate expecting the system to be set in a certain voltage based on Sanjeev's argument, but not actually there.. we expect ondemand+cpufreq to do the job on runtime anyways. Nishanth, When setting via mpurate, we need to get the appropriate voltage corresponding to the mpurate so that right combination can be done. This is where the mapping between freq and voltage needs to be queried. And OPP layer is best placed to provide the info... without duplication. The mechanism of changing the voltage itself can vary on the PMIC. BTW, I am getting ready to submit an updated patch for mpurate. Just waiting for an early resolution to this discussion. aye, I am aware of the concept here, just questioning what does it mean by setting mpurate to the kernel - it could mean two things: a) mean this is mpurate that the system was working on (aka) - now setup the required stuff to continue to function at that rate. b) go to this rate and forget where you were running at. the job of ondemand and other governors is to adjust to an optimal OPP using cpufreq which would conflict IMHO with (b), which kinda questions if you dont use cpufreq, does mpurate mean actually (a)? anyways for cpufreq to work at 720Mhz, you need to add that frequency and corresponding voltage to the opptable, neither exists, further mpurate should work with opp table as well, else clockframework has no direct mechanism to verify the valid OPPs on a runtime system. that was the intent of opp layer - to provide the rest of the users with a mechanism to verify, query and use opps without functional knowledge of the silicon it works on.. 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: omap3 pm: dependency between opp layer and cpufreq
> -Original Message- > From: Menon, Nishanth > Sent: Friday, May 28, 2010 7:03 PM > To: Koen Kooi > Cc: Premi, Sanjeev; linux-omap@vger.kernel.org; > eduardo.valen...@nokia.com; Kevin Hilman > Subject: Re: omap3 pm: dependency between opp layer and cpufreq > > On 05/28/2010 10:56 AM, Koen Kooi wrote: > > > > Op 28 mei 2010, om 09:39 heeft Menon, Nishanth het volgende > geschreven: > > > >>> -Original Message- > >>> From: Premi, Sanjeev > >>> Sent: Thursday, May 27, 2010 10:30 PM > >> > >> [...] > >> > >>>> > >>>> 3) Was there any specific need to tie the functions > "opp_get_voltage" > >>> and others to cpufreq only? > >>> > >>> yes, because without cpufreq there is no transitions in > the system :) > >>> > >>> [sp] I does - via bootarg - mpurate! > >>> > >>> When kernel boots, volatge must be set properly. > >>> We cannot rely on u-boot to be settiing everything > correctly. e.g. 720MHz > >>> on OMAP3530 would fail at nominal 1.2V set by u-boot. > >> > >> I agree, but mpurate does not seem to use the cpufreq > interfaces - so is > >> kinda a question how it interfaces back -> but note, > mpurate tells us what > >> the start freq is for the system - it still does no > *dynamic* transitions - > >> just a static startup frequency. But I agree, it assumes > that if you provide > >> mpurate, the system supposedly is operating at that > frequency, aka all > >> setups have been done for that operational > frequency(including voltage) > > > > There's also a funny bug in the current (PSP) > mpurate/cpufreq code. The mpurate code has a > > check for 720MHz on 35xx silicon, but cpufreq doesnt. So I can do: > > > > setenv bootargs ' mpurate=720' > > > > And the kernel will say "unsupported" and not switch to > 720MHz during boot. But if I do this after boot: > > > > cpufreq-set -f 720 > > > > it *will* switch to 720MHz, even if the mpurate code > explicitly forbids it. I tested on all the > >OMAP3 silicon I have and it will run at 720MHz fine, even > if it's out > of spec, so I'm happy with this bug :) > > :) on mainline, if you dont have the frequency in opp definitions and > your board has not done an explicit opp_add, cpufreq will > only set u to > the nearest available freq - easy for mainline fix if someone > would like > to send a patch adding the OPPs and the detection logic involved for > enabling them. > > Now, thinking aloud, the voltage setting by SR will probably occur in > late_init, if mpurate is setting the clock earlier in the > boot process, > we might have a potential conflict in the mpurate expecting > the system > to be set in a certain voltage based on Sanjeev's argument, but not > actually there.. we expect ondemand+cpufreq to do the job on runtime > anyways. Nishanth, When setting via mpurate, we need to get the appropriate voltage corresponding to the mpurate so that right combination can be done. This is where the mapping between freq and voltage needs to be queried. And OPP layer is best placed to provide the info... without duplication. The mechanism of changing the voltage itself can vary on the PMIC. BTW, I am getting ready to submit an updated patch for mpurate. Just waiting for an early resolution to this discussion. ~sanjeev > > 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: omap3 pm: dependency between opp layer and cpufreq
On 05/28/2010 10:56 AM, Koen Kooi wrote: Op 28 mei 2010, om 09:39 heeft Menon, Nishanth het volgende geschreven: -Original Message- From: Premi, Sanjeev Sent: Thursday, May 27, 2010 10:30 PM [...] 3) Was there any specific need to tie the functions "opp_get_voltage" and others to cpufreq only? yes, because without cpufreq there is no transitions in the system :) [sp] I does - via bootarg - mpurate! When kernel boots, volatge must be set properly. We cannot rely on u-boot to be settiing everything correctly. e.g. 720MHz on OMAP3530 would fail at nominal 1.2V set by u-boot. I agree, but mpurate does not seem to use the cpufreq interfaces - so is kinda a question how it interfaces back -> but note, mpurate tells us what the start freq is for the system - it still does no *dynamic* transitions - just a static startup frequency. But I agree, it assumes that if you provide mpurate, the system supposedly is operating at that frequency, aka all setups have been done for that operational frequency(including voltage) There's also a funny bug in the current (PSP) mpurate/cpufreq code. The mpurate code has a > check for 720MHz on 35xx silicon, but cpufreq doesnt. So I can do: setenv bootargs ' mpurate=720' And the kernel will say "unsupported" and not switch to 720MHz during boot. But if I do this after boot: cpufreq-set -f 720 it *will* switch to 720MHz, even if the mpurate code explicitly forbids it. I tested on all the >OMAP3 silicon I have and it will run at 720MHz fine, even if it's out of spec, so I'm happy with this bug :) :) on mainline, if you dont have the frequency in opp definitions and your board has not done an explicit opp_add, cpufreq will only set u to the nearest available freq - easy for mainline fix if someone would like to send a patch adding the OPPs and the detection logic involved for enabling them. Now, thinking aloud, the voltage setting by SR will probably occur in late_init, if mpurate is setting the clock earlier in the boot process, we might have a potential conflict in the mpurate expecting the system to be set in a certain voltage based on Sanjeev's argument, but not actually there.. we expect ondemand+cpufreq to do the job on runtime anyways. 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: omap3 pm: dependency between opp layer and cpufreq
Op 28 mei 2010, om 09:39 heeft Menon, Nishanth het volgende geschreven: >> -Original Message- >> From: Premi, Sanjeev >> Sent: Thursday, May 27, 2010 10:30 PM > > [...] > >>> >>> 3) Was there any specific need to tie the functions "opp_get_voltage" >> and others to cpufreq only? >> >> yes, because without cpufreq there is no transitions in the system :) >> >> [sp] I does - via bootarg - mpurate! >> >> When kernel boots, volatge must be set properly. >> We cannot rely on u-boot to be settiing everything correctly. e.g. 720MHz >> on OMAP3530 would fail at nominal 1.2V set by u-boot. > > I agree, but mpurate does not seem to use the cpufreq interfaces - so is > kinda a question how it interfaces back -> but note, mpurate tells us what > the start freq is for the system - it still does no *dynamic* transitions - > just a static startup frequency. But I agree, it assumes that if you provide > mpurate, the system supposedly is operating at that frequency, aka all > setups have been done for that operational frequency(including voltage) There's also a funny bug in the current (PSP) mpurate/cpufreq code. The mpurate code has a check for 720MHz on 35xx silicon, but cpufreq doesnt. So I can do: setenv bootargs ' mpurate=720' And the kernel will say "unsupported" and not switch to 720MHz during boot. But if I do this after boot: cpufreq-set -f 720 it *will* switch to 720MHz, even if the mpurate code explicitly forbids it. I tested on all the OMAP3 silicon I have and it will run at 720MHz fine, even if it's out of spec, so I'm happy with this bug :) regards, Koen-- 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: omap3 pm: dependency between opp layer and cpufreq
> -Original Message- > From: Premi, Sanjeev > Sent: Thursday, May 27, 2010 10:30 PM [...] > > > > 3) Was there any specific need to tie the functions "opp_get_voltage" > and others to cpufreq only? > > yes, because without cpufreq there is no transitions in the system :) > > [sp] I does - via bootarg - mpurate! > > When kernel boots, volatge must be set properly. > We cannot rely on u-boot to be settiing everything correctly. e.g. 720MHz > on OMAP3530 would fail at nominal 1.2V set by u-boot. I agree, but mpurate does not seem to use the cpufreq interfaces - so is kinda a question how it interfaces back -> but note, mpurate tells us what the start freq is for the system - it still does no *dynamic* transitions - just a static startup frequency. But I agree, it assumes that if you provide mpurate, the system supposedly is operating at that frequency, aka all setups have been done for that operational frequency(including voltage) 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: omap3 pm: dependency between opp layer and cpufreq
From: Menon, Nishanth Sent: Thursday, May 27, 2010 9:57 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: omap3 pm: dependency between opp layer and cpufreq [snip]--[snip] [sp] Responding via webmail.. so the formatting and quotes are non-standard :( > # OPP support in (OMAP3+ only at the moment) > # XXX The OPP TWL/TPS code should only be included when a TWL/TPS > # PMIC is selected. > ifdef CONFIG_CPU_FREQ > obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o ok this needs to be split: a) opp_twl_tps should depend on TWL_CORE and not CPUFREQ - there is no need actually b) opp.o should remain dependent on CPU_FREQ. [sp] That was in my next mail. > endif > > But changing CONFIG_CPU_FREQ to CONFIG_TWL4030_POWER leads to these errors: see (b) > [snip--[snip] > > Questions/ comments: > > 1) The linkage between OPP and Voltage are not driven by the PMIC. > They are defined by/for the silicon itself. look carefully at twl -> it is the abstraction where needed for pmic translation of a voltage value - this you agree is PMIC dependent I suppose. > > 2) The implementation for setting the voltage should depend upon the PMIC. ACK- the concept should be independent of PMIC - each PMIC, like 5030/tps Vs custom PMICs have thier own unique mechanisms of setting voltages - the renewed SR series from Thara addresses this concern.(not in pm branch yet - but potentially soon) > > 3) Was there any specific need to tie the functions "opp_get_voltage" and > others to cpufreq only? yes, because without cpufreq there is no transitions in the system :) [sp] I does - via bootarg - mpurate! When kernel boots, volatge must be set properly. We cannot rely on u-boot to be settiing everything correctly. e.g. 720MHz on OMAP3530 would fail at nominal 1.2V set by u-boot. > > I am working on a patch that should remove some of these dependencies. > But, trying to open up a discussion as well... do post them. thanks > > Best regards, > Sanjeev > -- > 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 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: omap3 pm: dependency between opp layer and cpufreq
On 05/27/2010 01:25 PM, Premi, Sanjeev wrote: Hi, While compiling for omap3_evm_defconfig, at the head of linux-omap, I encounter these errors: arch/arm/mach-omap2/built-in.o: In function `sr_configure_vp': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:315: undefined reference to `omap_twl_uv_to_vsel' /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:364: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_enable': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:609: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_reset_voltage': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:478: undefined reference to `omap_twl_uv_to_vsel' /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:496: undefined reference to `omap_twl_uv_to_vsel' make: *** [.tmp_vmlinux1] Error 1 Turn our that comment and code in plat-omap/Makefile don't match: # OPP support in (OMAP3+ only at the moment) # XXX The OPP TWL/TPS code should only be included when a TWL/TPS # PMIC is selected. ifdef CONFIG_CPU_FREQ obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o ok this needs to be split: a) opp_twl_tps should depend on TWL_CORE and not CPUFREQ - there is no need actually b) opp.o should remain dependent on CPU_FREQ. endif But changing CONFIG_CPU_FREQ to CONFIG_TWL4030_POWER leads to these errors: see (b) CC arch/arm/plat-omap/opp.o arch/arm/plat-omap/opp.c:54: error: redefinition of 'opp_get_voltage' arch/arm/plat-omap/include/plat/opp.h:240: error: previous definition of 'opp_get_voltage' was here arch/arm/plat-omap/opp.c:63: error: redefinition of 'opp_get_freq' arch/arm/plat-omap/include/plat/opp.h:245: error: previous definition of 'opp_get_freq' was here arch/arm/plat-omap/opp.c:79: error: conflicting types for 'opp_find_by_opp_id' arch/arm/plat-omap/include/plat/opp.h:296: error: previous definition of 'opp_find_by_opp_id' was here arch/arm/plat-omap/opp.c:102: error: redefinition of 'opp_get_opp_id' arch/arm/plat-omap/include/plat/opp.h:301: error: previous definition of 'opp_get_opp_id' was here arch/arm/plat-omap/opp.c:107: error: conflicting types for 'opp_get_opp_count' arch/arm/plat-omap/include/plat/opp.h:250: error: previous definition of 'opp_get_opp_count' was here arch/arm/plat-omap/opp.c:129: error: conflicting types for 'opp_find_freq_exact' arch/arm/plat-omap/include/plat/opp.h:256: error: previous definition of 'opp_find_freq_exact' was here arch/arm/plat-omap/opp.c:153: error: conflicting types for 'opp_find_freq_ceil' arch/arm/plat-omap/include/plat/opp.h:268: error: previous definition of 'opp_find_freq_ceil' was here arch/arm/plat-omap/opp.c:182: error: conflicting types for 'opp_find_freq_floor' arch/arm/plat-omap/include/plat/opp.h:262: error: previous definition of 'opp_find_freq_floor' was here arch/arm/plat-omap/opp.c:223: error: conflicting types for 'opp_add' arch/arm/plat-omap/include/plat/opp.h:280: error: previous definition of 'opp_add' was here arch/arm/plat-omap/opp.c:291: error: conflicting types for 'opp_init_list' arch/arm/plat-omap/include/plat/opp.h:274: error: previous definition of 'opp_init_list' was here arch/arm/plat-omap/opp.c:335: error: redefinition of 'opp_enable' arch/arm/plat-omap/include/plat/opp.h:285: error: previous definition of 'opp_enable' was here arch/arm/plat-omap/opp.c:345: error: redefinition of 'opp_disable' arch/arm/plat-omap/include/plat/opp.h:290: error: previous definition of 'opp_disable' was here arch/arm/plat-omap/opp.c:356: error: conflicting types for 'opp_init_cpufreq_table' arch/arm/plat-omap/include/plat/opp.h:307: error: previous definition of 'opp_init_cpufreq_table' was here make[1]: *** [arch/arm/plat-omap/opp.o] Error 1 The contents of "plat-omap/include/plat/opp.h" seem to be based on assumption that definition of OPP is needed only for cpufreq. But even if cpufreq is disabled, this information is required for setting the correct voltage against 'pre-defined' ARM frequency. Questions/ comments: 1) The linkage between OPP and Voltage are not driven by the PMIC. They are defined by/for the silicon itself. look carefully at twl -> it is the abstraction where needed for pmic translation of a voltage value - this you agree is PMIC dependent I suppose. 2) The implementation for setting the voltage should depend upon the PMIC. ACK- the concept should be independent of PMIC - each PMIC, like 5030/tps Vs custom PMICs have thier own unique mechanisms of setting voltages - the renewed SR series from Thara addresses this concern.(not in pm branch yet - but potentially soon) 3) Was there any specific need to tie the functions "opp_get_voltage" and others to cpufreq only? yes, because without cpufreq there is no transitions in the system :) I am working on a patch that should remove some of these dependencies. But, trying to open up a discussion as well... do post them. thanks Best regar
RE: omap3 pm: dependency between opp layer and cpufreq
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev > Sent: Thursday, May 27, 2010 6:50 PM > To: linux-omap@vger.kernel.org > Subject: RE: omap3 pm: dependency between opp layer and cpufreq > [snip]--[snip] > > diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile > index 2b9ebf0..18d291f 100644 > --- a/arch/arm/plat-omap/Makefile > +++ b/arch/arm/plat-omap/Makefile > @@ -15,7 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o > # OPP support in (OMAP3+ only at the moment) > # XXX The OPP TWL/TPS code should only be included when a TWL/TPS > # PMIC is selected. > -ifdef CONFIG_CPU_FREQ > +ifdef CONFIG_TWL4030_POWER > obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o > endif > After sending the mail, I realized that inclusion of opp_twl_tps.o should depend upon CONFIG_TWL4030_POWER and opp.o should be included as default. ~sanjeev [snip]--[snip] -- 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: omap3 pm: dependency between opp layer and cpufreq
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev > Sent: Thursday, May 27, 2010 4:56 PM > To: linux-omap@vger.kernel.org > Subject: omap3 pm: dependency between opp layer and cpufreq > > Hi, > > While compiling for omap3_evm_defconfig, at the head of > linux-omap, I encounter > these errors: > > arch/arm/mach-omap2/built-in.o: In function `sr_configure_vp': > /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:315: > undefined reference to `omap_twl_uv_to_vsel' > /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:364: > undefined reference to `omap_twl_uv_to_vsel' > arch/arm/mach-omap2/built-in.o: In function `sr_enable': > /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:609: > undefined reference to `omap_twl_uv_to_vsel' > arch/arm/mach-omap2/built-in.o: In function `sr_reset_voltage': > /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:478: > undefined reference to `omap_twl_uv_to_vsel' > /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:496: > undefined reference to `omap_twl_uv_to_vsel' > make: *** [.tmp_vmlinux1] Error 1 > > Turn our that comment and code in plat-omap/Makefile don't match: > > # OPP support in (OMAP3+ only at the moment) > # XXX The OPP TWL/TPS code should only be included when a TWL/TPS > # PMIC is selected. > ifdef CONFIG_CPU_FREQ > obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o > endif > > But changing CONFIG_CPU_FREQ to CONFIG_TWL4030_POWER leads to > these errors: > > CC arch/arm/plat-omap/opp.o > arch/arm/plat-omap/opp.c:54: error: redefinition of 'opp_get_voltage' > arch/arm/plat-omap/include/plat/opp.h:240: error: previous > definition of 'opp_get_voltage' was here > arch/arm/plat-omap/opp.c:63: error: redefinition of 'opp_get_freq' > arch/arm/plat-omap/include/plat/opp.h:245: error: previous > definition of 'opp_get_freq' was here > arch/arm/plat-omap/opp.c:79: error: conflicting types for > 'opp_find_by_opp_id' > arch/arm/plat-omap/include/plat/opp.h:296: error: previous > definition of 'opp_find_by_opp_id' was here > arch/arm/plat-omap/opp.c:102: error: redefinition of 'opp_get_opp_id' > arch/arm/plat-omap/include/plat/opp.h:301: error: previous > definition of 'opp_get_opp_id' was here > arch/arm/plat-omap/opp.c:107: error: conflicting types for > 'opp_get_opp_count' > arch/arm/plat-omap/include/plat/opp.h:250: error: previous > definition of 'opp_get_opp_count' was here > arch/arm/plat-omap/opp.c:129: error: conflicting types for > 'opp_find_freq_exact' > arch/arm/plat-omap/include/plat/opp.h:256: error: previous > definition of 'opp_find_freq_exact' was here > arch/arm/plat-omap/opp.c:153: error: conflicting types for > 'opp_find_freq_ceil' > arch/arm/plat-omap/include/plat/opp.h:268: error: previous > definition of 'opp_find_freq_ceil' was here > arch/arm/plat-omap/opp.c:182: error: conflicting types for > 'opp_find_freq_floor' > arch/arm/plat-omap/include/plat/opp.h:262: error: previous > definition of 'opp_find_freq_floor' was here > arch/arm/plat-omap/opp.c:223: error: conflicting types for 'opp_add' > arch/arm/plat-omap/include/plat/opp.h:280: error: previous > definition of 'opp_add' was here > arch/arm/plat-omap/opp.c:291: error: conflicting types for > 'opp_init_list' > arch/arm/plat-omap/include/plat/opp.h:274: error: previous > definition of 'opp_init_list' was here > arch/arm/plat-omap/opp.c:335: error: redefinition of 'opp_enable' > arch/arm/plat-omap/include/plat/opp.h:285: error: previous > definition of 'opp_enable' was here > arch/arm/plat-omap/opp.c:345: error: redefinition of 'opp_disable' > arch/arm/plat-omap/include/plat/opp.h:290: error: previous > definition of 'opp_disable' was here > arch/arm/plat-omap/opp.c:356: error: conflicting types for > 'opp_init_cpufreq_table' > arch/arm/plat-omap/include/plat/opp.h:307: error: previous > definition of 'opp_init_cpufreq_table' was here > make[1]: *** [arch/arm/plat-omap/opp.o] Error 1 > > The contents of "plat-omap/include/plat/opp.h" seem to be > based on assumption that definition of OPP is > needed only for cpufreq. But even if cpufreq is disabled, > this information is required for setting the > correct voltage against 'pre-defined' ARM frequency. > > Questions/ comments: > > 1) The linkage between OPP and Voltage are not driven
omap3 pm: dependency between opp layer and cpufreq
Hi, While compiling for omap3_evm_defconfig, at the head of linux-omap, I encounter these errors: arch/arm/mach-omap2/built-in.o: In function `sr_configure_vp': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:315: undefined reference to `omap_twl_uv_to_vsel' /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:364: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_enable': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:609: undefined reference to `omap_twl_uv_to_vsel' arch/arm/mach-omap2/built-in.o: In function `sr_reset_voltage': /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:478: undefined reference to `omap_twl_uv_to_vsel' /home/premi/linux-pm/arch/arm/mach-omap2/smartreflex.c:496: undefined reference to `omap_twl_uv_to_vsel' make: *** [.tmp_vmlinux1] Error 1 Turn our that comment and code in plat-omap/Makefile don't match: # OPP support in (OMAP3+ only at the moment) # XXX The OPP TWL/TPS code should only be included when a TWL/TPS # PMIC is selected. ifdef CONFIG_CPU_FREQ obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o endif But changing CONFIG_CPU_FREQ to CONFIG_TWL4030_POWER leads to these errors: CC arch/arm/plat-omap/opp.o arch/arm/plat-omap/opp.c:54: error: redefinition of 'opp_get_voltage' arch/arm/plat-omap/include/plat/opp.h:240: error: previous definition of 'opp_get_voltage' was here arch/arm/plat-omap/opp.c:63: error: redefinition of 'opp_get_freq' arch/arm/plat-omap/include/plat/opp.h:245: error: previous definition of 'opp_get_freq' was here arch/arm/plat-omap/opp.c:79: error: conflicting types for 'opp_find_by_opp_id' arch/arm/plat-omap/include/plat/opp.h:296: error: previous definition of 'opp_find_by_opp_id' was here arch/arm/plat-omap/opp.c:102: error: redefinition of 'opp_get_opp_id' arch/arm/plat-omap/include/plat/opp.h:301: error: previous definition of 'opp_get_opp_id' was here arch/arm/plat-omap/opp.c:107: error: conflicting types for 'opp_get_opp_count' arch/arm/plat-omap/include/plat/opp.h:250: error: previous definition of 'opp_get_opp_count' was here arch/arm/plat-omap/opp.c:129: error: conflicting types for 'opp_find_freq_exact' arch/arm/plat-omap/include/plat/opp.h:256: error: previous definition of 'opp_find_freq_exact' was here arch/arm/plat-omap/opp.c:153: error: conflicting types for 'opp_find_freq_ceil' arch/arm/plat-omap/include/plat/opp.h:268: error: previous definition of 'opp_find_freq_ceil' was here arch/arm/plat-omap/opp.c:182: error: conflicting types for 'opp_find_freq_floor' arch/arm/plat-omap/include/plat/opp.h:262: error: previous definition of 'opp_find_freq_floor' was here arch/arm/plat-omap/opp.c:223: error: conflicting types for 'opp_add' arch/arm/plat-omap/include/plat/opp.h:280: error: previous definition of 'opp_add' was here arch/arm/plat-omap/opp.c:291: error: conflicting types for 'opp_init_list' arch/arm/plat-omap/include/plat/opp.h:274: error: previous definition of 'opp_init_list' was here arch/arm/plat-omap/opp.c:335: error: redefinition of 'opp_enable' arch/arm/plat-omap/include/plat/opp.h:285: error: previous definition of 'opp_enable' was here arch/arm/plat-omap/opp.c:345: error: redefinition of 'opp_disable' arch/arm/plat-omap/include/plat/opp.h:290: error: previous definition of 'opp_disable' was here arch/arm/plat-omap/opp.c:356: error: conflicting types for 'opp_init_cpufreq_table' arch/arm/plat-omap/include/plat/opp.h:307: error: previous definition of 'opp_init_cpufreq_table' was here make[1]: *** [arch/arm/plat-omap/opp.o] Error 1 The contents of "plat-omap/include/plat/opp.h" seem to be based on assumption that definition of OPP is needed only for cpufreq. But even if cpufreq is disabled, this information is required for setting the correct voltage against 'pre-defined' ARM frequency. Questions/ comments: 1) The linkage between OPP and Voltage are not driven by the PMIC. They are defined by/for the silicon itself. 2) The implementation for setting the voltage should depend upon the PMIC. 3) Was there any specific need to tie the functions "opp_get_voltage" and others to cpufreq only? I am working on a patch that should remove some of these dependencies. But, trying to open up a discussion as well... Best regards, Sanjeev -- 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
