Re: omap3630: cpu revision bits are different
* Premi, Sanjeev [100812 15:42]: > Hi all, > > While re working on the cpu revision patch, I came > across these definitions: > > #define OMAP3630_REV_ES1_0 0x36300034 > #define OMAP3630_REV_ES1_1 0x36300134 > #define OMAP3630_REV_ES1_2 0x36300234 > > Contrast this with: > > #define OMAP3430_REV_ES1_0 0x34300034 > #define OMAP3430_REV_ES2_0 0x34301034 > #define OMAP3430_REV_ES2_1 0x34302034 > > I may have missed the discussion on this list, but > wanted to quickly check if the difference in intended > OR accidental. Hmm for those defines it should be just a running number for the revision so we should most likely just renumber the OMAP3430_REV_ES bits. > I do recognize that definitions for 3630 start at lower > nibble, so they appear to be better choice. Yeah. Care to do a patch to renumber 3430 revision bits for the next merge window? AFAIK, that should change anything in the functionality so it's only a cosmetic change. Should be grepped carefully though :) Tony -- 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: dspbridge and the omapl1x
> On Thu, Aug 12, 2010 at 2:16 AM, Kamoolkar, Mugdha wrote: >> You are correct that dynamic linking and loading is a feature that is >> available in DSPBridge, and which is missing in DSPLink, which could work on >> OMAPL1xx if you ported DSPBridge to OMAPL1xx > > I imagined that the lack of MMU would be a blocker in porting > dspbridge since it would be impossible to support scattered (in PAs) > pages on the DSP-side. But Mugdha makes it sound like the port could > be accomplished with DMM omitted. > > Also I believe that the new Contiguous Memory Allocation (CMA) > framework was developed specifically for systems that need to allocate > physically contiguous memory because they don't have an MMU. What > would say to avoiding the IOMMU requirement and keeping DMM by using > physically contiguous dynamically allocated memory regions like those > provided by the new CMA [2]? > Just curious as how CMA is different from Android's pmem. > 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 v4 3/8] wireless: wl1271: add platform driver to get board data
On Thursday, August 12, 2010, Russell King - ARM Linux wrote: > On Thu, Aug 12, 2010 at 09:40:19AM +0300, Ohad Ben-Cohen wrote: >> On Thu, Aug 12, 2010 at 12:25 AM, Russell King - ARM Linux >> wrote: >> >I've outlined a far simpler and easiler solution >> > which avoids this kind of abuse, and given suggestions on how to extend >> > it to support multiple instances. >> > >> >> Do you mean: >> http://www.spinics.net/lists/arm-kernel/msg95338.html >> ? >> >> I was under the impression you eventually discarded that approach in >> that post. > > Indeed. > > I'm talking about my first suggestion: > > http://lists.arm.linux.org.uk/lurker/message/20100804.114148.bf961e83.en.html > > which was later expanded by Vitaly: > > http://lists.arm.linux.org.uk/lurker/message/20100804.140119.f476c29c.en.html > > I don't think anyone had any negative comments against that proposal. Thanks, I see what you mean now. I'll give this a spin when I'm back (I'm away until e/o August) > -- 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] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Sun, 1 Aug 2010, Janusz Krzysztofik wrote: > Friday 30 July 2010 20:49:05 Janusz Krzysztofik napisaÅ(a): > > Friday 30 July 2010 13:07:42 Guennadi Liakhovetski napisaÅ(a): > > > On Sun, 18 Jul 2010, Janusz Krzysztofik wrote: > > > > This is a V4L2 driver for TI OMAP1 SoC camera interface. > > > > > > > > Two versions of the driver are provided, using either > > > > videobuf-dma-contig or videobuf-dma-sg. The former uses less processing > > > > power, but often fails to allocate contignuous buffer memory. The > > > > latter is free of this problem, but generates tens of DMA interrupts > > > > per frame. > > > > > > Hm, would it be difficult to first try contig, and if it fails - fall > > > back to sg? > > > > Hmm, let me think about it. > > Hi Gennadi, > > For me, your idea of frist trying contig and then falling back to sg if it > fails, sounds great. However, I'm not sure if implementing it at a specific > hardware driver level is a good solution. Nor soc_camera framework seems the > right place for it either. > > I think the right way would be if implemented at the videobuf-core level. > Then, drivers should be able to initialize both paths, providing queue > callbacks for both sets of methods, contig and sg, for videobuf sole use. Ok, here're my thoughts about this: 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. But given problems with this aproach in the current ARM tree [1], this might be a bit difficult. Still, those problems have to be and will be fixed somehow eventually, so, you might prefer to still just go that route. 2. If you do want to do the switching - we also discussed, how forthcoming changes to the videobuf subsystem will affest this work. I do not think it would be possible to implement this switching in the videobuf core. Remember, with the videobuf API you first call the respective implementation init method, which doesn't fail. Then, in REQBUFS ioctl you call videobuf_reqbufs(), which might already fail but normally doesn't. The biggest problem is the mmap call with the contig videobuf implementation. This one is likely to fail. So, you would have to catch the failing mmap, call videobuf_mmap_free(), then init the SG videobuf, request buffers and mmap them... With my 2 patches from today, there is only one process (file descriptor, to be precise), that manages the videobuf queue. So, this all can only be implemented in your driver. [1] http://thread.gmane.org/gmane.linux.ports.sh.devel/8560 > I'm not sure if I have enough skills to implement this idea. However, if > there > is a consensus on its general usfullness as a videobuf extension, I can have > a look at it in my spare time. > > For now, I'd propose limiting my changes for v2 to splitting both methods > into > separate sections, not interleaved with #ifdefs like they are now, as you've > already suggested. Yep, so, I think, your choice is either to drop sg completely, or to separate the two cleanly and switch between them dynamically in your driver. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
Kevin Hilman had written, on 08/12/2010 09:34 AM, the following: "Gopinath, Thara" writes: [...] No reason why we should have a different file for OMAP4. So a better name than opp3xxx_data.c? why do we need to have it in the same file? Remember, 3630,3430 are under OMAP3 family, but omap4 is considered a different arch. Code is more or less the same. Is that not a sufficient reason to reuse a file ? I dont really care as long as opp layer is usable by mpurate without depending on cpufreq and it is maintainable without going to if else nightmare. But personally, I dont see really reusuable code in that file (other than doing an opp addition in a loop) it could result eventually in a large amount of code redundancy and maintenance nightmare with OMAP4 variants coming in. Why do you say maintenance nightmare? It is going to be one opp table per SoC. Anyways, Kevin what is your take on this? I think we should keep separate files for each SoC listing the OPP data, and in those files should be *only* data. The init functions across these files will be basically the same, so maybe the common code should be pulled out into a separate file (pm.c?), and the data files have a very simple init function (device_initcall) that just registers their data. yep, this sounds like a good idea, let me try something on this line and post a new rev.. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: Add macros to evaluate cpu revision
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
> Sent: Monday, July 26, 2010 8:57 PM
> To: Menon, Nishanth
> Cc: Gadiyar, Anand; linux-omap@vger.kernel.org
> Subject: RE: [PATCH] omap: Add macros to evaluate cpu revision
>
[snip] [snip]
> > >>> +#define ES_2_0 OMAP_REVBITS_10
> > >>> +#define ES_2_1 OMAP_REVBITS_20
> > >> makes sense to go to 2_2
> > >>> +#define ES_3_0 OMAP_REVBITS_30
> > >>> +#define ES_3_1 OMAP_REVBITS_40
> > >>> +#define ES_3_1_2 OMAP_REVBITS_50
> > >> 3_2?
> > > This may not make sense to add now as there are no
> > > 2.2 or 3.2 revisions of any OMAP3/4 silicon?
> > >
> > Agreed for 3 and 4, but considering this is
> > arch/arm/plat-omap/include/plat/cpu.h, does it make sense in
> > looking all
> > OMAPs?
> > >>> In this case, the best option would be to prefix
> > OMAP34X_/ OMAP36X_
> > >>> OMAP44X_ etc and define the ES revisions for each context.
> > >> doing that is gonna make the code real dirty looking. at the
> > >
> > > dirty?? How come? The intent is to increase readability.
> > >
> > huh? should we start the old debate again?
> > Read this thread
> > http://marc.info/?l=linux-omap&m=127903615629407&w=2
> >
> > >> very least
> > >> mebbe bracket it in with #ifdef with CONFIG_OMAP2PLUS?
> > >
> > > What purpose does this #ifdef. The macro should/could be used
> > > quite generically.
> >
> > Now we are back in a full circle -> if you would like to
> > introduce the
> > patch for ALL omap silicon, you might want to consider 2420
> > and so on..
> > at the very least.
> >
> > introducing this for OMAP3 and 4 alone does not allow logic
> > to scale up.
>
> [sp] The logic is only in the macros viz. cpu_rev_ge(), cpu_rev_le,
> etc. The support for other omap silicons means having the
> mapping of the revision bits to actual silicon version.
>
[snip] [snip]
> > >
> > > Here is a sample usage from one of the patch I am reworking
> > > for submission here:
> > >
> > > @@ -488,7 +494,9 @@ void omap_sram_idle(void)
> > > * of AUTO_CNT = 1 enabled. This takes care of
> errata 1.142.
> > > * Hence store/restore the SDRC_POWER register here.
> > > */
> > > - if (omap_rev() >= OMAP3430_REV_ES3_0 &&
> > > + if ((cpu_is_omap3630()
> > > + || cpu_is_omap3505() || cpu_is_omap3517()
> > > + || cpu_rev_ge(34xx, OMAP34XX_ES_3_0)) &&
> > cpu_rev_ge(34xx, OMAP34XX_ES_3_0) -> this is the cause of my
> > comment on
> > dirty code - redundant OMAP34XX_ in the macro when I do say
> > it is 34xx
> > in the first parameter!
> >
>
> [sp] Dirtiness is in eye of beholder :)
> I did say earlier, that the patch is meant for increasing
> readability. I could have overcome this by using lowercase
> for revision macros.
>
> I did think of "exploiting" enums; but had been avoiding
> the need for adding new data structures. It, however, can
> be ugly!
>
[snip] [snip]
Below is an attempt to introduce enums to take care of uppercase
bit definitions vs lowercase function definitions. Of course it
is not a formal patch and I have tried to limit the patch only
for additions; not for deletions that can result due from the
enums declares below.
The revisions can now be done as:
- cpu_rev_ge(omap34xx, es3_0)
- cpu_rev_eq(am3505, es1_0)
- etc.
Also, I am using revision bit values instead of another macro
representing them (e.g. OMAP_REVISION_BITS_10). Given the
structure below, I felt use of actual bit values is better.
Nishanth:
There may be copy-paste errors in the actual revision definitions
(let us not deviate into those for now).
~sanjeev
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e2ae53..36a7047
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -467,4 +469,103 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
+/*
+ * Enumerate the CPU revisions for easy comparison against the
+ * revision bits specific for each processor family.
+ */
+#define DECLARE_CPU_REV(cpu) enum revs_ ##cpu
+#define CPU_REV(cpu,rev,bits) cpu## _ ##rev = bits
+
+DECLARE_CPU_REV(omap242x) {
+ CPU_REV(omap242x, es1_0, 0x00),
+ CPU_REV(omap242x, es2_0, 0x01),
+} ;
+
+DECLARE_CPU_REV(omap243x) {
+ CPU_REV(omap243x, es1_0, 0x00),
+} ;
+
+DECLARE_CPU_REV(omap34xx) {
+ CPU_REV(omap34xx, es1_0, 0x00),
+ CPU_REV(omap34xx, es2_0, 0x01),
+ CPU_REV(omap34xx, es2_1, 0x02),
+ CPU_REV(omap34xx, es3_0, 0x03),
+ CPU_REV(omap34xx, es3_1, 0x04),
+ CPU_REV(omap34xx, es3_1_2, 0x05),
+} ;
+
+DECLARE_CPU_REV(omap36xx) {
+ CPU_REV(omap36xx, es1_0, 0x00),
+ CPU_REV(omap36xx, es1_1, 0x01),
+}
Re: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
"Gopinath, Thara" writes: [...] >> >>> No reason why we should have a different file for OMAP4. So a better >>> name than opp3xxx_data.c? >> why do we need to have it in the same file? Remember, 3630,3430 are >> under OMAP3 family, but omap4 is considered a different arch. Code is more or less the same. Is that not a sufficient reason to reuse a file ? >>>I dont really care as long as opp layer is usable by mpurate without >>>depending on cpufreq and it is maintainable without going to if else >>>nightmare. But personally, I dont see really reusuable code in that file >>>(other than doing an opp addition in a loop) it could result eventually >>>in a large amount of code redundancy and maintenance nightmare with >>>OMAP4 variants coming in. > > Why do you say maintenance nightmare? It is going to be one opp table > per SoC. Anyways, Kevin what is your take on this? > I think we should keep separate files for each SoC listing the OPP data, and in those files should be *only* data. The init functions across these files will be basically the same, so maybe the common code should be pulled out into a separate file (pm.c?), and the data files have a very simple init function (device_initcall) that just registers their data. 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 0/2] Put OMAP2 SPI CS in unactive state when return from suspend
Gregory CLEMENT writes: > 2010/8/11 Kevin Hilman >> >> Gregory CLEMENT writes: >> >> > We notice that when system wake up from OFF mode, then CS is in >> > unactive state until the first SPI transfert. >> > For our design it lead to some conflict on this I/O. >> > Unactive state for CS when there is no transfert shoudl be the correct >> > behaviour: this is the purpose of these patches. >> >> This approach handles an off-mode transition during suspend, but if >> off-mode is enabled, you can also have an off-mode transition during >> idle. >> > > Well maybe I didn't use the correct words. > During the system life, I monitored the CS behaviour using a oscilloscope. > I also activate debug in omap2_mcspi, so I see when driver disable the > clocks and restore context when device is not used. > Each time the CS is in the correct state. It is only when there is a > suspend with the following configuration that on resume the CS is in > wrong state( ie activated) OK, that should be more clear in the changelog. The way I understood your description, the problem was related to an off-mode transition. > > echo 1 > /mnt/pm_debug/enable_off_mode > echo 0 > /mnt/pm_debug/core_pwrdm/suspend fyi... this part isn't needed. You're telling the OMAP PM core that you want the CORE powerdomain to go into off-mode, but you've you've already done that by the 'enable_off_mode' flag, which enables *all* powerdomains to hit off mode. > echo 1 > /mnt/pm_debug/voltage_off_while_idle > > >> >> Since you didn't describe what the conflicts you're seeing are, I would >> assume that you'll have the same problems in idle as in suspend, and >> this series doesn't address the idle case. > > I didn't see any problem in idle case, just when system resume from a > suspend to ram (echo mem > /sys/power/state) OK, I'd recommend you update the changelog to make that more clear. Then, I'll leave it to the SPI folks to review your patch. 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: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
>>-Original Message-
>>From: Menon, Nishanth
>>Sent: Wednesday, August 11, 2010 5:08 PM
>>To: Gopinath, Thara
>>Cc: Nishanth Menon; linux-omap; Eduardo Valentin; Kevin Hilman; Paul
>>Walmsley; Nayak, Rajendra;
>>Premi, Sanjeev; Tony Lindgren
>>Subject: Re: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
>>
>>On 08/11/2010 06:23 AM, Gopinath, Thara wrote:
>>>
>>>
> -Original Message-
> From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
> Sent: Wednesday, August 11, 2010 4:14 PM
> To: Gopinath, Thara
> Cc: Menon, Nishanth; linux-omap; Eduardo Valentin; Kevin Hilman; Paul
> Walmsley; Nayak, Rajendra;
> Premi, Sanjeev; Tony Lindgren
> Subject: Re: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
>
> On 08/11/2010 04:12 AM, Gopinath, Thara wrote:
>>
>>
-Original Message-
From: Menon, Nishanth
Sent: Wednesday, August 11, 2010 7:47 AM
To: linux-omap
Cc: Menon, Nishanth; Eduardo Valentin; Kevin Hilman; Paul Walmsley;
Nayak, Rajendra; Premi,
> Sanjeev;
Gopinath, Thara; Tony Lindgren
Subject: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
Make opp3xx data which is registered with the opp layer
dependent purely on CONFIG_PM as opp layer and pm.c users
are CONFIG_PM dependent not cpufreq dependent.
so we rename the data definition to opp3xxx_data.c (inline with what
we have for omap2), also move the build definition to be under
the existing CONFIG_PM build instead of CPUFREQ.
Cc: Eduardo Valentin
Cc: Kevin Hilman
Cc: Paul Walmsley
Cc: Rajendra Nayak
Cc: Sanjeev Premi
Cc: Thara Gopinath
Cc: Tony Lindgren
Signed-off-by: Nishanth Menon
---
Note:
This takes care of the discussion on opp file renaming and making
it independent of cpufreq, unless I missed something else
arch/arm/mach-omap2/Makefile |5 +
.../mach-omap2/{cpufreq34xx.c => opp3xxx_data.c} |0
2 files changed, 1 insertions(+), 4 deletions(-)
rename arch/arm/mach-omap2/{cpufreq34xx.c => opp3xxx_data.c} (100%)
>>
>> Is this part of PM-OPP branch? Also I was thinking of reusing the same
>> file for OMAP4.
> this defines the opp data base and would be part of pm-opp branch. the
> idea of rename was this:
> a) be clear that this is not dependent on cpufreq alone.
>>>
>>> I do not understand this. This files is not present in PM-OPP branch. But
>>> you have a patch
>>modifying it against PM-OPP branch. Am I looking at a wrong version of PM-OPP
>>branch?
>>you got me curious as well, my apologies, I had assumed things were how
>>they were before :( Looks like Kevin shuffled things around and the data
>>by itself is in cpufreq branch:
>>http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=refs/heads/pm-
>>cpufreq
>>
>>ergo, Kevin, do we need this cpufreq branch to contain the opp data:
>>http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-
>>pm.git;a=commitdiff;h=9f6847282f65cdcd26d740e6ae6afadc3ee00233
>>and related changes could potentially be pulled into the same pm-opp series?
>>
>>>
> b) use the same convention in arch/arm/mach-omap2/ like omap2's opp data
> files which could be converted to use the opp layer now instead of
> having it's own opp layer. and maybe hopefully omap1 as well..
> c) when we do specific product build, it makes sense to have arch
> specific files as it makes not much reason to carry the omap4/2
> definitions(even if init_data).
>
>> No reason why we should have a different file for OMAP4. So a better
>> name than opp3xxx_data.c?
> why do we need to have it in the same file? Remember, 3630,3430 are
> under OMAP3 family, but omap4 is considered a different arch.
>>>
>>> Code is more or less the same. Is that not a sufficient reason to reuse a
>>> file ?
>>I dont really care as long as opp layer is usable by mpurate without
>>depending on cpufreq and it is maintainable without going to if else
>>nightmare. But personally, I dont see really reusuable code in that file
>>(other than doing an opp addition in a loop) it could result eventually
>>in a large amount of code redundancy and maintenance nightmare with
>>OMAP4 variants coming in.
Why do you say maintenance nightmare? It is going to be one opp table per SoC.
Anyways, Kevin what is your take on this?
>>
>>Regards,
>>Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: PM debugfs removing OMAP3 hardcodings.
Thara Gopinath writes:
> This patch removes omap3 hardcodings from pm-debug.c
> so that enabling PM debugfs support does break compilation
> for other OMAP's. This is a preparatory patch for supporting
> OMAP4 pm entries through PM debugfs.
>
> Signed-off-by: Thara Gopinath
Looks good. Queuing to pm-fixes for 2.6.36-rc series.
Kevin
> ---
> arch/arm/mach-omap2/pm-debug.c | 21 -
> arch/arm/mach-omap2/pm34xx.c |5 -
> 2 files changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 723b44e..056ff17 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -37,6 +37,10 @@
> #include "pm.h"
>
> int omap2_pm_debug;
> +u32 enable_off_mode;
> +u32 sleep_while_idle;
> +u32 wakeup_timer_seconds;
> +u32 wakeup_timer_milliseconds;
>
> #define DUMP_PRM_MOD_REG(mod, reg)\
> regs[reg_count].name = #mod "." #reg; \
> @@ -494,8 +498,10 @@ int pm_dbg_regset_init(int reg_set)
>
> static int pwrdm_suspend_get(void *data, u64 *val)
> {
> - int ret;
> - ret = omap3_pm_get_suspend_state((struct powerdomain *)data);
> + int ret = -EINVAL;
> +
> + if (cpu_is_omap34xx())
> + ret = omap3_pm_get_suspend_state((struct powerdomain *)data);
> *val = ret;
>
> if (ret >= 0)
> @@ -505,7 +511,10 @@ static int pwrdm_suspend_get(void *data, u64 *val)
>
> static int pwrdm_suspend_set(void *data, u64 val)
> {
> - return omap3_pm_set_suspend_state((struct powerdomain *)data, (int)val);
> + if (cpu_is_omap34xx())
> + return omap3_pm_set_suspend_state(
> + (struct powerdomain *)data, (int)val);
> + return -EINVAL;
> }
>
> DEFINE_SIMPLE_ATTRIBUTE(pwrdm_suspend_fops, pwrdm_suspend_get,
> @@ -553,8 +562,10 @@ static int option_set(void *data, u64 val)
>
> *option = val;
>
> - if (option == &enable_off_mode)
> - omap3_pm_off_mode_enable(val);
> + if (option == &enable_off_mode) {
> + if (cpu_is_omap34xx())
> + omap3_pm_off_mode_enable(val);
> + }
>
> return 0;
> }
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index fb4994a..9c0301b 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -55,11 +55,6 @@
> #define OMAP343X_TABLE_VALUE_OFFSET 0x30
> #define OMAP343X_CONTROL_REG_VALUE_OFFSET 0x32
>
> -u32 enable_off_mode;
> -u32 sleep_while_idle;
> -u32 wakeup_timer_seconds;
> -u32 wakeup_timer_milliseconds;
> -
> struct power_state {
> struct powerdomain *pwrdm;
> u32 next_state;
--
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 v.4] omap: hwspinlock: Added hwspinlock driver
"Basak, Partha" writes:
>> +/* Attempt to acquire a spinlock once */
>> +int hwspinlock_trylock(struct hwspinlock *handle)
>> +{
>> + int retval = 0;
>> +
>> + if (WARN_ON(handle == NULL))
>> + return -EINVAL;
>> +
>> + if (WARN_ON(in_irq()))
>> + return -EPERM;
>> +
>> + if (pm_runtime_get(&handle->pdev->dev) < 0)
>> + return -ENODEV;
>> +
>> + /* Attempt to acquire the lock by reading from it */
>> + retval = readl(handle->lock_reg);
>> +
>> + if (retval == HWSPINLOCK_BUSY)
>> + pm_runtime_put(&handle->pdev->dev);
>
> Any reason for using pm_runtime_put instead of pm_runtime_put_sync?
>
> Using pm_runtime_gett_sync & pm_runtime_put_sync have been recommended
> by Kevin Hilman.
err, not exacly.
I recommend use of the runtime PM API. Driver writers can decide
whether they want to use the _sync() version of the API (which has
immediate side effect) or the normal version which may have delayed side
effect.
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: dspbridge and the omapl1x
Hari and Mugdha, On Wed, Aug 11, 2010 at 7:35 PM, Hari Kanigeri wrote: > On Wed, Aug 11, 2010 at 2:25 PM, Ben Gardiner > wrote: >> On Wed, Aug 11, 2010 at 12:55 PM, Hari Kanigeri >> wrote: >>> We are working on making some of core functionalities such as DMM, >>> resource Management, reset Management of co-processors generic for >>> any IPC to use. So if DSPLink is missing DMM functionality then it >>> should be just the matter of DSPLink adapting to this. >> >> I don't get what you're trying to say here, sorry. Would DSPLink be >> one of the IPCs for which the 'core functionalities' could be adapted? > > May be let's re-visit this point when the RFC is send on my above > mentioned features. > >> Could you explain an example of how DMM being made generic for any IPC >> to use could be applied to DSPLink? > > Basically today the Dynamic memory management is handled by DSPBridge. > So the userspace clients talk to DSPBridge, and DSPBridge in turn > talks to IOMMU to map the user passed Buffers. DSPBridge is managing > the virtual address space of DSP in this case. > So basically where we are going is replacing DSPBridge's DMM module > with a generic Kernel module that can handle the DMM for any given > number of Co-Processors. OMAP3 has only Co-Processor, where as OMAP4 > has 2 Co-Processors. The solution should be generic to handle any > number of Devices. > I will try to send an RFC of this implementation and I would love to > get feedback from you. I would be happy to review the RFC. > In case if you want to get some information on how the Dynamic memory > mapping works, you can refer pages 12-15 of this presentation > https://gforge.ti.com/gf/download/docmanfileversion/17/674/OMAP3430_Bridge_overview.pdf Thank you for the link; the diagram on page 13 was most helpful in solidifying my understanding of the IOMMU to which your are referring in your explanation of DMM above and in the roadmap below. >>> On a high level, this is what needs to be done to provide support for OMAP1. >>> >>> 1. Adapt to iommu. Add support if the support is not present for OMAP1. Gulp. This could be a problem. Thanks to your link above I now understand that the iommu which is controlled by dspbridge and facilitates the use by the DSP of scattered pages allocated on the ARM side is an MMU _separate_ from that of the ARM. The OMAP3430 obviously has an MMU for the DSP Side [1] but I can't find any documentation indicating that the OMAP L138 has a DSP-side MMU. On Thu, Aug 12, 2010 at 2:16 AM, Kamoolkar, Mugdha wrote: > One thing I would like to mention is that the DMM feature does require the > slave DSP to have an MMU. The OMAPL1xx devices do not have MMU for the DSP. > DMM cannot be implemented without the DSP having an MMU. Hence, even if you > ported DSPBridge to OMAPL1xx devices, you could not make use of the DMM > feature. Thank you, Mugdha, for reading my mind and confirming that there is no MMU on the omapL1x -- I saved a draft of this email last night and was going to do some more research to confirm myself but you saved me the trouble. On Thu, Aug 12, 2010 at 2:16 AM, Kamoolkar, Mugdha wrote: > You are correct that dynamic linking and loading is a feature that is > available in DSPBridge, and which is missing in DSPLink, which could work on > OMAPL1xx if you ported DSPBridge to OMAPL1xx I imagined that the lack of MMU would be a blocker in porting dspbridge since it would be impossible to support scattered (in PAs) pages on the DSP-side. But Mugdha makes it sound like the port could be accomplished with DMM omitted. Also I believe that the new Contiguous Memory Allocation (CMA) framework was developed specifically for systems that need to allocate physically contiguous memory because they don't have an MMU. What would say to avoiding the IOMMU requirement and keeping DMM by using physically contiguous dynamically allocated memory regions like those provided by the new CMA [2]? On Wed, Aug 11, 2010 at 7:35 PM, Hari Kanigeri wrote: >>> 2. Adapt to mailbox On Thu, Aug 12, 2010 at 2:16 AM, Kamoolkar, Mugdha wrote: > Also, OMAPL1xx devices do not use mailbox interrupts. They have a different > type of IPC interrupt, which is not mailbox. So a different kind of > abstraction would be required to be able to use either mailbox or this > different IPC interrupt. Good point. I believe that currently it is DSPLink which provides a mailbox implemented on top of the available IPC interrupt on the L13x. If re-using DSPLink in the dspbridge's baseimage is still overkill then we at least have code in DSPLink from which to base the standalone driver code. On Wed, Aug 11, 2010 at 7:35 PM, Hari Kanigeri wrote: >>> 3. Reset and Power management adaptation for OMAP1. >> >> Thanks for the roadmap. This doesn't sound too daunting, but that >> could be because I am ignorant of the details. :) > > I forgot to add item 4. "Surprises" :) :) I think we ran into a big one. Best Regards, Ben Gardiner [1] http://www
Re: [PATCH 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of sys_dev_class
"Basak, Partha" writes: [...] >> >> >> >> Why is this better than passing the next power state? >> > >> > This would keep the GPIO function omap2_gpio_prepare_for_idle agnostic >> of Power state definition dependencies. >> > >> >> And why is this better? >> >> Personally, I think the GPIO code should be told about the powerdomain >> state so it can make it's own decision about whether or not to save >> context. >> > > I see your point. > > But, in the approach we have followed so far, we are trying to > localize all Power domain related logic and information in > pm_34xxx.c. If we refer to all other such functions like > omap_uart_prepare_idle(),omap3_intc_prepare_idle(), > musb_context_save_restore()(newly introduced by USB patches for > HWMOD), they are all following the same paradigm. None of these > functions receive the Power state information as a parameter. The idea > is to segregate the Power domain related information into the power > layer. > > In omap2_gpio_prepare_for_idle() implementation, we are just being > consistent with this approach. > Yes, you're following the existing approach, but the existing approach is wrong, so I'm suggesting you change. There was no common design for any of these, and they all behave slightly differently. For example, we should be passing the power state in the UART hook so the UART code doesn't have to check 'enable_off_mode' to know whether or not to save context. IOW, instead of keeping the decision making centralized in the PM core, we should just be notifiying the drivers about the state change. The idle loop is kept simple, and all the inteligence should be in the drivers. Also, the PM core should no be telling a module to save context. It should be notifying the module of a state change. IOW, instead of calling these functions save/restore context, they should be called prepare/resume idle. In the linux-pm community, there are increasing discussions on how to combine CPUidle and runtime PM. So in the medium term, we'll probably be coming up with a more standard way for the idle path to notify drivers using runtime PM. Until that happens, all these prepare/resume idle hooks are just temporary. 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] OMAP3: PM: ensure IO wakeups are properly disabled
Ameya Palande writes:
> Hi Kevin,
>
> On Wed, 2010-08-11 at 18:03 +0200, ext Kevin Hilman wrote:
>> From: Kevin Hilman
>>
>> Commit 5a5f561 (convert OMAP3 PRCM macros to the _SHIFT/_MASK suffixes)
>> mistakenly removed the check for PER when disabling the IO chain.
>>
>> During idle, if the PER powerdomain transitions and CORE does not (as
>> is the case with the lower C-states when using CPUidle) the IO pad
>> wakeups are not being disabled in the idle path after they are
>> enabled.
>>
>> This patch ensures that the check for disabling IO wakeups also checks
>> for PER transitions, matching the check done to enable IO wakeups.
>>
>> Found when debugging PM/CPUidle related problems reported by Ameya
>> Palande . Problems were triggered
>> particularily on boards with UART2 consoles (n900, Overo) since UART2
>> is in the PER powerdomain.
>>
>> Tested on l-o master (omap3_defonfig + CONFIG_CPU_IDLE=y) as well
>> as with current PM branch. Boards tested: n900, Overo, omap3evm.
>>
>> Cc: Paul Walmsley
>> Cc: Ameya Palande
>> Tested-by: Jarkko Nikula
>> Signed-off-by: Kevin Hilman
>> ---
>> Tony, this should go in with fixes for -rc2
>>
>> Changes since v1
>> - added a bit of history about where the problem was created
>> - added 'Tested-by' for Jarkko
>>
>> arch/arm/mach-omap2/pm34xx.c |4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index fb4994a..7b03426 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -480,7 +480,9 @@ void omap_sram_idle(void)
>> }
>>
>> /* Disable IO-PAD and IO-CHAIN wakeup */
>> -if (omap3_has_io_wakeup() && core_next_state < PWRDM_POWER_ON) {
>> +if (omap3_has_io_wakeup() &&
>> +(per_next_state < PWRDM_POWER_ON ||
>> + core_next_state < PWRDM_POWER_ON)) {
>> prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
>> omap3_disable_io_chain();
>> }
>
> Thanks for your fix!
> I tried out following patch on n900 kernel (based on 2.6.35 mainline)
> hosted at: http://gitorious.org/nokia-n900-kernel
>
> Patch:
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index b88737f..887242d 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -479,7 +479,8 @@ void omap_sram_idle(void)
> }
>
> /* Disable IO-PAD and IO-CHAIN wakeup */
> - if (core_next_state < PWRDM_POWER_ON) {
> + if (per_next_state < PWRDM_POWER_ON ||
> + core_next_state < PWRDM_POWER_ON) {
> prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
> PM_WKEN);
> omap3_disable_io_chain();
> }
>
> And got following WARNING after sometime:
>
> [ 109.394714] [ cut here ]
> [ 109.399414] WARNING: at arch/arm/mach-omap2/pm34xx.c:292
> prcm_interrupt_handler+0xb4/0x108()
> [ 109.407897] prcm: WARNING: PRCM indicated MPU wakeup but no wakeup
> sources are marked
Since you're using a custom kernel (that I didn't look at), it's
difficult to guess what is happening here. Can you reproduce this using
the PM branch or l-o master? One thing is certain is that this is not
related to $SUBJECT patch.
There are lots of other events that can potentially trigger PRCM
interrupts: DPLL recalibration events, voltage processor events (usually
triggered by SR.)
But in this case, it looks like there may be a problem with interrupts
being enabled prematurely as well. An interrupt fires in the
CPUidle path, is serviced and upon exit soft IRQs run. During the
soft IRQ, the PRCM interrupt fires and triggers this warning.
Before I do any more digging, I'd like to know if this is reproducable
on l-o master or the PM branch.
Kevin
> [ 109.415771] Modules linked in: sco bnep l2cap bluetooth ipv6
> wl1251_spi wl1251 omaplfb pvrsrvkm cmt_speech mac80211 ssi_protocol hsi_
> char cmt omap_ssi crc7 g_ether tsl2563(C) industrialio(C) rtc_twl
> rtc_core twl4030_pwrbutton gpio_keys
> [ 109.437042] [] (unwind_backtrace+0x0/0x168) from
> [] (warn_slowpath_common+0x4c/0x64)
> [ 109.446594] [] (warn_slowpath_common+0x4c/0x64) from
> [] (warn_slowpath_fmt+0x2c/0x3c)
> [ 109.456237] [] (warn_slowpath_fmt+0x2c/0x3c) from
> [] (prcm_interrupt_handler+0xb4/0x108)
> [ 109.466125] [] (prcm_interrupt_handler+0xb4/0x108) from
> [] (handle_IRQ_event+0x24/0xe0)
> [ 109.475952] [] (handle_IRQ_event+0x24/0xe0) from
> [] (handle_level_irq+0xd4/0x180)
> [ 109.485260] [] (handle_level_irq+0xd4/0x180) from
> [] (asm_do_IRQ+0x6c/0x8c)
> [ 109.494018] [] (asm_do_IRQ+0x6c/0x8c) from []
> (__irq_svc+0x48/0xa8)
> [ 109.502075] Exception stack(0xc0481eb0 to 0xc0481ef8)
> [ 109.507141] 1ea0: 0020
> c04866f0 c048 c04db080
> [ 109.515380] 1ec0: c048 0202 0002 000a
> c048 c04db080
> [ 109.523620] 1ee
Re: dspbridge and the omapl1x
Mugdha, On Thu, Aug 12, 2010 at 1:16 AM, Kamoolkar, Mugdha wrote: > Ben, > >> >> >> > >> > I'm still not sure about the iommu features required by dspbridge, I >> > will need to look into this. But 2+3 sound like they could be provided >> > by DSPLink itself. Would it be sane to put dspbridge on top of >> > DSPLink? Just to sound it out, the DSP-side base image could be >> > DSPBios + DSPLink (DSP-side) and the ARM-side would be made of >> > dspbridge where the IPC is DSP Link 'compatible'. This could avoid a >> > rewrite of the DSP-side of dspbridge maybe? >> >> Probably over-kill to get the features you want. > iommu could not be adapted for OMAPL1xx since it abstracts the DSP MMU, which > is non-existent on OMAPL1xx devices. > > Also, OMAPL1xx devices do not use mailbox interrupts. They have a different > type of IPC interrupt, which is not mailbox. So a different kind of > abstraction would be required to be able to use either mailbox or this > different IPC interrupt. Thanks for providing information on OMAPL1xx devices. I wasn't aware of OMAP1 architecture. 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
omap3630: cpu revision bits are different
Hi all, While re working on the cpu revision patch, I came across these definitions: #define OMAP3630_REV_ES1_0 0x36300034 #define OMAP3630_REV_ES1_1 0x36300134 #define OMAP3630_REV_ES1_2 0x36300234 Contrast this with: #define OMAP3430_REV_ES1_0 0x34300034 #define OMAP3430_REV_ES2_0 0x34301034 #define OMAP3430_REV_ES2_1 0x34302034 I may have missed the discussion on this list, but wanted to quickly check if the difference in intended OR accidental. I do recognize that definitions for 3630 start at lower nibble, so they appear to be better choice. 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
RE: [PATCH 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of sys_dev_class
> > > -Original Message- > > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > > Sent: Tuesday, August 10, 2010 5:51 AM > > To: Varadarajan, Charulatha > > Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Nayak, > > Rajendra; Basak, Partha > > Subject: Re: [PATCH 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of > > sys_dev_class > > > > Charulatha V writes: > > > > > This patch makes GPIO driver to use dev_pm_ops instead of > > > sysdev_class. With this approach, gpio_bank_suspend & gpio_bank_resume > > > are not part of sys_dev_class. > > > > > > According to this patch, a GPIO bank relinquishes the clock using > > > PM runtime APIs when all the gpios in that bank are freed. > > > > This does not match the code. > > > > The only clock associated with a GPIO hwmod is the optional clock for > > the debounce clock. This clock is managed by the driver itself, not > > by using the PM runtime API. > > > > > It also > > > relinquishes the clocks in the idle-path too, as it is possible to > > > have a GPIO bank requested and still allow PER domain to go to OFF > > state. > > > > This doesn't make sense to me. What clocks are you referring to? > > > > The main clock is there for OMAP24xx, but not relevant for OMAP3 & 4. > Are you aligned? > > > In the idle path (interrupt disabled context), PM runtime APIs cannot > > > be used as they are not mutex-free functions. Hence omap_device APIs > > > are used in the idle and resume after idle path. > > > > This needs much more fleshing out. > > > > Exactly what mutexes are causing the problems here. As pointed out in > > previous discussions, the ones in the PM runtime core should not be a > > problem in this path. Therefore, I'll assume the problems are coming > > from the mutexes when the device code (mach-omap2/gpio.c) calls into the > > hwmod layer. More on this in comments on the next patch. > > > > Sorry, this has not been documented correctly. The issue has more to do > unconditional enabling of interrupts. We have received a patch from you on > using pm_runtime functions in Idle path. We will try on GPIO and revert > back. > > > > > > > > >> > To summarize, > > >> > 1. pm_runtime_get_sync() for any gpio bank is called when one of > the > > >> gpios > > >> >is requested on the bank, in which, no other gpio is being used > > (when > > >> >mod_usage becomes non-zero) > > >> > 2. omap_device_enable() is called during gpio resume after idle, > only > > >> >if the particular bank is being used (if mod_usage is non-zero) > > >> > > >> context is saved/restored in the idle path, but... > > >> > > >> > 3. pm_runtime_put_sync() is called when the last used gpio in that > > >> >gpio bank is freed (when mod_usage becomes zero) > > >> > > >> in this path, the bank is now runtime suspended, but context has not > > >> been saved for it. That should be fine, since this bank is no longer > > >> used, but now let's assume there was an off-mode transition and > context > > >> is lost. Then, gpio_request() is called which will trigger > > >> a pm_runtime_get_sync() and gpio_bank_runtime_resume() will be > called. > > >> > > >> In this case, it's not terribly clear that runtime_resume is doing > sane > > >> things if context has just been lost. Seems like runtime_resume > should > > >> be a nop in this case since any re-init will be be done in > > gpio_request(). > > > > > > Runtime_suspend/resume for GPIO is not doing any save/restore > > > context. In that sense, they are NOP. Context save/restore is taken > > > care of only in the Idle path based on target power state and last > > > power state respectively. > > > > OK, I didn't explain the problem I'm suspecting very well. Imagine this > > sequence of events: > > > > - mod_usage becomes zero > > - pm_runtime_put_sync() > > - gpio_bank_runtime_suspend() [ no context is saved ] > > [ off-mode transition, context is lost] > > - gpio_request() > > - pm_runtime_get_sync() > > - gpio_bank_runtime_resume() > > > > In this path, no context is saved, and no context is restored, which is > > what I would expect, since there's no need to save context if nobody is > > using that gpio bank anymore. However, gpio_bank_runtime_resume() is > > doing lots of reads/writes and read-modify-writes on GPIO bank registers > > that may have undefined contents after a context loss. > > Agreed. This can be resolved by saving the Init configurations when a GPIO bank is released & restoring the same during GPIO bank request. > > The point is that the GPIO register twiddling in > > gpio_bank_runtime_resume() does not seem to be needed if there are no > > users of that GPIO bank. > > Can you elaborate more? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 10/13 v5] OMAP: GPIO: Implement GPIO as a platform device
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, August 11, 2010 11:17 AM
> To: Basak, Partha
> Cc: Kevin Hilman; Varadarajan, Charulatha; linux-omap@vger.kernel.org;
> Cousson, Benoit; Nayak, Rajendra
> Subject: RE: [PATCH 10/13 v5] OMAP: GPIO: Implement GPIO as a platform
> device
>
> On Tue, 10 Aug 2010, Basak, Partha wrote:
>
> > As per our discussion with Paul & you during workshop, I believe,
> > optional clock control should be done using clock APIs. So, I would go
> > by your suggestion 1 of exposing an API to expose the optional clocks in
> > the hwmod, something like:
> >
> > struct omap_hwmod_opt_clk * omap_hwmod_get_opt_clks(struct omap_hwmod
> > *oh);
> >
> > If agreed, Charu will send updated patch.
>
> This should be done by modifying the hwmod code to call clk_add_alias()
> for the clock names for the optional clocks. I don't think any extra API
> is needed.
>
Lets see, if I got it right:
Refer to the OMAP3 hwmod data-base (omap_hwmod_3xxx.c):
static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
{ .role = "dbclk", .clk = "gpio1_dbck", },
};
Clock database(Clock3xxx_data.c):
CLK(NULL, "gpio1_dbck", &gpio1_dbck,CK_3XXX),
Refer to the OMAP4 hwmod database(omap_hwmod_44xx.c):
static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
{ .role = "dbclk", .clk = "sys_32k_ck" },
Clock database(Clock44xx_data.c):
CLK(NULL, "sys_32k_ck", &sys_32k_ck,CK_443X),
/*int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
struct device *dev);*/
I believe, you are suggesting to do the following in the hwmod framework, say
_setup(?):
clk_add_alias ( opt_clks.role,
oh->od.pdev.name,
opt_clks.clk,
NULL);
Then, from the driver, we can simply do a
clk_get(dev_ptr,
"dbclk">); /*hard-coded in the driver to be
sameas in the hwmod database*/
>
> - Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: OMAP: Beagle: revision detection
On Thu, Aug 12, 2010 at 7:00 AM, Tony Lindgren wrote:
> * Robert Nelson [100812 02:30]:
>> Due to the omap3530 ES3.0 Silicon being used on both the
>> B5/B6 and C1/2/3 Beagle we can't use the cpu_is_omap34xx()
>> routines to differentiate the Beagle Boards.
>>
>> However gpio pins 171,172,173 where setup for this prupose, so
>> lets use them.
>
>
>
>> --- a/arch/arm/plat-omap/include/plat/board.h
>> +++ b/arch/arm/plat-omap/include/plat/board.h
>> @@ -26,6 +26,22 @@ enum {
>> OMAP3EVM_BOARD_GEN_2, /* EVM Rev >= Rev E */
>> };
>>
>> +/*
>> + * OMAP3 Beagle revision
>> + * Run time detection of Beagle revision is done by reading GPIO.
>> + * GPIO ID -
>> + * AXBX = GPIO173, GPIO172, GPIO171: 1 1 1
>> + * C1_3 = GPIO173, GPIO172, GPIO171: 1 1 0
>> + * C4 = GPIO173, GPIO172, GPIO171: 1 0 1
>> + * XM = GPIO173, GPIO172, GPIO171: 0 0 0
>> + */
>> +enum {
>> + OMAP3BEAGLE_BOARD_AXBX = 0,
>> + OMAP3BEAGLE_BOARD_C1_3,
>> + OMAP3BEAGLE_BOARD_C4,
>> + OMAP3BEAGLE_BOARD_XM,
>> +};
>> +
>> /* Different peripheral ids */
>> #define OMAP_TAG_CLOCK 0x4f01
>> #define OMAP_TAG_LCD 0x4f05
>> @@ -173,4 +189,11 @@ u8 get_omap3_evm_rev(void);
>> #else
>> #define get_omap3_evm_rev() (-EINVAL)
>> #endif
>> +
>> +/* Beagle revision */
>> +#if defined(CONFIG_MACH_OMAP3_BEAGLE)
>> +u8 get_omap3_beagle_rev(void);
>> +#else
>> +#define get_omap3_beagle_rev() (-EINVAL)
>> +#endif
>> #endif
>
(Crap re cc-ing group)
Thanks Tony
> You should be able to keep this all in board-omap3beagle.c,
> no need for the header. If this header is needed somewhere
> else, chances are that something is wrong.
>
Yeah, I can do that instead, i don't see it really leaving board-omap3beagle.c..
I was using the existing "get_omap3_evm_rev" routines as an
inspiration and reference..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
--
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/3] ARM: OMAP: Beagle: revision detection
* Robert Nelson [100812 02:30]:
> Due to the omap3530 ES3.0 Silicon being used on both the
> B5/B6 and C1/2/3 Beagle we can't use the cpu_is_omap34xx()
> routines to differentiate the Beagle Boards.
>
> However gpio pins 171,172,173 where setup for this prupose, so
> lets use them.
> --- a/arch/arm/plat-omap/include/plat/board.h
> +++ b/arch/arm/plat-omap/include/plat/board.h
> @@ -26,6 +26,22 @@ enum {
> OMAP3EVM_BOARD_GEN_2, /* EVM Rev >= Rev E */
> };
>
> +/*
> + * OMAP3 Beagle revision
> + * Run time detection of Beagle revision is done by reading GPIO.
> + * GPIO ID -
> + * AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
> + * C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
> + * C4 = GPIO173, GPIO172, GPIO171: 1 0 1
> + * XM = GPIO173, GPIO172, GPIO171: 0 0 0
> + */
> +enum {
> + OMAP3BEAGLE_BOARD_AXBX = 0,
> + OMAP3BEAGLE_BOARD_C1_3,
> + OMAP3BEAGLE_BOARD_C4,
> + OMAP3BEAGLE_BOARD_XM,
> +};
> +
> /* Different peripheral ids */
> #define OMAP_TAG_CLOCK 0x4f01
> #define OMAP_TAG_LCD 0x4f05
> @@ -173,4 +189,11 @@ u8 get_omap3_evm_rev(void);
> #else
> #define get_omap3_evm_rev() (-EINVAL)
> #endif
> +
> +/* Beagle revision */
> +#if defined(CONFIG_MACH_OMAP3_BEAGLE)
> +u8 get_omap3_beagle_rev(void);
> +#else
> +#define get_omap3_beagle_rev() (-EINVAL)
> +#endif
> #endif
You should be able to keep this all in board-omap3beagle.c,
no need for the header. If this header is needed somewhere
else, chances are that something is wrong.
For the drivers, you should be able to pass the necessary
flags via platform_data if needed.
Regards,
Tony
--
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] OMAP3: PM: ensure IO wakeups are properly disabled
On Thu, 2010-08-12 at 13:51 +0200, ext Tony Lindgren wrote:
> * Ameya Palande [100812 13:28]:
> > Hi Kevin,
> >
> > On Wed, 2010-08-11 at 18:03 +0200, ext Kevin Hilman wrote:
> > > From: Kevin Hilman
> > >
> > > Commit 5a5f561 (convert OMAP3 PRCM macros to the _SHIFT/_MASK suffixes)
> > > mistakenly removed the check for PER when disabling the IO chain.
> > >
> > > During idle, if the PER powerdomain transitions and CORE does not (as
> > > is the case with the lower C-states when using CPUidle) the IO pad
> > > wakeups are not being disabled in the idle path after they are
> > > enabled.
> > >
> > > This patch ensures that the check for disabling IO wakeups also checks
> > > for PER transitions, matching the check done to enable IO wakeups.
> > >
> > > Found when debugging PM/CPUidle related problems reported by Ameya
> > > Palande . Problems were triggered
> > > particularily on boards with UART2 consoles (n900, Overo) since UART2
> > > is in the PER powerdomain.
> > >
> > > Tested on l-o master (omap3_defonfig + CONFIG_CPU_IDLE=y) as well
> > > as with current PM branch. Boards tested: n900, Overo, omap3evm.
> > >
> > > Cc: Paul Walmsley
> > > Cc: Ameya Palande
> > > Tested-by: Jarkko Nikula
> > > Signed-off-by: Kevin Hilman
> > > ---
> > > Tony, this should go in with fixes for -rc2
> > >
> > > Changes since v1
> > > - added a bit of history about where the problem was created
> > > - added 'Tested-by' for Jarkko
> > >
> > > arch/arm/mach-omap2/pm34xx.c |4 +++-
> > > 1 files changed, 3 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> > > index fb4994a..7b03426 100644
> > > --- a/arch/arm/mach-omap2/pm34xx.c
> > > +++ b/arch/arm/mach-omap2/pm34xx.c
> > > @@ -480,7 +480,9 @@ void omap_sram_idle(void)
> > > }
> > >
> > > /* Disable IO-PAD and IO-CHAIN wakeup */
> > > - if (omap3_has_io_wakeup() && core_next_state < PWRDM_POWER_ON) {
> > > + if (omap3_has_io_wakeup() &&
> > > + (per_next_state < PWRDM_POWER_ON ||
> > > + core_next_state < PWRDM_POWER_ON)) {
> > > prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
> > > omap3_disable_io_chain();
> > > }
> >
> > Thanks for your fix!
> > I tried out following patch on n900 kernel (based on 2.6.35 mainline)
> > hosted at: http://gitorious.org/nokia-n900-kernel
> >
> > Patch:
> >
> > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> > index b88737f..887242d 100644
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -479,7 +479,8 @@ void omap_sram_idle(void)
> > }
> >
> > /* Disable IO-PAD and IO-CHAIN wakeup */
> > - if (core_next_state < PWRDM_POWER_ON) {
> > + if (per_next_state < PWRDM_POWER_ON ||
> > + core_next_state < PWRDM_POWER_ON) {
> > prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
> > PM_WKEN);
> > omap3_disable_io_chain();
> > }
> >
> > And got following WARNING after sometime:
>
> So what's the deal, is this ack or nak for Kevin's patch then?
Kevin's patch seems to fix the serial port issue for sure, so we
definitely need it. I just wanted to point out that there are more issue
in CPUIDLE :)
Cheers,
Ameya.
--
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/3] ARM: OMAP: Beagle: revision detection
On Thu, Aug 12, 2010 at 2:03 AM, Jarkko Nikula wrote:
> Hi
>
> On Wed, 11 Aug 2010 18:37:40 -0500
> Robert Nelson wrote:
>
>> Due to the omap3530 ES3.0 Silicon being used on both the
>> B5/B6 and C1/2/3 Beagle we can't use the cpu_is_omap34xx()
>> routines to differentiate the Beagle Boards.
>>
>> However gpio pins 171,172,173 where setup for this prupose, so
>> lets use them.
>>
>> Tested on Beagle Revisions: B5, C2, C4, and xMA
>>
>> Signed-off-by: Robert Nelson
>> ---
>> arch/arm/mach-omap2/board-omap3beagle.c | 60
>> +++
>> arch/arm/plat-omap/include/plat/board.h | 23
>> 2 files changed, 83 insertions(+), 0 deletions(-)
>>
> ...
>> + beagle_rev = gpio_get_value(171) | (gpio_get_value(172) << 1)
>> + | (gpio_get_value(173) << 2);
>> +
>> + switch (beagle_rev) {
>> + case 7:
>> + printk(KERN_INFO "OMAP3 Beagle Rev: Ax/Bx\n");
>> + omap3_beagle_version = OMAP3BEAGLE_BOARD_AXBX;
>> + break;
>> + case 6:
>> + printk(KERN_INFO "OMAP3 Beagle Rev: C1/C2/C3\n");
>> + omap3_beagle_version = OMAP3BEAGLE_BOARD_C1_3;
>> + break;
>> + case 5:
>> + printk(KERN_INFO "OMAP3 Beagle Rev: C4\n");
>> + omap3_beagle_version = OMAP3BEAGLE_BOARD_C4;
>> + break;
>> + case 0:
>> + printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
>> + omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
>> + break;
>> + default:
>> + printk(KERN_INFO "OMAP3 Beagle Rev: unknown %hd\n",
>> beagle_rev);
>> + omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
>> + }
>
> My C2 reads as 2 and I have U-Boot 2009.01-dirty (Feb 19 2009 -
> 12:22:31). I believe these pins are not muxed correctly with that
> U-Boot version.
Thanks for testing Jarkko, i had been using U-Boot 2010.03.. So it
looked like we could use the more generic gpio routines, but i'll swap
to the omap_mux_init_gpio and retest on my systems..
>
> Therefore kernel should remux those pins so that version is detected
> right independently of bootloader version. Detections works fine if I
> add these:
>
> omap_mux_init_gpio(171, OMAP_PIN_INPUT_PULLUP);
> omap_mux_init_gpio(172, OMAP_PIN_INPUT_PULLUP);
> omap_mux_init_gpio(173, OMAP_PIN_INPUT_PULLUP);
>
>
> --
> Jarkko
>
--
Robert Nelson
http://www.rcn-ee.com/
--
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] OMAP3: PM: ensure IO wakeups are properly disabled
* Ameya Palande [100812 13:28]:
> Hi Kevin,
>
> On Wed, 2010-08-11 at 18:03 +0200, ext Kevin Hilman wrote:
> > From: Kevin Hilman
> >
> > Commit 5a5f561 (convert OMAP3 PRCM macros to the _SHIFT/_MASK suffixes)
> > mistakenly removed the check for PER when disabling the IO chain.
> >
> > During idle, if the PER powerdomain transitions and CORE does not (as
> > is the case with the lower C-states when using CPUidle) the IO pad
> > wakeups are not being disabled in the idle path after they are
> > enabled.
> >
> > This patch ensures that the check for disabling IO wakeups also checks
> > for PER transitions, matching the check done to enable IO wakeups.
> >
> > Found when debugging PM/CPUidle related problems reported by Ameya
> > Palande . Problems were triggered
> > particularily on boards with UART2 consoles (n900, Overo) since UART2
> > is in the PER powerdomain.
> >
> > Tested on l-o master (omap3_defonfig + CONFIG_CPU_IDLE=y) as well
> > as with current PM branch. Boards tested: n900, Overo, omap3evm.
> >
> > Cc: Paul Walmsley
> > Cc: Ameya Palande
> > Tested-by: Jarkko Nikula
> > Signed-off-by: Kevin Hilman
> > ---
> > Tony, this should go in with fixes for -rc2
> >
> > Changes since v1
> > - added a bit of history about where the problem was created
> > - added 'Tested-by' for Jarkko
> >
> > arch/arm/mach-omap2/pm34xx.c |4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> > index fb4994a..7b03426 100644
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -480,7 +480,9 @@ void omap_sram_idle(void)
> > }
> >
> > /* Disable IO-PAD and IO-CHAIN wakeup */
> > - if (omap3_has_io_wakeup() && core_next_state < PWRDM_POWER_ON) {
> > + if (omap3_has_io_wakeup() &&
> > + (per_next_state < PWRDM_POWER_ON ||
> > +core_next_state < PWRDM_POWER_ON)) {
> > prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
> > omap3_disable_io_chain();
> > }
>
> Thanks for your fix!
> I tried out following patch on n900 kernel (based on 2.6.35 mainline)
> hosted at: http://gitorious.org/nokia-n900-kernel
>
> Patch:
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index b88737f..887242d 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -479,7 +479,8 @@ void omap_sram_idle(void)
> }
>
> /* Disable IO-PAD and IO-CHAIN wakeup */
> - if (core_next_state < PWRDM_POWER_ON) {
> + if (per_next_state < PWRDM_POWER_ON ||
> + core_next_state < PWRDM_POWER_ON) {
> prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
> PM_WKEN);
> omap3_disable_io_chain();
> }
>
> And got following WARNING after sometime:
So what's the deal, is this ack or nak for Kevin's patch then?
Tony
--
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] OMAP2: Fix a cpu type check problem.
* Igor Grinberg [100811 14:29]: > On 08/11/10 13:27, Tony Lindgren wrote: > > * Premi, Sanjeev [100811 12:45]: > > > >>> -Original Message- > >>> From: linux-omap-ow...@vger.kernel.org > >>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren > >>> Sent: Wednesday, August 11, 2010 2:50 PM > >>> To: Igor Grinberg > >>> Cc: Stanley.Miao; linux-omap@vger.kernel.org > >>> Subject: Re: [PATCH] OMAP2: Fix a cpu type check problem. > >>> > >>> * Igor Grinberg [100810 17:25]: > >>> > On 08/10/10 15:36, Stanley.Miao wrote: > > > cpu_is_omap3517() and cpu_is_omap3505() are the subgroups > > > >>> of cpu_is_omap34xx(), > >>> > > so we should check cpu_is_omap3517() and > > > >>> cpu_is_omap3505() first, then check > >>> > > cpu_is_omap34xx(). > > > > Signed-off-by: Stanley.Miao > > > > > Tested-by: Igor Grinberg > > I've just ran into this yesterday evening. > Having a patch for this on the next day made me :) > Tested on AM3517. > > >>> Can you please describe what breaks so we can merge this as a fix? > >>> > >>> > >> cpu_is_34xx() will be true for all OMAP3 based devices including > >> AM3517. So, if we want to perform operations specific to AM3517, the > >> check for AM3517 should be done first else you match for 34xx would > >> return true; and you wouldn't go far enough to check for am3517. > >> > > Understood, but we need some concrete error like "otherwise booting > > xyz board fails with non-working USB" or similar. > > > > Otherwise, All AM35XX (Sitara) clocks do not get registered and device > drivers > (ti_hecc, etc...) that depend on those clocks are failing to get the > clock and > end up with non working device. Thanks, adding to omap-fixes with updated description. Tony -- 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] OMAP3: PM: ensure IO wakeups are properly disabled
Hi Kevin,
On Wed, 2010-08-11 at 18:03 +0200, ext Kevin Hilman wrote:
> From: Kevin Hilman
>
> Commit 5a5f561 (convert OMAP3 PRCM macros to the _SHIFT/_MASK suffixes)
> mistakenly removed the check for PER when disabling the IO chain.
>
> During idle, if the PER powerdomain transitions and CORE does not (as
> is the case with the lower C-states when using CPUidle) the IO pad
> wakeups are not being disabled in the idle path after they are
> enabled.
>
> This patch ensures that the check for disabling IO wakeups also checks
> for PER transitions, matching the check done to enable IO wakeups.
>
> Found when debugging PM/CPUidle related problems reported by Ameya
> Palande . Problems were triggered
> particularily on boards with UART2 consoles (n900, Overo) since UART2
> is in the PER powerdomain.
>
> Tested on l-o master (omap3_defonfig + CONFIG_CPU_IDLE=y) as well
> as with current PM branch. Boards tested: n900, Overo, omap3evm.
>
> Cc: Paul Walmsley
> Cc: Ameya Palande
> Tested-by: Jarkko Nikula
> Signed-off-by: Kevin Hilman
> ---
> Tony, this should go in with fixes for -rc2
>
> Changes since v1
> - added a bit of history about where the problem was created
> - added 'Tested-by' for Jarkko
>
> arch/arm/mach-omap2/pm34xx.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index fb4994a..7b03426 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -480,7 +480,9 @@ void omap_sram_idle(void)
> }
>
> /* Disable IO-PAD and IO-CHAIN wakeup */
> - if (omap3_has_io_wakeup() && core_next_state < PWRDM_POWER_ON) {
> + if (omap3_has_io_wakeup() &&
> + (per_next_state < PWRDM_POWER_ON ||
> + core_next_state < PWRDM_POWER_ON)) {
> prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
> omap3_disable_io_chain();
> }
Thanks for your fix!
I tried out following patch on n900 kernel (based on 2.6.35 mainline)
hosted at: http://gitorious.org/nokia-n900-kernel
Patch:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b88737f..887242d 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -479,7 +479,8 @@ void omap_sram_idle(void)
}
/* Disable IO-PAD and IO-CHAIN wakeup */
- if (core_next_state < PWRDM_POWER_ON) {
+ if (per_next_state < PWRDM_POWER_ON ||
+ core_next_state < PWRDM_POWER_ON) {
prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
omap3_disable_io_chain();
}
And got following WARNING after sometime:
[ 109.394714] [ cut here ]
[ 109.399414] WARNING: at arch/arm/mach-omap2/pm34xx.c:292
prcm_interrupt_handler+0xb4/0x108()
[ 109.407897] prcm: WARNING: PRCM indicated MPU wakeup but no wakeup
sources are marked
[ 109.415771] Modules linked in: sco bnep l2cap bluetooth ipv6
wl1251_spi wl1251 omaplfb pvrsrvkm cmt_speech mac80211 ssi_protocol hsi_
char cmt omap_ssi crc7 g_ether tsl2563(C) industrialio(C) rtc_twl
rtc_core twl4030_pwrbutton gpio_keys
[ 109.437042] [] (unwind_backtrace+0x0/0x168) from
[] (warn_slowpath_common+0x4c/0x64)
[ 109.446594] [] (warn_slowpath_common+0x4c/0x64) from
[] (warn_slowpath_fmt+0x2c/0x3c)
[ 109.456237] [] (warn_slowpath_fmt+0x2c/0x3c) from
[] (prcm_interrupt_handler+0xb4/0x108)
[ 109.466125] [] (prcm_interrupt_handler+0xb4/0x108) from
[] (handle_IRQ_event+0x24/0xe0)
[ 109.475952] [] (handle_IRQ_event+0x24/0xe0) from
[] (handle_level_irq+0xd4/0x180)
[ 109.485260] [] (handle_level_irq+0xd4/0x180) from
[] (asm_do_IRQ+0x6c/0x8c)
[ 109.494018] [] (asm_do_IRQ+0x6c/0x8c) from []
(__irq_svc+0x48/0xa8)
[ 109.502075] Exception stack(0xc0481eb0 to 0xc0481ef8)
[ 109.507141] 1ea0: 0020
c04866f0 c048 c04db080
[ 109.515380] 1ec0: c048 0202 0002 000a
c048 c04db080
[ 109.523620] 1ee0: 0002 c0481ef8 c00642c8 c00641c8 2113
[ 109.530303] [] (__irq_svc+0x48/0xa8) from []
(__do_softirq+0x3c/0xf8)
[ 109.538543] [] (__do_softirq+0x3c/0xf8) from []
(irq_exit+0x44/0xa8)
[ 109.546691] [] (irq_exit+0x44/0xa8) from []
(asm_do_IRQ+0x70/0x8c)
[ 109.554656] [] (asm_do_IRQ+0x70/0x8c) from []
(__irq_svc+0x48/0xa8)
[ 109.562713] Exception stack(0xc0481f38 to 0xc0481f80)
[ 109.567810] 1f20:
0028f9f0
[ 109.576049] 1f40: 0028f9f0 c04ba290 c04ba274 0003
0003 8002b868 411fc083
[ 109.584259] 1f60: 001f c0481f80 c00449a4
c00449b0 6013
[ 109.592498] [] (__irq_svc+0x48/0xa8) from []
(omap3_enter_idle+0x104/0x134)
[ 109.601287] [] (omap3_enter_idle+0x104/0x134) from
[] (cpuidle_idle_call+0xa0/0x108)
[ 109.610839] [] (cpuidle_idle_call+0xa0/0x108) from
[] (cpu_idle+0x48/0xa0)
[ 109.619506] [] (cpu_idle+0x48/0xa0) from []
(start_kernel+0x278/0x2d8)
[
RE: [PATCH 3/4 v2] omap: hwspinlock: Created driver for OMAP hardware spinlock.
> -Original Message-
> From: Que, Simon
> Sent: Thursday, August 12, 2010 6:00 AM
> To: Linux Omap; Tony Lindgren
> Cc: Cousson, Benoit; Shilimkar, Santosh; Premi, Sanjeev;
> Kanigeri, Hari
> Subject: [PATCH 3/4 v2] omap: hwspinlock: Created driver for
> OMAP hardware spinlock.
>
> Created driver for OMAP hardware spinlock.
>
> - Reserved spinlocks for internal use
> - Dynamic allocation of unreserved locks
> - Lock, unlock, and trylock functions, with or without
> disabling irqs/preempt
> - Registered as a platform device driver
>
> The device initialization uses hwmod to configure the devices.
> One device will be created for each IP. It will pass
> spinlock register offset info to the driver. The device
> initialization file is:
> arch/arm/mach-omap2/hwspinlocks.c
>
> The driver takes in register offset info passed in device
> initialization.
> It uses hwmod to obtain the base address of the hardware
> spinlock module.
> Then it reads info from the registers. The function
> hwspinlock_probe() initializes the array of spinlock
> structures, each containing a spinlock register address
> calculated from the base address and lock offsets.
> The device driver file is:
> arch/arm/plat-omap/hwspinlock.c
>
> Here's an API summary:
> int hwspinlock_lock(struct hwspinlock *);
> Attempt to lock a hardware spinlock. If it is busy,
> the function will
> keep trying until it succeeds. This is a blocking function.
> int hwspinlock_trylock(struct hwspinlock *);
> Attempt to lock a hardware spinlock. If it is busy,
> the function will
> return BUSY. If it succeeds in locking, the function
> will return
> ACQUIRED. This is a non-blocking function.
> int hwspinlock_unlock(struct hwspinlock *);
> Unlock a hardware spinlock.
>
> struct hwspinlock *hwspinlock_request(void);
> Provides for "dynamic allocation" of a hardware
> spinlock. It returns
> the handle to the next available (unallocated)
> spinlock. If no more
> locks are available, it returns NULL.
> struct hwspinlock *hwspinlock_request_specific(unsigned int);
> Provides for "static allocation" of a specific hardware
> spinlock. This
> allows the system to use a specific spinlock,
> identified by an ID. If
> the ID is invalid or if the desired lock is already
> allocated, this
> will return NULL. Otherwise it returns a spinlock handle.
> int hwspinlock_free(struct hwspinlock *);
> Frees an allocated hardware spinlock (either reserved
> or unreserved).
>
> Signed-off-by: Simon Que
> Signed-off-by: Hari Kanigeri
> Signed-off-by: Krishnamoorthy, Balaji T
> ---
> arch/arm/mach-omap2/hwspinlocks.c| 65 +
> arch/arm/plat-omap/hwspinlock.c | 353
> ++
> arch/arm/plat-omap/include/plat/hwspinlock.h | 47
> 3 files changed, 465 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/hwspinlocks.c
> create mode 100644 arch/arm/plat-omap/hwspinlock.c
> create mode 100644 arch/arm/plat-omap/include/plat/hwspinlock.h
>
> diff --git a/arch/arm/mach-omap2/hwspinlocks.c
> b/arch/arm/mach-omap2/hwspinlocks.c
> new file mode 100644
> index 000..154fc40
> --- /dev/null
> +++ b/arch/arm/mach-omap2/hwspinlocks.c
> @@ -0,0 +1,65 @@
> +/*
> + * OMAP hardware spinlock device initialization
> + *
> + * Copyright (C) 2010 Texas Instruments. All rights reserved.
> + *
> + * Contact: Simon Que
> + *
> + * 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 in the hope that it will be
> useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +
> +struct omap_device_pm_latency omap_spinlock_latency[] = {
> + {
> + .deactivate_func = omap_device_idle_hwmods,
> + .activate_func = omap_device_enable_hwmods,
> + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> + }
> +};
> +
> +/* Initialization function */
> +int __init hwspinlocks_init(void)
> +{
> + int retval = 0;
> +
> + struct omap_hwmod *oh;
> + const char *oh_name, *pdev_name;
> +
> + oh_name = "spinlock";
> + oh = omap_hwmod_lookup(oh_name);
> + if (WARN_ON(oh == NULL))
> + return -EINVAL;
> +
> + pdev_name = "hwspinlock";
> +
> + /* Pass data to device initial
Re: [PATCH v4 3/8] wireless: wl1271: add platform driver to get board data
On Thu, Aug 12, 2010 at 09:40:19AM +0300, Ohad Ben-Cohen wrote: > On Thu, Aug 12, 2010 at 12:25 AM, Russell King - ARM Linux > wrote: > >I've outlined a far simpler and easiler solution > > which avoids this kind of abuse, and given suggestions on how to extend > > it to support multiple instances. > > > > Do you mean: > http://www.spinics.net/lists/arm-kernel/msg95338.html > ? > > I was under the impression you eventually discarded that approach in > that post. Indeed. I'm talking about my first suggestion: http://lists.arm.linux.org.uk/lurker/message/20100804.114148.bf961e83.en.html which was later expanded by Vitaly: http://lists.arm.linux.org.uk/lurker/message/20100804.140119.f476c29c.en.html I don't think anyone had any negative comments against that proposal. -- 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/4 v2] omap: hwspinlock: uncomment the hwmod part for hwspinlock
> -Original Message-
> From: Que, Simon
> Sent: Thursday, August 12, 2010 6:00 AM
> To: Linux Omap; Tony Lindgren
> Cc: Cousson, Benoit; Shilimkar, Santosh; Premi, Sanjeev;
> Kanigeri, Hari
> Subject: [PATCH 1/4 v2] omap: hwspinlock: uncomment the hwmod
> part for hwspinlock
>
> uncomment the hwmod part for hwspinlock
>
> Signed-off-by: Simon Que
> Signed-off-by: Hari Kanigeri
> ---
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
[sp] I did not see this file in any of the "master",
"for-next" or "pm" branches.
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index bb0c870..81e3f3f 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -5797,7 +5797,7 @@ static __initdata struct omap_hwmod
> *omap44xx_hwmods[] = {
> /* &omap44xx_smartreflex_iva_hwmod, */
> /* &omap44xx_smartreflex_mpu_hwmod, */
> /* spinlock class */
> -/* &omap44xx_spinlock_hwmod, */
> + &omap44xx_spinlock_hwmod,
> /* timer class */
> &omap44xx_timer1_hwmod,
> &omap44xx_timer2_hwmod,
> --
> 1.7.0
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4 v2] omap: hwspinlock: Add HWSPINLOCK base address information in omap44xx.h
> -Original Message- > From: Que, Simon > Sent: Thursday, August 12, 2010 6:00 AM > To: Linux Omap; Tony Lindgren > Cc: Cousson, Benoit; Shilimkar, Santosh; Premi, Sanjeev; > Kanigeri, Hari > Subject: [PATCH 2/4 v2] omap: hwspinlock: Add HWSPINLOCK base > address information in omap44xx.h > > Add HWSPINLOCK base address information in omap44xx.h > > Signed-off-by: Simon Que > Signed-off-by: Hari Kanigeri > --- > arch/arm/plat-omap/include/plat/omap44xx.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h > b/arch/arm/plat-omap/include/plat/omap44xx.h > index 8b3f12f..8016508 100644 > --- a/arch/arm/plat-omap/include/plat/omap44xx.h > +++ b/arch/arm/plat-omap/include/plat/omap44xx.h > @@ -52,5 +52,7 @@ > #define OMAP4_MMU1_BASE0x55082000 > #define OMAP4_MMU2_BASE0x4A066000 > > +#define OMAP44XX_SPINLOCK_BASE (L4_44XX_BASE + 0xF6000) > + [sp] Can this be simply OMAP4_SPINLOCK_BASE equiv to OMAP4_MMUx_BASE defined just above. OR is this address specific to OMAP44xx only? (I haven't checked what is the the convention followed in rest of the file) > #endif /* __ASM_ARCH_OMAP44XX_H */ > -- > 1.7.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] OMAP: hwmod: Full data set for OMAP4430 ES1 & ES2
On 8/12/2010 2:34 AM, Kevin Hilman wrote: "Cousson, Benoit" writes: Hi Kevin, On 8/9/2010 9:11 PM, Kevin Hilman wrote: Benoit Cousson writes: Hi Kevin& Paul, Here is the OMAP4430 ES1& ES2 hwmod data v3 series. Please note that there is no difference between the ES1& ES2 wrt hwmod. This series is re-organised in order to allow initial submission for upstream with minimal interconnect data set + mpu. Further data will be sent along with the driver once adapted to hwmod. A first patch is done for the TIMER IP as an example. Patches are based on lo/for-next + for-next-fixes + pm-wip/hwmods-reset + pm-wip/hwmods-debugfs and are available here: git://dev.omapzoom.org/pub/scm/swarch/linux-omap-adv.git pm-wip/hwmods-omap4 Tested on OMAP4430 ES1.0 GP device using PAB board. This is looking good to me. Of course, as you noted we need to understand the root cause of need for those temporary patches before merging. To facilitate broader testing with the other hwmod conversions in progress, and to test with runtime PM, I've updated my pm-wip/hwmods-omap4 branch now includes your series (and its dependencies.) Cool, thanks. Maybe we should reshuffle the branch in order to allow people to start stacking the OMAP4 hwmod data in small pieces on top of the initial data. Yes, it is time for that. What about these branches: -> pm-wip/hwmods-omap4-full that contains the original full data that people will split but that nobody should use as a base. bbd5866 OMAP: hwmod: Temporary prevent reset during _setup for I2Cs c47ddf5 OMAP: hwmod: Temporary prevent reset during _setup for GPIOs 4d2fbb8 OMAP4: hwmod: Add remaining hwmods data for OMAP4430 ES1& ES2 a9a8f22 OMAP4: hwmod: Add TIMER data for OMAP4430 ES1& ES2 OK, done. -> pm-wip/hwmods-omap4-base to base all driver hwmod migration including the OMAP4 data part OK, done, but I kept the name pm-wip/hwmods-omap4 since that's what people are already using for a base. b8eccd4 OMAP: omap_hwmod: remove locking from hwmod_for_each iterators fyi... there's an updated version of this locking patch in my pm-wip/hwmods branch, based on top of your for-next-fixes branch, and included as part of pm-wip/hwmods-omap4. fedcdf6 PM: allow runtime PM get/put from interrupts-disabled context a55908c OMAP1: PM: add simple runtime PM layer to manage clocks be46d49 OMAP: bus-level PM: enable use of runtime PM API for... 1ebda92 OMAP: PM: initial runtime PM core support This is still pm-wip/runtime (but included in pm-wip/hwmods-omap4) 2cb85f7 USB: Remove omap_cfg_reg for 2430 This s still pm-backports (but included in pm-wip/hwmods-omap4) -> pm-wip/hwmods-omap4 71a4efa OMAP4: pm: Change l3_main to l3_main_1 during bus device init 1cf660c OMAP4: clock: Fix clock names and align with hwmod names 517cead OMAP4: hwmod: Add initial data for OMAP4430 ES1& ES2 I just left this as your for-next-fixes branch and merged it into my pm-wip/hwmods-omap4. Great, thanks. I'll start notifying people to rebase and re-submit the OMAP4 hwmod part. 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/2] Put OMAP2 SPI CS in unactive state when return from suspend
2010/8/11 Kevin Hilman > > Gregory CLEMENT writes: > > > We notice that when system wake up from OFF mode, then CS is in > > unactive state until the first SPI transfert. > > For our design it lead to some conflict on this I/O. > > Unactive state for CS when there is no transfert shoudl be the correct > > behaviour: this is the purpose of these patches. > > This approach handles an off-mode transition during suspend, but if > off-mode is enabled, you can also have an off-mode transition during > idle. > Well maybe I didn't use the correct words. During the system life, I monitored the CS behaviour using a oscilloscope. I also activate debug in omap2_mcspi, so I see when driver disable the clocks and restore context when device is not used. Each time the CS is in the correct state. It is only when there is a suspend with the following configuration that on resume the CS is in wrong state( ie activated) echo 1 > /mnt/pm_debug/enable_off_mode echo 0 > /mnt/pm_debug/core_pwrdm/suspend echo 1 > /mnt/pm_debug/voltage_off_while_idle > > Since you didn't describe what the conflicts you're seeing are, I would > assume that you'll have the same problems in idle as in suspend, and > this series doesn't address the idle case. I didn't see any problem in idle case, just when system resume from a suspend to ram (echo mem > /sys/power/state) > > Kevin > > > > > Gregory CLEMENT (2): > > spi: Add hook on suspend/resume for spi master > > spi/omap2_mcspi: When SPI wake up from OFF mode, CS is in wrong > > state: force it to unactive state > > > > drivers/spi/omap2_mcspi.c | 11 ++- > > drivers/spi/spi.c | 15 ++- > > include/linux/spi/spi.h | 4 +++- > > 3 files changed, 27 insertions(+), 3 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 -- Gregory CLEMENT -- 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 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of sys_dev_class
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Tuesday, August 10, 2010 11:40 PM
> To: Basak, Partha
> Cc: Varadarajan, Charulatha; linux-omap@vger.kernel.org; p...@pwsan.com;
> Cousson, Benoit; Nayak, Rajendra
> Subject: Re: [PATCH 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of
> sys_dev_class
>
> "Basak, Partha" writes:
>
> [...]
>
> >> > In the idle path (interrupt disabled context), PM runtime APIs cannot
> >> > be used as they are not mutex-free functions. Hence omap_device APIs
> >> > are used in the idle and resume after idle path.
> >>
> >> This needs much more fleshing out.
> >>
> >> Exactly what mutexes are causing the problems here. As pointed out in
> >> previous discussions, the ones in the PM runtime core should not be a
> >> problem in this path. Therefore, I'll assume the problems are coming
> >> from the mutexes when the device code (mach-omap2/gpio.c) calls into
> the
> >> hwmod layer. More on this in comments on the next patch.
> >>
> >
> > Sorry, this has not been documented correctly. The issue has more to
> > do unconditional enabling of interrupts. We have received a patch from
> > you on using pm_runtime functions in Idle path. We will try on GPIO
> > and revert back.
>
> OK
>
> >
> >> > To summarize,
> >> > 1. pm_runtime_get_sync() for any gpio bank is called when one of the
> >> gpios
> >> >is requested on the bank, in which, no other gpio is being used
> (when
> >> >mod_usage becomes non-zero)
> >> > 2. omap_device_enable() is called during gpio resume after idle, only
> >> >if the particular bank is being used (if mod_usage is non-zero)
> >>
> >> context is saved/restored in the idle path, but...
> >>
> >> > 3. pm_runtime_put_sync() is called when the last used gpio in that
> >> >gpio bank is freed (when mod_usage becomes zero)
> >>
> >> in this path, the bank is now runtime suspended, but context has not
> >> been saved for it. That should be fine, since this bank is no longer
> >> used, but now let's assume there was an off-mode transition and context
> >> is lost. Then, gpio_request() is called which will trigger
> >> a pm_runtime_get_sync() and gpio_bank_runtime_resume() will be called.
> >>
> >> In this case, it's not terribly clear that runtime_resume is doing sane
> >> things if context has just been lost. Seems like runtime_resume should
> >> be a nop in this case since any re-init will be be done in
> gpio_request().
> >
> > Runtime_suspend/resume for GPIO is not doing any save/restore
> > context. In that sense, they are NOP. Context save/restore is taken
> > care of only in the Idle path based on target power state and last
> > power state respectively.
>
> OK, I didn't explain the problem I'm suspecting very well. Imagine this
> sequence of events:
>
> - mod_usage becomes zero
> - pm_runtime_put_sync()
> - gpio_bank_runtime_suspend() [ no context is saved ]
> [ off-mode transition, context is lost]
> - gpio_request()
> - pm_runtime_get_sync()
> - gpio_bank_runtime_resume()
>
> In this path, no context is saved, and no context is restored, which is
> what I would expect, since there's no need to save context if nobody is
> using that gpio bank anymore. However, gpio_bank_runtime_resume() is
> doing lots of reads/writes and read-modify-writes on GPIO bank registers
> that may have undefined contents after a context loss.
>
> The point is that the GPIO register twiddling in
> gpio_bank_runtime_resume() does not seem to be needed if there are no
> users of that GPIO bank.
>
> [...]
>
> >> > static void omap3_enable_io_chain(void)
> >> > {
> >> > int timeout = 0;
> >> > @@ -395,15 +385,17 @@ void omap_sram_idle(void)
> >> > /* PER */
> >> > 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) {
> >> > per_next_state = PWRDM_POWER_RET;
> >> > pwrdm_set_next_pwrst(per_pwrdm,
> per_next_state);
> >> > per_state_modified = 1;
> >> > -} else
> >> > -omap3_per_save_context();
> >> > +}
> >> > }
> >> > +if (per_next_state == PWRDM_POWER_OFF)
> >> > +omap2_gpio_prepare_for_idle(true);
> >> > +else
> >> > +omap2_gpio_prepare_for_idle(false);
> >>
> >> Why is this better than passing the next power state?
> >
> > This would keep the GPIO function omap2_gpio_prepare_for_idle agnostic
> of Power state definition dependencies.
> >
>
> And why is this better?
>
> Personally, I think the GPIO code should be told about the powerdomain
> state so it can make it
Re: [PATCH v2 1/3] ARM: OMAP: Beagle: revision detection
Hi
On Wed, 11 Aug 2010 18:37:40 -0500
Robert Nelson wrote:
> Due to the omap3530 ES3.0 Silicon being used on both the
> B5/B6 and C1/2/3 Beagle we can't use the cpu_is_omap34xx()
> routines to differentiate the Beagle Boards.
>
> However gpio pins 171,172,173 where setup for this prupose, so
> lets use them.
>
> Tested on Beagle Revisions: B5, C2, C4, and xMA
>
> Signed-off-by: Robert Nelson
> ---
> arch/arm/mach-omap2/board-omap3beagle.c | 60
> +++
> arch/arm/plat-omap/include/plat/board.h | 23
> 2 files changed, 83 insertions(+), 0 deletions(-)
>
...
> + beagle_rev = gpio_get_value(171) | (gpio_get_value(172) << 1)
> + | (gpio_get_value(173) << 2);
> +
> + switch (beagle_rev) {
> + case 7:
> + printk(KERN_INFO "OMAP3 Beagle Rev: Ax/Bx\n");
> + omap3_beagle_version = OMAP3BEAGLE_BOARD_AXBX;
> + break;
> + case 6:
> + printk(KERN_INFO "OMAP3 Beagle Rev: C1/C2/C3\n");
> + omap3_beagle_version = OMAP3BEAGLE_BOARD_C1_3;
> + break;
> + case 5:
> + printk(KERN_INFO "OMAP3 Beagle Rev: C4\n");
> + omap3_beagle_version = OMAP3BEAGLE_BOARD_C4;
> + break;
> + case 0:
> + printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
> + omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
> + break;
> + default:
> + printk(KERN_INFO "OMAP3 Beagle Rev: unknown %hd\n", beagle_rev);
> + omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
> + }
My C2 reads as 2 and I have U-Boot 2009.01-dirty (Feb 19 2009 -
12:22:31). I believe these pins are not muxed correctly with that
U-Boot version.
Therefore kernel should remux those pins so that version is detected
right independently of bootloader version. Detections works fine if I
add these:
omap_mux_init_gpio(171, OMAP_PIN_INPUT_PULLUP);
omap_mux_init_gpio(172, OMAP_PIN_INPUT_PULLUP);
omap_mux_init_gpio(173, OMAP_PIN_INPUT_PULLUP);
--
Jarkko
--
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
