Re: In many cases softlockup can not be reported after disabling IRQ for long time
Hi, Don My concern is not actually that the softlockup could not be reported while the IRQ is disabled. What bothering me is that even AFTER re-enable the IRQ, it will not give warning in many cases. In theory, disabling IRQ for long time (10s in my case) also implies the high priority thread (watchdog) is blocked as well. So the ideal case is that softlockup driver could give warning right after the IRQ is re-enabled. It does so occasionally but fails to be consistent. On Wed, Feb 1, 2012 at 10:58 PM, Don Zickus dzic...@redhat.com wrote: On Wed, Feb 01, 2012 at 10:18:09AM +0800, TAO HU wrote: Hi, Don Thanks for your feedback! Unfortunately, the hardlockup depends on NMI which is not available on ARM (Cortex-A9) per my understanding. Our system uses OMAP4430. Any more suggestions? Ah. I wrongly assumed this is x86. Sorry about that. Ok, so this is what is going on. The softlockup check is just a high priority thread that periodically runs. If preemption is disabled that thread can't run (or any threads for that matter) and a softlockup condition will exist. However, in order to determine that, a periodic hrtimer has to come along and do the actual check. If that check fails, then the warning is printed out. However that accuracy is based on the resolution of that hrtimer which I set to about 1/5 the watchdog threshold or 1 second in this case. Unfortunately, if you disable the irqs, then that timer can't fire and now we don't have a way to trigger the softlockup check until interrupts are re-enabled. On x86, we have a backup plan for disabled interrupts and that is the hardlockup check which rely on NMIs (something that still fires even when interrupts are disabled). If on ARM you don't have NMIs, then it will be difficult to check for softlockups when interrupts are disabled. Though I do recall sparc doing something clever like using IRQ0 as a special purpose IRQ to emulate an NMI (IOW, software purposely avoided masking IRQ0). So when an interrupt came in on that irq, it was never blocked and always ran based on the irq nesting rules. I don't know ARM well enough to give any solution for your problem, but my reason above is why it isn't working the way you intended. Cheers, Don On Tue, Jan 31, 2012 at 11:47 PM, Don Zickus dzic...@redhat.com wrote: On Tue, Jan 31, 2012 at 03:28:09PM +0800, TAO HU wrote: Resend with a new subject On Wed, Jan 25, 2012 at 4:24 PM, TAO HU tgh...@motorola.com wrote: Hi, All While playing kernel 3.0.8 with below test code, it does NOT report any softlockup with 60%~70% chances. NOTE: the softlockup timeout is set to 10 seconds (i.e. watchdog_thresh=5) in my test. ... ... preempt_disable(); local_irq_disable(); for (i = 0; i 20; i++) mdelay(1000); local_irq_enable(); preempt_enable(); ... ... However, if I remove local_irq_disable()/local_irq_enable() it will report softlockup with no problem. I believe it is due to that after local_irq_enable() touch_softlockup_watchdog() is called prior softlockup timer. Hi Hu, Honestly, you should be getting hardlockup warnings if you are disabling interrupts. Do you see anything in the console output? Cheers, Don -- Best Regards Hu Tao -- Best Regards Hu Tao -- 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 1/5] OMAP4: hwmod: Add names for DMIC memory address space
Hi Paul, On 02/01/2012 09:08 PM, Paul Walmsley wrote: No sadly I can't. There are at least three levels of maintainers above me in my mainline submission path. As you may have seen, I've sent the patch to Tony and he has pulled the series: http://www.spinics.net/lists/linux-omap/msg63525.html I have missed this. so I've done what I can. Thanks, it is enough if it is on it's way. Will end up in the correct place at some point. Regards, Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()
Hi
On Thu, 2 Feb 2012, Shilimkar, Santosh wrote:
On Thu, Feb 2, 2012 at 12:57 AM, Paul Walmsley p...@pwsan.com wrote:
N.B., I haven't looked at this file before. There are a few other things
that don't look right that hopefully someone can take the initiative to
fix. For example, those calls to mpuss_clear_prev_logic_pwrst() and
cpu_clear_prev_logic_pwrst() should be removed as well. That should be
done by pwrdm_clear_all_prev_pwrst() in mach-omap2/powerdomain44xx.c.
Currently it's not, so that needs to be patched.
We(rajendra and myself) discussed this some time back with Benoit and we
agreed
that for CPU and MPU power domains which are needed very early in the PM power
up sequence, we can do direct APIs..
Looking at the call sites, don't these calls occur quite late in boot,
after everything is initialized? I see calls from a late_initcall() and a
suspend entry function. Am I missing something?
These calls were in critical path and the PD API's proposed for context clear
and logic clear were use to iterate over all power domains.
The code iterates over all powerdomains anyway a few lines above those
calls, right?
If the code only needs to iterate over a subset, let's discuss what you
need and a different iterator can be implemented in the powerdomain code.
It is only recently we got clear context etc some reasonable form
even though it still iterates over all hwmod etc which is really overhead.
Which mainline PM calls iterate over all hwmods?
Also you need to create 'pdev' etc for context-loss kind of APIs and
we all thought that that makes things un-ncessary complicated and
lengthy.
Could you point out the code that you are referring to? I seem to be
missing it :-(
If the existing powerdomain API is missing something you need, there's no
problem to add it. It makes things easier to debug and more portable in
the long term if there is a clean, standard interface. Another hope is
that more of the PM code can be shared.
In terms of performance, it seems pretty unlikely that one would be able
to measure a meaningful performance difference, unless we are missing an
API call that was needed? As we were discussing before, device reads are
likely to dominate the profile.
Flipping through the code, I see that code is getting duplicated again.
We now have three identical copies of clkdms_setup(). The OMAP4
pwrdms_setup() is doing string comparisons to skip powerdomains -- that's
also pretty fragile; that should be controlled through powerdomain flags
or some similar mechanism. Once that's fixed, it looks to me like that
function could be shared with the OMAP34xx pwrdms_setup()? Looks like we
could also share omap{3,4}_pm_suspend() and omap{2,3,4}_pm_{begin,end}?
It would be good if we can keep working towards making as much of this
code as common as possible. If already-tested code can be reused, that
should cut down on bugs and maintainer workload. Also, we can avoid
adding unnecessary lines of diff; we are trying to cut that down too..
Also all of the open-coded powerdomain register accesses in
omap-mpuss-lowpower.c should be removed - those should all go through
pwrdm_*() functions...
I will have another look at the code with your recent power domain
clean-ups and see what all can be moved to generic APIs.
That would be great!
- Paul
Re: In many cases softlockup can not be reported after disabling IRQ for long time
.sdrawkcab esra s'ti ,tsop pot t'noD (Don't top post, it's arse backwards.) On Thu, Feb 02, 2012 at 04:17:02PM +0800, TAO HU wrote: My concern is not actually that the softlockup could not be reported while the IRQ is disabled. What bothering me is that even AFTER re-enable the IRQ, it will not give warning in many cases. That's already been explained. softlockups are detected by time passing. Time can't properly advance with interrupts disabled, as the backing counter (assuming you're using the clocksource and clockevent stuff) could wrap. If it wraps, the systems idea of time which has passed will be incorrect. So, if interrupts are disabled for a long period, the system loses track of time, and therefore can't know how long the system has been blocked for. -- 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/2] of: Add generic device tree DMA helpers
On Wed, Feb 01, 2012 at 11:50:30AM +0100, Cousson, Benoit wrote: Hi Russell, On 2/1/2012 12:09 AM, Russell King - ARM Linux wrote: On Sat, Jan 28, 2012 at 11:06:02AM -0700, Grant Likely wrote: This makes the assumption that dma specifiers will only ever be 1 cell. I think to be generally useful, the full dma specifier needs to be either handed to the dma controller to get a cookie or passed back to the caller in its entirety. More to the point, who says that the DMA specifier is even an integer? When people are using DMA engines, it (probably) isn't an integer at all. Several platforms I know of use strings for this. Some platforms can even select between two or more DMA engines for handling the same peripheral - I believe Samsung do this depending on their individual workloads. However, the opaque DMA engine API for requesting a channel doesn't lend itself well to DT, as the match data and match function are entirely left to the individual DMA engine driver and/or platform itself. As far as creating another linear number space for DMA stuff, I'd really suggest against that - you're going to need some additional code in place to manage that numberspace. If you at least use a two- paid cookie, eg 'dma controller phandle + request signal' then that makes all the stuff we're starting to see with the IRQ subsystem, IRQ domains etc become completely unnecessary. I guess what I'm saying is ignore the flat number space, and go straight to some kind of 'dma domains' solution from the start. Fully agree, and this is exactly the idea of this DMA binding: First argument is always a DMA controller phandle and then you can add 0, 1 or more cells to define extra specifiers dependent of the DMA controller driver expectation. The one cell Grant was referring was just the extra specifier that is needed for a simple DMA engine like the SDMA we have inside OMAP. But the whole idea is to have a flexible enough mechanism to allow any kind of specifier. No more global linear number space like for IRQ! How does this work when you're stuffing a number into a struct resource as a plain DMA number? That looks very much like a linear number space, as you don't have a way to associate that number with anything else. -- 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/2] of: Add generic device tree DMA helpers
On 2/2/2012 9:45 AM, Russell King - ARM Linux wrote: On Wed, Feb 01, 2012 at 11:50:30AM +0100, Cousson, Benoit wrote: Hi Russell, On 2/1/2012 12:09 AM, Russell King - ARM Linux wrote: On Sat, Jan 28, 2012 at 11:06:02AM -0700, Grant Likely wrote: This makes the assumption that dma specifiers will only ever be 1 cell. I think to be generally useful, the full dma specifier needs to be either handed to the dma controller to get a cookie or passed back to the caller in its entirety. More to the point, who says that the DMA specifier is even an integer? When people are using DMA engines, it (probably) isn't an integer at all. Several platforms I know of use strings for this. Some platforms can even select between two or more DMA engines for handling the same peripheral - I believe Samsung do this depending on their individual workloads. However, the opaque DMA engine API for requesting a channel doesn't lend itself well to DT, as the match data and match function are entirely left to the individual DMA engine driver and/or platform itself. As far as creating another linear number space for DMA stuff, I'd really suggest against that - you're going to need some additional code in place to manage that numberspace. If you at least use a two- paid cookie, eg 'dma controller phandle + request signal' then that makes all the stuff we're starting to see with the IRQ subsystem, IRQ domains etc become completely unnecessary. I guess what I'm saying is ignore the flat number space, and go straight to some kind of 'dma domains' solution from the start. Fully agree, and this is exactly the idea of this DMA binding: First argument is always a DMA controller phandle and then you can add 0, 1 or more cells to define extra specifiers dependent of the DMA controller driver expectation. The one cell Grant was referring was just the extra specifier that is needed for a simple DMA engine like the SDMA we have inside OMAP. But the whole idea is to have a flexible enough mechanism to allow any kind of specifier. No more global linear number space like for IRQ! How does this work when you're stuffing a number into a struct resource as a plain DMA number? That looks very much like a linear number space, as you don't have a way to associate that number with anything else. As explained in the kernel doc header and in the changelog, that one is for legacy purpose only. +/** + * of_dma_to_resource - Decode a node's DMA and return it as a resource + * @dev: pointer to device tree node + * @index: zero-based index of the DMA request + * @r: pointer to resource structure to return result into. + * + * Using a resource to export a DMA request number to a driver should + * be used only for legacy purpose and on system when only one DMA controller + * is present. + * The proper and only scalable way is to use the native of_get_dma_request API + * in order retrieve both the DMA controller device node and the DMA request + * line for that controller. + */ There is indeed no way to put information about DMA controller and DMA line in the resource structure except if we start hacking the start and end attributes. But I'm not sure anyone will want to do that. The only way to take benefit of the extra information DT can provide is to use the of_get_dma_request API. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()
On Thu, Feb 2, 2012 at 2:03 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Thu, 2 Feb 2012, Shilimkar, Santosh wrote:
On Thu, Feb 2, 2012 at 12:57 AM, Paul Walmsley p...@pwsan.com wrote:
N.B., I haven't looked at this file before. There are a few other things
that don't look right that hopefully someone can take the initiative to
fix. For example, those calls to mpuss_clear_prev_logic_pwrst() and
cpu_clear_prev_logic_pwrst() should be removed as well. That should be
done by pwrdm_clear_all_prev_pwrst() in mach-omap2/powerdomain44xx.c.
Currently it's not, so that needs to be patched.
We(rajendra and myself) discussed this some time back with Benoit and we
agreed
that for CPU and MPU power domains which are needed very early in the PM
power
up sequence, we can do direct APIs..
Looking at the call sites, don't these calls occur quite late in boot,
after everything is initialized? I see calls from a late_initcall() and a
suspend entry function. Am I missing something?
The code has changed now because of the recent ARM suspend code and CPU PM idle
notifiers consolidation. O.w before we had to check the last power
state as early as MMU is
with identity mapping and we use to check the CPU last power state.
Then for the interrupt controller enable/disable etc as well we use to
check MPUSS PD
context lost state etc.
Thanks to the consolidation, some of those situations have reduced now.
These calls were in critical path and the PD API's proposed for context clear
and logic clear were use to iterate over all power domains.
The code iterates over all powerdomains anyway a few lines above those
calls, right?
As I said in other thread, that code was under PM debug.
If the code only needs to iterate over a subset, let's discuss what you
need and a different iterator can be implemented in the powerdomain code.
It is only recently we got clear context etc some reasonable form
even though it still iterates over all hwmod etc which is really overhead.
Which mainline PM calls iterate over all hwmods?
Also you need to create 'pdev' etc for context-loss kind of APIs and
we all thought that that makes things un-ncessary complicated and
lengthy.
Could you point out the code that you are referring to? I seem to be
missing it :-(
If the existing powerdomain API is missing something you need, there's no
problem to add it. It makes things easier to debug and more portable in
the long term if there is a clean, standard interface. Another hope is
that more of the PM code can be shared.
Yes, we do have issue with below APIs for OMAP4 and onwards design
because of the PRCM change.
pwrdm_clear_all_prev_pwrst
pwrdm_*_mem_*
There use to be a single power state and memory state register till OMAP3
at power domain level which can give you the logic and memory last test
which is needed for OSWR.
On OMAP4, we have registers per modules and it becomes difficult to model
this difference in APIs. Initially we tried to fix that with [1] and
then later realized
that's not going to work on OMAP4 + devices because of mentioned issue.
Regards
Santosh
[1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/42564
In terms of performance, it seems pretty unlikely that one would be able
to measure a meaningful performance difference, unless we are missing an
API call that was needed? As we were discussing before, device reads are
likely to dominate the profile.
Flipping through the code, I see that code is getting duplicated again.
We now have three identical copies of clkdms_setup(). The OMAP4
pwrdms_setup() is doing string comparisons to skip powerdomains -- that's
also pretty fragile; that should be controlled through powerdomain flags
or some similar mechanism. Once that's fixed, it looks to me like that
function could be shared with the OMAP34xx pwrdms_setup()? Looks like we
could also share omap{3,4}_pm_suspend() and omap{2,3,4}_pm_{begin,end}?
It would be good if we can keep working towards making as much of this
code as common as possible. If already-tested code can be reused, that
should cut down on bugs and maintainer workload. Also, we can avoid
adding unnecessary lines of diff; we are trying to cut that down too..
Also all of the open-coded powerdomain register accesses in
omap-mpuss-lowpower.c should be removed - those should all go through
pwrdm_*() functions...
I will have another look at the code with your recent power domain
clean-ups and see what all can be moved to generic APIs.
That would be great!
- 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 3/3] arm:omap:omap4: Hook-up am33xx support to existing prm code
On Wed, Feb 01, 2012 at 23:03:56, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Tue, Jan 24, 2012 at 04:05:32, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, Jan 11, 2012 at 21:48:25, Hiremath, Vaibhav wrote:
On Tue, Jan 10, 2012 at 23:39:22, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
AM33XX PRM module (L4_WK domain) will be treated as another seperate
partition in _prm_bases[] table.
Also, since cpu_is_omap34xx check is true for am33xx family of
devices, we must check cpu_is_am33xx fisrt, in order to follow
omap4 execution path.
Can you remind me why cpu_is_omap34xx() is true for AM33xx family?
Yeah sure...
Kevin,
As mentioned before, the main idea behind bringing am33xx under omap34xx
was mainly due to cortex-A8 family of devices.
It has been discussed and aligned long time back, so
please refer to the thread -
http://www.spinics.net/lists/linux-omap/msg41046.html
Multiple versions of -
http://www.spinics.net/lists/linux-omap/msg45505.html
Thanks,
Vaibhav
These AM3xxx devices make my brain hurt.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
[...]
diff --git a/arch/arm/mach-omap2/prminst44xx.c
b/arch/arm/mach-omap2/prminst44xx.c
index 3d9894f..fcc4123 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -19,6 +19,7 @@
#include common.h
#include prm44xx.h
+#include prm33xx.h
#include prminst44xx.h
#include prm-regbits-44xx.h
#include prcm44xx.h
@@ -31,6 +32,7 @@ static u32 _prm_bases[OMAP4_MAX_PRCM_PARTITIONS]
= {
[OMAP4430_CM2_PARTITION]= 0,
[OMAP4430_SCRM_PARTITION] = 0,
[OMAP4430_PRCM_MPU_PARTITION] =
OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE),
+ [AM33XX_PRM_PARTITION] =
AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE),
};
I'm not crazy about just extending the normal OMAP4 table.
If it is required then yes (with proper comment).
That would
imply that with each OMAP4 derivatve we keep extending this table.
I would say anyway we will end up adding
Cpu_is_xxx everywhere as we add new table for derivatives.
Instead, how about rename this to one to omap44xx_prm_bases[], then
create a new one called am33xx_prm_bases[]. Then, at init time,
assing
_prm_bases to the right one based on cpu_is_.
Just wanted to avoid cpu_is_ check here. Will specific comment
wouldn't
help here (I have clearly mentioned in patch description), may be in c
file
it is required?
OR
you want to be clearly separate table for code readability.
Kevin,
Any comments on this? Should I stick to what is implemented now?
cpu_is_* checks are acceptable at init time, and we use them often to
initialize SoC-dependent tables/arrays etc.
Kevin,
Sorry for delayed response,
Here is the ugly part, which I was referring to -
1) _prm_bases variable is static variable to the prminst44xx.c
2) prminst44xx.c file doesn't contain any boot time __init function,
So I have to either add exported __init function OR extern __prm_bases
variable and initialize somewhere outside this file.
3) Even if I create 2 separate variables, for example,
static u32 omap44xx_prm_bases[OMAP4_MAX_PRCM_PARTITIONS] = {
...
};
static u32 omap33xx_prm_bases[AM33XX_MAX_PRCM_PARTITIONS] = {
...
};
Makes it difficult and messy to handle inside below code,
BUG_ON doesn't make sense from AM335x perspective.
Then you can change the BUG_ON.
static u32 omap44xx_max_partitions = ARRAY_SIZE(omap44xx_prm_bases)
static u32 am33xx_max_partitions = ARRAY_SIZE(am33xx_prm_bases)
static u32 max_partitions.
At init time, assign max_partitions when you assign prm_bases, then
change the BUG_ON() to be something like:
BUG_ON(part = max_partitions || part == INVALID_PARTITION)
Kevin,
Getting rid of BUG_ON was the least and trivial one, the issue is 1 2.
Let me atleast attempt to implement something on this, will update you.
Thanks,
Vaibhav
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] arm/dts: OMAP3: Add omap3evm and am335xevm support
On Thu, Feb 02, 2012 at 10:26:29, Grant Likely wrote: On Wed, Feb 01, 2012 at 11:57:00AM +0530, Vaibhav Hiremath wrote: TI's OMAP3EVM and AM335xEVM are software development boards available for OMAP35x(AM/DM37x) and AM335x devices respectively; and these devices are considered under omap3 family. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Tony Lindgren t...@atomide.com Applied, thanks. Benoit and/or Grant, Can you also pull-in/merge all other patches which I had submitted recently? arm/dts: omap3-evm: Add i2c and twl4030 support arm/dts: Add support for TI AM3517/05 EVM board arm:omap2:board-generic: Add DT support for AM33xx devices arm/dts: Add support for TI AM335x EVM board Thanks, Vaibhav g. --- .../devicetree/bindings/arm/omap/omap.txt |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index dbdab40..ce78498 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -41,3 +41,9 @@ Boards: - OMAP4 PandaBoard : Low cost community board compatible = ti,omap4-panda, ti,omap4430 + +- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x + compatible = ti,omap3-evm, ti,omap3 + +- AM335X EVM : Software Developement Board for AM335x + compatible = ti,am335x-evm, ti,am33xx, ti,omap3 -- 1.7.0.4 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: OMAP2+: PM: code consolidation for 3.4
Hi This series consolidates some duplicated PM code across OMAP2, 3, and 4. This saves both binary kernel image size, and lines of source. These functions are just the low-hanging fruit; it looks to me like there's even more consolidation that could be done. Suspend + UART wakeup was tested on OMAP44xx BeagleBoard. On the OMAP35xx Beagleboard here, v3.3-rc2 doesn't seem to wake up from suspend correctly with or without these patches, so I've only boot-tested them on that platform. - Paul --- pm_cleanup_b_3.4 textdata bss dec hex filename 6596402 680284 5593820 12870506 c4636a vmlinux.orig 6596230 680292 5593756 12870278 c46286 vmlinux.patched Paul Walmsley (2): ARM: OMAP2+: PM: share clkdms_setup() across OMAP2, 3, 4 ARM: OMAP2+: PM: share some suspend-related functions across OMAP2, 3, 4 arch/arm/mach-omap2/pm.c | 74 ++ arch/arm/mach-omap2/pm.h |2 + arch/arm/mach-omap2/pm24xx.c | 69 +++ arch/arm/mach-omap2/pm34xx.c | 73 - arch/arm/mach-omap2/pm44xx.c | 57 ++-- 5 files changed, 91 insertions(+), 184 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
[PATCH 1/2] ARM: OMAP2+: PM: share clkdms_setup() across OMAP2, 3, 4
clkdms_setup() is identical across OMAP2, 3, and 4, so share it.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c | 10 ++
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm24xx.c | 13 +
arch/arm/mach-omap2/pm34xx.c | 17 +
arch/arm/mach-omap2/pm44xx.c | 18 +-
5 files changed, 14 insertions(+), 45 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..0118614 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -68,6 +68,16 @@ static void omap2_init_processor_devices(void)
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH 1
+int __init omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused)
+{
+ if (clkdm-flags CLKDM_CAN_ENABLE_AUTO)
+ clkdm_allow_idle(clkdm);
+ else if (clkdm-flags CLKDM_CAN_FORCE_SLEEP
+atomic_read(clkdm-usecount) == 0)
+ clkdm_sleep(clkdm);
+ return 0;
+}
+
/*
* This sets pwrdm state (other than mpu core. Currently only ON
* RET are supported.
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index b737b11..eef67f6 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,6 +22,7 @@ extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
extern int omap4_idle_init(void);
+extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index b8822f8..bfd7905 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -312,17 +312,6 @@ static const struct platform_suspend_ops omap_pm_ops = {
static const struct platform_suspend_ops __initdata omap_pm_ops;
#endif /* CONFIG_SUSPEND */
-/* XXX This function should be shareable between OMAP2xxx and OMAP3 */
-static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
-{
- if (clkdm-flags CLKDM_CAN_ENABLE_AUTO)
- clkdm_allow_idle(clkdm);
- else if (clkdm-flags CLKDM_CAN_FORCE_SLEEP
-atomic_read(clkdm-usecount) == 0)
- clkdm_sleep(clkdm);
- return 0;
-}
-
static void __init prcm_setup_regs(void)
{
int i, num_mem_banks;
@@ -364,7 +353,7 @@ static void __init prcm_setup_regs(void)
clkdm_sleep(gfx_clkdm);
/* Enable hardware-supervised idle for all clkdms */
- clkdm_for_each(clkdms_setup, NULL);
+ clkdm_for_each(omap_pm_clkdms_setup, NULL);
clkdm_add_wkdep(mpu_clkdm, wkup_clkdm);
/* REVISIT: Configure number of 32 kHz clock cycles for sys_clk
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc69875..ae962b5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -743,21 +743,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
}
/*
- * Enable hw supervised mode for all clockdomains if it's
- * supported. Initiate sleep transition for other clockdomains, if
- * they are not used
- */
-static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
-{
- if (clkdm-flags CLKDM_CAN_ENABLE_AUTO)
- clkdm_allow_idle(clkdm);
- else if (clkdm-flags CLKDM_CAN_FORCE_SLEEP
-atomic_read(clkdm-usecount) == 0)
- clkdm_sleep(clkdm);
- return 0;
-}
-
-/*
* Push functions to SRAM
*
* The minimum set of functions is pushed to SRAM for execution:
@@ -826,7 +811,7 @@ static int __init omap3_pm_init(void)
goto err2;
}
- (void) clkdm_for_each(clkdms_setup, NULL);
+ (void) clkdm_for_each(omap_pm_clkdms_setup, NULL);
mpu_pwrdm = pwrdm_lookup(mpu_pwrdm);
if (mpu_pwrdm == NULL) {
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c264ef7..a6fb31b 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -120,22 +120,6 @@ static const struct platform_suspend_ops omap_pm_ops = {
};
#endif /* CONFIG_SUSPEND */
-/*
- * Enable hardware supervised mode for all clockdomains if it's
- * supported. Initiate sleep transition for other clockdomains, if
- * they are not used
- */
-static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
-{
- if (clkdm-flags CLKDM_CAN_ENABLE_AUTO)
- clkdm_allow_idle(clkdm);
- else if (clkdm-flags CLKDM_CAN_FORCE_SLEEP
- atomic_read(clkdm-usecount) == 0)
- clkdm_sleep(clkdm);
- return 0;
-}
-
-
static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
{
struct power_state *pwrst;
@@ -249,7 +233,7 @@
[PATCH 2/2] ARM: OMAP2+: PM: share some suspend-related functions across OMAP2, 3, 4
The platform_suspend_ops can be shared across OMAP2, 3, and 4, along
with all of the functions referenced in that structure. This patch
shares them. It also removes the suspend_state file-scoped variable
in the OMAP2 and 3 PM code; it does not appear to be actually needed
by anything.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c | 64 ++
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm24xx.c | 56 +++--
arch/arm/mach-omap2/pm34xx.c | 56 -
arch/arm/mach-omap2/pm44xx.c | 39 +-
5 files changed, 77 insertions(+), 139 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 0118614..35f5ac6 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -15,11 +15,13 @@
#include linux/err.h
#include linux/opp.h
#include linux/export.h
+#include linux/suspend.h
#include plat/omap-pm.h
#include plat/omap_device.h
#include common.h
+#include prcm-common.h
#include voltage.h
#include powerdomain.h
#include clockdomain.h
@@ -28,6 +30,12 @@
static struct omap_device_pm_latency *pm_lats;
+/*
+ * omap_pm_suspend: points to a function that does the SoC-specific
+ * suspend work
+ */
+int (*omap_pm_suspend)(void);
+
static int _init_omap_device(char *name)
{
struct omap_hwmod *oh;
@@ -139,6 +147,8 @@ err:
return ret;
}
+
+
/*
* This API is to be called during init to set the various voltage
* domains to the voltage as per the opp table. Typically we boot up
@@ -206,6 +216,56 @@ exit:
return -EINVAL;
}
+#ifdef CONFIG_SUSPEND
+static int omap_pm_enter(suspend_state_t suspend_state)
+{
+ int ret = 0;
+
+ if (!omap_pm_suspend)
+ return -ENOENT; /* XXX doublecheck */
+
+ switch (suspend_state) {
+ case PM_SUSPEND_STANDBY:
+ case PM_SUSPEND_MEM:
+ ret = omap_pm_suspend();
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+static int omap_pm_begin(suspend_state_t state)
+{
+ disable_hlt();
+ if (cpu_is_omap34xx())
+ omap_prcm_irq_prepare();
+ return 0;
+}
+
+static void omap_pm_end(void)
+{
+ enable_hlt();
+ return;
+}
+
+static void omap_pm_finish(void)
+{
+ if (cpu_is_omap34xx())
+ omap_prcm_irq_complete();
+}
+
+static const struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap_pm_begin,
+ .end= omap_pm_end,
+ .enter = omap_pm_enter,
+ .finish = omap_pm_finish,
+ .valid = suspend_valid_only_mem,
+};
+
+#endif /* CONFIG_SUSPEND */
+
static void __init omap3_init_voltages(void)
{
if (!cpu_is_omap34xx())
@@ -248,6 +308,10 @@ static int __init omap2_common_pm_late_init(void)
/* Smartreflex device init */
omap_devinit_smartreflex();
+#ifdef CONFIG_SUSPEND
+ suspend_set_ops(omap_pm_ops);
+#endif
+
return 0;
}
late_initcall(omap2_common_pm_late_init);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index eef67f6..a051431 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -23,6 +23,7 @@ extern int omap_set_pwrdm_state(struct powerdomain *pwrdm,
u32 state);
extern int omap3_idle_init(void);
extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
+extern int (*omap_pm_suspend)(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index bfd7905..538cd15 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -53,19 +53,6 @@
#include powerdomain.h
#include clockdomain.h
-#ifdef CONFIG_SUSPEND
-static suspend_state_t suspend_state = PM_SUSPEND_ON;
-static inline bool is_suspending(void)
-{
- return (suspend_state != PM_SUSPEND_ON);
-}
-#else
-static inline bool is_suspending(void)
-{
- return false;
-}
-#endif
-
static void (*omap2_sram_idle)(void);
static void (*omap2_sram_suspend)(u32 dllctrl, void __iomem *sdrc_dlla_ctrl,
void __iomem *sdrc_power);
@@ -253,13 +240,6 @@ out:
}
#ifdef CONFIG_SUSPEND
-static int omap2_pm_begin(suspend_state_t state)
-{
- disable_hlt();
- suspend_state = state;
- return 0;
-}
-
static int omap2_pm_suspend(void)
{
u32 wken_wkup, mir1;
@@ -279,37 +259,6 @@ static int omap2_pm_suspend(void)
return 0;
}
-
-static int omap2_pm_enter(suspend_state_t state)
-{
- int ret = 0;
-
- switch (state) {
- case PM_SUSPEND_STANDBY:
- case PM_SUSPEND_MEM:
- ret = omap2_pm_suspend();
-
Re: [PATCH] arm/dts: OMAP3: Add omap3evm and am335xevm support
Hi Vaibhav, On 2/2/2012 10:34 AM, Hiremath, Vaibhav wrote: On Thu, Feb 02, 2012 at 10:26:29, Grant Likely wrote: On Wed, Feb 01, 2012 at 11:57:00AM +0530, Vaibhav Hiremath wrote: TI's OMAP3EVM and AM335xEVM are software development boards available for OMAP35x(AM/DM37x) and AM335x devices respectively; and these devices are considered under omap3 family. Signed-off-by: Vaibhav Hiremathhvaib...@ti.com Cc: Benoit Coussonb-cous...@ti.com Cc: Grant Likelygrant.lik...@secretlab.ca Cc: Tony Lindgrent...@atomide.com Applied, thanks. Benoit and/or Grant, Can you also pull-in/merge all other patches which I had submitted recently? I can pull them all through Tony's tree, but I still need Grant's Acked-by. So far, I have these ones ready for pull: arm/dts: Add support for TI OMAP3 EVM board. arm:omap2:board-generic: Add DT support for AM33xx devices arm/dts: Add support for TI AM335x EVM board It looks like these ones do not have the Ack: arm/dts: omap3-evm: Add i2c and twl4030 support arm/dts: Add support for TI AM3517/05 EVM board Regards, Benoit arm/dts: omap3-evm: Add i2c and twl4030 support arm/dts: Add support for TI AM3517/05 EVM board arm:omap2:board-generic: Add DT support for AM33xx devices arm/dts: Add support for TI AM335x EVM board Thanks, Vaibhav g. --- .../devicetree/bindings/arm/omap/omap.txt |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index dbdab40..ce78498 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -41,3 +41,9 @@ Boards: - OMAP4 PandaBoard : Low cost community board compatible = ti,omap4-panda, ti,omap4430 + +- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x + compatible = ti,omap3-evm, ti,omap3 + +- AM335X EVM : Software Developement Board for AM335x + compatible = ti,am335x-evm, ti,am33xx, ti,omap3 -- 1.7.0.4 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()
On Thu, 2 Feb 2012, Shilimkar, Santosh wrote: Yes, we do have issue with below APIs for OMAP4 and onwards design because of the PRCM change. pwrdm_clear_all_prev_pwrst pwrdm_*_mem_* There use to be a single power state and memory state register till OMAP3 at power domain level which can give you the logic and memory last test which is needed for OSWR. On OMAP4, we have registers per modules and it becomes difficult to model this difference in APIs. Initially we tried to fix that with [1] and then later realized that's not going to work on OMAP4 + devices because of mentioned issue. If the registers are per-module, it seems like the best place for those would be the hwmod layer. Do you think that makes sense? So, something like omap_hwmod_clear_all_prev_pwrst(), etc.? Seems like that should be pretty efficient. - 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 1/2] ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()
On Thu, Feb 2, 2012 at 3:35 PM, Paul Walmsley p...@pwsan.com wrote: On Thu, 2 Feb 2012, Shilimkar, Santosh wrote: Yes, we do have issue with below APIs for OMAP4 and onwards design because of the PRCM change. pwrdm_clear_all_prev_pwrst pwrdm_*_mem_* There use to be a single power state and memory state register till OMAP3 at power domain level which can give you the logic and memory last test which is needed for OSWR. On OMAP4, we have registers per modules and it becomes difficult to model this difference in APIs. Initially we tried to fix that with [1] and then later realized that's not going to work on OMAP4 + devices because of mentioned issue. If the registers are per-module, it seems like the best place for those would be the hwmod layer. Do you think that makes sense? So, something like omap_hwmod_clear_all_prev_pwrst(), etc.? Seems like that should be pretty efficient. But all these are power domain registers after all. Rajendra did one version of pwrdm_clear_all_prev_pwrst API and inside used hwmod. But then there he has iterate over all the modules belongs to that power domain. And if you use hwmod or omap_device kind of API, then you need to build those devices in init or some where. All of that was not looking so elegant and hence the other path was chosen. The mess is, the registers are still part of power domains though they are specific to module. And Fundamentally power domain is stil the central entity decides the fate of all the modules within that PD, in terms of context loss/ret etc. Regards santosh -- 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
[DSS2] TFT panel not working (only one column visible)
Dear mailing-list, I am using an AM-320240LETMQW LCD module connected to an OMAP4430. This module use the same display driver as the lb035q02 (the HX8238), so I have used the panel-lgphilips-lb035q02 driver as a starting point for my driver. When using fb-test or using dd if=/dev/urandom of=/dev/fb only the first (left) column (and not row) display some pixels. All the rest is black... I have checked with a scope that the pixclock, hsync and vsync seems ok. I don't know what to test more. Do you have any idea what can cause this kind of problems ? The working line seems to work fine the pixels are stable. Thanks in advance for any help Patrick -- 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] ARM: OMAP2+: PM: code consolidation for 3.4
On Thu, Feb 2, 2012 at 3:08 PM, Paul Walmsley p...@pwsan.com wrote: Hi This series consolidates some duplicated PM code across OMAP2, 3, and 4. This saves both binary kernel image size, and lines of source. These functions are just the low-hanging fruit; it looks to me like there's even more consolidation that could be done. Suspend + UART wakeup was tested on OMAP44xx BeagleBoard. On the OMAP35xx Beagleboard here, v3.3-rc2 doesn't seem to wake up from suspend correctly with or without these patches, so I've only boot-tested them on that platform. Thanks for patches. Tried them on OMAP4 SDP and suspend is fine on it. On the consolidation front, I found that OMAP4/OMAP5 can almost share most of the PRCM code. Actually it's too early to talk about OMAP5 patches, which are not even posted yet but just thought of mentioning that on this relevant thread. I can send you a git link to have early preview on those changes, if you would like to have a look at it. Regards Santosh -- 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 RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented
On Mon, 2012-01-30 at 23:58 +0100, Rafael J. Wysocki wrote: Thanks, but is anyone actually going to push it to Linus any time soon? I agree, but I am not the maintainer so cannot answer. David Woodhouse is aware of this, but I do not know when he gonna send the pull request. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[RFC 0/7] MFD: twl6040: Conversion to i2c driver
Hello, This series will convert the twl6040 MFD driver to an i2c driver. Compared to older twl4030/5030/TPS the twl6040 is a standalone audio IC. It is better if the twl6040-core (and all of it's child devices) does not depend on the twl-core since it has nothing to with it. With this conversion the dependency on twl can be dropped from the twl6040 driver stack (core, vibra, audio). Between the first and second patch the audio will not probe on OMAP4, but I felt it is better this way at least for the first RFC series to not have too big change within one patch. The two patch can be squashed together later if no objections. Regards, Peter --- Peter Ujfalusi (7): MFD: twl-core: Detach twl6040 from the pmic mfd driver MFD: twl6040: Convert to i2c driver, and separate it from twl core ASoC: twl6040: Remove dependency on twl4030 from Kconfig OMAP: 4430sdp: Correct fixed regulator device ID OMAP: sdp4430: Add fixed regulator for twl6040 needs OMAP: omap4panda: Add fixed regulator for twl6040 needs MFD: TWL6040: Add regulator support for VIO, V2V1 supplies arch/arm/mach-omap2/board-4430sdp.c| 77 +-- arch/arm/mach-omap2/board-generic.c|2 +- arch/arm/mach-omap2/board-omap4panda.c | 75 +-- arch/arm/mach-omap2/twl-common.c | 37 ++- arch/arm/mach-omap2/twl-common.h | 10 +- drivers/input/misc/Kconfig |1 - drivers/input/misc/twl6040-vibra.c |4 +- drivers/mfd/Kconfig|2 +- drivers/mfd/twl-core.c | 58 +++- drivers/mfd/twl6040-core.c | 165 ++-- include/linux/i2c/twl.h| 12 --- include/linux/mfd/twl6040.h| 27 + sound/soc/codecs/Kconfig |2 +- sound/soc/codecs/twl6040.c |3 +- 14 files changed, 375 insertions(+), 100 deletions(-) -- 1.7.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/7] MFD: twl-core: Detach twl6040 from the pmic mfd driver
On OMAP4 platform audio has separate IC, it is no longer part
of the pmic chip.
Prevent twl-core to claim the 0x4b address, which belongs to
the twl6040 audio IC.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 58 +++
1 files changed, 33 insertions(+), 25 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index e04e04d..ac6fdd93 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -115,8 +115,8 @@
#define twl_has_watchdog()false
#endif
-#if defined(CONFIG_MFD_TWL4030_AUDIO) ||
defined(CONFIG_MFD_TWL4030_AUDIO_MODULE) ||\
- defined(CONFIG_TWL6040_CORE) || defined(CONFIG_TWL6040_CORE_MODULE)
+#if defined(CONFIG_MFD_TWL4030_AUDIO) || \
+ defined(CONFIG_MFD_TWL4030_AUDIO_MODULE)
#define twl_has_codec()true
#else
#define twl_has_codec()false
@@ -146,6 +146,7 @@
#define SUB_CHIP_ID1 1
#define SUB_CHIP_ID2 2
#define SUB_CHIP_ID3 3
+#define SUB_CHIP_ID_INVAL 0xff
#define TWL_MODULE_LAST TWL4030_MODULE_LAST
@@ -315,7 +316,7 @@ static struct twl_mapping twl6030_map[] = {
* so they continue to match the order in this table.
*/
{ SUB_CHIP_ID1, TWL6030_BASEADD_USB },
- { SUB_CHIP_ID3, TWL6030_BASEADD_AUDIO },
+ { SUB_CHIP_ID_INVAL, TWL6030_BASEADD_AUDIO },
{ SUB_CHIP_ID2, TWL6030_BASEADD_DIEID },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
{ SUB_CHIP_ID1, TWL6030_BASEADD_PIH },
@@ -377,6 +378,11 @@ int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes)
return -EPERM;
}
sid = twl_map[mod_no].sid;
+ if (unlikely(sid == SUB_CHIP_ID_INVAL)) {
+ pr_err(%s: module %d is not part of the pmic\n,
+ DRIVER_NAME, mod_no);
+ return -EINVAL;
+ }
twl = twl_modules[sid];
mutex_lock(twl-xfer_lock);
@@ -434,6 +440,11 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes)
return -EPERM;
}
sid = twl_map[mod_no].sid;
+ if (unlikely(sid == SUB_CHIP_ID_INVAL)) {
+ pr_err(%s: module %d is not part of the pmic\n,
+ DRIVER_NAME, mod_no);
+ return -EINVAL;
+ }
twl = twl_modules[sid];
mutex_lock(twl-xfer_lock);
@@ -834,15 +845,6 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
return PTR_ERR(child);
}
- if (twl_has_codec() pdata-audio twl_class_is_6030()) {
- sub_chip_id = twl_map[TWL_MODULE_AUDIO_VOICE].sid;
- child = add_child(sub_chip_id, twl6040,
- pdata-audio, sizeof(*pdata-audio),
- false, 0, 0);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
/* twl4030 regulators */
if (twl_has_regulator() twl_class_is_4030()) {
child = add_regulator(TWL4030_REG_VPLL1, pdata-vpll1,
@@ -1163,18 +1165,21 @@ int twl6030_exit_irq(void);
static int twl_remove(struct i2c_client *client)
{
- unsigned i;
+ unsigned i, num_slaves;
int status;
- if (twl_class_is_4030())
+ if (twl_class_is_4030()) {
status = twl4030_exit_irq();
- else
+ num_slaves = TWL_NUM_SLAVES;
+ } else {
status = twl6030_exit_irq();
+ num_slaves = TWL_NUM_SLAVES - 1;
+ }
if (status 0)
return status;
- for (i = 0; i TWL_NUM_SLAVES; i++) {
+ for (i = 0; i num_slaves; i++) {
struct twl_client *twl = twl_modules[i];
if (twl-client twl-client != client)
@@ -1190,7 +1195,7 @@ static int __devinit
twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
int status;
- unsignedi;
+ unsignedi, num_slaves;
struct twl4030_platform_data*pdata = client-dev.platform_data;
struct device_node *node = client-dev.of_node;
u8 temp;
@@ -1244,7 +1249,17 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
return -EBUSY;
}
- for (i = 0; i TWL_NUM_SLAVES; i++) {
+ if ((id-driver_data) TWL6030_CLASS) {
+ twl_id = TWL6030_CLASS_ID;
+ twl_map = twl6030_map[0];
+ num_slaves = TWL_NUM_SLAVES - 1;
+ } else {
+ twl_id = TWL4030_CLASS_ID;
+ twl_map = twl4030_map[0];
+ num_slaves = TWL_NUM_SLAVES;
+ }
+
+ for (i = 0; i num_slaves; i++) {
struct twl_client *twl = twl_modules[i];
twl-address = client-addr + i;
@@ -1263,13 +1278,6 @@ twl_probe(struct i2c_client *client, const
[RFC 3/7] ASoC: twl6040: Remove dependency on twl4030 from Kconfig
twl6040 no longer needs twl4030. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- sound/soc/codecs/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 7c205e7..9462d50 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -56,7 +56,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TPA6130A2 if I2C select SND_SOC_TLV320DAC33 if I2C select SND_SOC_TWL4030 if TWL4030_CORE - select SND_SOC_TWL6040 if TWL4030_CORE + select SND_SOC_TWL6040 select SND_SOC_UDA134X select SND_SOC_UDA1380 if I2C select SND_SOC_WL1273 if MFD_WL1273_CORE -- 1.7.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 5/7] OMAP: sdp4430: Add fixed regulator for twl6040 needs
The twl6040 VIO power is connected to SMPS V1V8, the
V2V1 power is coming from SMPS V2V1 of twl6030.
These are fixed, always on regulators.
Create fixed voltage regulators for these supplies.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 58 +++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index d02172d..5de5753 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -64,6 +64,8 @@
#define FIXED_REG_VBAT_ID 0
#define FIXED_REG_VWLAN_ID 1
+#define FIXED_REG_V2V1_ID 2
+#define FIXED_REG_V1V8_ID 3
static const int sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
@@ -349,6 +351,60 @@ static int __init omap_ethernet_init(void)
return status;
}
+static struct regulator_consumer_supply sdp4430_vpmic_v2v1_supply[] = {
+ REGULATOR_SUPPLY(v2v1, 1-004b),
+};
+
+static struct regulator_init_data sdp4430_v2v1smps = {
+ .constraints = {
+ .always_on = true,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(sdp4430_vpmic_v2v1_supply),
+ .consumer_supplies = sdp4430_vpmic_v2v1_supply,
+};
+
+static struct fixed_voltage_config sdp4430_v2v1_pdata = {
+ .supply_name= VPMIC-V2V1,
+ .microvolts = 210,
+ .init_data = sdp4430_v2v1smps,
+ .gpio = -EINVAL,
+};
+
+static struct platform_device sdp4430_v2v1 = {
+ .name = reg-fixed-voltage,
+ .id = FIXED_REG_V2V1_ID,
+ .dev = {
+ .platform_data = sdp4430_v2v1_pdata,
+ },
+};
+
+static struct regulator_consumer_supply sdp4430_vpmic_v1v8_supply[] = {
+ REGULATOR_SUPPLY(vio, 1-004b),
+};
+
+static struct regulator_init_data sdp4430_v1v8smps = {
+ .constraints = {
+ .always_on = true,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(sdp4430_vpmic_v1v8_supply),
+ .consumer_supplies = sdp4430_vpmic_v1v8_supply,
+};
+
+static struct fixed_voltage_config sdp4430_v1v8_pdata = {
+ .supply_name= VPMIC-V1V8,
+ .microvolts = 180,
+ .init_data = sdp4430_v1v8smps,
+ .gpio = -EINVAL,
+};
+
+static struct platform_device sdp4430_v1v8 = {
+ .name = reg-fixed-voltage,
+ .id = FIXED_REG_V1V8_ID,
+ .dev = {
+ .platform_data = sdp4430_v1v8_pdata,
+ },
+};
+
static struct regulator_consumer_supply sdp4430_vbat_supply[] = {
REGULATOR_SUPPLY(vddvibl, twl6040-vibra),
REGULATOR_SUPPLY(vddvibr, twl6040-vibra),
@@ -416,6 +472,8 @@ static struct platform_device *sdp4430_devices[] __initdata
= {
sdp4430_vbat,
sdp4430_dmic_codec,
sdp4430_abe_audio,
+ sdp4430_v1v8,
+ sdp4430_v2v1,
};
static struct omap_musb_board_data musb_board_data = {
--
1.7.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 7/7] MFD: TWL6040: Add regulator support for VIO, V2V1 supplies
twl6040 has three power supply source:
VBAT needs to be connected to VBAT
VIO, and V2V1.
Add regulator support for the VIO, V2V1 supplies.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040-core.c | 41 +
include/linux/mfd/twl6040.h |2 ++
2 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl6040-core.c b/drivers/mfd/twl6040-core.c
index 21d6a99..04568ea 100644
--- a/drivers/mfd/twl6040-core.c
+++ b/drivers/mfd/twl6040-core.c
@@ -27,12 +27,14 @@
#include linux/types.h
#include linux/slab.h
#include linux/kernel.h
+#include linux/err.h
#include linux/platform_device.h
#include linux/gpio.h
#include linux/delay.h
#include linux/i2c.h
#include linux/mfd/core.h
#include linux/mfd/twl6040.h
+#include linux/regulator/consumer.h
#define VIBRACTRL_MEMBER(reg) ((reg == TWL6040_REG_VIBCTLL) ? 0 : 1)
@@ -541,6 +543,33 @@ static int __devinit twl6040_probe(struct i2c_client
*client,
i2c_set_clientdata(client, twl6040);
+ twl6040-vio = regulator_get(client-dev, vio);
+ if (IS_ERR(twl6040-vio)) {
+ ret = PTR_ERR(twl6040-vio);
+ dev_err(client-dev, Failed to request VIO supply: %d\n,
+ ret);
+ goto regulator_get_err;
+ }
+ twl6040-v2v1 = regulator_get(client-dev, v2v1);
+ if (IS_ERR(twl6040-v2v1)) {
+ ret = PTR_ERR(twl6040-v2v1);
+ dev_err(client-dev, Failed to request V2V1 supply: %d\n,
+ ret);
+ regulator_put(twl6040-vio);
+ goto regulator_get_err;
+ }
+ ret = regulator_enable(twl6040-vio);
+ if (ret != 0) {
+ dev_err(client-dev, Failed to enable VIO: %d\n, ret);
+ goto power_err;
+ }
+ ret = regulator_enable(twl6040-v2v1);
+ if (ret != 0) {
+ dev_err(client-dev, Failed to enable V2V1: %d\n, ret);
+ regulator_disable(twl6040-vio);
+ goto power_err;
+ }
+
twl6040-dev = client-dev;
twl6040-control_data = client;
twl6040-irq = client-irq;
@@ -632,6 +661,12 @@ gpio2_err:
if (gpio_is_valid(twl6040-audpwron))
gpio_free(twl6040-audpwron);
gpio1_err:
+ regulator_disable(twl6040-v2v1);
+ regulator_disable(twl6040-vio);
+power_err:
+ regulator_put(twl6040-vio);
+ regulator_put(twl6040-v2v1);
+regulator_get_err:
i2c_set_clientdata(client, NULL);
kfree(twl6040);
return ret;
@@ -652,6 +687,12 @@ static int __devexit twl6040_remove(struct i2c_client
*client)
mfd_remove_devices(client-dev);
i2c_set_clientdata(client, NULL);
+
+ regulator_disable(twl6040-v2v1);
+ regulator_disable(twl6040-vio);
+ regulator_put(twl6040-vio);
+ regulator_put(twl6040-v2v1);
+
kfree(twl6040);
return 0;
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index 72f530f..146de4e 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -201,6 +201,8 @@ struct twl6040_platform_data {
struct twl6040 {
struct i2c_client *control_data;
struct device *dev;
+ struct regulator *vio;
+ struct regulator *v2v1;
struct mutex mutex;
struct mutex io_mutex;
struct mutex irq_mutex;
--
1.7.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 6/7] OMAP: omap4panda: Add fixed regulator for twl6040 needs
The twl6040 VIO power is connected to SMPS V1V8, the
V2V1 power is coming from SMPS V2V1 of twl6030.
These are fixed, always on regulators.
Create fixed voltage regulators for these supplies.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 62 +++-
1 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index da31a72..4d66c60 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -56,6 +56,10 @@
#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define FIXED_REG_VWLAN_ID 0
+#define FIXED_REG_V2V1_ID 1
+#define FIXED_REG_V1V8_ID 2
+
/* wl127x BT, FM, GPS connectivity chip */
static int wl1271_gpios[] = {46, -1, -1};
static struct platform_device wl1271_device = {
@@ -116,10 +120,66 @@ static struct platform_device panda_abe_audio = {
},
};
+static struct regulator_consumer_supply panda_vdd_v2v1_supply[] = {
+ REGULATOR_SUPPLY(v2v1, 1-004b),
+};
+
+static struct regulator_init_data panda_v2v1smps = {
+ .constraints = {
+ .always_on = true,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(panda_vdd_v2v1_supply),
+ .consumer_supplies = panda_vdd_v2v1_supply,
+};
+
+static struct fixed_voltage_config panda_v2v1_pdata = {
+ .supply_name= VDD-V2V1,
+ .microvolts = 210,
+ .init_data = panda_v2v1smps,
+ .gpio = -EINVAL,
+};
+
+static struct platform_device panda_v2v1 = {
+ .name = reg-fixed-voltage,
+ .id = FIXED_REG_V2V1_ID,
+ .dev = {
+ .platform_data = panda_v2v1_pdata,
+ },
+};
+
+static struct regulator_consumer_supply panda_vio_v1v8_supply[] = {
+ REGULATOR_SUPPLY(vio, 1-004b),
+};
+
+static struct regulator_init_data panda_v1v8smps = {
+ .constraints = {
+ .always_on = true,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(panda_vio_v1v8_supply),
+ .consumer_supplies = panda_vio_v1v8_supply,
+};
+
+static struct fixed_voltage_config panda_v1v8_pdata = {
+ .supply_name= VIO-V1V8,
+ .microvolts = 180,
+ .init_data = panda_v1v8smps,
+ .gpio = -EINVAL,
+};
+
+static struct platform_device panda_v1v8 = {
+ .name = reg-fixed-voltage,
+ .id = FIXED_REG_V1V8_ID,
+ .dev = {
+ .platform_data = panda_v1v8_pdata,
+ },
+};
+
static struct platform_device *panda_devices[] __initdata = {
leds_gpio,
wl1271_device,
panda_abe_audio,
+ panda_v1v8,
+ panda_v2v1,
};
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
@@ -218,7 +278,7 @@ static struct fixed_voltage_config panda_vwlan = {
static struct platform_device omap_vwlan_device = {
.name = reg-fixed-voltage,
- .id = 1,
+ .id = FIXED_REG_VWLAN_ID,
.dev = {
.platform_data = panda_vwlan,
},
--
1.7.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/7] OMAP: 4430sdp: Correct fixed regulator device ID
The board has two fixed voltage regulator. Correct the
device ID for the vbat, which used -1.
Create defines for the fixed regulator IDs so when adding new
regulators we know the next available ID to use for them.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index f4ac553..d02172d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -62,6 +62,9 @@
#define GPIO_WIFI_PMENA54
#define GPIO_WIFI_IRQ 53
+#define FIXED_REG_VBAT_ID 0
+#define FIXED_REG_VWLAN_ID 1
+
static const int sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
KEY(0, 1, KEY_R),
@@ -368,7 +371,7 @@ static struct fixed_voltage_config sdp4430_vbat_pdata = {
static struct platform_device sdp4430_vbat = {
.name = reg-fixed-voltage,
- .id = -1,
+ .id = FIXED_REG_VBAT_ID,
.dev = {
.platform_data = sdp4430_vbat_pdata,
},
@@ -478,7 +481,7 @@ static struct fixed_voltage_config sdp4430_vwlan = {
static struct platform_device omap_vwlan_device = {
.name = reg-fixed-voltage,
- .id = 1,
+ .id = FIXED_REG_VWLAN_ID,
.dev = {
.platform_data = sdp4430_vwlan,
},
--
1.7.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/7] MFD: twl6040: Convert to i2c driver, and separate it from twl core
twl6040 is a separate chip, it is not part of the twl6030
PMIC.
Complete the separation of the twl6040 from the twl core.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 12 ++--
arch/arm/mach-omap2/board-generic.c|2 +-
arch/arm/mach-omap2/board-omap4panda.c | 13 ++--
arch/arm/mach-omap2/twl-common.c | 37 --
arch/arm/mach-omap2/twl-common.h | 10 +--
drivers/input/misc/Kconfig |1 -
drivers/input/misc/twl6040-vibra.c |4 +-
drivers/mfd/Kconfig|2 +-
drivers/mfd/twl6040-core.c | 124 ---
include/linux/i2c/twl.h| 12 ---
include/linux/mfd/twl6040.h| 25 +++
sound/soc/codecs/twl6040.c |3 +-
12 files changed, 174 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 7eaeb08..f4ac553 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include linux/usb/otg.h
#include linux/spi/spi.h
#include linux/i2c/twl.h
+#include linux/mfd/twl6040.h
#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
@@ -554,7 +555,7 @@ static struct regulator_init_data sdp4430_vusim = {
},
};
-static struct twl4030_codec_data twl6040_codec = {
+static struct twl6040_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
.hs_left_step = 0x0f,
.hs_right_step = 0x0f,
@@ -562,7 +563,7 @@ static struct twl4030_codec_data twl6040_codec = {
.hf_right_step = 0x1d,
};
-static struct twl4030_vibra_data twl6040_vibra = {
+static struct twl6040_vibra_data twl6040_vibra = {
.vibldrv_res = 8,
.vibrdrv_res = 3,
.viblmotor_res = 10,
@@ -571,16 +572,14 @@ static struct twl4030_vibra_data twl6040_vibra = {
.vddvibr_uV = 0,/* fixed volt supply - VBAT */
};
-static struct twl4030_audio_data twl6040_audio = {
+static struct twl6040_platform_data twl6040_data = {
.codec = twl6040_codec,
.vibra = twl6040_vibra,
.audpwron_gpio = 127,
- .naudint_irq= OMAP44XX_IRQ_SYS_2N,
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
static struct twl4030_platform_data sdp4430_twldata = {
- .audio = twl6040_audio,
/* Regulators */
.vusim = sdp4430_vusim,
.vaux1 = sdp4430_vaux1,
@@ -611,7 +610,8 @@ static int __init omap4_i2c_init(void)
TWL_COMMON_REGULATOR_VCXIO |
TWL_COMMON_REGULATOR_VUSB |
TWL_COMMON_REGULATOR_CLK32KG);
- omap4_pmic_init(twl6030, sdp4430_twldata);
+ omap4_pmic_init(twl6030, sdp4430_twldata,
+ twl6040_data, OMAP44XX_IRQ_SYS_2N);
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index d587560..68b9d8a 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -35,7 +35,7 @@ static struct twl4030_platform_data sdp4430_twldata = {
static void __init omap4_i2c_init(void)
{
- omap4_pmic_init(twl6030, sdp4430_twldata);
+ omap4_pmic_init(twl6030, sdp4430_twldata, NULL, 0);
}
#endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index eada955..da31a72 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -25,6 +25,7 @@
#include linux/gpio.h
#include linux/usb/otg.h
#include linux/i2c/twl.h
+#include linux/mfd/twl6040.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
#include linux/wl12xx.h
@@ -277,7 +278,7 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
return 0;
}
-static struct twl4030_codec_data twl6040_codec = {
+static struct twl6040_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
.hs_left_step = 0x0f,
.hs_right_step = 0x0f,
@@ -285,17 +286,14 @@ static struct twl4030_codec_data twl6040_codec = {
.hf_right_step = 0x1d,
};
-static struct twl4030_audio_data twl6040_audio = {
+static struct twl6040_platform_data twl6040_data = {
.codec = twl6040_codec,
.audpwron_gpio = 127,
- .naudint_irq= OMAP44XX_IRQ_SYS_2N,
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
/* Panda board uses the common PMIC configuration */
-static struct twl4030_platform_data omap4_panda_twldata = {
- .audio = twl6040_audio,
-};
+static struct twl4030_platform_data omap4_panda_twldata;
/*
*
Re: [RFC 4/7] OMAP: 4430sdp: Correct fixed regulator device ID
On Thu, Feb 02, 2012 at 02:16:56PM +0200, Peter Ujfalusi wrote: The board has two fixed voltage regulator. Correct the device ID for the vbat, which used -1. Create defines for the fixed regulator IDs so when adding new regulators we know the next available ID to use for them. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com signature.asc Description: Digital signature
Re: [RFC 5/7] OMAP: sdp4430: Add fixed regulator for twl6040 needs
On Thu, Feb 02, 2012 at 02:16:57PM +0200, Peter Ujfalusi wrote: The twl6040 VIO power is connected to SMPS V1V8, the V2V1 power is coming from SMPS V2V1 of twl6030. These are fixed, always on regulators. Create fixed voltage regulators for these supplies. Shouldn't the PMIC be creating the relevant fixed voltage regulators? It's a bit clearer given that the supplies actually come from the PMIC and it would cut down a bit on the boilerplate in boards (though much less so with device tree, sadly). signature.asc Description: Digital signature
Re: [RFC 6/7] OMAP: omap4panda: Add fixed regulator for twl6040 needs
On Thu, Feb 02, 2012 at 02:16:58PM +0200, Peter Ujfalusi wrote: The twl6040 VIO power is connected to SMPS V1V8, the V2V1 power is coming from SMPS V2V1 of twl6030. These are fixed, always on regulators. Create fixed voltage regulators for these supplies. Same issue as previously, shouldn't the PMIC create the regulators? signature.asc Description: Digital signature
Re: [RFC 3/7] ASoC: twl6040: Remove dependency on twl4030 from Kconfig
On Thu, Feb 02, 2012 at 02:16:55PM +0200, Peter Ujfalusi wrote: twl6040 no longer needs twl4030. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com Not applying since this needs to follow on from (or be integrated with) the patch splitting the twl6040 to avoid build breaks. signature.asc Description: Digital signature
Re: [RFC 2/7] MFD: twl6040: Convert to i2c driver, and separate it from twl core
On Thu, Feb 02, 2012 at 02:16:54PM +0200, Peter Ujfalusi wrote:
+static int twl6040_i2c_read(struct i2c_client *i2c, u8 *value, u8 reg)
+{
+ struct i2c_msg msg[2];
+ int ret;
May as well convert to regmap while you're at it, saves some code and
will get you access to the regmap features - you have to make updates in
all the relevant places anyway. We should be pushing to remove use of
the ASoC level code for register cache and whatnot to cut down on code
duplication (especially for MFDs where it has a few issues interacting
with the MFD) and this seems like a good opportunity.
The calling convention here seems a bit weird too, you've got value then
register but normally we have register then value for I2C/SPI devices.
Except when we don't :(
-module_platform_driver(twl6040_driver);
+static int __devinit twl6040_init(void)
+{
+ return i2c_add_driver(twl6040_driver);
+}
+module_init(twl6040_init);
+
+static void __devexit twl6040_exit(void)
+{
+ i2c_del_driver(twl6040_driver);
+}
+
+module_exit(twl6040_exit);
There's module_i2c_driver() in mainline as of the last merge window.
signature.asc
Description: Digital signature
Re: [RFC 7/7] MFD: TWL6040: Add regulator support for VIO, V2V1 supplies
On Thu, Feb 02, 2012 at 02:16:59PM +0200, Peter Ujfalusi wrote:
+ twl6040-vio = regulator_get(client-dev, vio);
+ if (IS_ERR(twl6040-vio)) {
+ ret = PTR_ERR(twl6040-vio);
+ dev_err(client-dev, Failed to request VIO supply: %d\n,
+ ret);
+ goto regulator_get_err;
+ }
+ twl6040-v2v1 = regulator_get(client-dev, v2v1);
+ if (IS_ERR(twl6040-v2v1)) {
+ ret = PTR_ERR(twl6040-v2v1);
+ dev_err(client-dev, Failed to request V2V1 supply: %d\n,
+ ret);
+ regulator_put(twl6040-vio);
+ goto regulator_get_err;
+ }
Looks like you want regulator_bulk_get() here. Or (better yet though
it'd be a potential issue for merge via MFD and the benefits aren't that
exciting since you still need to disable) devm_regulator_bulk_get().
+ ret = regulator_enable(twl6040-vio);
+ if (ret != 0) {
+ dev_err(client-dev, Failed to enable VIO: %d\n, ret);
+ goto power_err;
+ }
+ ret = regulator_enable(twl6040-v2v1);
+ if (ret != 0) {
+ dev_err(client-dev, Failed to enable V2V1: %d\n, ret);
+ regulator_disable(twl6040-vio);
+ goto power_err;
+ }
Similarly regulator_bulk_enable() here, and it'll fix...
gpio1_err:
+ regulator_disable(twl6040-v2v1);
+ regulator_disable(twl6040-vio);
...the fact that if you fail to enable the v2.1 regulator you don't
disable vio.
signature.asc
Description: Digital signature
Re: [PATCH 1/1] omap3: add definition for CONTROL_CAMERA_PHY_CTRL
Hi Laurent, On Thu, Jan 12, 2012 at 12:57:44AM +0100, Laurent Pinchart wrote: On Thursday 12 January 2012 00:03:55 Sakari Ailus wrote: On Wed, Jan 11, 2012 at 07:11:58AM -0700, Paul Walmsley wrote: On Sun, 8 Jan 2012, Sakari Ailus wrote: Hi Tony and Paul, On Wed, Dec 14, 2011 at 05:14:16PM +0200, Sakari Ailus wrote: The register is used to configure the behaviour of the CSI-2 and CCP-2 receivers. This register is available only in OMAP3630. The original patch was submitted by Vimarsh Zutshi. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- arch/arm/mach-omap2/control.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index d4ef75d..6a26a0d 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -183,6 +183,7 @@ #define OMAP3630_CONTROL_FUSE_OPP120_VDD1 (OMAP2_CONTROL_GENERAL + 0x0120) #define OMAP3630_CONTROL_FUSE_OPP50_VDD2(OMAP2_CONTROL_GENERAL + 0x0128) #define OMAP3630_CONTROL_FUSE_OPP100_VDD2 (OMAP2_CONTROL_GENERAL + 0x012C) +#define OMAP3630_CONTROL_CAMERA_PHY_CTRL (OMAP2_CONTROL_GENERAL + 0x02f0) I assume this patch hasn't gone anywhere yet which might be good. While the definition of this register would appear to belong to this file, it is being included from the OMAP 3 ISP driver, which only uses it if it's running on the 3630. The problem is that control.h isn't apparently intended to be included except locally and I didn't find a suitable file under include/mach to put this definition either. Currently this file is being included by the ISP driver with an explicit path. Do you have an insight how this could be handled better? We've been trying to ensure that register accesses to/from a given IP block only occur in a driver for that IP block. So under that principle, any System Control Module accesses should go into a System Control Module driver. Then that SCM driver should export (via EXPORT_SYMBOL) a higher-level interface to whatever code uses it. The idea is that this interface would remain stable no matter what underlying SoC was in use. Only thing is, we don't yet have a SCM driver. Historically, since the SCM is tightly coupled with the underlying SoC, when we've needed to do something like this in the past, we've added code to arch/arm/mach-omap2/control.c. But that's not really workable now. Do you know if this register, or something like it, is present on later OMAPs? Also, which bitfields are you planning to use? I don't believe it exists on other OMAPs --- possibly on 3730 but the CSI-2 receiver is not officially supported on it. The register does not exist on the 3430, at least not under the same name --- a reason for not existing could be that the 3430 only has one CSI-2 receiver. The 4430 doesn't seem to have it either, at least not under that name. I think the solution to conditionally access it in the ISP driver would be, albeit not pretty, a workable one: the driver is unlikely to be used on other platforms and this is a single register accessed in a single location. I'm of course open for better options. A (maybe less intrusive) hack would be to add an accessor function in arch/arm/mach-omap2/control.c and EXPORT_SYMBOL it. The functions in that file are currently defined in... surprise: control.h! So, is this something that in your opinion warrants creating another public header file, or is there an obvious public place to put this definition? I see not much difference since the register is only available on one OMAP 3 version (3[67]xx). Also, if the OMAP 3 ISP driver would be used on any other SoC than the OMAP 3, we'd need again to handle the situation differently. Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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 5/7] OMAP: sdp4430: Add fixed regulator for twl6040 needs
On 02/02/2012 02:40 PM, Mark Brown wrote: On Thu, Feb 02, 2012 at 02:16:57PM +0200, Peter Ujfalusi wrote: The twl6040 VIO power is connected to SMPS V1V8, the V2V1 power is coming from SMPS V2V1 of twl6030. These are fixed, always on regulators. Create fixed voltage regulators for these supplies. Shouldn't the PMIC be creating the relevant fixed voltage regulators? It's a bit clearer given that the supplies actually come from the PMIC and it would cut down a bit on the boilerplate in boards (though much less so with device tree, sadly). Yes these are coming from twl6030, so it might be better to create the fixed regulators in the PMIC driver. I'll take a look. Thanks, Péter -- 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 7/7] MFD: TWL6040: Add regulator support for VIO, V2V1 supplies
On 02/02/2012 02:52 PM, Mark Brown wrote:
On Thu, Feb 02, 2012 at 02:16:59PM +0200, Peter Ujfalusi wrote:
+twl6040-vio = regulator_get(client-dev, vio);
+if (IS_ERR(twl6040-vio)) {
+ret = PTR_ERR(twl6040-vio);
+dev_err(client-dev, Failed to request VIO supply: %d\n,
+ret);
+goto regulator_get_err;
+}
+twl6040-v2v1 = regulator_get(client-dev, v2v1);
+if (IS_ERR(twl6040-v2v1)) {
+ret = PTR_ERR(twl6040-v2v1);
+dev_err(client-dev, Failed to request V2V1 supply: %d\n,
+ret);
+regulator_put(twl6040-vio);
+goto regulator_get_err;
+}
Looks like you want regulator_bulk_get() here. Or (better yet though
it'd be a potential issue for merge via MFD and the benefits aren't that
exciting since you still need to disable) devm_regulator_bulk_get().
I need separate control for the two power source since we can hit
different power levels depending on which is powered/not powered:
power down: vio, v2v1 is OFF
deep sleep: vio is ON, v2v1 is OFF
sleep/power on: vio, v2v1 is ON
And we have certain sequence to move between power states.
+ret = regulator_enable(twl6040-vio);
+if (ret != 0) {
+dev_err(client-dev, Failed to enable VIO: %d\n, ret);
+goto power_err;
+}
+ret = regulator_enable(twl6040-v2v1);
+if (ret != 0) {
+dev_err(client-dev, Failed to enable V2V1: %d\n, ret);
+regulator_disable(twl6040-vio);
I disable the vio here, if the v2v1 enable fails.
+goto power_err;
+}
Similarly regulator_bulk_enable() here, and it'll fix...
gpio1_err:
+regulator_disable(twl6040-v2v1);
+regulator_disable(twl6040-vio);
...the fact that if you fail to enable the v2.1 regulator you don't
disable vio.
It is handled within the if(){}
With the devm_regulator this will be much nicer for sure.
--
Péter
--
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 2/7] MFD: twl6040: Convert to i2c driver, and separate it from twl core
On Thu, Feb 02, 2012 at 03:01:06PM +0200, Peter Ujfalusi wrote: On 02/02/2012 02:48 PM, Mark Brown wrote: The calling convention here seems a bit weird too, you've got value then register but normally we have register then value for I2C/SPI devices. I have based these part on the twl-core's implementation. I should not have done that, I know.. Let's see how it will look like with regmap. Yeah, like I say... Except when we don't :( ...it's not like we've been consistent so far. I'm not that fussed either way, I probably wouldn't have mentioned it if I hadn't otherwise been commenting. signature.asc Description: Digital signature
Re: [RFC 7/7] MFD: TWL6040: Add regulator support for VIO, V2V1 supplies
On Thu, Feb 02, 2012 at 03:18:09PM +0200, Peter Ujfalusi wrote:
On 02/02/2012 02:52 PM, Mark Brown wrote:
Looks like you want regulator_bulk_get() here. Or (better yet though
it'd be a potential issue for merge via MFD and the benefits aren't that
exciting since you still need to disable) devm_regulator_bulk_get().
I need separate control for the two power source since we can hit
different power levels depending on which is powered/not powered:
power down: vio, v2v1 is OFF
deep sleep: vio is ON, v2v1 is OFF
sleep/power on: vio, v2v1 is ON
And we have certain sequence to move between power states.
That's not a problem for using the bulk get - the array is part of the
API so you can use regulator_bulk_get() and still look at individual
supplies within the array later on when enabling and disabling them.
+ ret = regulator_enable(twl6040-vio);
+ if (ret != 0) {
+ dev_err(client-dev, Failed to enable VIO: %d\n, ret);
+ goto power_err;
+ }
+ ret = regulator_enable(twl6040-v2v1);
+ if (ret != 0) {
+ dev_err(client-dev, Failed to enable V2V1: %d\n, ret);
+ regulator_disable(twl6040-vio);
I disable the vio here, if the v2v1 enable fails.
Oh, that's quite confusing when mixed in with the goto/unwind - it'd be
clearer to have the extra lable to jump to.
signature.asc
Description: Digital signature
Re: [RFC 7/7] MFD: TWL6040: Add regulator support for VIO, V2V1 supplies
On 02/02/2012 03:32 PM, Mark Brown wrote:
That's not a problem for using the bulk get - the array is part of the
API so you can use regulator_bulk_get() and still look at individual
supplies within the array later on when enabling and disabling them.
For some reason I have associated the use of regulator_bulk_get with the
use of regulator_bulk_enable/disable. It did not even crossed my mind
that I can still use regulator_enable on the individual regulators.
Will convert the regulator_get/put to bulk operations. It will make the
code a bit cleaner.
Thanks
+ ret = regulator_enable(twl6040-vio);
+ if (ret != 0) {
+ dev_err(client-dev, Failed to enable VIO: %d\n, ret);
+ goto power_err;
+ }
+ ret = regulator_enable(twl6040-v2v1);
+ if (ret != 0) {
+ dev_err(client-dev, Failed to enable V2V1: %d\n, ret);
+ regulator_disable(twl6040-vio);
I disable the vio here, if the v2v1 enable fails.
Oh, that's quite confusing when mixed in with the goto/unwind - it'd be
clearer to have the extra lable to jump to.
I guess this is a matter of taste.
However I have found some inconsistent naming with the exit labels,
which I'm going to fix for the next series.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: OMAP: Couple of misc fixes for 3.3
Patches are tested on OMAP4430 SDP. The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab: Linux 3.3-rc2 (2012-01-31 13:31:54 -0800) Rajendra Nayak (1): ARM: OMAP: Get rid of reset for system timer Santosh Shilimkar (1): ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback arch/arm/mach-omap2/Kconfig |4 ++-- arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/io.c |1 + arch/arm/mach-omap2/omap4-common.c| 25 - arch/arm/mach-omap2/timer.c |1 - arch/arm/plat-omap/common.c |1 + arch/arm/plat-omap/include/plat/omap-secure.h |6 ++ 7 files changed, 27 insertions(+), 12 deletions(-) -- 1.7.4.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
[PATCH 1/2] ARM: OMAP: Get rid of reset for system timer
From: Rajendra Nayak rna...@ti.com hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/timer.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 6eeff0e..ccd2d6a 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -195,7 +195,6 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer, } } __omap_dm_timer_init_regs(timer); - __omap_dm_timer_reset(timer, 1, 1); timer-posted = 1; timer-rate = clk_get_rate(timer-fclk); -- 1.7.4.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
[PATCH 2/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
arm_memblock_steal() is not suppose to be used outside -reserve callback.
OMAP barrier errata code was using it outside reserve callback and hence
it was broken.
Move the allocation as part of -reserve callback to fix the it.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |4 ++--
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/omap4-common.c| 25 -
arch/arm/plat-omap/common.c |1 +
arch/arm/plat-omap/include/plat/omap-secure.h |6 ++
6 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41e6612..ac6b1d3 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -365,8 +365,8 @@ config OMAP3_SDRC_AC_TIMING
going on could result in system crashes;
config OMAP4_ERRATA_I688
- bool OMAP4 errata: Async Bridge Corruption (BROKEN)
- depends on ARCH_OMAP4 BROKEN
+ bool OMAP4 errata: Async Bridge Corruption
+ depends on ARCH_OMAP4
select ARCH_HAS_BARRIERS
help
If a data is stalled inside asynchronous bridge because of back
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index febffde..7e9338e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -132,6 +132,7 @@ void omap3_map_io(void);
void am33xx_map_io(void);
void omap4_map_io(void);
void ti81xx_map_io(void);
+void omap_barriers_init(void);
/**
* omap_test_timeout - busy-loop, testing a condition
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3f174d5..f64aa79 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -307,6 +307,7 @@ void __init omapam33xx_map_common_io(void)
void __init omap44xx_map_common_io(void)
{
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
+ omap_barriers_init();
}
#endif
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 40a8fbc..ebc5950 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -24,6 +24,7 @@
#include plat/irqs.h
#include plat/sram.h
+#include plat/omap-secure.h
#include mach/hardware.h
#include mach/omap-wakeupgen.h
@@ -43,6 +44,9 @@ static void __iomem *sar_ram_base;
void __iomem *dram_sync, *sram_sync;
+static phys_addr_t paddr;
+static u32 size;
+
void omap_bus_sync(void)
{
if (dram_sync sram_sync) {
@@ -52,18 +56,20 @@ void omap_bus_sync(void)
}
}
-static int __init omap_barriers_init(void)
+/* Steal one page physical memory for barrier implementation */
+int __init omap_barrier_reserve_memblock(void)
{
- struct map_desc dram_io_desc[1];
- phys_addr_t paddr;
- u32 size;
-
- if (!cpu_is_omap44xx())
- return -ENODEV;
size = ALIGN(PAGE_SIZE, SZ_1M);
paddr = arm_memblock_steal(size, SZ_1M);
+ return 0;
+}
+
+void __init omap_barriers_init(void)
+{
+ struct map_desc dram_io_desc[1];
+
dram_io_desc[0].virtual = OMAP4_DRAM_BARRIER_VA;
dram_io_desc[0].pfn = __phys_to_pfn(paddr);
dram_io_desc[0].length = size;
@@ -75,9 +81,10 @@ static int __init omap_barriers_init(void)
pr_info(OMAP4: Map 0x%08llx to 0x%08lx for dram barrier\n,
(long long) paddr, dram_io_desc[0].virtual);
- return 0;
}
-core_initcall(omap_barriers_init);
+#else
+void __init omap_barriers_init(void)
+{}
#endif
void __init gic_init_irq(void)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..4de7d1e 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -69,6 +69,7 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
omap_secure_ram_reserve_memblock();
+ omap_barrier_reserve_memblock();
}
void __init omap_init_consistent_dma_size(void)
diff --git a/arch/arm/plat-omap/include/plat/omap-secure.h
b/arch/arm/plat-omap/include/plat/omap-secure.h
index 64f9d1c..0f14fb7 100644
--- a/arch/arm/plat-omap/include/plat/omap-secure.h
+++ b/arch/arm/plat-omap/include/plat/omap-secure.h
@@ -10,4 +10,10 @@ static inline void omap_secure_ram_reserve_memblock(void)
{ }
#endif
+#ifdef CONFIG_OMAP4_ERRATA_I688
+extern int omap_barrier_reserve_memblock(void);
+#else
+static inline void omap_barrier_reserve_memblock(void)
+{ }
+#endif
#endif /* __OMAP_SECURE_H__ */
--
1.7.4.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: [RFC 7/7] MFD: TWL6040: Add regulator support for VIO, V2V1 supplies
On Thu, Feb 02, 2012 at 03:59:20PM +0200, Peter Ujfalusi wrote: On 02/02/2012 03:32 PM, Mark Brown wrote: That's not a problem for using the bulk get - the array is part of the API so you can use regulator_bulk_get() and still look at individual supplies within the array later on when enabling and disabling them. For some reason I have associated the use of regulator_bulk_get with the use of regulator_bulk_enable/disable. It did not even crossed my mind that I can still use regulator_enable on the individual regulators. They do normally end up going together since a very large proportion of devices need all their supplies on when active but don't care about sequencing so you end up with a common pattern. It's not required, though. Will convert the regulator_get/put to bulk operations. It will make the code a bit cleaner. Good stuff. signature.asc Description: Digital signature
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
(sorry, I'm slow at replying, attending some internal ARM conference) On 31 January 2012 18:09, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 31 Jan 2012, Catalin Marinas wrote: Maybe we could factor out the CPU-specific settings from proc-v*.S into a separate arch/arm/boot/preload directory. We keep proc-v*.S entirely generic and the implementation-defined bits setting in the preload code. You could have an option to link the preload with the kernel but we could recommend that people run this code from boot-loader before invoking the kernel. This code would be dependent on platform and chosen at build-time. But the actual kernel image would be generic. I'd recommend against that. Again, the reason is not technical but rather has to do with the tendency to laziness of human beings. So please let's not go there or it'll become the de facto standard. ... The whole idea behind having a generic kernel is all about distributions. If a generic kernel has to be distributed with a platform specific pre-kernel blob then we've gained nothing. The problem we have with a generic kernel in this context (e.g. errata bits) is that even though we use a read-check-write sequence for setting various bits during __v*_setup, as long as the boot loader did not set them the kernel will try a write access and fail. So with the current scenario, there is no way for an OMAP platform to run a generic kernel in non-secure mode (with all errata workarounds enabled) without modifying the boot loader. Same goes for the DTB. Those platform specific blobs must be distributed _with_ the hardware and _not_ with the software distribution. Having the dts files in the kernel right now is only a convenience for the transition to device tree. We could do the same and move the bit enabling to separate repository :). An alternative would be to also move those bits setting at a later time in the kernel booting (and re-disabling/enabling the MMU) as we don't have an easy way of figuring out whether the kernel is running in secure or non-secure mode. -- Catalin -- 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 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Thu, Feb 02, 2012 at 02:32:03PM +, Catalin Marinas wrote: We could do the same and move the bit enabling to separate repository :). We must certainly could do but that doesn't get around the errata issues when you have things before the kernel (or before these blobs) enabling things like the caches and MMU. The only answer which assures complete system stability is for the earliest reasonable point in the booting sequence to handle the errata, before any of the potential errata scenarios occur. For things like working around L2 cache problems, that means before the L2 cache is enabled for the first time. If the boot loader enables the L2 cache, then _it_ has to take care of the errata before it enables the L2 cache, and not some blob that it loads. If the boot loader enables the cache, and there are workarounds for buggy cache behaviour, then the boot loader has to implement those errata itself. And so the list goes on. I think the one issue which Santosh is justified about is: if that is the case, why have the errata workarounds in the kernel in the first place. I agree - it makes no sense when we have things like the decompressor enabling the caches. So, I propose that we rip out all those work-arounds that are just 'set this bit in some register' at boot time from the kernel itself right now, and reconsider how these are handled. If that means boot loader people need to update their code to deal with errata, because they want to use CPU features which have errata associated with them, they then get to deal with the errata updates themselves, and also have to carry the pain of dealing with running in non-secure mode. Or, they will have to chose to avoid using those features. But, having errata for things like DMB being faulty in the kernel after things like the boot loader will _already_ have had to issue DMB instructions, or for failing I-cache invalidate after we've already done some I-cache invalidates (eg, boot loader or the decompressor) is quite absurd. So, I think we need to rip out a fair number of these errata from the kernel itself; it's quite clear they're already being done far too late in the system boot sequence. -- 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 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On 2 February 2012 14:49, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Feb 02, 2012 at 02:32:03PM +, Catalin Marinas wrote: We could do the same and move the bit enabling to separate repository :). We must certainly could do but that doesn't get around the errata issues when you have things before the kernel (or before these blobs) enabling things like the caches and MMU. That was my original point - allow such code to be built into a blob that the boot loader can execute. But I got your point that not all boot loaders are able to execute two binary images. The only answer which assures complete system stability is for the earliest reasonable point in the booting sequence to handle the errata, before any of the potential errata scenarios occur. For things like working around L2 cache problems, that means before the L2 cache is enabled for the first time. If the boot loader enables the L2 cache, then _it_ has to take care of the errata before it enables the L2 cache, and not some blob that it loads. If the boot loader enables the cache, and there are workarounds for buggy cache behaviour, then the boot loader has to implement those errata itself. But as it was pointed out already, many of those are very rare conditions that you can't actually trigger during the boot sequence. There are other errata that require SMP for example and the boot loader (or decompressor) doesn't care. So, I propose that we rip out all those work-arounds that are just 'set this bit in some register' at boot time from the kernel itself right now, and reconsider how these are handled. Just don't remove them until we agree where we should *move* them. They are still good documentation so far. I would say just disable the workarounds in the kernel .config until we decide. But, having errata for things like DMB being faulty in the kernel after things like the boot loader will _already_ have had to issue DMB instructions, or for failing I-cache invalidate after we've already done some I-cache invalidates (eg, boot loader or the decompressor) is quite absurd. As I said, most errata are really hard to trigger (but ARM cannot guarantee that it is impossible, so they need to be published). -- Catalin -- 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] arm/dts: omap3-evm: Add i2c and twl4030 support
On Wed, Feb 01, 2012 at 11:56:08, Hiremath, Vaibhav wrote:
Add support for TWL4030, which is interfaced on i2c1 bus.
Also add clock frequencies for other i2c instances(2 3)
required for client-device exist on OMAP3EVM board.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tony Lindgren t...@atomide.com
---
Changes from V1:
- As per comment from Benoit, changed hex representation
from uppercase to lowercase.
arch/arm/boot/dts/omap3-evm.dts | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..f349ee9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,31 @@
reg = 0x8000 0x1000; /* 256 MB */
};
};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 40;
+
+ /*
+ * TVP5146 Video decoder-in for analog input support.
+ */
+ tvp5146@5c {
+ compatible = ti,tvp5146m2;
+ reg = 0x5c;
+ };
+};
Grant,
Can you ack this patch and below patch as well, so that
Benoit can queue it in his tree?
arm/dts: Add support for TI AM3517/05 EVM board
Thanks,
Vaibhav
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()
Paul, On Thu, Feb 2, 2012 at 3:47 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, Feb 2, 2012 at 3:35 PM, Paul Walmsley p...@pwsan.com wrote: On Thu, 2 Feb 2012, Shilimkar, Santosh wrote: Yes, we do have issue with below APIs for OMAP4 and onwards design because of the PRCM change. pwrdm_clear_all_prev_pwrst pwrdm_*_mem_* There use to be a single power state and memory state register till OMAP3 at power domain level which can give you the logic and memory last test which is needed for OSWR. On OMAP4, we have registers per modules and it becomes difficult to model this difference in APIs. Initially we tried to fix that with [1] and then later realized that's not going to work on OMAP4 + devices because of mentioned issue. If the registers are per-module, it seems like the best place for those would be the hwmod layer. Do you think that makes sense? So, something like omap_hwmod_clear_all_prev_pwrst(), etc.? Seems like that should be pretty efficient. But all these are power domain registers after all. Rajendra did one version of pwrdm_clear_all_prev_pwrst API and inside used hwmod. But then there he has iterate over all the modules belongs to that power domain. And if you use hwmod or omap_device kind of API, then you need to build those devices in init or some where. All of that was not looking so elegant and hence the other path was chosen. The mess is, the registers are still part of power domains though they are specific to module. And Fundamentally power domain is stil the central entity decides the fate of all the modules within that PD, in terms of context loss/ret etc. I looked at the MPUSS file. There are 3 functions which access power domain registers directly. - mpuss_clear_prev_logic_pwrst - cpu_clear_prev_logic_pwrst - omap4_mpuss_read_prev_context_state All of these functions access the context registers which we don't have support today at power domian APIs for mentioned issue. This file is using power domain APIs in all possible scenario's except the OSWR scenario which needs the context register accesses. if the context clear and read can be handled part of PD APIs, then we can certainly kill this functions. Regards santosh -- 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: In many cases softlockup can not be reported after disabling IRQ for long time
On Thu, Feb 02, 2012 at 04:17:02PM +0800, TAO HU wrote: Hi, Don My concern is not actually that the softlockup could not be reported while the IRQ is disabled. What bothering me is that even AFTER re-enable the IRQ, it will not give warning in many cases. In theory, disabling IRQ for long time (10s in my case) also implies the high priority thread (watchdog) is blocked as well. So the ideal case is that softlockup driver could give warning right after the IRQ is re-enabled. It does so occasionally but fails to be consistent. The only thing I can think of is that the clock/jiffies isn't updated until after the hrtimer is run. I'm not sure if there is any guarantee for ordering once interrupts are enabled. But that is just a guess. I guess in theory, I would expect that when interrupts are enabled, the system would immediately jump into an IRQ context, update the clock/jiffies, then run all the other irq handlers like hrtimers, which would see the new time and do the right thing. After everything is done, the system would return to your test code and re-enable preemption allowing the softlockup thread to run again. I could be very wrong though. :-) Cheers, Don -- 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: In many cases softlockup can not be reported after disabling IRQ for long time
On Thu, Feb 02, 2012 at 10:58:41AM -0500, Don Zickus wrote: The only thing I can think of is that the clock/jiffies isn't updated until after the hrtimer is run. I'm not sure if there is any guarantee for ordering once interrupts are enabled. But that is just a guess. I guess in theory, I would expect that when interrupts are enabled, the system would immediately jump into an IRQ context, update the clock/jiffies, then run all the other irq handlers like hrtimers, which would see the new time and do the right thing. After everything is done, the system would return to your test code and re-enable preemption allowing the softlockup thread to run again. I could be very wrong though. :-) The first thing to confirm is whether disabling interrupts for 10s results in the system losing proper track of time. If it does, then you've immediately found the problem. So, what you need to do us to use /usr/bin/time to execute a userspace command which causes your thread to simulate a soft-lockup. If you arrange for your soft-lockup to last for (eg) exactly 10 seconds, and /usr/bin/time reports less than 10 seconds have passed, you've found why the system can't report it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 02/25] gpio/omap: use flag to identify wakeup domain
From: Charulatha V ch...@ti.com
In omap3, save/restore context is implemented for GPIO banks 2-6 as GPIO bank1
is in wakeup domain. Instead of identifying bank's power domain by bank id,
use 'loses_context' flag which is filled by pwrdm_can_ever_lose_context()
during dev_init.
For getting the powerdomain pointer, omap_hwmod_get_pwrdm() is used.
omap_device_get_pwrdm() could not be used as the pwrdm information needs to be
filled in pdata, whereas omap_device_get_pwrdm() could be used only after
omap_device_build() call.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/gpio.c |6 ++
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio-omap.c | 13 ++---
3 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 07ac648..076be34 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -24,6 +24,8 @@
#include plat/omap_hwmod.h
#include plat/omap_device.h
+#include powerdomain.h
+
static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
{
struct platform_device *pdev;
@@ -31,6 +33,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
struct omap_gpio_dev_attr *dev_attr;
char *name = omap_gpio;
int id;
+ struct powerdomain *pwrdm;
/*
* extract the device id from name field available in the
@@ -99,6 +102,9 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
return -EINVAL;
}
+ pwrdm = omap_hwmod_get_pwrdm(oh);
+ pdata-loses_context = pwrdm_can_ever_lose_context(pwrdm);
+
pdev = omap_device_build(name, id - 1, oh, pdata,
sizeof(*pdata), NULL, 0, false);
kfree(pdata);
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index acf1c77..6eb035c 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -198,6 +198,7 @@ struct omap_gpio_platform_data {
int bank_width; /* GPIO bank width */
int bank_stride;/* Only needed for omap1 MPUIO */
bool dbck_flag; /* dbck required or not - True for OMAP34 */
+ bool loses_context; /* whether the bank would ever lose context */
struct omap_gpio_reg_offs *regs;
};
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 6ea7390..07efa15 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -56,6 +56,7 @@ struct gpio_bank {
u32 dbck_enable_mask;
struct device *dev;
bool dbck_flag;
+ bool loses_context;
int stride;
u32 width;
u16 id;
@@ -1181,7 +1182,7 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
bank-dbck_flag = pdata-dbck_flag;
bank-stride = pdata-bank_stride;
bank-width = pdata-bank_width;
-
+ bank-loses_context = pdata-loses_context;
bank-regs = pdata-regs;
if (bank-regs-set_dataout bank-regs-clr_dataout)
@@ -1337,8 +1338,7 @@ void omap2_gpio_prepare_for_idle(int off_mode)
u32 l1 = 0, l2 = 0;
int j;
- /* TODO: Do not use cpu_is_omap34xx */
- if ((cpu_is_omap34xx()) (bank-id == 0))
+ if (!bank-loses_context)
continue;
for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
@@ -1405,8 +1405,7 @@ void omap2_gpio_resume_after_idle(void)
u32 l = 0, gen, gen0, gen1;
int j;
- /* TODO: Do not use cpu_is_omap34xx */
- if ((cpu_is_omap34xx()) (bank-id == 0))
+ if (!bank-loses_context)
continue;
for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
@@ -1505,7 +1504,7 @@ void omap_gpio_save_context(void)
list_for_each_entry(bank, omap_gpio_list, node) {
i++;
- if (bank-id == 0)
+ if (!bank-loses_context)
continue;
gpio_context[i].irqenable1 =
@@ -1539,7 +1538,7 @@ void omap_gpio_restore_context(void)
list_for_each_entry(bank, omap_gpio_list, node) {
i++;
- if (bank-id == 0)
+ if (!bank-loses_context)
continue;
__raw_writel(gpio_context[i].irqenable1,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 10/25] gpio/omap: cleanup set_gpio_triggering function
Getting rid of ifdefs within the function by adding register offset intctrl
and associating OMAP_GPIO_INT_CONTROL in respective SoC specific files.
Also, use wkup_status register consistently instead of referring to wakeup
clear and wakeup set register offsets. Get rid of cpu_is_ checks in
set_gpio_trigger() using irqctrl.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/gpio15xx.c |2 +
arch/arm/mach-omap1/gpio16xx.c |3 +
arch/arm/mach-omap1/gpio7xx.c |2 +
arch/arm/plat-omap/include/plat/gpio.h |3 +
drivers/gpio/gpio-omap.c | 157 +---
5 files changed, 53 insertions(+), 114 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
index f8c15ea..2adfece 100644
--- a/arch/arm/mach-omap1/gpio15xx.c
+++ b/arch/arm/mach-omap1/gpio15xx.c
@@ -42,6 +42,7 @@ static struct omap_gpio_reg_offs omap15xx_mpuio_regs = {
.irqstatus = OMAP_MPUIO_GPIO_INT,
.irqenable = OMAP_MPUIO_GPIO_MASKIT,
.irqenable_inv = true,
+ .irqctrl= OMAP_MPUIO_GPIO_INT_EDGE,
};
static struct __initdata omap_gpio_platform_data omap15xx_mpu_gpio_config = {
@@ -83,6 +84,7 @@ static struct omap_gpio_reg_offs omap15xx_gpio_regs = {
.irqstatus = OMAP1510_GPIO_INT_STATUS,
.irqenable = OMAP1510_GPIO_INT_MASK,
.irqenable_inv = true,
+ .irqctrl= OMAP1510_GPIO_INT_CONTROL,
};
static struct __initdata omap_gpio_platform_data omap15xx_gpio_config = {
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 1eb47e2..46bb57a 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -45,6 +45,7 @@ static struct omap_gpio_reg_offs omap16xx_mpuio_regs = {
.irqstatus = OMAP_MPUIO_GPIO_INT,
.irqenable = OMAP_MPUIO_GPIO_MASKIT,
.irqenable_inv = true,
+ .irqctrl= OMAP_MPUIO_GPIO_INT_EDGE,
};
static struct __initdata omap_gpio_platform_data omap16xx_mpu_gpio_config = {
@@ -90,6 +91,8 @@ static struct omap_gpio_reg_offs omap16xx_gpio_regs = {
.set_irqenable = OMAP1610_GPIO_SET_IRQENABLE1,
.clr_irqenable = OMAP1610_GPIO_CLEAR_IRQENABLE1,
.wkup_en= OMAP1610_GPIO_WAKEUPENABLE,
+ .edgectrl1 = OMAP1610_GPIO_EDGE_CTRL1,
+ .edgectrl2 = OMAP1610_GPIO_EDGE_CTRL2,
};
static struct __initdata omap_gpio_platform_data omap16xx_gpio1_config = {
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
index 923eaa1..207a23c 100644
--- a/arch/arm/mach-omap1/gpio7xx.c
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -47,6 +47,7 @@ static struct omap_gpio_reg_offs omap7xx_mpuio_regs = {
.irqstatus = OMAP_MPUIO_GPIO_INT / 2,
.irqenable = OMAP_MPUIO_GPIO_MASKIT / 2,
.irqenable_inv = true,
+ .irqctrl= OMAP_MPUIO_GPIO_INT_EDGE 1,
};
static struct __initdata omap_gpio_platform_data omap7xx_mpu_gpio_config = {
@@ -88,6 +89,7 @@ static struct omap_gpio_reg_offs omap7xx_gpio_regs = {
.irqstatus = OMAP7XX_GPIO_INT_STATUS,
.irqenable = OMAP7XX_GPIO_INT_MASK,
.irqenable_inv = true,
+ .irqctrl= OMAP7XX_GPIO_INT_CONTROL,
};
static struct __initdata omap_gpio_platform_data omap7xx_gpio1_config = {
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index 914c976..9e403e5 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -195,6 +195,9 @@ struct omap_gpio_reg_offs {
u16 leveldetect1;
u16 risingdetect;
u16 fallingdetect;
+ u16 irqctrl;
+ u16 edgectrl1;
+ u16 edgectrl2;
bool irqenable_inv;
};
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index ceb9edf..f39d9e4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -199,52 +199,32 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
__raw_writel(val, reg);
}
-#ifdef CONFIG_ARCH_OMAP2PLUS
-static inline void set_24xx_gpio_triggering(struct gpio_bank *bank, int gpio,
+static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
int trigger)
{
void __iomem *base = bank-base;
u32 gpio_bit = 1 gpio;
- if (cpu_is_omap44xx()) {
- _gpio_rmw(base, OMAP4_GPIO_LEVELDETECT0, gpio_bit,
- trigger IRQ_TYPE_LEVEL_LOW);
- _gpio_rmw(base, OMAP4_GPIO_LEVELDETECT1, gpio_bit,
- trigger IRQ_TYPE_LEVEL_HIGH);
- _gpio_rmw(base, OMAP4_GPIO_RISINGDETECT, gpio_bit,
- trigger IRQ_TYPE_EDGE_RISING);
-
[PATCH v9 15/25] gpio/omap: fix bankwidth for OMAP7xx MPUIO
From: Charulatha V ch...@ti.com
In all OMAP1 SoCs, the MPUIO bank width is 16 bits. But, in OMAP7xx,
it is wrongly initialised to 32. Fix this.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/gpio7xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
index 433491c..4771d6b 100644
--- a/arch/arm/mach-omap1/gpio7xx.c
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -52,8 +52,8 @@ static struct omap_gpio_reg_offs omap7xx_mpuio_regs = {
static struct __initdata omap_gpio_platform_data omap7xx_mpu_gpio_config = {
.virtual_irq_start = IH_MPUIO_BASE,
- .bank_width = 32,
.is_mpuio = true,
+ .bank_width = 16,
.bank_stride= 2,
.regs = omap7xx_mpuio_regs,
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 20/25] gpio/omap: fix incorrect access of debounce module
Enable debounce clock before writing/reading debounce registers.
Disable the clock at the end so that it is synchronized with the
pm_runtime_get/put_sync calls.
Enable debounce clock per module. This call is mandatory because
in omap_gpio_request() when *_runtime_get_sync() is called,
_gpio_dbck_enable() within runtime callbck fails to turn on dbck
because dbck_enable_mask used within _gpio_dbck_enable() is still
not initialized at that point. Therefore we have to enable dbck here.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0ea3dc9..7515382 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -203,22 +203,30 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
l = GPIO_BIT(bank, gpio);
+ clk_enable(bank-dbck);
reg = bank-base + bank-regs-debounce;
__raw_writel(debounce, reg);
reg = bank-base + bank-regs-debounce_en;
val = __raw_readl(reg);
- if (debounce) {
+ if (debounce)
val |= l;
- clk_enable(bank-dbck);
- } else {
+ else
val = ~l;
- clk_disable(bank-dbck);
- }
bank-dbck_enable_mask = val;
__raw_writel(val, reg);
+ clk_disable(bank-dbck);
+ /*
+* Enable debounce clock per module.
+* This call is mandatory because in omap_gpio_request() when
+* *_runtime_get_sync() is called, _gpio_dbck_enable() within
+* runtime callbck fails to turn on dbck because dbck_enable_mask
+* used within _gpio_dbck_enable() is still not initialized at
+* that point. Therefore we have to enable dbck here.
+*/
+ _gpio_dbck_enable(bank);
}
static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 21/25] gpio/omap: remove omap_gpio_save_context overhead
Context is now saved dynamically in respective functions whenever and
whichever registers are modified. This avoid overhead of saving all
registers context in the runtime suspend callback.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 56 +++---
1 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 7515382..4056d78 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -101,6 +101,7 @@ static void _set_gpio_direction(struct gpio_bank *bank, int
gpio, int is_input)
else
l = ~(1 gpio);
__raw_writel(l, reg);
+ bank-context.oe = l;
}
@@ -131,6 +132,7 @@ static void _set_gpio_dataout_mask(struct gpio_bank *bank,
int gpio, int enable)
else
l = ~gpio_bit;
__raw_writel(l, reg);
+ bank-context.dataout = l;
}
static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
@@ -244,8 +246,20 @@ static inline void set_gpio_trigger(struct gpio_bank
*bank, int gpio,
_gpio_rmw(base, bank-regs-fallingdetect, gpio_bit,
trigger IRQ_TYPE_EDGE_FALLING);
- if (likely(!(bank-non_wakeup_gpios gpio_bit)))
+ bank-context.leveldetect0 =
+ __raw_readl(bank-base + bank-regs-leveldetect0);
+ bank-context.leveldetect1 =
+ __raw_readl(bank-base + bank-regs-leveldetect1);
+ bank-context.risingdetect =
+ __raw_readl(bank-base + bank-regs-risingdetect);
+ bank-context.fallingdetect =
+ __raw_readl(bank-base + bank-regs-fallingdetect);
+
+ if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
+ bank-context.wake_en =
+ __raw_readl(bank-base + bank-regs-wkup_en);
+ }
/* This part needs to be executed always for OMAP{34xx, 44xx} */
if (!bank-regs-irqctrl) {
@@ -338,6 +352,8 @@ static int _set_gpio_triggering(struct gpio_bank *bank, int
gpio, int trigger)
/* Enable wake-up during idle for dynamic tick */
_gpio_rmw(base, bank-regs-wkup_en, 1 gpio, trigger);
+ bank-context.wake_en =
+ __raw_readl(bank-base + bank-regs-wkup_en);
__raw_writel(l, reg);
}
return 0;
@@ -430,6 +446,7 @@ static void _enable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
}
__raw_writel(l, reg);
+ bank-context.irqenable1 = l;
}
static void _disable_gpio_irqbank(struct gpio_bank *bank, int gpio_mask)
@@ -450,6 +467,7 @@ static void _disable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
}
__raw_writel(l, reg);
+ bank-context.irqenable1 = l;
}
static inline void _set_gpio_irqenable(struct gpio_bank *bank, int gpio, int
enable)
@@ -541,6 +559,7 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
/* Module is enabled, clocks are not gated */
ctrl = ~GPIO_MOD_CTRL_BIT;
__raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
}
bank-mod_usage |= 1 offset;
@@ -558,9 +577,12 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(bank-lock, flags);
- if (bank-regs-wkup_en)
+ if (bank-regs-wkup_en) {
/* Disable wake-up during idle for dynamic tick */
_gpio_rmw(base, bank-regs-wkup_en, 1 offset, 0);
+ bank-context.wake_en =
+ __raw_readl(bank-base + bank-regs-wkup_en);
+ }
bank-mod_usage = ~(1 offset);
@@ -572,6 +594,7 @@ static void omap_gpio_free(struct gpio_chip *chip, unsigned
offset)
/* Module is disabled, clocks are gated */
ctrl |= GPIO_MOD_CTRL_BIT;
__raw_writel(ctrl, reg);
+ bank-context.ctrl = ctrl;
}
_reset_gpio(bank, bank-chip.base + offset);
@@ -1157,7 +1180,6 @@ static int omap_gpio_resume(struct device *dev)
}
-static void omap_gpio_save_context(struct gpio_bank *bank);
static void omap_gpio_restore_context(struct gpio_bank *bank);
static int omap_gpio_runtime_suspend(struct device *dev)
@@ -1170,7 +1192,7 @@ static int omap_gpio_runtime_suspend(struct device *dev)
spin_lock_irqsave(bank-lock, flags);
if (bank-power_mode != OFF_MODE) {
bank-power_mode = 0;
- goto save_gpio_context;
+ goto update_gpio_context_count;
}
/*
* If going to OFF, remove triggering for all
@@ -1178,7 +1200,7 @@ static int omap_gpio_runtime_suspend(struct device *dev)
* generated. See OMAP2420 Errata item 1.101.
[PATCH v9 14/25] gpio/omap: remove bank-method METHOD_* macros
From: Charulatha V ch...@ti.com
The only bank-type (method) used in the OMAP GPIO driver is MPUIO type as they
need to be handled separately. Identify the same using a flag and remove all
METHOD_* macros.
mpuio_init() function is defined under #ifdefs. It is required only in case
of MPUIO bank type and only when PM operations are supported by it.
This is applicable only in case of OMAP16xx SoC's MPUIO GPIO bank type.
For all the other cases it is a dummy function. Hence clean up the same
and remove all the OMAP SoC specific #ifdefs.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/gpio15xx.c |3 +-
arch/arm/mach-omap1/gpio16xx.c |6 +
arch/arm/mach-omap1/gpio7xx.c |8 +--
arch/arm/mach-omap2/gpio.c |2 -
arch/arm/plat-omap/include/plat/gpio.h |8 +--
drivers/gpio/gpio-omap.c | 38 +--
6 files changed, 10 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
index 950e467..634903e 100644
--- a/arch/arm/mach-omap1/gpio15xx.c
+++ b/arch/arm/mach-omap1/gpio15xx.c
@@ -47,7 +47,7 @@ static struct omap_gpio_reg_offs omap15xx_mpuio_regs = {
static struct __initdata omap_gpio_platform_data omap15xx_mpu_gpio_config = {
.virtual_irq_start = IH_MPUIO_BASE,
- .bank_type = METHOD_MPUIO,
+ .is_mpuio = true,
.bank_width = 16,
.bank_stride= 1,
.regs = omap15xx_mpuio_regs,
@@ -90,7 +90,6 @@ static struct omap_gpio_reg_offs omap15xx_gpio_regs = {
static struct __initdata omap_gpio_platform_data omap15xx_gpio_config = {
.virtual_irq_start = IH_GPIO_BASE,
- .bank_type = METHOD_GPIO_1510,
.bank_width = 16,
.regs = omap15xx_gpio_regs,
};
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 86ac415..1c5f90e 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -53,7 +53,7 @@ static struct omap_gpio_reg_offs omap16xx_mpuio_regs = {
static struct __initdata omap_gpio_platform_data omap16xx_mpu_gpio_config = {
.virtual_irq_start = IH_MPUIO_BASE,
- .bank_type = METHOD_MPUIO,
+ .is_mpuio = true,
.bank_width = 16,
.bank_stride= 1,
.regs = omap16xx_mpuio_regs,
@@ -100,7 +100,6 @@ static struct omap_gpio_reg_offs omap16xx_gpio_regs = {
static struct __initdata omap_gpio_platform_data omap16xx_gpio1_config = {
.virtual_irq_start = IH_GPIO_BASE,
- .bank_type = METHOD_GPIO_1610,
.bank_width = 16,
.regs = omap16xx_gpio_regs,
};
@@ -130,7 +129,6 @@ static struct __initdata resource
omap16xx_gpio2_resources[] = {
static struct __initdata omap_gpio_platform_data omap16xx_gpio2_config = {
.virtual_irq_start = IH_GPIO_BASE + 16,
- .bank_type = METHOD_GPIO_1610,
.bank_width = 16,
.regs = omap16xx_gpio_regs,
};
@@ -160,7 +158,6 @@ static struct __initdata resource
omap16xx_gpio3_resources[] = {
static struct __initdata omap_gpio_platform_data omap16xx_gpio3_config = {
.virtual_irq_start = IH_GPIO_BASE + 32,
- .bank_type = METHOD_GPIO_1610,
.bank_width = 16,
.regs = omap16xx_gpio_regs,
};
@@ -190,7 +187,6 @@ static struct __initdata resource
omap16xx_gpio4_resources[] = {
static struct __initdata omap_gpio_platform_data omap16xx_gpio4_config = {
.virtual_irq_start = IH_GPIO_BASE + 48,
- .bank_type = METHOD_GPIO_1610,
.bank_width = 16,
.regs = omap16xx_gpio_regs,
};
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
index 207a23c..433491c 100644
--- a/arch/arm/mach-omap1/gpio7xx.c
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -52,8 +52,8 @@ static struct omap_gpio_reg_offs omap7xx_mpuio_regs = {
static struct __initdata omap_gpio_platform_data omap7xx_mpu_gpio_config = {
.virtual_irq_start = IH_MPUIO_BASE,
- .bank_type = METHOD_MPUIO,
.bank_width = 32,
+ .is_mpuio = true,
.bank_stride= 2,
.regs = omap7xx_mpuio_regs,
};
@@ -94,7 +94,6 @@ static struct omap_gpio_reg_offs omap7xx_gpio_regs = {
static struct __initdata omap_gpio_platform_data omap7xx_gpio1_config = {
.virtual_irq_start = IH_GPIO_BASE,
- .bank_type = METHOD_GPIO_7XX,
[PATCH v9 07/25] gpio/omap: further cleanup using wkup_en register
Wakeup enable register offset initialized according to OMAP versions
during device registration. Use this to avoid version checks.
Starting with OMAP4, legacy registers should not be used in combination
with the updated regsiters. Use wkup_en register consistently for
all SoCs wherever applicable.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/gpio16xx.c |1 +
arch/arm/mach-omap2/gpio.c |2 +
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio-omap.c | 110 ++--
4 files changed, 25 insertions(+), 89 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index df4bb44..1eb47e2 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -89,6 +89,7 @@ static struct omap_gpio_reg_offs omap16xx_gpio_regs = {
.irqenable = OMAP1610_GPIO_IRQENABLE1,
.set_irqenable = OMAP1610_GPIO_SET_IRQENABLE1,
.clr_irqenable = OMAP1610_GPIO_CLEAR_IRQENABLE1,
+ .wkup_en= OMAP1610_GPIO_WAKEUPENABLE,
};
static struct __initdata omap_gpio_platform_data omap16xx_gpio1_config = {
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index bc9271a..4877b52 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -89,6 +89,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
pdata-regs-debounce = OMAP24XX_GPIO_DEBOUNCE_VAL;
pdata-regs-debounce_en = OMAP24XX_GPIO_DEBOUNCE_EN;
pdata-regs-ctrl = OMAP24XX_GPIO_CTRL;
+ pdata-regs-wkup_en = OMAP24XX_GPIO_WAKE_EN;
break;
case 2:
pdata-bank_type = METHOD_GPIO_44XX;
@@ -106,6 +107,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
pdata-regs-debounce = OMAP4_GPIO_DEBOUNCINGTIME;
pdata-regs-debounce_en = OMAP4_GPIO_DEBOUNCENABLE;
pdata-regs-ctrl = OMAP4_GPIO_CTRL;
+ pdata-regs-wkup_en = OMAP4_GPIO_IRQWAKEN0;
break;
default:
WARN(1, Invalid gpio bank_type\n);
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index db94bd1..2b54bca 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -189,6 +189,7 @@ struct omap_gpio_reg_offs {
u16 debounce;
u16 debounce_en;
u16 ctrl;
+ u16 wkup_en;
bool irqenable_inv;
};
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 5cc2c04..3daedff 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -51,9 +51,7 @@ struct gpio_bank {
u16 virtual_irq_start;
int method;
u32 suspend_wakeup;
-#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP2PLUS)
u32 saved_wakeup;
-#endif
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
@@ -598,30 +596,15 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
static void omap_gpio_free(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
+ void __iomem *base = bank-base;
unsigned long flags;
spin_lock_irqsave(bank-lock, flags);
-#ifdef CONFIG_ARCH_OMAP16XX
- if (bank-method == METHOD_GPIO_1610) {
- /* Disable wake-up during idle for dynamic tick */
- void __iomem *reg = bank-base + OMAP1610_GPIO_CLEAR_WAKEUPENA;
- __raw_writel(1 offset, reg);
- }
-#endif
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
- if (bank-method == METHOD_GPIO_24XX) {
- /* Disable wake-up during idle for dynamic tick */
- void __iomem *reg = bank-base + OMAP24XX_GPIO_CLEARWKUENA;
- __raw_writel(1 offset, reg);
- }
-#endif
-#ifdef CONFIG_ARCH_OMAP4
- if (bank-method == METHOD_GPIO_44XX) {
+
+ if (bank-regs-wkup_en)
/* Disable wake-up during idle for dynamic tick */
- void __iomem *reg = bank-base + OMAP4_GPIO_IRQWAKEN0;
- __raw_writel(1 offset, reg);
- }
-#endif
+ _gpio_rmw(base, bank-regs-wkup_en, 1 offset, 0);
+
bank-mod_usage = ~(1 offset);
if (bank-regs-ctrl !bank-mod_usage) {
@@ -1071,8 +1054,8 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int
irq_start,
ct-chip.irq_mask = irq_gc_mask_set_bit;
ct-chip.irq_unmask = irq_gc_mask_clr_bit;
ct-chip.irq_set_type = gpio_irq_type;
- /* REVISIT: assuming only 16xx supports MPUIO wake events */
- if (cpu_is_omap16xx())
+
+ if (bank-regs-wkup_en)
[PATCH v9 19/25] gpio/omap: fix debounce clock handling
The dbck_enable_mask indicates which all GPIOs within a bank have debounce
enabled and dbck is enabled/disabled based upon this. But there is no
mechanism to track the dbck state. In order to manage the dbck state we need
additional flag and logic so that turning off/on dbck is synchronized with
pm_runtime_put/get_sync calls.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 29 +++--
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8b619fd..0ea3dc9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -67,6 +67,7 @@ struct gpio_bank {
struct clk *dbck;
u32 mod_usage;
u32 dbck_enable_mask;
+ bool dbck_enabled;
struct device *dev;
bool is_mpuio;
bool dbck_flag;
@@ -158,6 +159,22 @@ static inline void _gpio_rmw(void __iomem *base, u32 reg,
u32 mask, bool set)
__raw_writel(l, base + reg);
}
+static inline void _gpio_dbck_enable(struct gpio_bank *bank)
+{
+ if (bank-dbck_enable_mask !bank-dbck_enabled) {
+ clk_enable(bank-dbck);
+ bank-dbck_enabled = true;
+ }
+}
+
+static inline void _gpio_dbck_disable(struct gpio_bank *bank)
+{
+ if (bank-dbck_enable_mask bank-dbck_enabled) {
+ clk_disable(bank-dbck);
+ bank-dbck_enabled = false;
+ }
+}
+
/**
* _set_gpio_debounce - low level gpio debounce time
* @bank: the gpio bank we're acting upon
@@ -1176,6 +1193,7 @@ save_gpio_context:
bank-get_context_loss_count(bank-dev);
omap_gpio_save_context(bank);
+ _gpio_dbck_disable(bank);
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -1190,6 +1208,7 @@ static int omap_gpio_runtime_resume(struct device *dev)
unsigned long flags;
spin_lock_irqsave(bank-lock, flags);
+ _gpio_dbck_enable(bank);
if (!bank-enabled_non_wakeup_gpios || !bank-workaround_enabled) {
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -1271,16 +1290,11 @@ void omap2_gpio_prepare_for_idle(int pwr_mode)
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
- int j;
-
if (!bank-mod_usage || !bank-loses_context)
continue;
bank-power_mode = pwr_mode;
- for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
- clk_disable(bank-dbck);
-
pm_runtime_put_sync_suspend(bank-dev);
}
}
@@ -1290,14 +1304,9 @@ void omap2_gpio_resume_after_idle(void)
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
- int j;
-
if (!bank-mod_usage || !bank-loses_context)
continue;
- for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
- clk_enable(bank-dbck);
-
pm_runtime_get_sync(bank-dev);
}
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 13/25] gpio/omap: remove unnecessary bit-masking for read access
Remove un-necessary bit masking. Since the register are 4 byte aligned and readl would work as is. The 'enabled' mask is already taking care to mask for bank width. Signed-off-by: Charulatha V ch...@ti.com Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com --- drivers/gpio/gpio-omap.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 485b6b2..38beccc 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -576,9 +576,6 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) enabled = _get_gpio_irqbank_mask(bank); isr_saved = isr = __raw_readl(isr_reg) enabled; - if (cpu_is_omap15xx() (bank-method == METHOD_MPUIO)) - isr = 0x; - if (bank-level_mask) level_mask = bank-level_mask enabled; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 16/25] gpio/omap: use pm-runtime framework
Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put()
for enabling/disabling clocks appropriately. Remove syscore_ops and
instead use SET_RUNTIME_PM_OPS macro.
There is no more need to call omap_device_disable_idle_on_suspend
since driver is PM runtime adapted now.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/gpio.c |2 -
drivers/gpio/gpio-omap.c | 65 ---
2 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index dfda6b3..1e0b750 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -136,8 +136,6 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
return PTR_ERR(pdev);
}
- omap_device_disable_idle_on_suspend(pdev);
-
return 0;
}
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 951d784..b92a23f 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -21,6 +21,7 @@
#include linux/io.h
#include linux/slab.h
#include linux/pm_runtime.h
+#include linux/pm.h
#include mach/hardware.h
#include asm/irq.h
@@ -483,8 +484,14 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
unsigned long flags;
- spin_lock_irqsave(bank-lock, flags);
+ /*
+* If this is the first gpio_request for the bank,
+* enable the bank module.
+*/
+ if (!bank-mod_usage)
+ pm_runtime_get_sync(bank-dev);
+ spin_lock_irqsave(bank-lock, flags);
/* Set trigger to none. You need to enable the desired trigger with
* request_irq() or set_irq_type().
*/
@@ -540,6 +547,13 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
_reset_gpio(bank, bank-chip.base + offset);
spin_unlock_irqrestore(bank-lock, flags);
+
+ /*
+* If this is the last gpio to be freed in the bank,
+* disable the bank module.
+*/
+ if (!bank-mod_usage)
+ pm_runtime_put(bank-dev);
}
/*
@@ -565,6 +579,7 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
bank = irq_get_handler_data(irq);
isr_reg = bank-base + bank-regs-irqstatus;
+ pm_runtime_get_sync(bank-dev);
if (WARN_ON(!isr_reg))
goto exit;
@@ -625,6 +640,7 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
exit:
if (!unmasked)
chained_irq_exit(chip, desc);
+ pm_runtime_put(bank-dev);
}
static void gpio_irq_shutdown(struct irq_data *d)
@@ -1037,6 +1053,7 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
}
pm_runtime_enable(bank-dev);
+ pm_runtime_irq_safe(bank-dev);
pm_runtime_get_sync(bank-dev);
if (bank-is_mpuio)
@@ -1046,6 +1063,8 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
omap_gpio_chip_init(bank);
omap_gpio_show_rev(bank);
+ pm_runtime_put(bank-dev);
+
list_add_tail(bank-node, omap_gpio_list);
return ret;
@@ -1056,7 +1075,9 @@ err_exit:
return ret;
}
-static int omap_gpio_suspend(void)
+#ifdef CONFIG_ARCH_OMAP2PLUS
+
+static int omap_gpio_suspend(struct device *dev)
{
struct gpio_bank *bank;
@@ -1080,7 +1101,7 @@ static int omap_gpio_suspend(void)
return 0;
}
-static void omap_gpio_resume(void)
+static int omap_gpio_resume(struct device *dev)
{
struct gpio_bank *bank;
@@ -1089,21 +1110,17 @@ static void omap_gpio_resume(void)
unsigned long flags;
if (!bank-regs-wkup_en)
- return;
+ return 0;
spin_lock_irqsave(bank-lock, flags);
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
_gpio_rmw(base, bank-regs-wkup_en, bank-saved_wakeup, 1);
spin_unlock_irqrestore(bank-lock, flags);
}
+
+ return 0;
}
-static struct syscore_ops omap_gpio_syscore_ops = {
- .suspend= omap_gpio_suspend,
- .resume = omap_gpio_resume,
-};
-
-#ifdef CONFIG_ARCH_OMAP2PLUS
static void omap_gpio_save_context(struct gpio_bank *bank);
static void omap_gpio_restore_context(struct gpio_bank *bank);
@@ -1145,11 +1162,15 @@ void omap2_gpio_prepare_for_idle(int off_mode)
__raw_writel(l2, bank-base + bank-regs-risingdetect);
save_gpio_context:
+
if (bank-get_context_loss_count)
bank-context_loss_count =
bank-get_context_loss_count(bank-dev);
omap_gpio_save_context(bank);
+
+ if
[PATCH v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
With register offsets now defined for respective OMAP versions we can get rid
of cpu_class_* checks. This function now has common initialization code for
all OMAP versions. Initialization specific to OMAP16xx has been moved within
omap16xx_gpio_init().
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/gpio16xx.c | 35 +-
drivers/gpio/gpio-omap.c | 77
2 files changed, 57 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 46bb57a..86ac415 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -24,6 +24,9 @@
#define OMAP1610_GPIO4_BASE0xfffbbc00
#define OMAP1_MPUIO_VBASE OMAP1_MPUIO_BASE
+/* smart idle, enable wakeup */
+#define SYSCONFIG_WORD 0x14
+
/* mpu gpio */
static struct __initdata resource omap16xx_mpu_gpio_resources[] = {
{
@@ -218,12 +221,42 @@ static struct __initdata platform_device *
omap16xx_gpio_dev[] = {
static int __init omap16xx_gpio_init(void)
{
int i;
+ void __iomem *base;
+ struct resource *res;
+ struct platform_device *pdev;
+ struct omap_gpio_platform_data *pdata;
if (!cpu_is_omap16xx())
return -EINVAL;
- for (i = 0; i ARRAY_SIZE(omap16xx_gpio_dev); i++)
+ for (i = 0; i ARRAY_SIZE(omap16xx_gpio_dev); i++) {
+ pdev = omap16xx_gpio_dev[i];
+ pdata = pdev-dev.platform_data;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (unlikely(!res)) {
+ dev_err(pdev-dev, Invalid mem resource.\n);
+ return -ENODEV;
+ }
+
+ base = ioremap(res-start, resource_size(res));
+ if (unlikely(!base)) {
+ dev_err(pdev-dev, ioremap failed.\n);
+ return -ENOMEM;
+ }
+
+ __raw_writel(SYSCONFIG_WORD, base + OMAP1610_GPIO_SYSCONFIG);
+ iounmap(base);
+
+ /*
+* Enable system clock for GPIO module.
+* The CAM_CLK_CTRL *is* really the right place.
+*/
+ omap_writel(omap_readl(ULPD_CAM_CLK_CTRL) | 0x04,
+ ULPD_CAM_CLK_CTRL);
+
platform_device_register(omap16xx_gpio_dev[i]);
+ }
return 0;
}
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f39d9e4..a948351 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -610,7 +610,6 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
if (!(isr 1))
continue;
-#ifdef CONFIG_ARCH_OMAP1
/*
* Some chips can't respond to both rising and falling
* at the same time. If this irq was requested with
@@ -620,7 +619,6 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
*/
if (bank-toggle_mask (1 gpio_index))
_toggle_gpio_edge_triggering(bank, gpio_index);
-#endif
generic_handle_irq(gpio_irq);
}
@@ -898,62 +896,30 @@ static void __init omap_gpio_show_rev(struct gpio_bank
*bank)
*/
static struct lock_class_key gpio_lock_class;
-/* TODO: Cleanup cpu_is_* checks */
static void omap_gpio_mod_init(struct gpio_bank *bank)
{
- if (cpu_class_is_omap2()) {
- if (cpu_is_omap44xx()) {
- __raw_writel(0x, bank-base +
- OMAP4_GPIO_IRQSTATUSCLR0);
- __raw_writel(0x, bank-base +
-OMAP4_GPIO_DEBOUNCENABLE);
- /* Initialize interface clk ungated, module enabled */
- __raw_writel(0, bank-base + OMAP4_GPIO_CTRL);
- } else if (cpu_is_omap34xx()) {
- __raw_writel(0x, bank-base +
- OMAP24XX_GPIO_IRQENABLE1);
- __raw_writel(0x, bank-base +
- OMAP24XX_GPIO_IRQSTATUS1);
- __raw_writel(0x, bank-base +
- OMAP24XX_GPIO_DEBOUNCE_EN);
-
- /* Initialize interface clk ungated, module enabled */
- __raw_writel(0, bank-base + OMAP24XX_GPIO_CTRL);
- }
- } else if (cpu_class_is_omap1()) {
- if (bank_is_mpuio(bank)) {
- __raw_writew(0x,
[PATCH v9 17/25] gpio/omap: optimize suspend and resume functions
There is no need to operate on all the banks every time the function is called.
Just operate on the current bank passed by the framework.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 54 -
1 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index b92a23f..9db892c 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1052,6 +1052,8 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
goto err_free;
}
+ platform_set_drvdata(pdev, bank);
+
pm_runtime_enable(bank-dev);
pm_runtime_irq_safe(bank-dev);
pm_runtime_get_sync(bank-dev);
@@ -1079,44 +1081,46 @@ err_exit:
static int omap_gpio_suspend(struct device *dev)
{
- struct gpio_bank *bank;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ void __iomem *base = bank-base;
+ void __iomem *wakeup_enable;
+ unsigned long flags;
- list_for_each_entry(bank, omap_gpio_list, node) {
- void __iomem *base = bank-base;
- void __iomem *wake_status;
- unsigned long flags;
+ if (!bank-mod_usage || !bank-loses_context)
+ return 0;
- if (!bank-regs-wkup_en)
- return 0;
+ if (!bank-regs-wkup_en || !bank-suspend_wakeup)
+ return 0;
- wake_status = bank-base + bank-regs-wkup_en;
+ wakeup_enable = bank-base + bank-regs-wkup_en;
- spin_lock_irqsave(bank-lock, flags);
- bank-saved_wakeup = __raw_readl(wake_status);
- _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
- _gpio_rmw(base, bank-regs-wkup_en, bank-suspend_wakeup, 1);
- spin_unlock_irqrestore(bank-lock, flags);
- }
+ spin_lock_irqsave(bank-lock, flags);
+ bank-saved_wakeup = __raw_readl(wakeup_enable);
+ _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-suspend_wakeup, 1);
+ spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
static int omap_gpio_resume(struct device *dev)
{
- struct gpio_bank *bank;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ void __iomem *base = bank-base;
+ unsigned long flags;
- list_for_each_entry(bank, omap_gpio_list, node) {
- void __iomem *base = bank-base;
- unsigned long flags;
+ if (!bank-mod_usage || !bank-loses_context)
+ return 0;
- if (!bank-regs-wkup_en)
- return 0;
+ if (!bank-regs-wkup_en || !bank-saved_wakeup)
+ return 0;
- spin_lock_irqsave(bank-lock, flags);
- _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
- _gpio_rmw(base, bank-regs-wkup_en, bank-saved_wakeup, 1);
- spin_unlock_irqrestore(bank-lock, flags);
- }
+ spin_lock_irqsave(bank-lock, flags);
+ _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-saved_wakeup, 1);
+ spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 03/25] gpio/omap: make gpio_context part of gpio_bank structure
From: Charulatha V ch...@ti.com
Currently gpio_context array used to save gpio bank's context, is used only for
OMAP3 architecture. Move gpio_context as part of gpio_bank structure so that it
can be specific to each gpio bank and can be used for any OMAP architecture
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 76 -
1 files changed, 34 insertions(+), 42 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 07efa15..6788c8a 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -30,6 +30,19 @@
static LIST_HEAD(omap_gpio_list);
+struct gpio_regs {
+ u32 irqenable1;
+ u32 irqenable2;
+ u32 wake_en;
+ u32 ctrl;
+ u32 oe;
+ u32 leveldetect0;
+ u32 leveldetect1;
+ u32 risingdetect;
+ u32 fallingdetect;
+ u32 dataout;
+};
+
struct gpio_bank {
struct list_head node;
unsigned long pbase;
@@ -43,7 +56,7 @@ struct gpio_bank {
#endif
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
-
+ struct gpio_regs context;
u32 saved_datain;
u32 saved_fallingdetect;
u32 saved_risingdetect;
@@ -66,23 +79,6 @@ struct gpio_bank {
struct omap_gpio_reg_offs *regs;
};
-#ifdef CONFIG_ARCH_OMAP3
-struct omap3_gpio_regs {
- u32 irqenable1;
- u32 irqenable2;
- u32 wake_en;
- u32 ctrl;
- u32 oe;
- u32 leveldetect0;
- u32 leveldetect1;
- u32 risingdetect;
- u32 fallingdetect;
- u32 dataout;
-};
-
-static struct omap3_gpio_regs gpio_context[OMAP34XX_NR_GPIOS];
-#endif
-
#define GPIO_INDEX(bank, gpio) (gpio % bank-width)
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
@@ -1499,33 +1495,31 @@ void omap2_gpio_resume_after_idle(void)
void omap_gpio_save_context(void)
{
struct gpio_bank *bank;
- int i = 0;
list_for_each_entry(bank, omap_gpio_list, node) {
- i++;
if (!bank-loses_context)
continue;
- gpio_context[i].irqenable1 =
+ bank-context.irqenable1 =
__raw_readl(bank-base + OMAP24XX_GPIO_IRQENABLE1);
- gpio_context[i].irqenable2 =
+ bank-context.irqenable2 =
__raw_readl(bank-base + OMAP24XX_GPIO_IRQENABLE2);
- gpio_context[i].wake_en =
+ bank-context.wake_en =
__raw_readl(bank-base + OMAP24XX_GPIO_WAKE_EN);
- gpio_context[i].ctrl =
+ bank-context.ctrl =
__raw_readl(bank-base + OMAP24XX_GPIO_CTRL);
- gpio_context[i].oe =
+ bank-context.oe =
__raw_readl(bank-base + OMAP24XX_GPIO_OE);
- gpio_context[i].leveldetect0 =
+ bank-context.leveldetect0 =
__raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT0);
- gpio_context[i].leveldetect1 =
+ bank-context.leveldetect1 =
__raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT1);
- gpio_context[i].risingdetect =
+ bank-context.risingdetect =
__raw_readl(bank-base + OMAP24XX_GPIO_RISINGDETECT);
- gpio_context[i].fallingdetect =
+ bank-context.fallingdetect =
__raw_readl(bank-base + OMAP24XX_GPIO_FALLINGDETECT);
- gpio_context[i].dataout =
+ bank-context.dataout =
__raw_readl(bank-base + OMAP24XX_GPIO_DATAOUT);
}
}
@@ -1533,33 +1527,31 @@ void omap_gpio_save_context(void)
void omap_gpio_restore_context(void)
{
struct gpio_bank *bank;
- int i = 0;
list_for_each_entry(bank, omap_gpio_list, node) {
- i++;
if (!bank-loses_context)
continue;
- __raw_writel(gpio_context[i].irqenable1,
+ __raw_writel(bank-context.irqenable1,
bank-base + OMAP24XX_GPIO_IRQENABLE1);
- __raw_writel(gpio_context[i].irqenable2,
+ __raw_writel(bank-context.irqenable2,
bank-base + OMAP24XX_GPIO_IRQENABLE2);
- __raw_writel(gpio_context[i].wake_en,
+ __raw_writel(bank-context.wake_en,
bank-base + OMAP24XX_GPIO_WAKE_EN);
- __raw_writel(gpio_context[i].ctrl,
+ __raw_writel(bank-context.ctrl,
bank-base + OMAP24XX_GPIO_CTRL);
- __raw_writel(gpio_context[i].oe,
+ __raw_writel(bank-context.oe,
bank-base + OMAP24XX_GPIO_OE);
- __raw_writel(gpio_context[i].leveldetect0,
+
[PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count
From: Charulatha V ch...@ti.com
The gpio_bank_count is the count of number of GPIO devices in a SoC. Remove this
dependency from the driver by using list. Also remove the dependency on array of
pointers to gpio_bank struct of all GPIO devices.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/gpio15xx.c |1 -
arch/arm/mach-omap1/gpio16xx.c |2 -
arch/arm/mach-omap1/gpio7xx.c |2 -
arch/arm/mach-omap2/gpio.c |1 -
arch/arm/plat-omap/include/plat/gpio.h |3 -
drivers/gpio/gpio-omap.c | 163
6 files changed, 80 insertions(+), 92 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
index 399da4c..f8c15ea 100644
--- a/arch/arm/mach-omap1/gpio15xx.c
+++ b/arch/arm/mach-omap1/gpio15xx.c
@@ -115,7 +115,6 @@ static int __init omap15xx_gpio_init(void)
platform_device_register(omap15xx_mpu_gpio);
platform_device_register(omap15xx_gpio);
- gpio_bank_count = 2;
return 0;
}
postcore_initcall(omap15xx_gpio_init);
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 0f399bd..df4bb44 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -221,8 +221,6 @@ static int __init omap16xx_gpio_init(void)
for (i = 0; i ARRAY_SIZE(omap16xx_gpio_dev); i++)
platform_device_register(omap16xx_gpio_dev[i]);
- gpio_bank_count = ARRAY_SIZE(omap16xx_gpio_dev);
-
return 0;
}
postcore_initcall(omap16xx_gpio_init);
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
index 5ab63ea..923eaa1 100644
--- a/arch/arm/mach-omap1/gpio7xx.c
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -282,8 +282,6 @@ static int __init omap7xx_gpio_init(void)
for (i = 0; i ARRAY_SIZE(omap7xx_gpio_dev); i++)
platform_device_register(omap7xx_gpio_dev[i]);
- gpio_bank_count = ARRAY_SIZE(omap7xx_gpio_dev);
-
return 0;
}
postcore_initcall(omap7xx_gpio_init);
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 8cbfbc2..07ac648 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -111,7 +111,6 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
omap_device_disable_idle_on_suspend(pdev);
- gpio_bank_count++;
return 0;
}
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index 9e86ee0..acf1c77 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -202,9 +202,6 @@ struct omap_gpio_platform_data {
struct omap_gpio_reg_offs *regs;
};
-/* TODO: Analyze removing gpio_bank_count usage from driver code */
-extern int gpio_bank_count;
-
extern void omap2_gpio_prepare_for_idle(int off_mode);
extern void omap2_gpio_resume_after_idle(void);
extern void omap_set_gpio_debounce(int gpio, int enable);
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0b05629..6ea7390 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -28,7 +28,10 @@
#include asm/gpio.h
#include asm/mach/irq.h
+static LIST_HEAD(omap_gpio_list);
+
struct gpio_bank {
+ struct list_head node;
unsigned long pbase;
void __iomem *base;
u16 irq;
@@ -55,6 +58,7 @@ struct gpio_bank {
bool dbck_flag;
int stride;
u32 width;
+ u16 id;
void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
@@ -78,15 +82,6 @@ struct omap3_gpio_regs {
static struct omap3_gpio_regs gpio_context[OMAP34XX_NR_GPIOS];
#endif
-/*
- * TODO: Cleanup gpio_bank usage as it is having information
- * related to all instances of the device
- */
-static struct gpio_bank *gpio_bank;
-
-/* TODO: Analyze removing gpio_bank_count usage from driver code */
-int gpio_bank_count;
-
#define GPIO_INDEX(bank, gpio) (gpio % bank-width)
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
@@ -869,9 +864,8 @@ static struct platform_device omap_mpuio_device = {
/* could list the /proc/iomem resources */
};
-static inline void mpuio_init(void)
+static inline void mpuio_init(struct gpio_bank *bank)
{
- struct gpio_bank *bank = gpio_bank[0];
platform_set_drvdata(omap_mpuio_device, bank);
if (platform_driver_register(omap_mpuio_driver) == 0)
@@ -879,13 +873,13 @@ static inline void mpuio_init(void)
}
#else
-static inline void mpuio_init(void) {}
+static inline void mpuio_init(struct gpio_bank *bank) {}
#endif /* 16xx */
#else
#define bank_is_mpuio(bank)0
-static inline void mpuio_init(void) {}
+static inline void mpuio_init(struct gpio_bank *bank) {}
#endif
@@ -1007,20 +1001,8 @@ static void __init omap_gpio_show_rev(struct gpio_bank
*bank)
*/
static
[PATCH v9 24/25] gpio/omap: restore OE only after setting the output level
From: Nishanth Menon n...@ti.com
Setup the dataout register before restoring OE. This is to make
sure that we have valid data in dataout register which would be
made available in output pins as soon as OE is enabled. Else,
there is risk of unknown data getting out into gpio pins.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 36aaea7..81fdbcf 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1351,7 +1351,6 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
__raw_writel(bank-context.wake_en,
bank-base + bank-regs-wkup_en);
__raw_writel(bank-context.ctrl, bank-base + bank-regs-ctrl);
- __raw_writel(bank-context.oe, bank-base + bank-regs-direction);
__raw_writel(bank-context.leveldetect0,
bank-base + bank-regs-leveldetect0);
__raw_writel(bank-context.leveldetect1,
@@ -1361,6 +1360,8 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
__raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
__raw_writel(bank-context.dataout, bank-base + bank-regs-dataout);
+ __raw_writel(bank-context.oe, bank-base + bank-regs-direction);
+
if (bank-dbck_enable_mask) {
__raw_writel(bank-context.debounce, bank-base +
bank-regs-debounce);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 05/25] gpio/omap: make non-wakeup GPIO part of pdata
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are available only in OMAP2. Avoid cpu_is checks by making
non_wakeup_gpios as part of pdata.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpio.c |8
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio-omap.c |8 +---
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index f84db8f..1d60fff 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -65,6 +65,14 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
switch (oh-class-rev) {
case 0:
+ if (id == 1)
+ /* non-wakeup GPIO pins for OMAP2 Bank1 */
+ pdata-non_wakeup_gpios = 0xe203ffc0;
+ else if (id == 2)
+ /* non-wakeup GPIO pins for OMAP2 Bank2 */
+ pdata-non_wakeup_gpios = 0x08700040;
+ /* fall through */
+
case 1:
pdata-bank_type = METHOD_GPIO_24XX;
pdata-regs-revision = OMAP24XX_GPIO_REVISION;
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index c1ddc5a..49ec751 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -199,6 +199,7 @@ struct omap_gpio_platform_data {
int bank_stride;/* Only needed for omap1 MPUIO */
bool dbck_flag; /* dbck required or not - True for OMAP34 */
bool loses_context; /* whether the bank would ever lose context */
+ u32 non_wakeup_gpios;
struct omap_gpio_reg_offs *regs;
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a1a3b9d..2eed159 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1021,13 +1021,6 @@ static void omap_gpio_mod_init(struct gpio_bank *bank)
/* Initialize interface clk ungated, module enabled */
__raw_writel(0, bank-base + OMAP24XX_GPIO_CTRL);
- } else if (cpu_is_omap24xx()) {
- static const u32 non_wakeup_gpios[] = {
- 0xe203ffc0, 0x08700040
- };
- if (bank-id ARRAY_SIZE(non_wakeup_gpios))
- bank-non_wakeup_gpios =
- non_wakeup_gpios[bank-id];
}
} else if (cpu_class_is_omap1()) {
if (bank_is_mpuio(bank)) {
@@ -1180,6 +1173,7 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
bank-dbck_flag = pdata-dbck_flag;
bank-stride = pdata-bank_stride;
bank-width = pdata-bank_width;
+ bank-non_wakeup_gpios = pdata-non_wakeup_gpios;
bank-loses_context = pdata-loses_context;
bank-get_context_loss_count = pdata-get_context_loss_count;
bank-regs = pdata-regs;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 18/25] gpio/omap: cleanup prepare_for_idle and resume_after_idle
Since *_prepare_for_idle() and *_resume_after_idle() are called
with interrupts disabled they should be kept as simple as possible.
So, moving most of the stuff to *_runtime_suspend/resume() callbacks.
To avoid invalid context restore happening in *_runtime_resume()
callback as a result of *_get_sync() call in *_gpio_probe(), update
bank-context_loss_count. This would make context restore condition
check false in the callback and skip restore until further
initialization take place. The workaround_enabled static variable
is now a member of struct gpio_bank.
Unlike most GPIO registers the OE has 0x as the default value.
To make sure invalid context is not restored, updating the OE context
with default value.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 241 +++---
1 files changed, 143 insertions(+), 98 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 9db892c..8b619fd 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -29,6 +29,8 @@
#include asm/gpio.h
#include asm/mach/irq.h
+#define OFF_MODE 1
+
static LIST_HEAD(omap_gpio_list);
struct gpio_regs {
@@ -73,6 +75,8 @@ struct gpio_bank {
u32 width;
int context_loss_count;
u16 id;
+ int power_mode;
+ bool workaround_enabled;
void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
int (*get_context_loss_count)(struct device *dev);
@@ -905,6 +909,8 @@ static void omap_gpio_mod_init(struct gpio_bank *bank)
if (bank-regs-debounce_en)
_gpio_rmw(base, bank-regs-debounce_en, 0, 1);
+ /* Save OE default value (0x) in the context */
+ bank-context.oe = __raw_readl(bank-base + bank-regs-direction);
/* Initialize interface clk ungated, module enabled */
if (bank-regs-ctrl)
_gpio_rmw(base, bank-regs-ctrl, 0, 1);
@@ -1129,135 +1135,170 @@ static int omap_gpio_resume(struct device *dev)
static void omap_gpio_save_context(struct gpio_bank *bank);
static void omap_gpio_restore_context(struct gpio_bank *bank);
-void omap2_gpio_prepare_for_idle(int off_mode)
+static int omap_gpio_runtime_suspend(struct device *dev)
{
- struct gpio_bank *bank;
-
- list_for_each_entry(bank, omap_gpio_list, node) {
- u32 l1 = 0, l2 = 0;
- int j;
-
- if (!bank-loses_context)
- continue;
-
- for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
- clk_disable(bank-dbck);
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ u32 l1 = 0, l2 = 0;
+ unsigned long flags;
- if (!off_mode)
- continue;
+ spin_lock_irqsave(bank-lock, flags);
+ if (bank-power_mode != OFF_MODE) {
+ bank-power_mode = 0;
+ goto save_gpio_context;
+ }
+ /*
+* If going to OFF, remove triggering for all
+* non-wakeup GPIOs. Otherwise spurious IRQs will be
+* generated. See OMAP2420 Errata item 1.101.
+*/
+ if (!(bank-enabled_non_wakeup_gpios))
+ goto save_gpio_context;
- /* If going to OFF, remove triggering for all
-* non-wakeup GPIOs. Otherwise spurious IRQs will be
-* generated. See OMAP2420 Errata item 1.101. */
- if (!(bank-enabled_non_wakeup_gpios))
- goto save_gpio_context;
+ bank-saved_datain = __raw_readl(bank-base +
+ bank-regs-datain);
+ l1 = __raw_readl(bank-base + bank-regs-fallingdetect);
+ l2 = __raw_readl(bank-base + bank-regs-risingdetect);
- bank-saved_datain = __raw_readl(bank-base +
- bank-regs-datain);
- l1 = __raw_readl(bank-base + bank-regs-fallingdetect);
- l2 = __raw_readl(bank-base + bank-regs-risingdetect);
+ bank-saved_fallingdetect = l1;
+ bank-saved_risingdetect = l2;
+ l1 = ~bank-enabled_non_wakeup_gpios;
+ l2 = ~bank-enabled_non_wakeup_gpios;
- bank-saved_fallingdetect = l1;
- bank-saved_risingdetect = l2;
- l1 = ~bank-enabled_non_wakeup_gpios;
- l2 = ~bank-enabled_non_wakeup_gpios;
+ __raw_writel(l1, bank-base + bank-regs-fallingdetect);
+ __raw_writel(l2, bank-base + bank-regs-risingdetect);
- __raw_writel(l1, bank-base + bank-regs-fallingdetect);
- __raw_writel(l2, bank-base + bank-regs-risingdetect);
+ bank-workaround_enabled = true;
save_gpio_context:
-
- if
[PATCH v9 04/25] gpio/omap: handle save/restore context in GPIO driver
Modify omap_gpio_prepare_for_idle() omap_gpio_resume_after_idle() functions
to handle save context restore context respectively in the OMAP GPIO driver
itself instead of calling these functions from pm specific files.
For this, in gpio_prepare_for_idle(), call *_get_context_loss_count() and in
gpio_resume_after_idle() call it again. If the count is different, do restore
context.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpio.c |3 +-
arch/arm/mach-omap2/pm34xx.c | 14
arch/arm/plat-omap/include/plat/gpio.h |5 +-
drivers/gpio/gpio-omap.c | 131 ++--
4 files changed, 63 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 076be34..f84db8f 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -23,6 +23,7 @@
#include plat/omap_hwmod.h
#include plat/omap_device.h
+#include plat/omap-pm.h
#include powerdomain.h
@@ -55,7 +56,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
pdata-bank_width = dev_attr-bank_width;
pdata-dbck_flag = dev_attr-dbck_flag;
pdata-virtual_irq_start = IH_GPIO_BASE + 32 * (id - 1);
-
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
pdata-regs = kzalloc(sizeof(struct omap_gpio_reg_offs), GFP_KERNEL);
if (!pdata) {
pr_err(gpio%d: Memory allocation failed\n, id);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc69875..59c6dc1 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -75,16 +75,6 @@ static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
static struct powerdomain *cam_pwrdm;
-static inline void omap3_per_save_context(void)
-{
- omap_gpio_save_context();
-}
-
-static inline void omap3_per_restore_context(void)
-{
- omap_gpio_restore_context();
-}
-
static void omap3_enable_io_chain(void)
{
int timeout = 0;
@@ -332,8 +322,6 @@ void omap_sram_idle(void)
if (per_next_state PWRDM_POWER_ON) {
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
omap2_gpio_prepare_for_idle(per_going_off);
- if (per_next_state == PWRDM_POWER_OFF)
- omap3_per_save_context();
}
/* CORE */
@@ -399,8 +387,6 @@ void omap_sram_idle(void)
if (per_next_state PWRDM_POWER_ON) {
per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
omap2_gpio_resume_after_idle();
- if (per_prev_state == PWRDM_POWER_OFF)
- omap3_per_restore_context();
}
/* Disable IO-PAD and IO-CHAIN wakeup */
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index 6eb035c..c1ddc5a 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -201,14 +201,15 @@ struct omap_gpio_platform_data {
bool loses_context; /* whether the bank would ever lose context */
struct omap_gpio_reg_offs *regs;
+
+ /* Return context loss count due to PM states changing */
+ int (*get_context_loss_count)(struct device *dev);
};
extern void omap2_gpio_prepare_for_idle(int off_mode);
extern void omap2_gpio_resume_after_idle(void);
extern void omap_set_gpio_debounce(int gpio, int enable);
extern void omap_set_gpio_debounce_time(int gpio, int enable);
-extern void omap_gpio_save_context(void);
-extern void omap_gpio_restore_context(void);
/*-*/
/* Wrappers for new style GPIO calls, using the new infrastructure
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 6788c8a..a1a3b9d 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -72,9 +72,11 @@ struct gpio_bank {
bool loses_context;
int stride;
u32 width;
+ int context_loss_count;
u16 id;
void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
+ int (*get_context_loss_count)(struct device *dev);
struct omap_gpio_reg_offs *regs;
};
@@ -1179,6 +1181,7 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
bank-stride = pdata-bank_stride;
bank-width = pdata-bank_width;
bank-loses_context = pdata-loses_context;
+ bank-get_context_loss_count = pdata-get_context_loss_count;
bank-regs = pdata-regs;
if (bank-regs-set_dataout bank-regs-clr_dataout)
@@ -1323,11 +1326,11 @@ static struct syscore_ops omap_gpio_syscore_ops = {
#ifdef CONFIG_ARCH_OMAP2PLUS
-static int workaround_enabled;
[PATCH v9 12/25] gpio/omap: use pinctrl offset instead of macro
From: Charulatha V ch...@ti.com
Use regs-pinctrl field instead of using the macro OMAP1510_GPIO_PIN_CONTROL
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/gpio15xx.c |1 +
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio-omap.c |8 +++-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
index 2adfece..950e467 100644
--- a/arch/arm/mach-omap1/gpio15xx.c
+++ b/arch/arm/mach-omap1/gpio15xx.c
@@ -85,6 +85,7 @@ static struct omap_gpio_reg_offs omap15xx_gpio_regs = {
.irqenable = OMAP1510_GPIO_INT_MASK,
.irqenable_inv = true,
.irqctrl= OMAP1510_GPIO_INT_CONTROL,
+ .pinctrl= OMAP1510_GPIO_PIN_CONTROL,
};
static struct __initdata omap_gpio_platform_data omap15xx_gpio_config = {
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index 9e403e5..8be1651 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -198,6 +198,7 @@ struct omap_gpio_reg_offs {
u16 irqctrl;
u16 edgectrl1;
u16 edgectrl2;
+ u16 pinctrl;
bool irqenable_inv;
};
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a948351..485b6b2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -490,15 +490,13 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
*/
_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
-#ifdef CONFIG_ARCH_OMAP15XX
- if (bank-method == METHOD_GPIO_1510) {
- void __iomem *reg;
+ if (bank-regs-pinctrl) {
+ void __iomem *reg = bank-base + bank-regs-pinctrl;
/* Claim the pin for MPU */
- reg = bank-base + OMAP1510_GPIO_PIN_CONTROL;
__raw_writel(__raw_readl(reg) | (1 offset), reg);
}
-#endif
+
if (bank-regs-ctrl !bank-mod_usage) {
void __iomem *reg = bank-base + bank-regs-ctrl;
u32 ctrl;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 00/25] gpio/omap: driver cleanup and fixes
The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab: Linus Torvalds (1): Linux 3.3-rc2 are available in the git repository at: http://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev Branch: for_3.4/gpio_cleanup_fixes_v9 This series is continuation of cleanup of OMAP GPIO driver and fixes. The cleanup include getting rid of cpu_is_* checks wherever possible, use of gpio_bank list instead of static array, use of unique platform specific value associated data member to OMAP platforms to avoid cpu_is_* checks. The series also include PM runtime support. Power Tests a) OMAP3430SDP - Modify board-3430sdp.c file to have multiple GPIO modules active with debounce timeout enabled. - Enable CPU-Idle - Enable UART timeouts - Enable offmode - echo mem /sys/power/state - Verify retention and offmode count increment Used following patches to avoid exception during system suspend:- [PATCH RFC 1/2] mtd : Prevent the NULL pointer access [PATCH RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented # echo mem /sys/power/state [ 47.128021] PM: Syncing filesystems ... done. [ 47.144104] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 47.168243] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 47.205139] Unable to handle kernel NULL pointer dereference at virtual addre ss 00a0 [ 47.213317] pgd = deaac000 [ 47.216033] [00a0] *pgd=9e932831, *pte=, *ppte= [ 47.222381] Internal error: Oops: 17 [#1] SMP [ 47.226745] Modules linked in: [ 47.229827] CPU: 0Not tainted (3.3.0-rc2-00031-g12c5c5c #235) [ 47.236022] PC is at mtd_cls_suspend+0x8/0x20 [ 47.240386] LR is at mtd_cls_suspend+0x8/0x20 [ 47.244750] pc : [c02e78f8]lr : [c02e78f8]psr: a013 [ 47.244750] sp : dea1fe60 ip : fp : c0ee7d40 [ 47.256256] r10: c0ee7cf0 r9 : r8 : c02e78f0 [ 47.261474] r7 : r6 : r5 : 0002 r4 : dea45800 [ 47.268005] r3 : deb4cac0 r2 : r1 : 0002 r0 : [ 47.274536] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 47.281677] Control: 10c5387d Table: 9eaac019 DAC: 0015 [ 47.287445] Process sh (pid: 1177, stack limit = 0xdea1e2f8) [ 47.293090] Stack: (0xdea1fe60 to 0xdea2) [...] b) ZOOM3 - Enable CPU-Idle - Enable UART timeout - echo mem /sys/power/state - Wakeup system using serial keyboard - Verify retention count increment Functional Tests - Done on OMAP2430, OMAP3430SDP, ZOOM3, OMAP4430 Bootup Test - Done on OMAP1710 Used following patch to fix OMAP1 build error:- [PATCH] i2c: OMAP: Fix OMAP1 build error v9: - Summary of Comments/Issues fixed * GPIO wakeup does not work * Call debounce clock enable/disable functions from PM runtime callbacks. This will avoid calling the functions from multiple places. * Modify description of following patch to match latest changes. gpio/omap: save and restore debounce registers. * Use (bank-regs-set_dataout bank-regs-clr_dataout) together instead of using only one of them. * Remove cpu_is_omap() checks from set_gpio_trigger(). * _gpio_dbck_enable() in runtime callback triggered from omap_gpio_request does not enable dbck because dbck_enable_mask is not set at this point. * Workaround associated with an errata got missed in v8. This has been included. v8: - Remove PM_CONFIG macro around following assignment. pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count; - Once pm_runtime is enabled there is no more need for calling the omap_device_disable_idle_on_suspend(od). - With pm_runtime, handling of clocks in Suspend is taken care of by powerdomain hooks. So remove usage of *_runtime_put/get* from suspend/resume hooks and Idle path. - Add handling of debounce clocks along the Suspend and Idle paths. - Remove [PATCH 04/24] gpio/omap: fix pwrdm_post_transition call sequence from this series. This will be merged as part of power cleanup series. - Remove [PATCH v7 20/26] gpio/omap: skip operations in runtime callbacks The bank-mod_usage check in this patch is not needed any more because they are now already being taken care in suspend/resume and Idle paths. - Remove [PATCH v7 26/26] gpio/omap: add dbclk aliases for all gpio modules This is already taken care in hwmod. - Remove redundant blank line in [PATCH v7 14/26] gpio/omap: remove unnecessary bit-masking for read access - if (cpu_is_omap15xx() (bank-method == METHOD_MPUIO)) - isr = 0x; if (bank-level_mask) level_mask = bank-level_mask enabled; v7: - Use pm_runtime_put() instead of
[PATCH v9 09/25] gpio/omap: remove hardcoded offsets in context save/restore
It is not required to use hard-coded offsets any more in context save and
restore functions and instead use the generic offsets which have been correctly
initialized during device registration.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpio.c |2 +
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio-omap.c | 42 +++
3 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index ae5043e..f4c45ca 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -84,6 +84,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
pdata-regs-irqstatus = OMAP24XX_GPIO_IRQSTATUS1;
pdata-regs-irqstatus2 = OMAP24XX_GPIO_IRQSTATUS2;
pdata-regs-irqenable = OMAP24XX_GPIO_IRQENABLE1;
+ pdata-regs-irqenable2 = OMAP24XX_GPIO_IRQENABLE2;
pdata-regs-set_irqenable = OMAP24XX_GPIO_SETIRQENABLE1;
pdata-regs-clr_irqenable = OMAP24XX_GPIO_CLEARIRQENABLE1;
pdata-regs-debounce = OMAP24XX_GPIO_DEBOUNCE_VAL;
@@ -106,6 +107,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
pdata-regs-irqstatus = OMAP4_GPIO_IRQSTATUS0;
pdata-regs-irqstatus2 = OMAP4_GPIO_IRQSTATUS1;
pdata-regs-irqenable = OMAP4_GPIO_IRQSTATUSSET0;
+ pdata-regs-irqenable2 = OMAP4_GPIO_IRQSTATUSSET1;
pdata-regs-set_irqenable = OMAP4_GPIO_IRQSTATUSSET0;
pdata-regs-clr_irqenable = OMAP4_GPIO_IRQSTATUSCLR0;
pdata-regs-debounce = OMAP4_GPIO_DEBOUNCINGTIME;
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index 395b3c1..914c976 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -184,6 +184,7 @@ struct omap_gpio_reg_offs {
u16 irqstatus;
u16 irqstatus2;
u16 irqenable;
+ u16 irqenable2;
u16 set_irqenable;
u16 clr_irqenable;
u16 debounce;
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 991dd39..ceb9edf 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1369,45 +1369,43 @@ void omap2_gpio_resume_after_idle(void)
static void omap_gpio_save_context(struct gpio_bank *bank)
{
bank-context.irqenable1 =
- __raw_readl(bank-base + OMAP24XX_GPIO_IRQENABLE1);
+ __raw_readl(bank-base + bank-regs-irqenable);
bank-context.irqenable2 =
- __raw_readl(bank-base + OMAP24XX_GPIO_IRQENABLE2);
+ __raw_readl(bank-base + bank-regs-irqenable2);
bank-context.wake_en =
- __raw_readl(bank-base + OMAP24XX_GPIO_WAKE_EN);
- bank-context.ctrl = __raw_readl(bank-base + OMAP24XX_GPIO_CTRL);
- bank-context.oe = __raw_readl(bank-base + OMAP24XX_GPIO_OE);
+ __raw_readl(bank-base + bank-regs-wkup_en);
+ bank-context.ctrl = __raw_readl(bank-base + bank-regs-ctrl);
+ bank-context.oe = __raw_readl(bank-base + bank-regs-direction);
bank-context.leveldetect0 =
- __raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT0);
+ __raw_readl(bank-base + bank-regs-leveldetect0);
bank-context.leveldetect1 =
- __raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT1);
+ __raw_readl(bank-base + bank-regs-leveldetect1);
bank-context.risingdetect =
- __raw_readl(bank-base + OMAP24XX_GPIO_RISINGDETECT);
+ __raw_readl(bank-base + bank-regs-risingdetect);
bank-context.fallingdetect =
- __raw_readl(bank-base + OMAP24XX_GPIO_FALLINGDETECT);
- bank-context.dataout =
- __raw_readl(bank-base + OMAP24XX_GPIO_DATAOUT);
+ __raw_readl(bank-base + bank-regs-fallingdetect);
+ bank-context.dataout = __raw_readl(bank-base + bank-regs-dataout);
}
static void omap_gpio_restore_context(struct gpio_bank *bank)
{
__raw_writel(bank-context.irqenable1,
- bank-base + OMAP24XX_GPIO_IRQENABLE1);
+ bank-base + bank-regs-irqenable);
__raw_writel(bank-context.irqenable2,
- bank-base + OMAP24XX_GPIO_IRQENABLE2);
+ bank-base + bank-regs-irqenable2);
__raw_writel(bank-context.wake_en,
- bank-base + OMAP24XX_GPIO_WAKE_EN);
- __raw_writel(bank-context.ctrl, bank-base + OMAP24XX_GPIO_CTRL);
- __raw_writel(bank-context.oe, bank-base + OMAP24XX_GPIO_OE);
+ bank-base +
[PATCH v9 23/25] gpio/omap: enable irq at the end of all configuration in restore
From: Nishanth Menon n...@ti.com
Setup the interrupt enable registers only after we have configured the
required edge and required configurations, not before, to prevent
spurious events as part of restore routine.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 560567d..36aaea7 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1348,10 +1348,6 @@ void omap2_gpio_resume_after_idle(void)
static void omap_gpio_restore_context(struct gpio_bank *bank)
{
- __raw_writel(bank-context.irqenable1,
- bank-base + bank-regs-irqenable);
- __raw_writel(bank-context.irqenable2,
- bank-base + bank-regs-irqenable2);
__raw_writel(bank-context.wake_en,
bank-base + bank-regs-wkup_en);
__raw_writel(bank-context.ctrl, bank-base + bank-regs-ctrl);
@@ -1371,6 +1367,11 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
__raw_writel(bank-context.debounce_en,
bank-base + bank-regs-debounce_en);
}
+
+ __raw_writel(bank-context.irqenable1,
+ bank-base + bank-regs-irqenable);
+ __raw_writel(bank-context.irqenable2,
+ bank-base + bank-regs-irqenable2);
}
#else
#define omap_gpio_suspend NULL
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 08/25] gpio/omap: use level/edge detect reg offsets
By adding level and edge detection register offsets and then initializing them
correctly according to OMAP versions during device registrations we can now
remove
lot of revision checks in these functions.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpio.c |8 ++
arch/arm/plat-omap/include/plat/gpio.h |4 +
drivers/gpio/gpio-omap.c | 114 +---
3 files changed, 44 insertions(+), 82 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 4877b52..ae5043e 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -90,6 +90,10 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
pdata-regs-debounce_en = OMAP24XX_GPIO_DEBOUNCE_EN;
pdata-regs-ctrl = OMAP24XX_GPIO_CTRL;
pdata-regs-wkup_en = OMAP24XX_GPIO_WAKE_EN;
+ pdata-regs-leveldetect0 = OMAP24XX_GPIO_LEVELDETECT0;
+ pdata-regs-leveldetect1 = OMAP24XX_GPIO_LEVELDETECT1;
+ pdata-regs-risingdetect = OMAP24XX_GPIO_RISINGDETECT;
+ pdata-regs-fallingdetect = OMAP24XX_GPIO_FALLINGDETECT;
break;
case 2:
pdata-bank_type = METHOD_GPIO_44XX;
@@ -108,6 +112,10 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
pdata-regs-debounce_en = OMAP4_GPIO_DEBOUNCENABLE;
pdata-regs-ctrl = OMAP4_GPIO_CTRL;
pdata-regs-wkup_en = OMAP4_GPIO_IRQWAKEN0;
+ pdata-regs-leveldetect0 = OMAP4_GPIO_LEVELDETECT0;
+ pdata-regs-leveldetect1 = OMAP4_GPIO_LEVELDETECT1;
+ pdata-regs-risingdetect = OMAP4_GPIO_RISINGDETECT;
+ pdata-regs-fallingdetect = OMAP4_GPIO_FALLINGDETECT;
break;
default:
WARN(1, Invalid gpio bank_type\n);
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index 2b54bca..395b3c1 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -190,6 +190,10 @@ struct omap_gpio_reg_offs {
u16 debounce_en;
u16 ctrl;
u16 wkup_en;
+ u16 leveldetect0;
+ u16 leveldetect1;
+ u16 risingdetect;
+ u16 fallingdetect;
bool irqenable_inv;
};
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 3daedff..991dd39 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -257,15 +257,9 @@ static inline void set_24xx_gpio_triggering(struct
gpio_bank *bank, int gpio,
bank-enabled_non_wakeup_gpios = ~gpio_bit;
}
- if (cpu_is_omap44xx()) {
- bank-level_mask =
- __raw_readl(bank-base + OMAP4_GPIO_LEVELDETECT0) |
- __raw_readl(bank-base + OMAP4_GPIO_LEVELDETECT1);
- } else {
- bank-level_mask =
- __raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT0) |
- __raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT1);
- }
+ bank-level_mask =
+ __raw_readl(bank-base + bank-regs-leveldetect0) |
+ __raw_readl(bank-base + bank-regs-leveldetect1);
}
#endif
@@ -405,12 +399,12 @@ static int gpio_irq_type(struct irq_data *d, unsigned
type)
if (type ~IRQ_TYPE_SENSE_MASK)
return -EINVAL;
- /* OMAP1 allows only only edge triggering */
- if (!cpu_class_is_omap2()
-(type (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
+ bank = irq_data_get_irq_chip_data(d);
+
+ if (!bank-regs-leveldetect0
+ (type (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
return -EINVAL;
- bank = irq_data_get_irq_chip_data(d);
spin_lock_irqsave(bank-lock, flags);
retval = _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), type);
spin_unlock_irqrestore(bank-lock, flags);
@@ -658,9 +652,8 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
if (cpu_is_omap15xx() (bank-method == METHOD_MPUIO))
isr = 0x;
- if (cpu_class_is_omap2()) {
+ if (bank-level_mask)
level_mask = bank-level_mask enabled;
- }
/* clear edge sensitive interrupts before handler(s) are
called so that we don't miss any interrupt occurred while
@@ -1271,40 +1264,18 @@ void omap2_gpio_prepare_for_idle(int off_mode)
if (!(bank-enabled_non_wakeup_gpios))
goto save_gpio_context;
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- bank-saved_datain =
[PATCH v9 25/25] gpio/omap: handle set_dataout reg capable IP on restore
From: Nishanth Menon n...@ti.com
GPIO IP revisions such as those used in OMAP4 have a set_dataout
while the previous revisions used a single dataout register.
Depending on what is available restore the dataout settings
to the right register.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 81fdbcf..4273401 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1359,7 +1359,12 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
bank-base + bank-regs-risingdetect);
__raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
- __raw_writel(bank-context.dataout, bank-base + bank-regs-dataout);
+ if (bank-regs-set_dataout bank-regs-clr_dataout)
+ __raw_writel(bank-context.dataout,
+ bank-base + bank-regs-set_dataout);
+ else
+ __raw_writel(bank-context.dataout,
+ bank-base + bank-regs-dataout);
__raw_writel(bank-context.oe, bank-base + bank-regs-direction);
if (bank-dbck_enable_mask) {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 22/25] gpio/omap: save and restore debounce registers
From: Nishanth Menon n...@ti.com
GPIO debounce registers need to be saved and restored for proper functioning
of driver.
Signed-off-by: Nishanth Menon n...@ti.com
tarun.ka...@ti.com: Debounce context save is moved to _set_gpio_debounce()
as part of dynamic context save to remove overhead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 4056d78..560567d 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -44,6 +44,8 @@ struct gpio_regs {
u32 risingdetect;
u32 fallingdetect;
u32 dataout;
+ u32 debounce;
+ u32 debounce_en;
};
struct gpio_bank {
@@ -229,6 +231,10 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
* that point. Therefore we have to enable dbck here.
*/
_gpio_dbck_enable(bank);
+ if (bank-dbck_enable_mask) {
+ bank-context.debounce = debounce;
+ bank-context.debounce_en = val;
+ }
}
static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
@@ -1359,6 +1365,12 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
__raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
__raw_writel(bank-context.dataout, bank-base + bank-regs-dataout);
+ if (bank-dbck_enable_mask) {
+ __raw_writel(bank-context.debounce, bank-base +
+ bank-regs-debounce);
+ __raw_writel(bank-context.debounce_en,
+ bank-base + bank-regs-debounce_en);
+ }
}
#else
#define omap_gpio_suspend NULL
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 06/25] gpio/omap: avoid cpu checks during module ena/disable
From: Charulatha V ch...@ti.com
Remove cpu-is checks while enabling/disabling OMAP GPIO module during a gpio
request/free.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpio.c |2 +
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio-omap.c | 53 ++--
3 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 1d60fff..bc9271a 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -88,6 +88,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
pdata-regs-clr_irqenable = OMAP24XX_GPIO_CLEARIRQENABLE1;
pdata-regs-debounce = OMAP24XX_GPIO_DEBOUNCE_VAL;
pdata-regs-debounce_en = OMAP24XX_GPIO_DEBOUNCE_EN;
+ pdata-regs-ctrl = OMAP24XX_GPIO_CTRL;
break;
case 2:
pdata-bank_type = METHOD_GPIO_44XX;
@@ -104,6 +105,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
*unused)
pdata-regs-clr_irqenable = OMAP4_GPIO_IRQSTATUSCLR0;
pdata-regs-debounce = OMAP4_GPIO_DEBOUNCINGTIME;
pdata-regs-debounce_en = OMAP4_GPIO_DEBOUNCENABLE;
+ pdata-regs-ctrl = OMAP4_GPIO_CTRL;
break;
default:
WARN(1, Invalid gpio bank_type\n);
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index 49ec751..db94bd1 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -188,6 +188,7 @@ struct omap_gpio_reg_offs {
u16 clr_irqenable;
u16 debounce;
u16 debounce_en;
+ u16 ctrl;
bool irqenable_inv;
};
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 2eed159..5cc2c04 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -83,6 +83,7 @@ struct gpio_bank {
#define GPIO_INDEX(bank, gpio) (gpio % bank-width)
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
+#define GPIO_MOD_CTRL_BIT BIT(0)
static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int is_input)
{
@@ -577,22 +578,18 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
__raw_writel(__raw_readl(reg) | (1 offset), reg);
}
#endif
- if (!cpu_class_is_omap1()) {
- if (!bank-mod_usage) {
- void __iomem *reg = bank-base;
- u32 ctrl;
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
- reg += OMAP24XX_GPIO_CTRL;
- else if (cpu_is_omap44xx())
- reg += OMAP4_GPIO_CTRL;
- ctrl = __raw_readl(reg);
- /* Module is enabled, clocks are not gated */
- ctrl = 0xFFFE;
- __raw_writel(ctrl, reg);
- }
- bank-mod_usage |= 1 offset;
+ if (bank-regs-ctrl !bank-mod_usage) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is enabled, clocks are not gated */
+ ctrl = ~GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
}
+
+ bank-mod_usage |= 1 offset;
+
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -625,22 +622,18 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
__raw_writel(1 offset, reg);
}
#endif
- if (!cpu_class_is_omap1()) {
- bank-mod_usage = ~(1 offset);
- if (!bank-mod_usage) {
- void __iomem *reg = bank-base;
- u32 ctrl;
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
- reg += OMAP24XX_GPIO_CTRL;
- else if (cpu_is_omap44xx())
- reg += OMAP4_GPIO_CTRL;
- ctrl = __raw_readl(reg);
- /* Module is disabled, clocks are gated */
- ctrl |= 1;
- __raw_writel(ctrl, reg);
- }
+ bank-mod_usage = ~(1 offset);
+
+ if (bank-regs-ctrl !bank-mod_usage) {
+ void __iomem *reg = bank-base + bank-regs-ctrl;
+ u32 ctrl;
+
+ ctrl = __raw_readl(reg);
+ /* Module is disabled, clocks are gated */
+ ctrl |= GPIO_MOD_CTRL_BIT;
+ __raw_writel(ctrl, reg);
}
+
_reset_gpio(bank, bank-chip.base + offset);
spin_unlock_irqrestore(bank-lock, flags);
}
--
1.7.0.4
--
To unsubscribe from this
Re: [PATCH-V2 3/3] arm:omap:omap4: Hook-up am33xx support to existing prm code
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, Feb 01, 2012 at 23:03:56, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Tue, Jan 24, 2012 at 04:05:32, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, Jan 11, 2012 at 21:48:25, Hiremath, Vaibhav wrote:
On Tue, Jan 10, 2012 at 23:39:22, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
AM33XX PRM module (L4_WK domain) will be treated as another
seperate
partition in _prm_bases[] table.
Also, since cpu_is_omap34xx check is true for am33xx family of
devices, we must check cpu_is_am33xx fisrt, in order to follow
omap4 execution path.
Can you remind me why cpu_is_omap34xx() is true for AM33xx family?
Yeah sure...
Kevin,
As mentioned before, the main idea behind bringing am33xx under
omap34xx
was mainly due to cortex-A8 family of devices.
It has been discussed and aligned long time back, so
please refer to the thread -
http://www.spinics.net/lists/linux-omap/msg41046.html
Multiple versions of -
http://www.spinics.net/lists/linux-omap/msg45505.html
Thanks,
Vaibhav
These AM3xxx devices make my brain hurt.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
[...]
diff --git a/arch/arm/mach-omap2/prminst44xx.c
b/arch/arm/mach-omap2/prminst44xx.c
index 3d9894f..fcc4123 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -19,6 +19,7 @@
#include common.h
#include prm44xx.h
+#include prm33xx.h
#include prminst44xx.h
#include prm-regbits-44xx.h
#include prcm44xx.h
@@ -31,6 +32,7 @@ static u32 _prm_bases[OMAP4_MAX_PRCM_PARTITIONS]
= {
[OMAP4430_CM2_PARTITION]= 0,
[OMAP4430_SCRM_PARTITION] = 0,
[OMAP4430_PRCM_MPU_PARTITION] =
OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE),
+ [AM33XX_PRM_PARTITION] =
AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE),
};
I'm not crazy about just extending the normal OMAP4 table.
If it is required then yes (with proper comment).
That would
imply that with each OMAP4 derivatve we keep extending this table.
I would say anyway we will end up adding
Cpu_is_xxx everywhere as we add new table for derivatives.
Instead, how about rename this to one to omap44xx_prm_bases[], then
create a new one called am33xx_prm_bases[]. Then, at init time,
assing
_prm_bases to the right one based on cpu_is_.
Just wanted to avoid cpu_is_ check here. Will specific comment
wouldn't
help here (I have clearly mentioned in patch description), may be in c
file
it is required?
OR
you want to be clearly separate table for code readability.
Kevin,
Any comments on this? Should I stick to what is implemented now?
cpu_is_* checks are acceptable at init time, and we use them often to
initialize SoC-dependent tables/arrays etc.
Kevin,
Sorry for delayed response,
Here is the ugly part, which I was referring to -
1) _prm_bases variable is static variable to the prminst44xx.c
2) prminst44xx.c file doesn't contain any boot time __init function,
So I have to either add exported __init function OR extern __prm_bases
variable and initialize somewhere outside this file.
3) Even if I create 2 separate variables, for example,
static u32 omap44xx_prm_bases[OMAP4_MAX_PRCM_PARTITIONS] = {
...
};
static u32 omap33xx_prm_bases[AM33XX_MAX_PRCM_PARTITIONS] = {
...
};
Makes it difficult and messy to handle inside below code,
BUG_ON doesn't make sense from AM335x perspective.
Then you can change the BUG_ON.
static u32 omap44xx_max_partitions = ARRAY_SIZE(omap44xx_prm_bases)
static u32 am33xx_max_partitions = ARRAY_SIZE(am33xx_prm_bases)
static u32 max_partitions.
At init time, assign max_partitions when you assign prm_bases, then
change the BUG_ON() to be something like:
BUG_ON(part = max_partitions || part == INVALID_PARTITION)
Kevin,
Getting rid of BUG_ON was the least and trivial one, the issue is 1 2.
Oh, I didn't think those two were a problem since we do similiar things
throughout the kernel. Consider using an initcall instead of calling it
from somwhere else, unless there are specific dependencies.
Kevin
Let me atleast attempt to implement something on this, will update you.
Thanks,
Vaibhav
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
RE: [PATCH-V2 3/3] arm:omap:omap4: Hook-up am33xx support to existing prm code
On Wed, Feb 01, 2012 at 23:03:56, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Tue, Jan 24, 2012 at 04:05:32, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, Jan 11, 2012 at 21:48:25, Hiremath, Vaibhav wrote:
On Tue, Jan 10, 2012 at 23:39:22, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
AM33XX PRM module (L4_WK domain) will be treated as another seperate
partition in _prm_bases[] table.
Also, since cpu_is_omap34xx check is true for am33xx family of
devices, we must check cpu_is_am33xx fisrt, in order to follow
omap4 execution path.
Can you remind me why cpu_is_omap34xx() is true for AM33xx family?
Yeah sure...
Kevin,
As mentioned before, the main idea behind bringing am33xx under omap34xx
was mainly due to cortex-A8 family of devices.
It has been discussed and aligned long time back, so
please refer to the thread -
http://www.spinics.net/lists/linux-omap/msg41046.html
Multiple versions of -
http://www.spinics.net/lists/linux-omap/msg45505.html
Thanks,
Vaibhav
These AM3xxx devices make my brain hurt.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
[...]
diff --git a/arch/arm/mach-omap2/prminst44xx.c
b/arch/arm/mach-omap2/prminst44xx.c
index 3d9894f..fcc4123 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -19,6 +19,7 @@
#include common.h
#include prm44xx.h
+#include prm33xx.h
#include prminst44xx.h
#include prm-regbits-44xx.h
#include prcm44xx.h
@@ -31,6 +32,7 @@ static u32 _prm_bases[OMAP4_MAX_PRCM_PARTITIONS]
= {
[OMAP4430_CM2_PARTITION]= 0,
[OMAP4430_SCRM_PARTITION] = 0,
[OMAP4430_PRCM_MPU_PARTITION] =
OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE),
+ [AM33XX_PRM_PARTITION] =
AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE),
};
I'm not crazy about just extending the normal OMAP4 table.
If it is required then yes (with proper comment).
That would
imply that with each OMAP4 derivatve we keep extending this table.
I would say anyway we will end up adding
Cpu_is_xxx everywhere as we add new table for derivatives.
Instead, how about rename this to one to omap44xx_prm_bases[], then
create a new one called am33xx_prm_bases[]. Then, at init time,
assing
_prm_bases to the right one based on cpu_is_.
Just wanted to avoid cpu_is_ check here. Will specific comment
wouldn't
help here (I have clearly mentioned in patch description), may be in c
file
it is required?
OR
you want to be clearly separate table for code readability.
Kevin,
Any comments on this? Should I stick to what is implemented now?
cpu_is_* checks are acceptable at init time, and we use them often to
initialize SoC-dependent tables/arrays etc.
Kevin,
Sorry for delayed response,
Here is the ugly part, which I was referring to -
1) _prm_bases variable is static variable to the prminst44xx.c
2) prminst44xx.c file doesn't contain any boot time __init function,
So I have to either add exported __init function OR extern __prm_bases
variable and initialize somewhere outside this file.
3) Even if I create 2 separate variables, for example,
static u32 omap44xx_prm_bases[OMAP4_MAX_PRCM_PARTITIONS] = {
...
};
static u32 omap33xx_prm_bases[AM33XX_MAX_PRCM_PARTITIONS] = {
...
};
Makes it difficult and messy to handle inside below code,
BUG_ON doesn't make sense from AM335x perspective.
Then you can change the BUG_ON.
static u32 omap44xx_max_partitions = ARRAY_SIZE(omap44xx_prm_bases)
static u32 am33xx_max_partitions = ARRAY_SIZE(am33xx_prm_bases)
static u32 max_partitions.
At init time, assign max_partitions when you assign prm_bases, then
change the BUG_ON() to be something like:
BUG_ON(part = max_partitions || part == INVALID_PARTITION)
Kevin,
Sorry for delayed response on this, was into volleyball match whole day...
As I mentioned, I attempted to do this and below is output of git-diff.
Also, I have boot tested it on AM335xEVM board.
NOTE: Diff is created on top of my earlier submitted patches.
===git diff=
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b3da178..f387857 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -39,6 +39,7 @@
#include plat/omap-pm.h
#include voltage.h
#include powerdomain.h
+#include prminst44xx.h
#include clockdomain.h
#include plat/omap_hwmod.h
@@ -475,6 +476,7 @@ void __init am33xx_init_early(void)
omap2_set_globals_am33xx();
Re: [PATCH 1/2] ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()
Paul Walmsley p...@pwsan.com writes: On Tue, 31 Jan 2012, Kevin Hilman wrote: Kevin Hilman khil...@ti.com writes: Paul Walmsley p...@pwsan.com writes: Remove some superfluous calls to pwrdm_clear_all_prev_pwrst(). pwrdm_pre_transition(), which appears a few lines after these calls, invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's no need to do it twice. It looks like these two for OMAP4 are surpurfluous since the immediately follow a call to pwrdm_pre_transition() as well. Santosh/Rajendra, please confirm/ack. So after the discussion, do you want to fold this into the original patch, or do you want a separate patch? Your changes make sense to me. I am fine with you adding them into the original patch and adding some credit for you into the commit message. Or you can create a separate patch. OK, I'll fold it in. Thanks, 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 RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented
On Thursday, February 02, 2012, Artem Bityutskiy wrote: On Mon, 2012-01-30 at 23:58 +0100, Rafael J. Wysocki wrote: Thanks, but is anyone actually going to push it to Linus any time soon? I agree, but I am not the maintainer so cannot answer. David Woodhouse is aware of this, but I do not know when he gonna send the pull request. Well, the problem is being reported by more and more people, so I'd like to push the fix quickly. David, please let me know if you don't want me to include the $subject patch into the next PM fixes pull request. If I don't hear from you, I'll push it next week for -rc4. Thanks, Rafael -- 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] ARM: OMAP2+: PM: code consolidation for 3.4
Paul Walmsley p...@pwsan.com writes: Hi This series consolidates some duplicated PM code across OMAP2, 3, and 4. This saves both binary kernel image size, and lines of source. These functions are just the low-hanging fruit; it looks to me like there's even more consolidation that could be done. Suspend + UART wakeup was tested on OMAP44xx BeagleBoard. I assume you meant Panda board? On the OMAP35xx Beagleboard here, v3.3-rc2 doesn't seem to wake up from suspend correctly with or without these patches, so I've only boot-tested them on that platform. I also tested idle suspend + UART wakeup on 3430/n900, 3530/Overo. Will add these to my cleanup queue for v3.4[1] after adding a Tested-by from Santosh. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/cleanup/pm -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: Get rid of reset for system timer
Santosh Shilimkar santosh.shilim...@ti.com writes: From: Rajendra Nayak rna...@ti.com hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code. That is true for OMAP4, but have you verified if this is indeed a duplicate reset on OMAP2/3? 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] ARM: OMAP2+: PM: code consolidation for 3.4
On Thu, 2 Feb 2012, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: Suspend + UART wakeup was tested on OMAP44xx BeagleBoard. I assume you meant Panda board? Yep On the OMAP35xx Beagleboard here, v3.3-rc2 doesn't seem to wake up from suspend correctly with or without these patches, so I've only boot-tested them on that platform. I also tested idle suspend + UART wakeup on 3430/n900, 3530/Overo. Will add these to my cleanup queue for v3.4[1] after adding a Tested-by from Santosh. Great. Do you know what the deal is with suspend on 34xx? I enabled ttyO2 wakeup and entered suspend, but serial traffic doesn't bring it out? - 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 v9 01/25] gpio/omap: remove dependency on gpio_bank_count
Hi, On Thu, Feb 02, 2012 at 11:00:27PM +0530, Tarun Kanti DebBarma wrote: diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 0b05629..6ea7390 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -28,7 +28,10 @@ #include asm/gpio.h #include asm/mach/irq.h +static LIST_HEAD(omap_gpio_list); I guess it's now too late because patch is acked and everything, but I think if you make the driver handle one bank alone and just instantiate it multiple times (omap_gpio.0, omap_gpio.1, omap_gpio.3, etc) driver would be faar simpler. -- balbi signature.asc Description: Digital signature
Re: [PATCH 07/20] ARM: OMAP3+: SmartReflex: clear ERRCONFIG_VPBOUNDINTST only on a need
Jean Pihet jean.pi...@newoldbits.com writes: From: Nishanth Menon n...@ti.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit minor: this doesn't belong in the changelog. I will remove it locally. 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 v9 01/25] gpio/omap: remove dependency on gpio_bank_count
On Thu, Feb 02, 2012 at 08:41:07PM +0200, Felipe Balbi wrote: Hi, On Thu, Feb 02, 2012 at 11:00:27PM +0530, Tarun Kanti DebBarma wrote: diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 0b05629..6ea7390 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -28,7 +28,10 @@ #include asm/gpio.h #include asm/mach/irq.h +static LIST_HEAD(omap_gpio_list); I guess it's now too late because patch is acked and everything, but I think if you make the driver handle one bank alone and just instantiate it multiple times (omap_gpio.0, omap_gpio.1, omap_gpio.3, etc) driver would be faar simpler. Is there any shared state between the banks? On my very cursory glance it looked like banks still have some interaction between them. If not, then yes I agree that multiple instances would be better. g. -- 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 00/20] ARM: OMAP3+: SmartReflex: bugfixes
Jean Pihet jean.pi...@newoldbits.com writes: Integrate the latest SmartReflex bufixes from Felipe Balbi [1] and Nishant Menon [2], plus misc bugfixes. Based on latest master branch of the mainline git tree (3.3.0-rc1) [3], commit 27ba234c8dfe86c96675d4ef275d1d3c1f5f7053. [1] http://marc.info/?l=linux-omapm=132134699423547w=2 [2] https://github.com/nmenon/linux-omap-ti-pm/commits/linux-omap-3.0 [3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=shortlog Can you break this series up further? There is lots of stuff in this series that does not qualify as a fix or a cleanup. (specifically, all the ones starting with introduce...). We need to keep fixes and cleanups separate from new features. 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 v9 00/25] gpio/omap: driver cleanup and fixes
On Thu, Feb 02, 2012 at 11:00:26PM +0530, Tarun Kanti DebBarma wrote: The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab: Linus Torvalds (1): Linux 3.3-rc2 are available in the git repository at: http://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev Branch: for_3.4/gpio_cleanup_fixes_v9 Bad git url. I had to replace 'http:' with 'git:'. I've merged this series into my gpio/next branch. It should show up in linux-next in a couple of days. g. This series is continuation of cleanup of OMAP GPIO driver and fixes. The cleanup include getting rid of cpu_is_* checks wherever possible, use of gpio_bank list instead of static array, use of unique platform specific value associated data member to OMAP platforms to avoid cpu_is_* checks. The series also include PM runtime support. Power Tests a) OMAP3430SDP - Modify board-3430sdp.c file to have multiple GPIO modules active with debounce timeout enabled. - Enable CPU-Idle - Enable UART timeouts - Enable offmode - echo mem /sys/power/state - Verify retention and offmode count increment Used following patches to avoid exception during system suspend:- [PATCH RFC 1/2] mtd : Prevent the NULL pointer access [PATCH RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented # echo mem /sys/power/state [ 47.128021] PM: Syncing filesystems ... done. [ 47.144104] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 47.168243] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 47.205139] Unable to handle kernel NULL pointer dereference at virtual addre ss 00a0 [ 47.213317] pgd = deaac000 [ 47.216033] [00a0] *pgd=9e932831, *pte=, *ppte= [ 47.222381] Internal error: Oops: 17 [#1] SMP [ 47.226745] Modules linked in: [ 47.229827] CPU: 0Not tainted (3.3.0-rc2-00031-g12c5c5c #235) [ 47.236022] PC is at mtd_cls_suspend+0x8/0x20 [ 47.240386] LR is at mtd_cls_suspend+0x8/0x20 [ 47.244750] pc : [c02e78f8]lr : [c02e78f8]psr: a013 [ 47.244750] sp : dea1fe60 ip : fp : c0ee7d40 [ 47.256256] r10: c0ee7cf0 r9 : r8 : c02e78f0 [ 47.261474] r7 : r6 : r5 : 0002 r4 : dea45800 [ 47.268005] r3 : deb4cac0 r2 : r1 : 0002 r0 : [ 47.274536] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 47.281677] Control: 10c5387d Table: 9eaac019 DAC: 0015 [ 47.287445] Process sh (pid: 1177, stack limit = 0xdea1e2f8) [ 47.293090] Stack: (0xdea1fe60 to 0xdea2) [...] b) ZOOM3 - Enable CPU-Idle - Enable UART timeout - echo mem /sys/power/state - Wakeup system using serial keyboard - Verify retention count increment Functional Tests - Done on OMAP2430, OMAP3430SDP, ZOOM3, OMAP4430 Bootup Test - Done on OMAP1710 Used following patch to fix OMAP1 build error:- [PATCH] i2c: OMAP: Fix OMAP1 build error v9: - Summary of Comments/Issues fixed * GPIO wakeup does not work * Call debounce clock enable/disable functions from PM runtime callbacks. This will avoid calling the functions from multiple places. * Modify description of following patch to match latest changes. gpio/omap: save and restore debounce registers. * Use (bank-regs-set_dataout bank-regs-clr_dataout) together instead of using only one of them. * Remove cpu_is_omap() checks from set_gpio_trigger(). * _gpio_dbck_enable() in runtime callback triggered from omap_gpio_request does not enable dbck because dbck_enable_mask is not set at this point. * Workaround associated with an errata got missed in v8. This has been included. v8: - Remove PM_CONFIG macro around following assignment. pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count; - Once pm_runtime is enabled there is no more need for calling the omap_device_disable_idle_on_suspend(od). - With pm_runtime, handling of clocks in Suspend is taken care of by powerdomain hooks. So remove usage of *_runtime_put/get* from suspend/resume hooks and Idle path. - Add handling of debounce clocks along the Suspend and Idle paths. - Remove [PATCH 04/24] gpio/omap: fix pwrdm_post_transition call sequence from this series. This will be merged as part of power cleanup series. - Remove [PATCH v7 20/26] gpio/omap: skip operations in runtime callbacks The bank-mod_usage check in this patch is not needed any more because they are now already being taken care in suspend/resume and Idle paths. - Remove [PATCH v7 26/26] gpio/omap: add dbclk aliases for all gpio modules This is already taken care in hwmod. - Remove redundant blank
Re: [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count
On Thu, Feb 02, 2012 at 12:16:30PM -0700, Grant Likely wrote: On Thu, Feb 02, 2012 at 08:41:07PM +0200, Felipe Balbi wrote: Hi, On Thu, Feb 02, 2012 at 11:00:27PM +0530, Tarun Kanti DebBarma wrote: diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 0b05629..6ea7390 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -28,7 +28,10 @@ #include asm/gpio.h #include asm/mach/irq.h +static LIST_HEAD(omap_gpio_list); I guess it's now too late because patch is acked and everything, but I think if you make the driver handle one bank alone and just instantiate it multiple times (omap_gpio.0, omap_gpio.1, omap_gpio.3, etc) driver would be faar simpler. Is there any shared state between the banks? On my very cursory glance it looked like banks still have some interaction between them. If not, then yes I agree that multiple instances would be better. A quick glance at the TRM shows that banks have separate address spaces and IRQ lines. I think it's done this way because we can handoff one (or more) bank to other cores on the SoC, so they need to be pretty independent. I could be missing something though. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()
Hi Santosh On Thu, 2 Feb 2012, Shilimkar, Santosh wrote: On Thu, Feb 2, 2012 at 3:47 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, Feb 2, 2012 at 3:35 PM, Paul Walmsley p...@pwsan.com wrote: On Thu, 2 Feb 2012, Shilimkar, Santosh wrote: Yes, we do have issue with below APIs for OMAP4 and onwards design because of the PRCM change. pwrdm_clear_all_prev_pwrst pwrdm_*_mem_* There use to be a single power state and memory state register till OMAP3 at power domain level which can give you the logic and memory last test which is needed for OSWR. On OMAP4, we have registers per modules and it becomes difficult to model this difference in APIs. Initially we tried to fix that with [1] and then later realized that's not going to work on OMAP4 + devices because of mentioned issue. If the registers are per-module, it seems like the best place for those would be the hwmod layer. Do you think that makes sense? So, something like omap_hwmod_clear_all_prev_pwrst(), etc.? Seems like that should be pretty efficient. But all these are power domain registers after all. Rajendra did one version of pwrdm_clear_all_prev_pwrst API and inside used hwmod. But then there he has iterate over all the modules belongs to that power domain. And if you use hwmod or omap_device kind of API, then you need to build those devices in init or some where. All of that was not looking so elegant and hence the other path was chosen. The mess is, the registers are still part of power domains though they are specific to module. And Fundamentally power domain is stil the central entity decides the fate of all the modules within that PD, in terms of context loss/ret etc. I looked at the MPUSS file. There are 3 functions which access power domain registers directly. - mpuss_clear_prev_logic_pwrst - cpu_clear_prev_logic_pwrst - omap4_mpuss_read_prev_context_state All of these functions access the context registers which we don't have support today at power domian APIs for mentioned issue. This file is using power domain APIs in all possible scenario's except the OSWR scenario which needs the context register accesses. if the context clear and read can be handled part of PD APIs, then we can certainly kill this functions. That sounds great. Maybe we can add powerdomain functions for these purposes that take both a powerdomain pointer and a hwmod pointer. That should hopefully work. - Paul
Re: patch tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
Hi Greg, On Thu, 26 Jan 2012, Paul Walmsley wrote: On Thu, 26 Jan 2012, Greg KH wrote: Ok, I've just reverted both of these patches for now, please send new ones when you have them. Thanks. A pull request is at the bottom of this message. The patches are also available from the mailing list archives here: http://marc.info/?l=linux-arm-kernelm=132754676014389w=2 http://marc.info/?l=linux-arm-kernelm=132754677914395w=2 http://marc.info/?l=linux-arm-kernelm=132754676014388w=2 Any comments on these? - Paul - Paul The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: Linux 3.3-rc1 (2012-01-19 15:04:48 -0800) are available in the git repository at: git://git.pwsan.com/linux-2.6 omap_serial_fixes_3.3rc Paul Walmsley (3): tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode tty: serial: OMAP: block idle while the UART is transferring data in PIO mode tty: serial: OMAP: wakeup latency constraint is in microseconds, not milliseconds arch/arm/mach-omap2/serial.c |8 drivers/tty/serial/omap-serial.c | 30 +- 2 files changed, 29 insertions(+), 9 deletions(-) - 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 RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented
On Thu, Feb 02, 2012 at 07:40:26PM +0100, Rafael J. Wysocki wrote: On Thursday, February 02, 2012, Artem Bityutskiy wrote: On Mon, 2012-01-30 at 23:58 +0100, Rafael J. Wysocki wrote: Thanks, but is anyone actually going to push it to Linus any time soon? I agree, but I am not the maintainer so cannot answer. David Woodhouse is aware of this, but I do not know when he gonna send the pull request. Well, the problem is being reported by more and more people, so I'd like to push the fix quickly. David, please let me know if you don't want me to include the $subject patch into the next PM fixes pull request. If I don't hear from you, I'll push it next week for -rc4. I too have it in my tree as a patch which Artem sent me, as it's rather fundamental to not oopsing the kernel when you suspend/resume on any ARM platform. -- 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] ARM: OMAP2+: PM: code consolidation for 3.4
On Thu, 2 Feb 2012, Paul Walmsley wrote: Great. Do you know what the deal is with suspend on 34xx? I enabled ttyO2 wakeup and entered suspend, but serial traffic doesn't bring it out? Just a quick followup; Kevin tracked this down. v3.3-rc needs the MTD suspend patch that Artem posted recently to suspend correctly on OMAP35xx BeagleBoard with omap2plus_defconfig. Thanks Kevin. - 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 RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented
On Thursday, February 02, 2012, Russell King - ARM Linux wrote: On Thu, Feb 02, 2012 at 07:40:26PM +0100, Rafael J. Wysocki wrote: On Thursday, February 02, 2012, Artem Bityutskiy wrote: On Mon, 2012-01-30 at 23:58 +0100, Rafael J. Wysocki wrote: Thanks, but is anyone actually going to push it to Linus any time soon? I agree, but I am not the maintainer so cannot answer. David Woodhouse is aware of this, but I do not know when he gonna send the pull request. Well, the problem is being reported by more and more people, so I'd like to push the fix quickly. David, please let me know if you don't want me to include the $subject patch into the next PM fixes pull request. If I don't hear from you, I'll push it next week for -rc4. I too have it in my tree as a patch which Artem sent me, as it's rather fundamental to not oopsing the kernel when you suspend/resume on any ARM platform. It actually affects everyone using MTD and suspend (not only ARM) and that's why I thought I'd take it, but I'm fine with any other resolution as long as the patch goes to Linus before 3.3-final. Thanks, Rafael -- 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 tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
On Thu, Feb 02, 2012 at 01:03:01PM -0700, Paul Walmsley wrote: Hi Greg, On Thu, 26 Jan 2012, Paul Walmsley wrote: On Thu, 26 Jan 2012, Greg KH wrote: Ok, I've just reverted both of these patches for now, please send new ones when you have them. Thanks. A pull request is at the bottom of this message. The patches are also available from the mailing list archives here: http://marc.info/?l=linux-arm-kernelm=132754676014389w=2 http://marc.info/?l=linux-arm-kernelm=132754677914395w=2 http://marc.info/?l=linux-arm-kernelm=132754676014388w=2 Any comments on these? They are in my to-apply queue, I'm getting to them... greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count
On 2/2/2012 8:45 PM, Felipe Balbi wrote:
On Thu, Feb 02, 2012 at 12:16:30PM -0700, Grant Likely wrote:
On Thu, Feb 02, 2012 at 08:41:07PM +0200, Felipe Balbi wrote:
Hi,
On Thu, Feb 02, 2012 at 11:00:27PM +0530, Tarun Kanti DebBarma wrote:
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0b05629..6ea7390 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -28,7 +28,10 @@
#includeasm/gpio.h
#includeasm/mach/irq.h
+static LIST_HEAD(omap_gpio_list);
I guess it's now too late because patch is acked and everything, but I
think if you make the driver handle one bank alone and just instantiate
it multiple times (omap_gpio.0, omap_gpio.1, omap_gpio.3, etc) driver
would be faar simpler.
Is there any shared state between the banks? On my very cursory glance it
looked like banks still have some interaction between them. If not, then
yes I agree that multiple instances would be better.
A quick glance at the TRM shows that banks have separate address spaces
and IRQ lines. I think it's done this way because we can handoff one (or
more) bank to other cores on the SoC, so they need to be pretty
independent.
I could be missing something though.
In fact the driver already handled the 6 GPIOS banks as individual devices:
[0.185638] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[0.185882] OMAP GPIO hardware version 0.1
[0.186767] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[0.187744] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[0.188751] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[0.189819] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[0.190917] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
That list is only used to iterate over all the instances during CPU idle:
void omap2_gpio_prepare_for_idle(int pwr_mode)
{
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
if (!bank-mod_usage || !bank-loses_context)
continue;
bank-power_mode = pwr_mode;
pm_runtime_put_sync_suspend(bank-dev);
}
}
void omap2_gpio_resume_after_idle(void)
{
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
if (!bank-mod_usage || !bank-loses_context)
continue;
pm_runtime_get_sync(bank-dev);
}
}
I don't know if there is some reason to not use driver_for_each_device.
Kevin,
Do we have any constraint inside omap_sram_idle to not use the device
iterator?
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patch tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
On Thu, Jan 26, 2012 at 12:34:50PM -0700, Paul Walmsley wrote: On Thu, 26 Jan 2012, Greg KH wrote: Ok, I've just reverted both of these patches for now, please send new ones when you have them. Thanks. A pull request is at the bottom of this message. The patches are also available from the mailing list archives here: http://marc.info/?l=linux-arm-kernelm=132754676014389w=2 http://marc.info/?l=linux-arm-kernelm=132754677914395w=2 http://marc.info/?l=linux-arm-kernelm=132754676014388w=2 Now applied. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count
Hi,
On Thu, Feb 02, 2012 at 09:48:13PM +0100, Cousson, Benoit wrote:
On 2/2/2012 8:45 PM, Felipe Balbi wrote:
On Thu, Feb 02, 2012 at 12:16:30PM -0700, Grant Likely wrote:
On Thu, Feb 02, 2012 at 08:41:07PM +0200, Felipe Balbi wrote:
Hi,
On Thu, Feb 02, 2012 at 11:00:27PM +0530, Tarun Kanti DebBarma wrote:
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0b05629..6ea7390 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -28,7 +28,10 @@
#includeasm/gpio.h
#includeasm/mach/irq.h
+static LIST_HEAD(omap_gpio_list);
I guess it's now too late because patch is acked and everything, but I
think if you make the driver handle one bank alone and just instantiate
it multiple times (omap_gpio.0, omap_gpio.1, omap_gpio.3, etc) driver
would be faar simpler.
Is there any shared state between the banks? On my very cursory glance it
looked like banks still have some interaction between them. If not, then
yes I agree that multiple instances would be better.
A quick glance at the TRM shows that banks have separate address spaces
and IRQ lines. I think it's done this way because we can handoff one (or
more) bank to other cores on the SoC, so they need to be pretty
independent.
I could be missing something though.
In fact the driver already handled the 6 GPIOS banks as individual devices:
[0.185638] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[0.185882] OMAP GPIO hardware version 0.1
[0.186767] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[0.187744] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[0.188751] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[0.189819] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[0.190917] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
yeah, but you can get all of that for free from driver core. Just add
one platform_device for each bank and make the omap-gpio.c only
understand one bank. No tricks.
What I'm trying to say is to remove the Bank array or list_head and make
probe() get called 6 times by creating 6 omap_gpio platform_devices.
From probe you cann gpiochip_add() once and only once.
That list is only used to iterate over all the instances during CPU idle:
void omap2_gpio_prepare_for_idle(int pwr_mode)
{
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
if (!bank-mod_usage || !bank-loses_context)
continue;
bank-power_mode = pwr_mode;
pm_runtime_put_sync_suspend(bank-dev);
}
}
void omap2_gpio_resume_after_idle(void)
{
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
if (!bank-mod_usage || !bank-loses_context)
continue;
pm_runtime_get_sync(bank-dev);
}
}
that's the thing which is unnecessary, actually :-)
Why do we even have this omap2_gpio_resume_after_idle() ? Can't the gpio
driver handle its own PM or listen to cpuidle notificaitons for that ?
I would like to understand why do we need this hack for pm runtime.
Can't you just use -prepare() and -complete() from dev_pm_ops ?
I don't know if there is some reason to not use driver_for_each_device.
driver_for_each_device() is already handled by driver core. So your
omap_device_build() would have a loop creating N omap_devices, one for
each gpio bank. Each bank would receive one IRQ line and one address
base. And they would only understand that. Every instance of the driver
handles the GPIOs connected on one bank.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count
Hi again,
On Thu, Feb 02, 2012 at 11:49:08PM +0200, Felipe Balbi wrote:
In fact the driver already handled the 6 GPIOS banks as individual devices:
[0.185638] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[0.185882] OMAP GPIO hardware version 0.1
[0.186767] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[0.187744] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[0.188751] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[0.189819] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[0.190917] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
yeah, but you can get all of that for free from driver core. Just add
one platform_device for each bank and make the omap-gpio.c only
understand one bank. No tricks.
What I'm trying to say is to remove the Bank array or list_head and make
probe() get called 6 times by creating 6 omap_gpio platform_devices.
From probe you cann gpiochip_add() once and only once.
call
I actually just took the time to go over the driver and that's what it
does. So the list_head is only there fo the nasty cpuidle stuff below:
That list is only used to iterate over all the instances during CPU idle:
void omap2_gpio_prepare_for_idle(int pwr_mode)
{
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
if (!bank-mod_usage || !bank-loses_context)
continue;
bank-power_mode = pwr_mode;
pm_runtime_put_sync_suspend(bank-dev);
}
}
void omap2_gpio_resume_after_idle(void)
{
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
if (!bank-mod_usage || !bank-loses_context)
continue;
pm_runtime_get_sync(bank-dev);
}
}
that's the thing which is unnecessary, actually :-)
Why do we even have this omap2_gpio_resume_after_idle() ? Can't the gpio
driver handle its own PM or listen to cpuidle notificaitons for that ?
I would like to understand why do we need this hack for pm runtime.
Can't you just use -prepare() and -complete() from dev_pm_ops ?
This question remains. Why do we need those funtions ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count
On 2/2/2012 10:53 PM, Felipe Balbi wrote:
Hi again,
On Thu, Feb 02, 2012 at 11:49:08PM +0200, Felipe Balbi wrote:
In fact the driver already handled the 6 GPIOS banks as individual devices:
[0.185638] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[0.185882] OMAP GPIO hardware version 0.1
[0.186767] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[0.187744] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[0.188751] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[0.189819] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[0.190917] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
yeah, but you can get all of that for free from driver core. Just add
one platform_device for each bank and make the omap-gpio.c only
understand one bank. No tricks.
What I'm trying to say is to remove the Bank array or list_head and make
probe() get called 6 times by creating 6 omap_gpio platform_devices.
From probe you cann gpiochip_add() once and only once.
call
I actually just took the time to go over the driver and that's what it
does. So the list_head is only there fo the nasty cpuidle stuff below:
Yes, that was my point :-)
That list is only used to iterate over all the instances during CPU idle:
void omap2_gpio_prepare_for_idle(int pwr_mode)
{
struct gpio_bank *bank;
list_for_each_entry(bank,omap_gpio_list, node) {
if (!bank-mod_usage || !bank-loses_context)
continue;
bank-power_mode = pwr_mode;
pm_runtime_put_sync_suspend(bank-dev);
}
}
void omap2_gpio_resume_after_idle(void)
{
struct gpio_bank *bank;
list_for_each_entry(bank,omap_gpio_list, node) {
if (!bank-mod_usage || !bank-loses_context)
continue;
pm_runtime_get_sync(bank-dev);
}
}
that's the thing which is unnecessary, actually :-)
Why do we even have this omap2_gpio_resume_after_idle() ? Can't the gpio
driver handle its own PM or listen to cpuidle notificaitons for that ?
I would like to understand why do we need this hack for pm runtime.
Can't you just use -prepare() and -complete() from dev_pm_ops ?
This question remains. Why do we need those funtions ?
These functions are called from the CPUIdle path so outside the scope of
the GPIO driver. These are part of a bunch of nasty PM hacks we are
doing in the CPU idle loop. We are in the process of getting rid of most
of them, but it looks like some are still needed.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 01/25] gpio/omap: remove dependency on gpio_bank_count
Hi,
On Thu, Feb 02, 2012 at 11:00:43PM +0100, Cousson, Benoit wrote:
On 2/2/2012 10:53 PM, Felipe Balbi wrote:
Hi again,
On Thu, Feb 02, 2012 at 11:49:08PM +0200, Felipe Balbi wrote:
In fact the driver already handled the 6 GPIOS banks as individual devices:
[0.185638] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[0.185882] OMAP GPIO hardware version 0.1
[0.186767] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[0.187744] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[0.188751] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[0.189819] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[0.190917] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
yeah, but you can get all of that for free from driver core. Just add
one platform_device for each bank and make the omap-gpio.c only
understand one bank. No tricks.
What I'm trying to say is to remove the Bank array or list_head and make
probe() get called 6 times by creating 6 omap_gpio platform_devices.
From probe you cann gpiochip_add() once and only once.
call
I actually just took the time to go over the driver and that's what it
does. So the list_head is only there fo the nasty cpuidle stuff below:
Yes, that was my point :-)
:-) my bad
That list is only used to iterate over all the instances during CPU idle:
void omap2_gpio_prepare_for_idle(int pwr_mode)
{
struct gpio_bank *bank;
list_for_each_entry(bank,omap_gpio_list, node) {
if (!bank-mod_usage || !bank-loses_context)
continue;
bank-power_mode = pwr_mode;
pm_runtime_put_sync_suspend(bank-dev);
}
}
void omap2_gpio_resume_after_idle(void)
{
struct gpio_bank *bank;
list_for_each_entry(bank,omap_gpio_list, node) {
if (!bank-mod_usage || !bank-loses_context)
continue;
pm_runtime_get_sync(bank-dev);
}
}
that's the thing which is unnecessary, actually :-)
Why do we even have this omap2_gpio_resume_after_idle() ? Can't the gpio
driver handle its own PM or listen to cpuidle notificaitons for that ?
I would like to understand why do we need this hack for pm runtime.
Can't you just use -prepare() and -complete() from dev_pm_ops ?
This question remains. Why do we need those funtions ?
These functions are called from the CPUIdle path so outside the scope
of the GPIO driver. These are part of a bunch of nasty PM hacks we
are doing in the CPU idle loop. We are in the process of getting rid
of most of them, but it looks like some are still needed.
Too bad. I can see that the gpio pm implementation seems a bit
peculiar. I mean, pm does reference counting and yet the driver has
checks to prevent multiple gets and puts on a single bank (meaning that
pm counter will be either 0 or 1 at any point in time).
To me it looks like those functions are there in order to forcefully put
PER power domain in OFF because drivers are always holding a reference
to their gpios (drivers generally gpio_request() on probe() and
gpio_free() on remove()).
Looks like the entire pm implementation on OMAP gpio driver has always
considered only the fact that gpios can be requested and freed, but
never that we want the system to go to OFF even while gpios are
requested, because we have I/O PAD wakeups. At some point that has to be
sorted out because that HACK is quite ugly :-)
I'll see if I find some time to go over the interactions between
gpio-omap.c and pm24x.c and pm34xx.c any of these days, but I can't
promise anything ;-)
--
balbi
signature.asc
Description: Digital signature
