Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: 2010/6/1 Thomas Gleixner t...@linutronix.de: On Mon, 31 May 2010, Arve Hjønnevåg wrote: On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 31 May 2010, James Bottomley wrote: For MSM hardware, it looks possible to unify the S and C states by doing suspend to ram from idle but I'm not sure how much work that is. On ARM, it's not rocket science and we have in tree support for this already (OMAP). I have done the same thing on a Samsung part as a prove of concept two years ago and it's really easy as the hardware is sane. Hint: It's designed for mobile devices :) We already enter the same power state from idle and suspend on msm. In the absence of misbehaving apps, the difference in power consumption is entirely caused by periodic timers in the user-space framework _and_ kernel. It only takes a few timers triggering per second (I think 3 if they do no work) to double the average power consumption on the G1 if the radio is off. We originally added wakelocks because the hardware we had at the time had much lower power consumption in suspend then idle, but we still use suspend because it saves power. So how do you differentiate between timers which _should_ fire and those you do not care about ? Only alarms are allowed to fire while suspended. We have mechanisms in place to defer timers so the wakeups are minimized. If that's not enough we need to revisit. Deferring the the timers forever without stopping the clock can cause problems. Our user space code has a lot of timeouts that will trigger an error if an app does not respond in time. Freezing everything and stopping the clock while suspended is a lot simpler than trying to stop individual timers and processes from running. And resume updates timekeeping to account for the slept time. So the only way to get away with that is to sleep under a second or just ignoring the update by avoiding the access to rtc. So how do you keep timekeeping happy ? Thanks, tglx
Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown ne...@suse.de wrote:
On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
On Tue, 1 Jun 2010, Neil Brown wrote:
I think you have acknowledged that there is a race with suspend - thanks.
Next step was can it be closed.
You seem to suggest that it can, but you describe it as a work around
rather than a bug fix...
Do you agree that the race is a bug, and therefore it is appropriate to
fix it assuming an acceptable fix can be found (which I think it can)?
If we can fix it, yes we definitely should do and not work around it.
Thanks,
tglx
OK.
Here is my suggestion.
While I think this patch would actually work, and hope the ugly aspects are
reasonably balanced by the simplicity, I present it primarily as a base for
improvement.
The important part is to present how drivers and user-space can co-operate
to avoid losing wake-events. The details of what happens in the kernel are
certainly up for discussion (as is everything else really of course).
The user-space suspend daemon avoids losing wake-events by using
fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event
is ready to be read by user-space. This may involve:
- the one daemon processing all wake events
Wake up events are not all processed by one daemon.
- Both the suspend daemon and the main event handling daemon opening any
given device that delivers wake events (this should work with input
events ... unless grabbing is needed)
Not all wakeup events are broadcast like input events so they cannot
be read by both daemons. Not that this really matters, since reading
the event from the suspend daemon does not mean that it has been
delivered to and processed by the other daemon.
- The event handling daemon giving the suspend-daemon's pid as F_OWNER, and
using poll/select to get the events itself.
I don't like the idea of using signals for this. Without the hack Alan
Stern suggested, you will temporarily block suspend if the wakeup
event happened before the suspend daemon thread made it to the kernel,
but abort suspend if it happened right after.
When 'mem' is written to /sys/power/state, suspend_prepare waits in an
interruptible wait until any wake-event that might have been initiated before
the suspend was request, has had a chance to be queued for user-space and
trigger kill_fasync.
And what happens if you are not waiting when this happens?
Currently this wait is a configurable time after the last wake-event was
initiated. This is hackish, but simple and probably adequate.
Waiting after a wake event is the same as suspend_block_timeout. This
is useful when passing events through layers of code that does no
block suspend, but we should strive to avoid it. Other people had much
stronger objections to this, which is why it is not included in the
last suspend blocker patchset.
It also does not work for drivers that need to block suspend for more
than a few seconds. For instance the gpio keypad matrix driver needs
to block suspend while keys are pressed so it can scan the keypad.
If more precise timing is needed and achievable, that can be added later. It
would be an entirely internal change and would not affect the API further.
Some of the code developed for suspend-blockers might be a starting point for
this.
Drivers should call pm_suspend_delay() whenever a wake-event occurs. This
simply records the time so that the suspend process knows if there is in fact
any need to wait at all.
The delay to wait after the last pm_suspend_delay() is limited to 10 seconds
and can be set by kernel parameter suspend_block_delay=number-of-milliseconds
It defaults to 2 jiffies (which is possibly too short).
- Would this fix the bug??
- and address the issues that suspend-blockers was created to address?
- or are the requirements on user-space too onerous?
Thanks,
NeilBrown
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 5e781d8..ccbadd0 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -142,11 +142,13 @@ extern void arch_suspend_disable_irqs(void);
extern void arch_suspend_enable_irqs(void);
extern int pm_suspend(suspend_state_t state);
+extern void pm_suspend_delay(void);
#else /* !CONFIG_SUSPEND */
#define suspend_valid_only_mem NULL
static inline void suspend_set_ops(struct platform_suspend_ops *ops) {}
static inline int pm_suspend(suspend_state_t state) { return -ENOSYS; }
+static inlint void pm_suspend_delay(void) {}
#endif /* !CONFIG_SUSPEND */
/* struct pbe is used for creating lists of pages that should be restored
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 56e7dbb..07897b9 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -46,6 +46,69 @@ bool valid_state(suspend_state_t state)
return suspend_ops
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Thomas Gleixner t...@linutronix.de: On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: 2010/6/1 Thomas Gleixner t...@linutronix.de: On Mon, 31 May 2010, Arve Hjønnevåg wrote: On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 31 May 2010, James Bottomley wrote: For MSM hardware, it looks possible to unify the S and C states by doing suspend to ram from idle but I'm not sure how much work that is. On ARM, it's not rocket science and we have in tree support for this already (OMAP). I have done the same thing on a Samsung part as a prove of concept two years ago and it's really easy as the hardware is sane. Hint: It's designed for mobile devices :) We already enter the same power state from idle and suspend on msm. In the absence of misbehaving apps, the difference in power consumption is entirely caused by periodic timers in the user-space framework _and_ kernel. It only takes a few timers triggering per second (I think 3 if they do no work) to double the average power consumption on the G1 if the radio is off. We originally added wakelocks because the hardware we had at the time had much lower power consumption in suspend then idle, but we still use suspend because it saves power. So how do you differentiate between timers which _should_ fire and those you do not care about ? Only alarms are allowed to fire while suspended. We have mechanisms in place to defer timers so the wakeups are minimized. If that's not enough we need to revisit. Deferring the the timers forever without stopping the clock can cause problems. Our user space code has a lot of timeouts that will trigger an error if an app does not respond in time. Freezing everything and stopping the clock while suspended is a lot simpler than trying to stop individual timers and processes from running. And resume updates timekeeping to account for the slept time. So the No, for the monotonic clock it does the opposite. The hardware clock is read on resume and the offset is set so the monotonic clock gets the same value as it had when suspend was called. only way to get away with that is to sleep under a second or just ignoring the update by avoiding the access to rtc. So how do you keep timekeeping happy ? -- Arve Hjønnevå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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: 2010/6/2 Thomas Gleixner t...@linutronix.de: On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: Deferring the the timers forever without stopping the clock can cause problems. Our user space code has a lot of timeouts that will trigger an error if an app does not respond in time. Freezing everything and stopping the clock while suspended is a lot simpler than trying to stop individual timers and processes from running. And resume updates timekeeping to account for the slept time. So the No, for the monotonic clock it does the opposite. The hardware clock is read on resume and the offset is set so the monotonic clock gets the same value as it had when suspend was called. Grr, yes. Misread the code. -ENOTENOUGHCOFFEE Thanks, tglx
[GIT PULL] omap iommu: fixes for 2.6.35-rc1
Hi Tony, Patches only for fixes for omap iommu module during -rc cycle. The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://gitorious.org/~doyu/lk/mainline.git v2.6.35-rc1-iommu-fixes Hiroshi DOYU (1): omap iommu: Make omap-iommu.o built-in Kanigeri, Hari (1): omap iommu: update ducati mmu irq define name Satish (1): omap iommu: Fix Memory leak arch/arm/mach-omap2/Makefile |5 - arch/arm/mach-omap2/omap-iommu.c |2 +- arch/arm/plat-omap/iovmm.c |4 +++- 3 files changed, 8 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Ads7846 breaks suspend-to-ram on 3430SDP
Dmitry Torokhov wrote: Hi Anand, On Fri, May 14, 2010 at 02:26:40PM +0530, Gadiyar, Anand wrote: Looks like the ads7846 driver breaks suspend-to-ram at least on the OMAP 3430SDP. On a kernel built with the omap3_defconfig, with no_console_suspend, I see the log below. Will investigate some time next week, unless someone already has a fix. Could you please try 2.6.35-rc1 - I expect Kevin's fix to handle regulatore registering failure will take care of this oops. Thanks for the tip. I don't see the crash with 2.6.35-rc1. But I still cannot get the console back after a suspend. I don't think this is related to the ads7846 driver any more. - Anand # echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.01 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. PM: suspend of devices complete after 108.439 msecs PM: late suspend of devices complete after 0.274 msecs Class driver suspend failed for cpu0 PM: early resume of devices complete after 0.122 msecs -- 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] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 00:05:14 -0700 Arve Hjønnevåg a...@android.com wrote: On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown ne...@suse.de wrote: On Tue, 1 Jun 2010 12:50:01 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Tue, 1 Jun 2010, Neil Brown wrote: I think you have acknowledged that there is a race with suspend - thanks. Next step was can it be closed. You seem to suggest that it can, but you describe it as a work around rather than a bug fix... Do you agree that the race is a bug, and therefore it is appropriate to fix it assuming an acceptable fix can be found (which I think it can)? If we can fix it, yes we definitely should do and not work around it. Thanks, tglx OK. Here is my suggestion. While I think this patch would actually work, and hope the ugly aspects are reasonably balanced by the simplicity, I present it primarily as a base for improvement. The important part is to present how drivers and user-space can co-operate to avoid losing wake-events. The details of what happens in the kernel are certainly up for discussion (as is everything else really of course). The user-space suspend daemon avoids losing wake-events by using fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event is ready to be read by user-space. This may involve: - the one daemon processing all wake events Wake up events are not all processed by one daemon. Not with your current user-space code, no. Are you saying that you are not open to any significant change in the Android user-space code? That would make the situation a lot harder to resolve. - Both the suspend daemon and the main event handling daemon opening any given device that delivers wake events (this should work with input events ... unless grabbing is needed) Not all wakeup events are broadcast like input events so they cannot be read by both daemons. Not that this really matters, since reading the event from the suspend daemon does not mean that it has been delivered to and processed by the other daemon. There would still need to be some sort of communication between the the suspend daemon on any event daemon to ensure that the events had been processed. This could be very light weight interaction. The point though is that with this patch it becomes possible to avoid races. Possible is better than impossible. - The event handling daemon giving the suspend-daemon's pid as F_OWNER, and using poll/select to get the events itself. I don't like the idea of using signals for this. Without the hack Alan Stern suggested, you will temporarily block suspend if the wakeup event happened before the suspend daemon thread made it to the kernel, but abort suspend if it happened right after. I'm not sure why that difference matters. But I'm also not sure that it is true. When any wakeup event happen, a signal will be delivered to the suspend daemon. This will interrupt a pending suspend request, or a sleep, or whatever else the daemon is doing. It can then go back to waiting for a good time to suspend, and then try to suspend again. When 'mem' is written to /sys/power/state, suspend_prepare waits in an interruptible wait until any wake-event that might have been initiated before the suspend was request, has had a chance to be queued for user-space and trigger kill_fasync. And what happens if you are not waiting when this happens? I'm not sure I understand the question. Could you explain it please? Either the initial event happens late enough to abort/resume the suspend, or the signal happens early enough to abort the suspend, or alert the daemon not to do a suspend. Either way we don't get stuck in suspend. Currently this wait is a configurable time after the last wake-event was initiated. This is hackish, but simple and probably adequate. Waiting after a wake event is the same as suspend_block_timeout. This is useful when passing events through layers of code that does no block suspend, but we should strive to avoid it. Other people had much stronger objections to this, which is why it is not included in the last suspend blocker patchset. Absolutely agree. The idea of of waiting was just a simple way to present code that actually could work. There are doubtlessly better ways and I assume they have been implemented in the suspend-blocker code. We just need some way to wait for the suspend-block count to reach zero, with some confidence that this amount of time is limited. (though to be honest ... the incredible simplicity of waiting a little while is very compelling :-)) It also does not work for drivers that need to block suspend for more than a few seconds. For instance the gpio keypad matrix driver needs to block suspend while keys are pressed so it can scan the keypad. I cannot imagine why it would take multiple seconds to scan a keypad. Can you explain
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: 2010/6/1 Thomas Gleixner t...@linutronix.de: On Mon, 31 May 2010, Arve Hjønnevåg wrote: 2010/5/31 Rafael J. Wysocki r...@sisk.pl: On Monday 31 May 2010, Arve Hjønnevåg wrote: 2010/5/30 Rafael J. Wysocki r...@sisk.pl: ... I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle? Assume for a while that you don't use suspend blockers, OK? I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers. It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle. And why should you miss a wakeup there ? If you get an interrupt in the transition, then you are not longer idle. Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore. You still are addicted to the current suspend mechanism. :) The whole point of doing it from idle in the form of a deep power state is to avoid the massive sh*tload of work which is neccesary to run the existing suspend code. But that needs runtime power management and tweaks to avoid your timers waking you, etc. The mechanism you want to use is: suspend no matter what, like closing the lid of the laptop, but with a few tweaks around it: 1) An interrupt on a wakeup source which comes in while the suspend code runs, i.e before you transitioned into wakeup mode, must abort / prevent suspend. 2) Prevent another attempt to suspend before the event has been delivered and the apps have signaled that they have not longer any work to do. As a side effect you confine crappy apps with that mechanism in some way. In the laptop case we do not want the tweaks as not going into suspend might set your backpack on fire. If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to: 1) crappy applications keeping the cpu away from idle 2) timers firing Would solving those two issues be sufficient for you or am I missing something ? Thanks, tglx
Re: [RFC] [PATCH v3 2/4] OMAP4: Keyboard device registration
On Mon, 31 May 2010 16:44:52 -0500
Arce, Abraham x0066...@ti.com wrote:
+ unsigned int length = 0, id = 0;
+ int hw_mod_name_len = 16;
+ char oh_name[hw_mod_name_len];
+ char *name = omap4-keypad;
+
+ length = snprintf(oh_name, hw_mod_name_len, kbd);
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -EIO;
+ }
Maybe I'm missing something here, but I don't see where length is
being used, and why the snprintf()/oh_name thing is needed. What about:
unsigned int id = 0;
char *name = omap4-keypad;
oh = omap_hwmod_lookup(kbd);
if (!oh) {
pr_err(Could not look up kbd\n);
return -EIO;
}
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 18:06:14 +1000 Neil Brown ne...@suse.de wrote: I cannot imagine why it would take multiple seconds to scan a keypad. Can you explain that? Do you mean while keys are held pressed? Maybe you don't get a wake-up event on key-release? In that case your user-space daemon could block suspend while there are any pressed keys confused. IIRC, the device sends interrupts only for first key-down and last key-up. To detect simultaneous key-presses you must actively scan it after the first key-down. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Thomas Gleixner t...@linutronix.de: On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: 2010/6/1 Thomas Gleixner t...@linutronix.de: On Mon, 31 May 2010, Arve Hjønnevåg wrote: 2010/5/31 Rafael J. Wysocki r...@sisk.pl: On Monday 31 May 2010, Arve Hjønnevåg wrote: 2010/5/30 Rafael J. Wysocki r...@sisk.pl: ... I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle? Assume for a while that you don't use suspend blockers, OK? I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers. It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle. And why should you miss a wakeup there ? If you get an interrupt in the transition, then you are not longer idle. Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore. You still are addicted to the current suspend mechanism. :) No I want you to stop confusing low power idle modes with suspend. I know how to enter low power modes from idle if that low power mode is not too disruptive. The whole point of doing it from idle in the form of a deep power state is to avoid the massive sh*tload of work which is neccesary to run the existing suspend code. But that needs runtime power management and tweaks to avoid your timers waking you, etc. The mechanism you want to use is: suspend no matter what, like closing the lid of the laptop, but with a few tweaks around it: 1) An interrupt on a wakeup source which comes in while the suspend code runs, i.e before you transitioned into wakeup mode, must abort / prevent suspend. 2) Prevent another attempt to suspend before the event has been delivered and the apps have signaled that they have not longer any work to do. As a side effect you confine crappy apps with that mechanism in some way. In the laptop case we do not want the tweaks as not going into suspend might set your backpack on fire. If that is the case you should also disable the wakeup events. If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to: 1) crappy applications keeping the cpu away from idle 2) timers firing Would solving those two issues be sufficient for you or am I missing something ? Solving those two is enough for current android phones, but it may not be enough for other android devices. 1 is not solvable (meaning we cannot fix all apps), and 2 is difficult to fix since the periodic work is useful while the device is actually in use. One possible way to solve 2 is to allow timers on a not-idle clock. Unrelated to Android, I also want to use opportunistic suspend on my desktop. -- Arve Hjønnevå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 V2] misc : ROHM BH1780GLI Ambient light sensor Driver
- Original Message - From: Andrew Morton a...@linux-foundation.org To: Jonathan Cameron ker...@jic23.retrosnub.co.uk Cc: Hemanth V heman...@ti.com; linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org; Daniel Mack dan...@caiaq.de; Jonathan Cameron ji...@cam.ac.uk; Wolfram Sang w.s...@pengutronix.de Sent: Wednesday, June 02, 2010 2:24 AM Subject: Re: [PATCH V2] misc : ROHM BH1780GLI Ambient light sensor Driver On Tue, 01 Jun 2010 21:39:10 +0100 Jonathan Cameron ker...@jic23.retrosnub.co.uk wrote: It would be most useful if the changelog were to fully describe the proposed kernel-userspace interface. That's the most important part of the driver, because it's the only part we can never change. There is a desultory effort to maintain sysfs API descriptions under Documentation/ABI/. I'd have thought that it would be appropriate to document this driver's ABI in there. Agreed, but we get back to the debate of what we should standardise on. I'd suggest standardising on one of the existing drivers. That way we have two compliant drivers and only need to change (n-2) others. If we pick some new standard then we need to change (n) drivers. Currently this driver follows the same sysfs convention as supported by isl29003.c in drivers/misc. -- 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: [alsa-devel] [PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
Hi, On Tuesday 01 June 2010 14:18:19 Ujfalusi Peter (Nokia-D/Tampere) wrote: .. Liam if you are going to take the series, could you fix the patch names? I can also resend them if it is easier for you. --- Peter Ujfalusi (5): OMAP: McBSP: Function to query the FIFO size OMAP2: McBSP: Change the way how the FIFO is handled OMAP2: McBSP: Use the port's buffer_size when calculating tx delay These two are not for OMAP2, but OMAP3 I really don't know how it happened, that I left the OMAP2 there, since I have noticed it in the first RFC series.. ASoC: omap-mcbsp: Save, and use wlen for threshold configuration ASoC: omap-mcbsp: Place correct constraints for streams arch/arm/mach-omap2/mcbsp.c | 10 ++-- arch/arm/plat-omap/include/plat/mcbsp.h |2 + arch/arm/plat-omap/mcbsp.c | 51 ++- sound/soc/omap/omap-mcbsp.c | 113 --- 4 files changed, 129 insertions(+), 47 deletions(-) Thank you, 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote: If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to: 1) crappy applications keeping the cpu away from idle 2) timers firing Would solving those two issues be sufficient for you or am I missing something ? Aren't the container snapshot/resume people fighting the same set of problems here? -- 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] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Neil Brown ne...@suse.de: On Wed, 2 Jun 2010 00:05:14 -0700 Arve Hjønnevåg a...@android.com wrote: On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown ne...@suse.de wrote: On Tue, 1 Jun 2010 12:50:01 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Tue, 1 Jun 2010, Neil Brown wrote: I think you have acknowledged that there is a race with suspend - thanks. Next step was can it be closed. You seem to suggest that it can, but you describe it as a work around rather than a bug fix... Do you agree that the race is a bug, and therefore it is appropriate to fix it assuming an acceptable fix can be found (which I think it can)? If we can fix it, yes we definitely should do and not work around it. Thanks, tglx OK. Here is my suggestion. While I think this patch would actually work, and hope the ugly aspects are reasonably balanced by the simplicity, I present it primarily as a base for improvement. The important part is to present how drivers and user-space can co-operate to avoid losing wake-events. The details of what happens in the kernel are certainly up for discussion (as is everything else really of course). The user-space suspend daemon avoids losing wake-events by using fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event is ready to be read by user-space. This may involve: - the one daemon processing all wake events Wake up events are not all processed by one daemon. Not with your current user-space code, no. Are you saying that you are not open to any significant change in the Android user-space code? That would make the situation a lot harder to resolve. Some wakeup events like the an incoming phone may be handled by a vendor supplied daemon that I do not have the source code for. And, no I'm not open to a change that would require all wakeup events to go to a single process. - Both the suspend daemon and the main event handling daemon opening any given device that delivers wake events (this should work with input events ... unless grabbing is needed) Not all wakeup events are broadcast like input events so they cannot be read by both daemons. Not that this really matters, since reading the event from the suspend daemon does not mean that it has been delivered to and processed by the other daemon. There would still need to be some sort of communication between the the suspend daemon on any event daemon to ensure that the events had been processed. This could be very light weight interaction. The point though is that with this patch it becomes possible to avoid races. Possible is better than impossible. We already have a solution. I don't think rejecting our solution but merging a worse solution should be the goal. - The event handling daemon giving the suspend-daemon's pid as F_OWNER, and using poll/select to get the events itself. I don't like the idea of using signals for this. Without the hack Alan Stern suggested, you will temporarily block suspend if the wakeup event happened before the suspend daemon thread made it to the kernel, but abort suspend if it happened right after. I'm not sure why that difference matters. But I'm also not sure that it is true. When any wakeup event happen, a signal will be delivered to the suspend daemon. This will interrupt a pending suspend request, or a sleep, or whatever else the daemon is doing. It can then go back to waiting for a good time to suspend, and then try to suspend again. This is inferior to the solution that is in the android kernel and the suspend blocker patchset. Both suspend as soon as possible and do not require signal handlers that modify the argument to your kernel call. When 'mem' is written to /sys/power/state, suspend_prepare waits in an interruptible wait until any wake-event that might have been initiated before the suspend was request, has had a chance to be queued for user-space and trigger kill_fasync. And what happens if you are not waiting when this happens? I'm not sure I understand the question. Could you explain it please? If the thread is not already in the kernel how does your signal handler abort suspend. Either the initial event happens late enough to abort/resume the suspend, or the signal happens early enough to abort the suspend, or alert the daemon not to do a suspend. Either way we don't get stuck in suspend. Currently this wait is a configurable time after the last wake-event was initiated. This is hackish, but simple and probably adequate. Waiting after a wake event is the same as suspend_block_timeout. This is useful when passing events through layers of code that does no block suspend, but we should strive to avoid it. Other people had much stronger objections to this, which is why it is not included in the last suspend blocker patchset. Absolutely agree. The idea of of waiting
Re: [alsa-devel] [PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
On Wed, 2010-06-02 at 12:05 +0300, Peter Ujfalusi wrote: Hi, On Tuesday 01 June 2010 14:18:19 Ujfalusi Peter (Nokia-D/Tampere) wrote: .. Liam if you are going to take the series, could you fix the patch names? I can also resend them if it is easier for you. Peter, I think it's probably better if you can resend. Can you also append the Acks too. Tony, do we have your ack too ? Thanks Liam -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Thomas Gleixner t...@linutronix.de: On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: 2010/6/2 Thomas Gleixner t...@linutronix.de: On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore. You still are addicted to the current suspend mechanism. :) No I want you to stop confusing low power idle modes with suspend. I know how to enter low power modes from idle if that low power mode is not too disruptive. What prevents us from going into a disruptive mode from idle ? I don't see a reason - except crappy ACPI stuff, which I'm happy to ignore. What do you consider disruptive? Disabling active interrupts? Stopping the monotonic clock? If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to: 1) crappy applications keeping the cpu away from idle 2) timers firing Would solving those two issues be sufficient for you or am I missing something ? Solving those two is enough for current android phones, but it may not be enough for other android devices. In which way ? May not be enough is a pretty vague statement. They may not be based on hardware that can get to the same power mode from idle as suspend. This could be acpi based hardware, it could be like the hardware we started with that did not have regular timers that could run in the low power mode, or devices could loose their state in the lowest power mode. 1 is not solvable (meaning we cannot fix all apps), We can mitigate it with cgroups and confine crap there, i.e. force idle them. I think using suspend is much simpler. It avoids having to worry about dependencies between processes. and 2 is difficult to fix since the periodic work is useful while the device is actually in use. One possible way to solve 2 is to allow timers on a not-idle clock. That's what I had in mind. Unrelated to Android, I also want to use opportunistic suspend on my desktop. I expect that intel/amd fixing their stuff is going to happen way before we sprinkled suspend blockers over a full featured desktop distro. You do not need to sprinkle suspend blocker all over the distro for it to be useful. You can convert the existing auto-suspend code to use opportunistic suspend and all apps that don't use suspend blocker will behave as they do today while allowing apps to use suspend blockers to keep the system running after the auto-suspend timeout expired. -- Arve Hjønnevå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] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: 2010/6/2 Neil Brown ne...@suse.de: There would still need to be some sort of communication between the the suspend daemon on any event daemon to ensure that the events had been processed. This could be very light weight interaction. The point though is that with this patch it becomes possible to avoid races. Possible is better than impossible. We already have a solution. I don't think rejecting our solution but merging a worse solution should be the goal. That's not the goal at all. We want a solution which is acceptable for android and OTOH does not get into the way of other approaches. The main problem I have is that suspend blockers are only addressing one particular problem space of power management. We have more requirements than that, e.g. an active device transfer requires to prevent the idle code to select a deep power state due to latency requirements. So we then have to implement two mechanisms in the relevant drivers: 1) telling the idle code to limit latency 2) telling the suspend code not to suspend My main interest is to limit it to one mechanism, which is QoS based and let idle and suspend make the appropriate decisions based on that information. Thanks, tglx
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote: No I want you to stop confusing low power idle modes with suspend. I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state. (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're fixing it, get over it already). Unrelated to Android, I also want to use opportunistic suspend on my desktop. So you're going to sprinkle this suspend blocker shite all over regular userspace? Why not instead work on getting apps to behave properly and idle when there's nothing to do? After all, if you have the code to add suspend blockers into, you also have the means to fix it being stupid in the first place. -- 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] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Thomas Gleixner t...@linutronix.de: On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: 2010/6/2 Neil Brown ne...@suse.de: There would still need to be some sort of communication between the the suspend daemon on any event daemon to ensure that the events had been processed. This could be very light weight interaction. The point though is that with this patch it becomes possible to avoid races. Possible is better than impossible. We already have a solution. I don't think rejecting our solution but merging a worse solution should be the goal. That's not the goal at all. We want a solution which is acceptable for android and OTOH does not get into the way of other approaches. I don't actually think the suspend blocker patchset get in the way of anything else. The main problem I have is that suspend blockers are only addressing one particular problem space of power management. We have more requirements than that, e.g. an active device transfer requires to prevent the idle code to select a deep power state due to latency requirements. So we then have to implement two mechanisms in the relevant drivers: 1) telling the idle code to limit latency 2) telling the suspend code not to suspend And 3) telling the idle code to not enter low power modes that disrupt active interrupts or clocks. Our wakelock code handles 2 and 3, but I removed support for 3 on request since you can hack it by specifying a latency value that you know the low power mode cannot support. My main interest is to limit it to one mechanism, which is QoS based and let idle and suspend make the appropriate decisions based on that information. We can use one mechanism for this, but we still have to specify both. To me this is just another naming argument and not a good reason to not merge the suspend blocker code. You have to modify the same drivers if you call suspend_block() as if you call pm_qos_update_requirement(don't suspend). We have to specify when it is not safe to suspend independent of when it is not safe to enter low power idle modes so unless you want to have a bitmap of constraints you don't save any calls. And, if we later get a constraint framework that supports everything, we can switch to it then and we will then already have some drivers annotated. -- Arve Hjønnevå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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Peter Zijlstra pet...@infradead.org: On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote: No I want you to stop confusing low power idle modes with suspend. I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state. No, idle is transparent, suspend is not. (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're fixing it, get over it already). I don't think it is realistic to drop support for all existing hardware. Unrelated to Android, I also want to use opportunistic suspend on my desktop. So you're going to sprinkle this suspend blocker shite all over regular userspace? I have said several times, that regular user-space will not need to be modified to maintain their current behavior. Why not instead work on getting apps to behave properly and idle when there's nothing to do? After all, if you have the code to add suspend blockers into, you also have the means to fix it being stupid in the first place. Why would I add suspend blockers to the code I want to prevent running? -- Arve Hjønnevå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: [GIT PULL] omap iommu: for-next for 2.6.35-rc1
On Wed, Jun 02, 2010 at 09:50:54AM +0200, Doyu Hiroshi (Nokia-D/Helsinki) wrote: omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr should these two be here or should they go to 2.6.36 merge window ? at least from the description it doesn't look like they are fixing any bugs. omap iommu: add functionality to get TLB miss interrupt for this add functionality to get TLB miss interrupt the other two look suspicious looking only at the description. -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan
Hi, Sorry for the delay, I eventually got the time to look at your patches. On Tue, 2010-06-01 at 11:25 +0100, Hiroshi DOYU wrote: There is a false positive case that a pointer is calculated by other methods than the usual container_of macro. kmemleak_ignore can cover such a false positive, but it would loose the advantage of memory leak detection. This patch allows kmemleak to work with such false positives by introducing a new special memory block with a specified calculation formula. A client module can register its area with a conversion function, with which function kmemleak scan could calculate a correct pointer. While something needs to be done to cover these situations, I'm not so convinced about the method as it complicates the code requiring such conversion by having to insert two kmemleak hooks and a callback function. Can we not add a new prio tree (or just use the existing one) for pointer aliases? The advantage is that you only have a single function to call, something like kmemleak_add_alias() and you do it at the point the value was converted. Thanks. -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote: 2010/6/2 Peter Zijlstra pet...@infradead.org: On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote: No I want you to stop confusing low power idle modes with suspend. I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state. No, idle is transparent, suspend is not. Which is where the problem is, it should be. Why would I add suspend blockers to the code I want to prevent running? Because what you want might not be what others want. Suppose you're fine with your torrent client/irc client/etc.. to loose their network connection when you're not behind your desktop so you don't add suspend blockers there. Me, I'd be ready to administer physical violence if either of those lost their connections when I wasn't around to keep the screen-saver from kicking in. This leads to having to sprinkle magic dust (and lots of config options) all over userspace. Something that gets esp interesting with only a boolean interface. In the example above, having an active net connection would prevent my desktop from suspending, but what if another platform can maintain net connections while suspended? Do we then end up with arch specific code in the net-stack? I'm sure DaveM would love that. -- 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
[FOR TESTING] [PATCH] KS8851: Fix RX skbuff NULL pointer
From: Eric Dumazet eric.duma...@gmail.com
Fix the allocation length of rx skbuff.
Based on discussion http://lkml.org/lkml/2010/5/26/501
Signed-off-by: Abraham Arce x0066...@ti.com
---
drivers/net/ks8851.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index b4fb07a..05bd312 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -503,8 +503,9 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
ks8851_wrreg16(ks, KS_RXQCR,
ks-rc_rxqcr | RXQCR_SDA | RXQCR_ADRFE);
- if (rxlen 0) {
- skb = netdev_alloc_skb(ks-netdev, rxlen + 2 + 8);
+ if (rxlen 4) {
+ rxlen -= 4;
+ skb = netdev_alloc_skb(ks-netdev, 2 + 8 + ALIGN(rxlen,
4));
if (!skb) {
/* todo - dump frame and move on */
}
@@ -513,7 +514,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
* for the status header and 4 bytes of garbage */
skb_reserve(skb, 2 + 4 + 4);
- rxpkt = skb_put(skb, rxlen - 4) - 8;
+ rxpkt = skb_put(skb, rxlen) - 8;
/* align the packet length to 4 bytes, and add 4 bytes
* as we're getting the rx status header as well */
@@ -526,7 +527,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
netif_rx(skb);
ks-netdev-stats.rx_packets++;
- ks-netdev-stats.rx_bytes += rxlen - 4;
+ ks-netdev-stats.rx_bytes += rxlen;
}
ks8851_wrreg16(ks, KS_RXQCR, ks-rc_rxqcr);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1
Hi Felipe, From: Balbi Felipe (Nokia-D/Helsinki) felipe.ba...@nokia.com Subject: Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Wed, 2 Jun 2010 12:01:00 +0200 On Wed, Jun 02, 2010 at 09:50:54AM +0200, Doyu Hiroshi (Nokia-D/Helsinki) wrote: omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr should these two be here or should they go to 2.6.36 merge window ? at least from the description it doesn't look like they are fixing any bugs. omap iommu: add functionality to get TLB miss interrupt for this add functionality to get TLB miss interrupt the other two look suspicious looking only at the description. This subject might be misleading. These patches are for for-next, which means for v2.6.36. v2.6.35-rc1 on subject implies the base TAG for these patches. For fixes: http://marc.info/?l=linux-omapm=127546506730794w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1
On Wed, Jun 02, 2010 at 01:06:44PM +0200, Doyu Hiroshi (Nokia-D/Helsinki) wrote: This subject might be misleading. These patches are for for-next, which means for v2.6.36. v2.6.35-rc1 on subject implies the base TAG for these patches. ok, sorry for that :-) -- balbi DefectiveByDesign.org -- 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: Trying to understand how to use new OMAP mux code
* Laurent Epinat laurent.epi...@cioinfoindus.fr [100602 13:03]: Hello all How can I call omap_mux_init_signal() from external driver compiled as module ? cause the function is not in the standard path include files and is not exported You can't that's the whole idea :) Instead, please do the muxing in the board-*.c file for all the pins, or for the device when you initialize the platform data. The muxing of pins is board specific, and doing it in the board-*.c files allows us to free the memory for the unused pin data. Note that you can also mux using the kernel cmdline if you have something non-standard connected to your board pins. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan
From: ext Catalin Marinas catalin.mari...@arm.com Subject: Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan Date: Wed, 2 Jun 2010 12:01:24 +0200 Hi, Sorry for the delay, I eventually got the time to look at your patches. Thank you for your review. On Tue, 2010-06-01 at 11:25 +0100, Hiroshi DOYU wrote: There is a false positive case that a pointer is calculated by other methods than the usual container_of macro. kmemleak_ignore can cover such a false positive, but it would loose the advantage of memory leak detection. This patch allows kmemleak to work with such false positives by introducing a new special memory block with a specified calculation formula. A client module can register its area with a conversion function, with which function kmemleak scan could calculate a correct pointer. While something needs to be done to cover these situations, I'm not so convinced about the method as it complicates the code requiring such conversion by having to insert two kmemleak hooks and a callback function. Can we not add a new prio tree (or just use the existing one) for pointer aliases? The advantage is that you only have a single function to call, something like kmemleak_add_alias() and you do it at the point the value was converted. Actually I considered the above aliasing a little bit but I gave up soon. I was afraid that this method might consume way more memory since this just adds another member for struct kmemleak_object, but adding a single member for all objects. The number of kmemleak_object is usually numerous. Do you think that this increase of memory consumption is acceptable? -- 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
[PATCHv2 02/11] OMAP2: Devkit8000: change panel to generic panel
Choose the generic panel for lcd code of Devkit8000.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 08a2a01..3bde0e6 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -175,7 +175,7 @@ static struct regulator_consumer_supply
devkit8000_vio_supplies[] = {
static struct omap_dss_device devkit8000_lcd_device = {
.name = lcd,
- .driver_name= innolux_at_panel,
+ .driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.platform_enable= devkit8000_panel_enable_lcd,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 04/11] OMAP2: Devkit8000: Setup LCD reset
From: Kan-Ru Chen ka...@0xlab.org
This patch corrects the LCD reset pin configuration.
Original code from early devkit8000 patch sets the TWL4030 GPIO_1
to EHCI_nOC and TWL4030_GPIO_MAX+1 to ledA. Indeed these two pins
are both LCD_PWREN. Setup the lcd reset_gpio properly so it can be
disabled when other display is turned on.
Signed-off-by: Kan-Ru Chen ka...@0xlab.org
---
arch/arm/mach-omap2/board-devkit8000.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 17a2517..70552d8 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -134,11 +134,15 @@ static int devkit8000_panel_enable_lcd(struct
omap_dss_device *dssdev)
twl_i2c_write_u8(TWL4030_MODULE_GPIO, 0x80, REG_GPIODATADIR1);
twl_i2c_write_u8(TWL4030_MODULE_LED, 0x0, 0x0);
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
{
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 0);
}
static int devkit8000_panel_enable_dvi(struct omap_dss_device *dssdev)
@@ -183,6 +187,7 @@ static struct omap_dss_device devkit8000_lcd_device = {
.driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
+ .reset_gpio = -EINVAL, /* will be replaced */
.platform_enable= devkit8000_panel_enable_lcd,
.platform_disable = devkit8000_panel_disable_lcd,
};
@@ -281,6 +286,12 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+/* gpio + 1 is LCD_PWREN (out, active high) */
+ devkit8000_lcd_device.reset_gpio = gpio + 1;
+ gpio_request(devkit8000_lcd_device.reset_gpio, LCD_PWREN);
+ /* Disable until needed */
+ gpio_direction_output(devkit8000_lcd_device.reset_gpio, 0);
+
/* gpio + 7 is DVI_PD (out, active low) */
devkit8000_dvi_device.reset_gpio = gpio + 7;
gpio_request(devkit8000_dvi_device.reset_gpio, DVI PowerDown);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 10/11] OMAP2: Devkit8000: Remove unused omap_board_config
omap_board_config is no longer used and thats why empty.
This patch removes the empty omap_board_config.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index dbd16de..a485d39 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -126,8 +126,6 @@ static struct omap2_hsmmc_info mmc[] = {
},
{} /* Terminator */
};
-static struct omap_board_config_kernel devkit8000_config[] __initdata = {
-};
static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
{
@@ -464,8 +462,6 @@ static struct platform_device keys_gpio = {
static void __init devkit8000_init_irq(void)
{
- omap_board_config = devkit8000_config;
- omap_board_config_size = ARRAY_SIZE(devkit8000_config);
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
omap_init_irq();
@@ -797,8 +793,6 @@ static void __init devkit8000_init(void)
devkit8000_i2c_init();
platform_add_devices(devkit8000_devices,
ARRAY_SIZE(devkit8000_devices));
- omap_board_config = devkit8000_config;
- omap_board_config_size = ARRAY_SIZE(devkit8000_config);
spi_register_board_info(devkit8000_spi_board_info,
ARRAY_SIZE(devkit8000_spi_board_info));
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 11/11] OMAP2: Devkit8000: Fix regulator for power supply
Devkit8000 uses the TPS65930 and not the TWL4030.
The TPS65930 uses only a subset of the power supplies
of the TWL4030.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index a485d39..648b565 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -380,7 +380,7 @@ static struct twl4030_platform_data devkit8000_twldata = {
static struct i2c_board_info __initdata devkit8000_i2c_boardinfo[] = {
{
- I2C_BOARD_INFO(twl4030, 0x48),
+ I2C_BOARD_INFO(tps65930, 0x48),
.flags = I2C_CLIENT_WAKE,
.irq = INT_34XX_SYS_NIRQ,
.platform_data = devkit8000_twldata,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 03/11] OMAP2: Devkit8000: Enable DVI-D output
From: Kan-Ru Chen ka...@0xlab.org
This patch corrects the DVI-D output setup of Devkit8000
Devkit8000 has different DVI reset pin with the BeagleBoard.
On Devkit8000 the TWL4030 GPIO_7 is assigned to do the job.
Signed-off-by: Kan-Ru Chen ka...@0xlab.org
---
arch/arm/mach-omap2/board-devkit8000.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 3bde0e6..17a2517 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -140,13 +140,18 @@ static int devkit8000_panel_enable_lcd(struct
omap_dss_device *dssdev)
static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
{
}
+
static int devkit8000_panel_enable_dvi(struct omap_dss_device *dssdev)
{
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_dvi(struct omap_dss_device *dssdev)
{
+ if (dssdev-reset_gpio != -EINVAL)
+ gpio_set_value(dssdev-reset_gpio, 0);
}
static int devkit8000_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -186,6 +191,7 @@ static struct omap_dss_device devkit8000_dvi_device = {
.driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
+ .reset_gpio = -EINVAL, /* will be replaced */
.platform_enable= devkit8000_panel_enable_dvi,
.platform_disable = devkit8000_panel_disable_dvi,
};
@@ -272,6 +278,15 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
devkit8000_vmmc1_supply.dev = mmc[0].dev;
devkit8000_vsim_supply.dev = mmc[0].dev;
+ /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
+ gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+
+ /* gpio + 7 is DVI_PD (out, active low) */
+ devkit8000_dvi_device.reset_gpio = gpio + 7;
+ gpio_request(devkit8000_dvi_device.reset_gpio, DVI PowerDown);
+ /* Disable until needed */
+ gpio_direction_output(devkit8000_dvi_device.reset_gpio, 0);
+
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 00/11] Multiple fixes for Devkit8000
These patches correct errors that were done while using the board code from beagle board for Devkit8000. The Devkit8000 uses the TPS65930, an reduced version of the TWL4030. So not all power supplies from the TWL4030 are available. The DSS2 do not need a VDVI any longer so it is removed. The definition of the supplies are changed to use the new REGULATOR_SUPPLY macro. The pins for lcd and dvi powerdown are corrected. Changes to v1: -remove the patches that only fix comments -expand the description of the patches Kan-Ru Chen (2): OMAP2: Devkit8000: Enable DVI-D output OMAP2: Devkit8000: Setup LCD reset Thomas Weber (9): OMAP2: Devkit8000: Cleanup for power supplies OMAP2: Devkit8000: change panel to generic panel OMAP2: Devkit8000: Remove unneeded VDVI supply OMAP2: Devkit8000: Remove non existing vsim supply OMAP2: Devkit8000: Remove en-/disable for tv panel OMAP2: Devkit8000: Using the REGULATOR_SUPPLY macro OMAP2: Devkit8000: Using gpio_is_valid macro OMAP2: Devkit8000: Remove unused omap_board_config OMAP2: Devkit8000: Fix regulator for power supply arch/arm/mach-omap2/board-devkit8000.c | 122 +++- 1 files changed, 58 insertions(+), 64 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
[PATCHv2 09/11] OMAP2: Devkit8000: Using gpio_is_valid macro
Using the macro gpio_is_valid for check of valid gpio pins.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 3da88c8..dbd16de 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -134,27 +134,27 @@ static int devkit8000_panel_enable_lcd(struct
omap_dss_device *dssdev)
twl_i2c_write_u8(TWL4030_MODULE_GPIO, 0x80, REG_GPIODATADIR1);
twl_i2c_write_u8(TWL4030_MODULE_LED, 0x0, 0x0);
- if (dssdev-reset_gpio != -EINVAL)
+ if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value(dssdev-reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
{
- if (dssdev-reset_gpio != -EINVAL)
+ if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value(dssdev-reset_gpio, 0);
}
static int devkit8000_panel_enable_dvi(struct omap_dss_device *dssdev)
{
- if (dssdev-reset_gpio != -EINVAL)
+ if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value(dssdev-reset_gpio, 1);
return 0;
}
static void devkit8000_panel_disable_dvi(struct omap_dss_device *dssdev)
{
- if (dssdev-reset_gpio != -EINVAL)
+ if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value(dssdev-reset_gpio, 0);
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 06/11] OMAP2: Devkit8000: Remove non existing vsim supply
The Devkit8000 uses the cost reduced variant tps65930 of the twl4030.
The TPS65930 only has vdd1, vdd2, vpll1, vio, vmmc1, vdac and vaux2.
vaux2 is not used on Devkit8000.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 22 --
1 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 8cc8c3b..59877b1 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -168,15 +168,10 @@ static void devkit8000_panel_disable_tv(struct
omap_dss_device *dssdev)
{
}
-
static struct regulator_consumer_supply devkit8000_vmmc1_supply = {
.supply = vmmc,
};
-static struct regulator_consumer_supply devkit8000_vsim_supply = {
- .supply = vmmc_aux,
-};
-
/* ads7846 on SPI */
static struct regulator_consumer_supply devkit8000_vio_supplies[] = {
REGULATOR_SUPPLY(vcc, spi2.0)
@@ -281,7 +276,6 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
/* link regulators to MMC adapters */
devkit8000_vmmc1_supply.dev = mmc[0].dev;
- devkit8000_vsim_supply.dev = mmc[0].dev;
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
@@ -334,21 +328,6 @@ static struct regulator_init_data devkit8000_vmmc1 = {
.consumer_supplies = devkit8000_vmmc1_supply,
};
-/* VSIM for MMC1 pins DAT4..DAT7 (2 mA, plus card == max 50 mA) */
-static struct regulator_init_data devkit8000_vsim = {
- .constraints = {
- .min_uV = 180,
- .max_uV = 300,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = 1,
- .consumer_supplies = devkit8000_vsim_supply,
-};
-
/* VDAC for DSS driving S-Video (8 mA unloaded, max 65 mA) */
static struct regulator_init_data devkit8000_vdac = {
.constraints = {
@@ -414,7 +393,6 @@ static struct twl4030_platform_data devkit8000_twldata = {
.gpio = devkit8000_gpio_data,
.codec = devkit8000_codec_data,
.vmmc1 = devkit8000_vmmc1,
- .vsim = devkit8000_vsim,
.vdac = devkit8000_vdac,
.vpll1 = devkit8000_vpll1,
.vio= devkit8000_vio,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 08/11] OMAP2: Devkit8000: Using the REGULATOR_SUPPLY macro
Replacing supplies with the REGULATOR_SUPPLY macro.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 33 ---
1 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 095dc7a..3da88c8 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -158,14 +158,13 @@ static void devkit8000_panel_disable_dvi(struct
omap_dss_device *dssdev)
gpio_set_value(dssdev-reset_gpio, 0);
}
-static struct regulator_consumer_supply devkit8000_vmmc1_supply = {
- .supply = vmmc,
-};
+static struct regulator_consumer_supply devkit8000_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
+
/* ads7846 on SPI */
-static struct regulator_consumer_supply devkit8000_vio_supplies[] = {
- REGULATOR_SUPPLY(vcc, spi2.0)
-};
+static struct regulator_consumer_supply devkit8000_vio_supply =
+ REGULATOR_SUPPLY(vcc, spi2.0);
static struct omap_dss_device devkit8000_lcd_device = {
.name = lcd,
@@ -214,10 +213,8 @@ static struct platform_device devkit8000_dss_device = {
},
};
-static struct regulator_consumer_supply devkit8000_vdda_dac_supply = {
- .supply = vdda_dac,
- .dev= devkit8000_dss_device.dev,
-};
+static struct regulator_consumer_supply devkit8000_vdda_dac_supply =
+ REGULATOR_SUPPLY(vdda_dac, omapdss);
static int board_keymap[] = {
KEY(0, 0, KEY_1),
@@ -294,12 +291,8 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
.setup = devkit8000_twl_gpio_setup,
};
-static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = {
- {
- .supply = vdds_dsi,
- .dev= devkit8000_dss_device.dev,
- }
-};
+static struct regulator_consumer_supply devkit8000_vpll1_supply =
+ REGULATOR_SUPPLY(vdds_dsi, omapdss);
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data devkit8000_vmmc1 = {
@@ -340,8 +333,8 @@ static struct regulator_init_data devkit8000_vpll1 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = ARRAY_SIZE(devkit8000_vpll1_supplies),
- .consumer_supplies = devkit8000_vpll1_supplies,
+ .num_consumer_supplies = 1,
+ .consumer_supplies = devkit8000_vpll1_supply,
};
/* VAUX4 for ads7846 and nubs */
@@ -355,8 +348,8 @@ static struct regulator_init_data devkit8000_vio = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = ARRAY_SIZE(devkit8000_vio_supplies),
- .consumer_supplies = devkit8000_vio_supplies,
+ .num_consumer_supplies = 1,
+ .consumer_supplies = devkit8000_vio_supply,
};
static struct twl4030_usb_data devkit8000_usb_data = {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 07/11] OMAP2: Devkit8000: Remove en-/disable for tv panel
devkit8000_panel_enable_tv and devkit8000_panel_disable_tv are already
done in DSS2 code. So they are no longer needed in board code.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 12
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 59877b1..095dc7a 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -158,16 +158,6 @@ static void devkit8000_panel_disable_dvi(struct
omap_dss_device *dssdev)
gpio_set_value(dssdev-reset_gpio, 0);
}
-static int devkit8000_panel_enable_tv(struct omap_dss_device *dssdev)
-{
-
- return 0;
-}
-
-static void devkit8000_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct regulator_consumer_supply devkit8000_vmmc1_supply = {
.supply = vmmc,
};
@@ -201,8 +191,6 @@ static struct omap_dss_device devkit8000_tv_device = {
.driver_name= venc,
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable= devkit8000_panel_enable_tv,
- .platform_disable = devkit8000_panel_disable_tv,
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 01/11] OMAP2: Devkit8000: Cleanup for power supplies
Corrected the wrong power supplies in devkit8000 code.
Add supply for ads7846 to support the new regulator framework for
touchscreen.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 32 ++--
1 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 922b746..08a2a01 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -168,6 +168,10 @@ static struct regulator_consumer_supply
devkit8000_vsim_supply = {
.supply = vmmc_aux,
};
+/* ads7846 on SPI */
+static struct regulator_consumer_supply devkit8000_vio_supplies[] = {
+ REGULATOR_SUPPLY(vcc, spi2.0)
+};
static struct omap_dss_device devkit8000_lcd_device = {
.name = lcd,
@@ -282,7 +286,7 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
.setup = devkit8000_twl_gpio_setup,
};
-static struct regulator_consumer_supply devkit8000_vpll2_supplies[] = {
+static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = {
{
.supply = vdvi,
.dev= devkit8000_lcd_device.dev,
@@ -337,8 +341,8 @@ static struct regulator_init_data devkit8000_vdac = {
.consumer_supplies = devkit8000_vdda_dac_supply,
};
-/* VPLL2 for digital video outputs */
-static struct regulator_init_data devkit8000_vpll2 = {
+/* VPLL1 for digital video outputs */
+static struct regulator_init_data devkit8000_vpll1 = {
.constraints = {
.name = VDVI,
.min_uV = 180,
@@ -348,8 +352,23 @@ static struct regulator_init_data devkit8000_vpll2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = ARRAY_SIZE(devkit8000_vpll2_supplies),
- .consumer_supplies = devkit8000_vpll2_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(devkit8000_vpll1_supplies),
+ .consumer_supplies = devkit8000_vpll1_supplies,
+};
+
+/* VAUX4 for ads7846 and nubs */
+static struct regulator_init_data devkit8000_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(devkit8000_vio_supplies),
+ .consumer_supplies = devkit8000_vio_supplies,
};
static struct twl4030_usb_data devkit8000_usb_data = {
@@ -376,7 +395,8 @@ static struct twl4030_platform_data devkit8000_twldata = {
.vmmc1 = devkit8000_vmmc1,
.vsim = devkit8000_vsim,
.vdac = devkit8000_vdac,
- .vpll2 = devkit8000_vpll2,
+ .vpll1 = devkit8000_vpll1,
+ .vio= devkit8000_vio,
.keypad = devkit8000_kp_data,
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 05/11] OMAP2: Devkit8000: Remove unneeded VDVI supply
The VDVI power supply is no longer needed in
board code with the new DSS2 interface.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 70552d8..8cc8c3b 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -314,10 +314,6 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = {
{
- .supply = vdvi,
- .dev= devkit8000_lcd_device.dev,
- },
- {
.supply = vdds_dsi,
.dev= devkit8000_dss_device.dev,
}
@@ -370,7 +366,6 @@ static struct regulator_init_data devkit8000_vdac = {
/* VPLL1 for digital video outputs */
static struct regulator_init_data devkit8000_vpll1 = {
.constraints = {
- .name = VDVI,
.min_uV = 180,
.max_uV = 180,
.valid_modes_mask = REGULATOR_MODE_NORMAL
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trying to understand how to use new OMAP mux code
On Wed, 2 Jun 2010 14:21:30 +0300 Tony Lindgren t...@atomide.com wrote: How can I call omap_mux_init_signal() from external driver compiled as module ? cause the function is not in the standard path include files and is not exported You can't that's the whole idea :) Instead, please do the muxing in the board-*.c file for all the pins, or for the device when you initialize the platform data. The muxing of pins is board specific, and doing it in the board-*.c files allows us to free the memory for the unused pin data. Note that you can also mux using the kernel cmdline if you have something non-standard connected to your board pins. Side note. How about add-on cards for e.g. BeagleBoard? It would be nice feature if a kernel module for that particular add-on card can do the muxing without needing to specify them on cmdline. I.e. if you are switching between cards there is no need to figure out new cmdline for each of them. For me even rootwait is sometimes too difficult to remember :-) -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 02 Jun 2010 11:10:51 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote: If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to: 1) crappy applications keeping the cpu away from idle 2) timers firing Would solving those two issues be sufficient for you or am I missing something ? Aren't the container snapshot/resume people fighting the same set of problems here? And virtualisation - its a big one for virtualisation because if you've got 1000 misbehaving guests generating 100 wakeups a second you've got a problem Alan -- 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: [alsa-devel] [PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
On Wednesday 02 June 2010 12:15:22 ext Liam Girdwood wrote: On Wed, 2010-06-02 at 12:05 +0300, Peter Ujfalusi wrote: Hi, On Tuesday 01 June 2010 14:18:19 Ujfalusi Peter (Nokia-D/Tampere) wrote: .. Liam if you are going to take the series, could you fix the patch names? I can also resend them if it is easier for you. Peter, I think it's probably better if you can resend. Can you also append the Acks too. Tony, do we have your ack too ? No problem, I'll wait for Tony's ack, and resend the series. Thanks Liam -- 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] [PATCH v3 3/4] OMAP4: Keyboard board support
Felipe,
+static struct omap4_keypad_platform_data sdp4430_keypad_data = {
+.keymap_data= sdp4430_keymap_data,
+.rows = 8,
+.cols = 8,
+.device_enable = omap_device_enable,
+.device_shutdown= omap_device_shutdown,
+.device_idle= omap_device_idle,
again all three are undefined
To be removed...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan
From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan Date: Wed, 02 Jun 2010 14:34:58 +0300 (EEST) From: ext Catalin Marinas catalin.mari...@arm.com Subject: Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan Date: Wed, 2 Jun 2010 12:01:24 +0200 Hi, Sorry for the delay, I eventually got the time to look at your patches. Thank you for your review. On Tue, 2010-06-01 at 11:25 +0100, Hiroshi DOYU wrote: There is a false positive case that a pointer is calculated by other methods than the usual container_of macro. kmemleak_ignore can cover such a false positive, but it would loose the advantage of memory leak detection. This patch allows kmemleak to work with such false positives by introducing a new special memory block with a specified calculation formula. A client module can register its area with a conversion function, with which function kmemleak scan could calculate a correct pointer. While something needs to be done to cover these situations, I'm not so convinced about the method as it complicates the code requiring such conversion by having to insert two kmemleak hooks and a callback function. Can we not add a new prio tree (or just use the existing one) for pointer aliases? The advantage is that you only have a single function to call, something like kmemleak_add_alias() and you do it at the point the value was converted. Ok, I understand now. Please ignore my previous. I'll try the above. -- 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 v3 2/4] OMAP4: Keyboard device registration
Thanks Thomas,
+ unsigned int length = 0, id = 0;
+ int hw_mod_name_len = 16;
+ char oh_name[hw_mod_name_len];
+ char *name = omap4-keypad;
+
+ length = snprintf(oh_name, hw_mod_name_len, kbd);
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -EIO;
+ }
Maybe I'm missing something here, but I don't see where length is
being used, and why the snprintf()/oh_name thing is needed. What about:
unsigned int id = 0;
char *name = omap4-keypad;
oh = omap_hwmod_lookup(kbd);
if (!oh) {
pr_err(Could not look up kbd\n);
return -EIO;
}
I'll remove length variable and keep snprintf, below oh_name - kbd is used
again, this will keep name defined in one single place
WARN(IS_ERR(od), Could not build omap_device for %s %s\n,
name, oh_name);
Best Regards
Abraham
--
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] misc : ROHM BH1780GLI Ambient light sensor Driver
Is there any standardisation of the ABIs whcih these drivers offer? If so, does this new driver comply with that? There was an attempt to sort this out but Linux vetoed it because he is under the delusion that light sensors are input devices. That doesn't work in many use cases as you have to go ask them the light level and the polling needed for input events keeps wrecks your idle behaviour when you need to sample them when required instead. Instead therefore the API is random and the devices appear in random ways and classes. We have some intel drivers to submit as well as and when sanity prevails. Alan -- 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
beagleboard expansion boards, was Trying to understand how to use new OMAP mux code
Op 2 jun 2010, om 13:46 heeft Jarkko Nikula het volgende geschreven: On Wed, 2 Jun 2010 14:21:30 +0300 Tony Lindgren t...@atomide.com wrote: How can I call omap_mux_init_signal() from external driver compiled as module ? cause the function is not in the standard path include files and is not exported You can't that's the whole idea :) Instead, please do the muxing in the board-*.c file for all the pins, or for the device when you initialize the platform data. The muxing of pins is board specific, and doing it in the board-*.c files allows us to free the memory for the unused pin data. Note that you can also mux using the kernel cmdline if you have something non-standard connected to your board pins. Side note. How about add-on cards for e.g. BeagleBoard? It would be nice feature if a kernel module for that particular add-on card can do the muxing without needing to specify them on cmdline. I.e. if you are switching between cards there is no need to figure out new cmdline for each of them. For me even rootwait is sometimes too difficult to remember :-) What we (as in beagleboard.org) are currently doing is this: u-boot: http://gitorious.org/beagleboard-validation/u-boot/commit/70ed67cacbb1b7158e059b9b5d10308cce2d917a http://gitorious.org/beagleboard-validation/u-boot/commit/74f700341c656e1636221a53347caccbfc07c224 kernel: http://gitorious.org/beagleboard-validation/linux/commit/32fb278553a4cd6126c1791d70aa33df12f73d90 It's very ugly and needs a rethink before it can get posted to here, but it works great! The plan is to do this as part of the patchset to add support for the 37xx based beagleboardXM. regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code
On Wed, 2 Jun 2010 14:56:30 +0200 Koen Kooi k...@dominion.thruhere.net wrote: How about add-on cards for e.g. BeagleBoard? It would be nice feature if a kernel module for that particular add-on card can do the muxing without needing to specify them on cmdline. I.e. if you are switching between cards there is no need to figure out new cmdline for each of them. For me even rootwait is sometimes too difficult to remember :-) What we (as in beagleboard.org) are currently doing is this: u-boot: http://gitorious.org/beagleboard-validation/u-boot/commit/70ed67cacbb1b7158e059b9b5d10308cce2d917a http://gitorious.org/beagleboard-validation/u-boot/commit/74f700341c656e1636221a53347caccbfc07c224 kernel: http://gitorious.org/beagleboard-validation/linux/commit/32fb278553a4cd6126c1791d70aa33df12f73d90 It's very ugly and needs a rethink before it can get posted to here, but it works great! The plan is to do this as part of the patchset to add support for the 37xx based beagleboardXM. Problem is that amount of expansion boards is practically unlimited so patching bootloader and board file could come quite maintenance effort. Of course there are some lets say generic boards but bunch of in-house, DIY, etc. boards and there is no point to patch common bootloader and kernel board files because of them. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH v3 2/4] OMAP4: Keyboard device registration
On Wed, 2 Jun 2010 07:45:07 -0500 Arce, Abraham x0066...@ti.com wrote: I'll remove length variable and keep snprintf, below oh_name - kbd is used again, this will keep name defined in one single place WARN(IS_ERR(od), Could not build omap_device for %s %s\n, name, oh_name); In this case, why not: char *oh_name = kbd; There's really no point in using snprintf() for statically-defined strings. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] Davinci: Create seperate Kconfig file for davinci devices
Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hiremath, Vaibhav Sent: Thursday, May 27, 2010 9:11 AM To: linux-me...@vger.kernel.org Cc: mche...@redhat.com; Karicheri, Muralidharan; linux- o...@vger.kernel.org; Hiremath, Vaibhav Subject: [PATCH 1/2] Davinci: Create seperate Kconfig file for davinci devices From: Vaibhav Hiremath hvaib...@ti.com Currently VPFE Capture driver and DM6446 CCDC driver is being reused for AM3517. So this patch is preparing the Kconfig/makefile for re-use of such IP's. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/Kconfig | 61 +-- drivers/media/video/Makefile|2 +- drivers/media/video/davinci/Kconfig | 93 +++ 3 files changed, 95 insertions(+), 61 deletions(-) create mode 100644 drivers/media/video/davinci/Kconfig diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index ad9e6f9..e5d74ae 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -570,66 +570,7 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. -config VIDEO_VPSS_SYSTEM - tristate VPSS System module driver - depends on ARCH_DAVINCI - help -Support for vpss system module for video driver - -config VIDEO_VPFE_CAPTURE - tristate VPFE Video Capture Driver - depends on VIDEO_V4L2 ARCH_DAVINCI - select VIDEOBUF_DMA_CONTIG - help -Support for DM VPFE based frame grabber. This is the -common V4L2 module for following DMXXX SoCs from Texas -Instruments:- DM6446 DM355. - Vaibhav, Could you also list DM365 here? This was somehow missed. -To compile this driver as a module, choose M here: the -module will be called vpfe-capture. - -config VIDEO_DM6446_CCDC - tristate DM6446 CCDC HW module - depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from slave decoders. - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_DM355_CCDC - tristate DM355 CCDC HW module - depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DM355 CCD hw module. DM355 CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from a slave decoders - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_ISIF - tristate ISIF HW module - depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables ISIF hw module. This is the hardware module for - configuring ISIF in VPFE to capture Raw Bayer RGB data from - a image sensor or YUV data from a YUV source. - - To compile this driver as a module, choose M here: the - module will be called vpfe. +source drivers/media/video/davinci/Kconfig source drivers/media/video/omap/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index cc93859..aa1ea2f 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -177,7 +177,7 @@ obj-$(CONFIG_VIDEO_SAA7164) += saa7164/ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o -obj-$(CONFIG_ARCH_DAVINCI)+= davinci/ +obj-y += davinci/ obj-$(CONFIG_ARCH_OMAP) += omap/ diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig new file mode 100644 index 000..97f889d --- /dev/null +++ b/drivers/media/video/davinci/Kconfig @@ -0,0 +1,93 @@ +config DISPLAY_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Display + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + select VIDEO_ADV7343 + select VIDEO_THS7303 + help +Support for DM6467 based display device. + +To compile this driver as a module, choose M here: the +module will be called vpif_display. + +config CAPTURE_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Capture + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + help +Support for DM6467 based capture device. + +
Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code
* Jarkko Nikula jhnik...@gmail.com [100602 16:06]: On Wed, 2 Jun 2010 14:56:30 +0200 Koen Kooi k...@dominion.thruhere.net wrote: How about add-on cards for e.g. BeagleBoard? It would be nice feature if a kernel module for that particular add-on card can do the muxing without needing to specify them on cmdline. I.e. if you are switching between cards there is no need to figure out new cmdline for each of them. For me even rootwait is sometimes too difficult to remember :-) What we (as in beagleboard.org) are currently doing is this: u-boot: http://gitorious.org/beagleboard-validation/u-boot/commit/70ed67cacbb1b7158e059b9b5d10308cce2d917a http://gitorious.org/beagleboard-validation/u-boot/commit/74f700341c656e1636221a53347caccbfc07c224 kernel: http://gitorious.org/beagleboard-validation/linux/commit/32fb278553a4cd6126c1791d70aa33df12f73d90 It's very ugly and needs a rethink before it can get posted to here, but it works great! The plan is to do this as part of the patchset to add support for the 37xx based beagleboardXM. Problem is that amount of expansion boards is practically unlimited so patching bootloader and board file could come quite maintenance effort. Of course there are some lets say generic boards but bunch of in-house, DIY, etc. boards and there is no point to patch common bootloader and kernel board files because of them. Just saveenv the kernel cmdline options in u-boot? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] AM3517: Add VPFE Capture driver support to board file
Vaibhav,
See below my comments...
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, May 27, 2010 9:11 AM
To: linux-me...@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org; Hiremath, Vaibhav
Subject: [PATCH 2/2] AM3517: Add VPFE Capture driver support to board file
From: Vaibhav Hiremath hvaib...@ti.com
Also created vpfe master/slave clock aliases, since naming
convention is different in both Davinci and AM3517 devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 161
+
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index c1c4389..edcb6db 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,15 +30,168 @@
#include plat/board.h
#include plat/common.h
+#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include media/tvp514x.h
+#include media/davinci/vpfe_capture.h
+
#include mux.h
#define LCD_PANEL_PWR 176
#define LCD_PANEL_BKLIGHT_PWR 182
#define LCD_PANEL_PWM 181
+/*
+ * VPFE - Video Decoder interface
+ */
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+};
+
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity= 1,
+ .vs_polarity= 1
+};
+
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI1A,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5C),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static void am3517_evm_clear_vpfe_intr(int vdint)
+{
+ unsigned int vpfe_int_clr;
+
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+
+ switch (vdint) {
+ /* VD0 interrrupt */
+ case INT_35XX_CCDC_VD0_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ break;
+ /* VD1 interrrupt */
+ case INT_35XX_CCDC_VD1_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ break;
+ /* VD2 interrrupt */
+ case INT_35XX_CCDC_VD2_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ break;
+ /* Clear all interrrupts */
+ default:
+ vpfe_int_clr = ~(AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ vpfe_int_clr |= (AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ break;
+ }
+ omap_ctrl_writel(vpfe_int_clr, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs= ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 3,
+ .sub_devs = vpfe_sub_devs,
+ .clr_intr = am3517_evm_clear_vpfe_intr,
+ .card_name = DM6446 EVM,
[MK] You might want to change the card name to match with what you are using.
This is what user will see in querycap and should reflect the correct name IMO.
+ .ccdc = DM6446 CCDC,
+};
+
+static struct resource vpfe_resources[] = {
+ {
+
RE: [PATCH 1/2] Davinci: Create seperate Kconfig file for davinci devices
From: Karicheri, Muralidharan Sent: Wednesday, June 02, 2010 7:23 PM To: Hiremath, Vaibhav; linux-me...@vger.kernel.org Cc: mche...@redhat.com; linux-omap@vger.kernel.org Subject: RE: [PATCH 1/2] Davinci: Create seperate Kconfig file for davinci devices Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hiremath, Vaibhav Sent: Thursday, May 27, 2010 9:11 AM To: linux-me...@vger.kernel.org Cc: mche...@redhat.com; Karicheri, Muralidharan; linux- o...@vger.kernel.org; Hiremath, Vaibhav Subject: [PATCH 1/2] Davinci: Create seperate Kconfig file for davinci devices From: Vaibhav Hiremath hvaib...@ti.com Currently VPFE Capture driver and DM6446 CCDC driver is being reused for AM3517. So this patch is preparing the Kconfig/makefile for re-use of such IP's. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/Kconfig | 61 +-- drivers/media/video/Makefile|2 +- drivers/media/video/davinci/Kconfig | 93 +++ 3 files changed, 95 insertions(+), 61 deletions(-) create mode 100644 drivers/media/video/davinci/Kconfig diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index ad9e6f9..e5d74ae 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -570,66 +570,7 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. -config VIDEO_VPSS_SYSTEM - tristate VPSS System module driver - depends on ARCH_DAVINCI - help -Support for vpss system module for video driver - -config VIDEO_VPFE_CAPTURE - tristate VPFE Video Capture Driver - depends on VIDEO_V4L2 ARCH_DAVINCI - select VIDEOBUF_DMA_CONTIG - help -Support for DM VPFE based frame grabber. This is the -common V4L2 module for following DMXXX SoCs from Texas -Instruments:- DM6446 DM355. - Vaibhav, Could you also list DM365 here? This was somehow missed. I believe you are referring to Instruments:- DM6446, DM365 DM355 Submitting this patch alone with this change. Thanks, Vaibhav -To compile this driver as a module, choose M here: the -module will be called vpfe-capture. - -config VIDEO_DM6446_CCDC - tristate DM6446 CCDC HW module - depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from slave decoders. - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_DM355_CCDC - tristate DM355 CCDC HW module - depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DM355 CCD hw module. DM355 CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from a slave decoders - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_ISIF - tristate ISIF HW module - depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables ISIF hw module. This is the hardware module for - configuring ISIF in VPFE to capture Raw Bayer RGB data from - a image sensor or YUV data from a YUV source. - - To compile this driver as a module, choose M here: the - module will be called vpfe. +source drivers/media/video/davinci/Kconfig source drivers/media/video/omap/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index cc93859..aa1ea2f 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -177,7 +177,7 @@ obj-$(CONFIG_VIDEO_SAA7164) += saa7164/ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o -obj-$(CONFIG_ARCH_DAVINCI)+= davinci/ +obj-y += davinci/ obj-$(CONFIG_ARCH_OMAP) += omap/ diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig new file mode 100644 index 000..97f889d --- /dev/null +++ b/drivers/media/video/davinci/Kconfig @@ -0,0 +1,93 @@ +config DISPLAY_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Display + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + select VIDEO_ADV7343 + select VIDEO_THS7303 +
RE: [PATCH 1/2] Davinci: Create seperate Kconfig file for davinci devices
Vaibhav, Could you also list DM365 here? This was somehow missed. I believe you are referring to Instruments:- DM6446, DM365 DM355 yes. Thanks. Submitting this patch alone with this change. Thanks, Vaibhav -To compile this driver as a module, choose M here: the -module will be called vpfe-capture. - -config VIDEO_DM6446_CCDC - tristate DM6446 CCDC HW module - depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from slave decoders. - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_DM355_CCDC - tristate DM355 CCDC HW module - depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DM355 CCD hw module. DM355 CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from a slave decoders - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_ISIF - tristate ISIF HW module - depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables ISIF hw module. This is the hardware module for - configuring ISIF in VPFE to capture Raw Bayer RGB data from - a image sensor or YUV data from a YUV source. - - To compile this driver as a module, choose M here: the - module will be called vpfe. +source drivers/media/video/davinci/Kconfig source drivers/media/video/omap/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index cc93859..aa1ea2f 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -177,7 +177,7 @@ obj-$(CONFIG_VIDEO_SAA7164) += saa7164/ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o -obj-$(CONFIG_ARCH_DAVINCI)+= davinci/ +obj-y += davinci/ obj-$(CONFIG_ARCH_OMAP) += omap/ diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig new file mode 100644 index 000..97f889d --- /dev/null +++ b/drivers/media/video/davinci/Kconfig @@ -0,0 +1,93 @@ +config DISPLAY_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Display + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + select VIDEO_ADV7343 + select VIDEO_THS7303 + help +Support for DM6467 based display device. + +To compile this driver as a module, choose M here: the +module will be called vpif_display. + +config CAPTURE_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Capture + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + help +Support for DM6467 based capture device. + +To compile this driver as a module, choose M here: the +module will be called vpif_capture. + +config VIDEO_DAVINCI_VPIF + tristate DaVinci VPIF Driver + depends on DISPLAY_DAVINCI_DM646X_EVM + help +Support for DaVinci VPIF Driver. + +To compile this driver as a module, choose M here: the +module will be called vpif. + +config VIDEO_VPSS_SYSTEM + tristate VPSS System module driver + depends on ARCH_DAVINCI + help +Support for vpss system module for video driver + +config VIDEO_VPFE_CAPTURE + tristate VPFE Video Capture Driver + depends on VIDEO_V4L2 (ARCH_DAVINCI || ARCH_OMAP3) + select VIDEOBUF_DMA_CONTIG + help +Support for DMx/AMx VPFE based frame grabber. This is the +common V4L2 module for following DMx/AMx SoCs from Texas +Instruments:- DM6446, DM355 AM3517/05. + +To compile this driver as a module, choose M here: the +module will be called vpfe-capture. + +config VIDEO_DM6446_CCDC + tristate DM6446 CCDC HW module + depends on VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from slave decoders. + + To compile this driver as a module, choose M here: the + module will be called vpfe. + +config VIDEO_DM355_CCDC + tristate DM355
Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code
Op 2 jun 2010, om 15:57 heeft Tony Lindgren het volgende geschreven: * Jarkko Nikula jhnik...@gmail.com [100602 16:06]: On Wed, 2 Jun 2010 14:56:30 +0200 Koen Kooi k...@dominion.thruhere.net wrote: How about add-on cards for e.g. BeagleBoard? It would be nice feature if a kernel module for that particular add-on card can do the muxing without needing to specify them on cmdline. I.e. if you are switching between cards there is no need to figure out new cmdline for each of them. For me even rootwait is sometimes too difficult to remember :-) What we (as in beagleboard.org) are currently doing is this: u-boot: http://gitorious.org/beagleboard-validation/u-boot/commit/70ed67cacbb1b7158e059b9b5d10308cce2d917a http://gitorious.org/beagleboard-validation/u-boot/commit/74f700341c656e1636221a53347caccbfc07c224 kernel: http://gitorious.org/beagleboard-validation/linux/commit/32fb278553a4cd6126c1791d70aa33df12f73d90 It's very ugly and needs a rethink before it can get posted to here, but it works great! The plan is to do this as part of the patchset to add support for the 37xx based beagleboardXM. Problem is that amount of expansion boards is practically unlimited so patching bootloader and board file could come quite maintenance effort. Of course there are some lets say generic boards but bunch of in-house, DIY, etc. boards and there is no point to patch common bootloader and kernel board files because of them. Just saveenv the kernel cmdline options in u-boot? People typing 'saveenv' without checking account for like half of the RMAs for beagleboards Also, the beagleboard xM has no NAND, so I'm using a boot.scr uboot script on SD to set params. But the problem we are trying to solve is this: Support all beagle expansion boards mentioned in http://elinux.org/BeagleBoardPinMux#Vendor_and_Device_IDs out of the box That means that a user can plug in an expansion board, apply power and it will just work. That's the case now for the zippy, zippy2, trainer and beaglefpga boards with the current u-boot and kernel setup. I agree it doesn't scale, but I haven't seen any actual effort by the beagleboard/omap3 community to make the muxing and initializing the board (i2c, spi, gpio, rtc) work completely in the kernel :( regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] AM3517: Add VPFE Capture driver support to board file
From: Karicheri, Muralidharan
Sent: Wednesday, June 02, 2010 7:31 PM
To: Hiremath, Vaibhav; linux-me...@vger.kernel.org
Cc: mche...@redhat.com; linux-omap@vger.kernel.org
Subject: RE: [PATCH 2/2] AM3517: Add VPFE Capture driver support to board file
Vaibhav,
See below my comments...
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, May 27, 2010 9:11 AM
To: linux-me...@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org; Hiremath, Vaibhav
Subject: [PATCH 2/2] AM3517: Add VPFE Capture driver support to board file
From: Vaibhav Hiremath hvaib...@ti.com
Also created vpfe master/slave clock aliases, since naming
convention is different in both Davinci and AM3517 devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 161
+
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index c1c4389..edcb6db 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,15 +30,168 @@
#include plat/board.h
#include plat/common.h
+#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include media/tvp514x.h
+#include media/davinci/vpfe_capture.h
+
#include mux.h
#define LCD_PANEL_PWR 176
#define LCD_PANEL_BKLIGHT_PWR 182
#define LCD_PANEL_PWM 181
+/*
+ * VPFE - Video Decoder interface
+ */
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+};
+
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity= 1,
+ .vs_polarity= 1
+};
+
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI1A,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5C),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static void am3517_evm_clear_vpfe_intr(int vdint)
+{
+ unsigned int vpfe_int_clr;
+
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+
+ switch (vdint) {
+ /* VD0 interrrupt */
+ case INT_35XX_CCDC_VD0_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ break;
+ /* VD1 interrrupt */
+ case INT_35XX_CCDC_VD1_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ break;
+ /* VD2 interrrupt */
+ case INT_35XX_CCDC_VD2_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ break;
+ /* Clear all interrrupts */
+ default:
+ vpfe_int_clr = ~(AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ vpfe_int_clr |= (AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ break;
+ }
+ omap_ctrl_writel(vpfe_int_clr, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs= ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 3,
+ .sub_devs = vpfe_sub_devs,
+ .clr_intr = am3517_evm_clear_vpfe_intr,
+ .card_name
Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code
On Wed, 2 Jun 2010 16:57:10 +0300 Tony Lindgren t...@atomide.com wrote: Problem is that amount of expansion boards is practically unlimited so patching bootloader and board file could come quite maintenance effort. Of course there are some lets say generic boards but bunch of in-house, DIY, etc. boards and there is no point to patch common bootloader and kernel board files because of them. Just saveenv the kernel cmdline options in u-boot? I meant that if kernel module could do muxing then there is no need the user to change muxings for different add-on boards. Works fine if you have one board but how about when amount of expansion boards grow? -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] kmemleak: Fix false positive with special scan
On Wed, 2010-06-02 at 12:34 +0100, Hiroshi DOYU wrote:
From: ext Catalin Marinas catalin.mari...@arm.com
Can we not add a new prio tree (or just use the existing one) for
pointer aliases? The advantage is that you only have a single function
to call, something like kmemleak_add_alias() and you do it at the point
the value was converted.
Actually I considered the above aliasing a little bit but I gave up
soon.
I was afraid that this method might consume way more memory since this
just adds another member for struct kmemleak_object, but adding a
single member for all objects. The number of kmemleak_object is
usually numerous.
We could use a different tree with a struct kmemleak_alias structure
which is much smaller. Something like below:
struct kmemleak_alias {
struct list_head alias_list;
struct prio_tree_node tree_node;
struct kmemleak_object *object;
}
And an alias_list member would be added to kmemleak_object as well.
Would the alias tree need to allow overlapping? Like different IOMMU
mappings with the same address (but pointing to different physical
memory).
--
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: Trying to understand how to use new OMAP mux code
Hello all How can I call omap_mux_init_signal() from external driver compiled as module ? cause the function is not in the standard path include files and is not exported regards, Laurent Le 11.03.2010 23:48, Tony Lindgren a écrit : * Peter Baradapeter.bar...@gmail.com [100311 14:29]: 1) Suppose I want to talk to a bluetooth chip through UART2. UART2_TX gives me a choice of pins to hook up to, either to pin AA26 in Mode0, or pin AF5 in Mode1. If I use omape_mux_init_signal(uart2_tx, OMAP_PIN_OUTPUT), which pin will that map to? You need to check the omap package type you're using to find out the correct ball name. If you get lucky, that's already in mux34xx.c and you don't need search through the TRMs :) 2) How can I tell the muxing code that I want a specific pin for my UART2_TX signal (that's not a GPIO since those can be directly specified by GPIO number)? Then you want to use the full signal name: omap_mux_init_signal(mode0_name.desired_mode, OMAP_PIN_FLAGS) But as the balls can be separate for each package type, you need to figure that out first. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Salutations Laurent Epinat - mailto:laurent.epi...@cioinfoindus.fr CIO Informatique Le millenium 1, rue de Presse - BP 710 42950 Saint-Etienne Cedex 9 Tel33 (0) 477 93 34 32 Tcopie 33 (0) 477 79 75 55 WWW : http://www.cioinfoindus.fr/ -- 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: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code
* Jarkko Nikula jhnik...@gmail.com [100602 17:06]: On Wed, 2 Jun 2010 16:57:10 +0300 Tony Lindgren t...@atomide.com wrote: Problem is that amount of expansion boards is practically unlimited so patching bootloader and board file could come quite maintenance effort. Of course there are some lets say generic boards but bunch of in-house, DIY, etc. boards and there is no point to patch common bootloader and kernel board files because of them. Just saveenv the kernel cmdline options in u-boot? I meant that if kernel module could do muxing then there is no need the user to change muxings for different add-on boards. Works fine if you have one board but how about when amount of expansion boards grow? Yeah having the modules do the platform device init and registration will lead into nasty conflicts. The platform device registration really needs to happen in the board-*.c files, not in the drivers. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code
On Wed, Jun 02, 2010 at 04:45:48PM +0200, ext Tony Lindgren wrote: Yeah having the modules do the platform device init and registration will lead into nasty conflicts. The platform device registration really needs to happen in the board-*.c files, not in the drivers. yeah, unless you had a way to register a particular platform_device conditionaly based on the attached daughter card, but then again, if you can detect the daughter card, you might as well use that information to do the muxing correctly on the board-*.c file. I have to agree modules are not supposed to change platform stuff. On the other hand, that could be used by EHCI/OHCI to implement port handoff on runtime: mux all usb ports to ehci, if enumeration fails, remux ports to ohci and try again. -- balbi DefectiveByDesign.org -- 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: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code
* Felipe Balbi felipe.ba...@nokia.com [100602 17:50]: I have to agree modules are not supposed to change platform stuff. On the other hand, that could be used by EHCI/OHCI to implement port handoff on runtime: mux all usb ports to ehci, if enumeration fails, remux ports to ohci and try again. To do that all we have to do is to do is have the pin remux function in mach-omap2/*hci.c, then pass a pointer to that function to the *hci glue driver. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: 2010/6/1 James Bottomley james.bottom...@suse.de: On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote: On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley james.bottom...@suse.de wrote: On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote: On Tuesday 01 June 2010, James Bottomley wrote: On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. As long as you can set a wakeup timer, an S state is just a C state with side effects. The significant one is that entering an S state stops the process scheduler and any in-kernel timers. I don't think Google care at all about whether suspend is entered through an explicit transition or something hooked into cpuidle - the relevant issue is that they want to be able to express a set of constraints that lets them control whether or not the scheduler keeps on scheduling, and which doesn't let them lose wakeup events in the process. Exactly, so my understanding of where we currently are is: Thanks for the recap. 1. pm_qos will be updated to be able to express the android suspend blockers as interactivity constraints (exact name TBD, but probably /dev/cpu_interactivity) I think that's not been decided yet precisely enough. I saw a few ideas here and there in the thread, but which of them are we going to follow? Well, android only needs two states (block and don't block), so that gets translated as 2 s32 values (say 0 and INT_MAX). I've seen defines like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to describe these, but if all we're arguing over is the define name, that's progress. I think we need separate state constraints for suspend and idle low power modes. On the msm platform only a subset of the interrupts can wake up from the low power mode, so we block the use if the low power mode from idle while other interrupts are enabled. We do not block suspend however if those interrupts are not marked as wakeup interrupts. Most constraints that prevent suspend are not hardware specific and should not prevent entering low power modes from idle. In other words we may need to prevent low power idle modes while allowing suspend, and we may need to prevent suspend while allowing low power idle modes. Well, as I said, pm_qos is s32 ... it's easy to make the constraint ternary instead of binary. No, they have to be two separate constraints, otherwise a constraint to block suspend would override a constraint to block a low power idle mode or the other way around. Depends. If you block the system from going into low power idle, does that mean you still want it to be fully suspended? If yes, then we do have independent constraints. If not, they have a hierarchy: * Fully Interactive (no low power idle or suspend) * Partially Interactive (may go into low power idle but not suspend) * None (may go into low power idle or suspend) Which is expressable as a ternary constraint. James -- 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] OMAP: GPIO: fix auto-disable of debounce clock
The addition of the new debounce code (commit 168ef3d9a56bd8bffe0ef4189c450888b4aefefe) broke the auto-disable of debounce clocks on idle by forgetting to update the debounce clock enable mask. Add back the updating of bank-dbck_enable_mask so debounce clocks are auto-disabled. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- Please include for 2.6.35-rc series. arch/arm/plat-omap/gpio.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index 393e921..9b7e354 100644 --- a/arch/arm/plat-omap/gpio.c +++ b/arch/arm/plat-omap/gpio.c @@ -673,6 +673,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank, unsigned gpio, if (cpu_is_omap34xx() || cpu_is_omap44xx()) clk_disable(bank-dbck); } + bank-dbck_enable_mask = val; __raw_writel(val, reg); } -- 1.7.0.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code
Felipe Balbi wrote: On Wed, Jun 02, 2010 at 04:45:48PM +0200, ext Tony Lindgren wrote: Yeah having the modules do the platform device init and registration will lead into nasty conflicts. The platform device registration really needs to happen in the board-*.c files, not in the drivers. yeah, unless you had a way to register a particular platform_device conditionaly based on the attached daughter card, but then again, if you can detect the daughter card, you might as well use that information to do the muxing correctly on the board-*.c file. I have to agree modules are not supposed to change platform stuff. On the other hand, that could be used by EHCI/OHCI to implement port handoff on runtime: mux all usb ports to ehci, if enumeration fails, remux ports to ohci and try again. FWIW, this specific configuration is not supported on OMAP3s today. You cannot dynamically hand off from EHCI to OHCI - the issue being that we don't have a single PHY that can talk both interface languages on the exact same pads as the OMAP. One other case I can think of where you might want to change mux modes dynamically is as a workaround for an errata. For instance, you might want to mux a particular pad to safe-mode when entering off-mode and mux it back to a functional mode after exiting off-mode. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: simple sd card performance bug fix on OMAP
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Friday, May 28, 2010 2:55 PM To: Stephen Schwarm, CSDP; linux-omap@vger.kernel.org Subject: RE: simple sd card performance bug fix on OMAP Stephen Schwarm, CSDP wrote: I have not had time to make a formal patch for this but I thought it was significant enough just to send it out. The problem is on omap systems that use omap_hsmmc.c to run sd or mmc cards. If the system you are using has an 8 wire interface, it will only use a one wire interface to 4 wire cards (eg, sd class 4 and sd class 6). In the file driver/mmc/omap_hsmmc.c in the function omap_hsmmc_probe: at about line 1739 change: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; else if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; to: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) mmc-caps |= w; just delete the word else. This sets the MMC_CAP_4_BIT_DATA bit on interfaces that have 8 wire interfaces. We have seen a BIG performance improvement on our systems. Thanks for reporting this. A similar patch was posted a while ago and is currently marked as awaiting upstream, although it looks like it got lost again. https://patchwork.kernel.org/patch/78713/ A revised version of the same patch was posted. https://patchwork.kernel.org/patch/93519/ Tony, Can you please push this? Regards, Madhu - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 2, 2010 at 1:06 AM, Neil Brown ne...@suse.de wrote: On Wed, 2 Jun 2010 00:05:14 -0700 Arve Hjønnevåg a...@android.com wrote: The user-space suspend daemon avoids losing wake-events by using fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event is ready to be read by user-space. This may involve: - the one daemon processing all wake events Wake up events are not all processed by one daemon. Not with your current user-space code, no. Are you saying that you are not open to any significant change in the Android user-space code? That would make the situation a lot harder to resolve. There are many wakeup events possible in a typical system -- keypresses or other input events, network traffic, telephony events, media events (fill audio buffer, fill video decoder buffer, etc), and I think requiring that all wakeup event processing bottleneck through a single userspace process is non-optimal here. The current suspend-blocker proposal already involves userspace changes (it's different than our existing wakelock interface), and we're certainly not opposed to any/all userspace changes on principle, but on the other hand we're not interested in significant reworks of userspace unless they actually improve the situation somehow. I think bottlenecking events through a central daemon would represent a step backwards. Brian -- 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] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 21:02:24 +1000 Neil Brown ne...@suse.de wrote: And this decision (to block suspend) really needs to be made in the driver, not in userspace? Well, it fits. The requirement is a direct consequence of the intimate knowledge the driver has about the driven devices. Or if you get in an upper layer, the knowledge that the subsystem has about it's requirements to function properly. Why would you separate it out? If all your drivers specify their needed requirements, the pm-core (or idle) has the maximum flexibility to implement any strategy and is guaranteed a stable system as long as it honours the given requirements. (That's the theory, of course.) You could get those drivers to return EBUSY from PM_SUSPEND_PREPARE (which would need to be a configurable option), but then I guess you have no way to wait for the device to become non-busy. If user-space really cannot tell if the driver is busy or not, then I would suggest that the driver is fairly poorly designed. In general, userspace has no business knowing if the driver is busy or not. It would need intimate knowledge about the driver to determine if it is busy or not. That is what the kernel is all about, to hide that knowledge from userspace and masking it with a one-fits-all-API. It would seem then that a user-space requested suspend is not sufficient for your needs even if we remove the race window, as you have drivers that want to avoid suspend indefinitely, and that need to avoid suspend status is not visible from user-space. Well, but the kernel-solution and the userspace solution should be pretty independent. The tricky part here seems to be to have a kernel-userspace-boundary that doesn't require a specific kernel implementation and works. Could someone perhaps make a recap on what are the problems with the API? I have no clear eye (experience?) for that (or so it seems). It is a pity that this extra requirement was not clear from your introduction to the Opportunistic suspend support patch. I think that the main problem was that _all_ the requirements were not communicated well. That caused everybody to think that their solution would be a better fit. You are not alone. If that be the case, I'll stop bothering you with suggestions that can never work. Thanks for your time, NeilBrown Don't be frustrated. What should Arve be? :) Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 02 Jun 2010 10:05:11 -0500 James Bottomley james.bottom...@suse.de wrote: On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: No, they have to be two separate constraints, otherwise a constraint to block suspend would override a constraint to block a low power idle mode or the other way around. Depends. If you block the system from going into low power idle, does that mean you still want it to be fully suspended? If yes, then we do have independent constraints. If not, they have a hierarchy: * Fully Interactive (no low power idle or suspend) * Partially Interactive (may go into low power idle but not suspend) * None (may go into low power idle or suspend) Which is expressable as a ternary constraint. James But unblocking suspend at the moment is independent to getting idle. If you have the requirement to stay in the highest-idle level (i.e. best latency you can get) that does not (currently) mean, that you can not suspend. To preserve that explicit fall-through while still having working run-time-powermanagement I think the qos-constraints need to be separated. disclaimer: just from what I read Provided you can reach the same power state from idle, current suspend could probably also be implemented by just the freezing part and a hint to the idle-loop to provide accelerated fall-through to lowest power. /disclaimer At that point, you could probably merge the constraints. But the freezing part is also the hard part, isn't it? (I have no idea. Thomas seems to think about cgroups for that and doing smth about the timers.) Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 02 Jun 2010 12:21:28 +0200 Peter Zijlstra pet...@infradead.org wrote: On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote: 2010/6/2 Peter Zijlstra pet...@infradead.org: On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote: No I want you to stop confusing low power idle modes with suspend. I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state. No, idle is transparent, suspend is not. Which is where the problem is, it should be. Why would I add suspend blockers to the code I want to prevent running? Because what you want might not be what others want. Suppose you're fine with your torrent client/irc client/etc.. to loose their network connection when you're not behind your desktop so you don't add suspend blockers there. Me, I'd be ready to administer physical violence if either of those lost their connections when I wasn't around to keep the screen-saver from kicking in. Do you switch your pc on and off manually? Sometimes? Really? (if not, you are probably a kernel hacker *g*) I assume, in general, there are only a few reasons to shut down a machine: 1. One has to do maintainance on the hardware or somehow needs to interrupt the power supply. 2. One wants to save power. 3. One wants to go easy on the hardware. 4. ...? Obviously, for reason 1 we need to maintain the shutdown-paths indefinitely. But the rest are usecases that are similar to the suspend-blocker usecases. You know that you are not using the machine and going through the pain to shut down your machine. You have to do it manually. Why? This leads to having to sprinkle magic dust (and lots of config options) all over userspace. Something that gets esp interesting with only a boolean interface. A userspace daemon could keep track of what applications can be ignored. The wordprocessor probably should not keep the system busy. As well as a running firefox. It is a hard problem. But we have _no way of deciding any of this in the kernel_! In the example above, having an active net connection would prevent my desktop from suspending, but what if another platform can maintain net connections while suspended? Do we then end up with arch specific code in the net-stack? I'm sure DaveM would love that. If it is driver knowledge, then it goes into the driver. If it is platform knowledge, then it goes into the platform code. I think that is a clear requirement to keeping sanity. The problem is there independently of suspend blockers. If the system can suspend with network up, then you shure as hell want to suspend even if the network is up. So it would actually be a reason for any kind of suspend blockers scheme. Wouldn't it? Cheers, Flo -- 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
Physical NAND corruption due to extended use
Hi, I've got android-2.6.29 kernel and android-1.5r3 SDK version running on a gumstix Overo Earth (TI OMAP 3503), and I'm using the platform to implement a data logging application. The partition has been configured as read-write /dev/mtd4, with a merged rootfs and system folder. There are no separate /userdata and /cache partitions, all the rootfs, system, userdata and cache folders are on the /dev/mtd4 partition in rw mode. Now after 3 days of extended use and continuous writing, we suspect a potential corruption of the NAND device (a micron 256MB FLASH, 256MB RAM POP module). Has anyone else found micron NAND devices to get corrupted due to extended use? What options should I consider if I want to run my application from NAND and write data to the on-board NAND, and run the application reliably without corrupting the NAND device for at least 5 years? I am using the YAFFS2 filesystem. Best regards, Elvis Dowson -- 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: Physical NAND corruption due to extended use
Not sure if its of any use to you, but we had a similar situation and we are now looking at UBI (http://www.linux-mtd.infradead.org/doc/ubi.html). We use JFFS2 and we are considering using it over UBI. We had problems of data corruption in the flash so we now mount only partitions with writable data as RW. Rest of them remain RO and gets remounted as RW only when we want to write to it. Once written, we mount it RO again. Suresh On Wed, Jun 2, 2010 at 12:14 PM, Elvis Dowson elvis.dow...@mac.com wrote: Hi, I've got android-2.6.29 kernel and android-1.5r3 SDK version running on a gumstix Overo Earth (TI OMAP 3503), and I'm using the platform to implement a data logging application. The partition has been configured as read-write /dev/mtd4, with a merged rootfs and system folder. There are no separate /userdata and /cache partitions, all the rootfs, system, userdata and cache folders are on the /dev/mtd4 partition in rw mode. Now after 3 days of extended use and continuous writing, we suspect a potential corruption of the NAND device (a micron 256MB FLASH, 256MB RAM POP module). Has anyone else found micron NAND devices to get corrupted due to extended use? What options should I consider if I want to run my application from NAND and write data to the on-board NAND, and run the application reliably without corrupting the NAND device for at least 5 years? I am using the YAFFS2 filesystem. Best regards, Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wednesday 02 June 2010, Neil Brown wrote: On Tue, 1 Jun 2010 12:50:01 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Tue, 1 Jun 2010, Neil Brown wrote: I think you have acknowledged that there is a race with suspend - thanks. Next step was can it be closed. You seem to suggest that it can, but you describe it as a work around rather than a bug fix... Do you agree that the race is a bug, and therefore it is appropriate to fix it assuming an acceptable fix can be found (which I think it can)? If we can fix it, yes we definitely should do and not work around it. Thanks, tglx OK. Here is my suggestion. While I think this patch would actually work, and hope the ugly aspects are reasonably balanced by the simplicity, I present it primarily as a base for improvement. The important part is to present how drivers and user-space can co-operate to avoid losing wake-events. The details of what happens in the kernel are certainly up for discussion (as is everything else really of course). The user-space suspend daemon avoids losing wake-events by using fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event is ready to be read by user-space. This may involve: - the one daemon processing all wake events - Both the suspend daemon and the main event handling daemon opening any given device that delivers wake events (this should work with input events ... unless grabbing is needed) - The event handling daemon giving the suspend-daemon's pid as F_OWNER, and using poll/select to get the events itself. When 'mem' is written to /sys/power/state, suspend_prepare waits in an interruptible wait until any wake-event that might have been initiated before the suspend was request, has had a chance to be queued for user-space and trigger kill_fasync. Currently this wait is a configurable time after the last wake-event was initiated. This is hackish, but simple and probably adequate. If more precise timing is needed and achievable, that can be added later. It would be an entirely internal change and would not affect the API further. Some of the code developed for suspend-blockers might be a starting point for this. Drivers should call pm_suspend_delay() whenever a wake-event occurs. This simply records the time so that the suspend process knows if there is in fact any need to wait at all. The delay to wait after the last pm_suspend_delay() is limited to 10 seconds and can be set by kernel parameter suspend_block_delay=number-of-milliseconds It defaults to 2 jiffies (which is possibly too short). - Would this fix the bug?? - and address the issues that suspend-blockers was created to address? - or are the requirements on user-space too onerous? In theory wakeup events can also happen after wait_for_blockers() has returned 0 and I guess we should rollback the suspend in such cases. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: On Wed, 02 Jun 2010 10:05:11 -0500 James Bottomley james.bottom...@suse.de wrote: On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: No, they have to be two separate constraints, otherwise a constraint to block suspend would override a constraint to block a low power idle mode or the other way around. Depends. If you block the system from going into low power idle, does that mean you still want it to be fully suspended? If yes, then we do have independent constraints. If not, they have a hierarchy: * Fully Interactive (no low power idle or suspend) * Partially Interactive (may go into low power idle but not suspend) * None (may go into low power idle or suspend) Which is expressable as a ternary constraint. James But unblocking suspend at the moment is independent to getting idle. If you have the requirement to stay in the highest-idle level (i.e. best latency you can get) that does not (currently) mean, that you can not suspend. I don't understand that as a reason. If we looks at this a qos constraints, you're saying that the system may not drop into certain low power states because it might turn something off that's currently being used by a driver or a process. Suspend is certainly the lowest state of that because it turns everything off, why would it be legal to drop into that? I also couldn't find this notion of separation of idleness power from suspend blocking in the original suspend block patch set ... if you can either tell me where it is, or give me an example of the separated use cases, I'd understand better. To preserve that explicit fall-through while still having working run-time-powermanagement I think the qos-constraints need to be separated. OK, as above, why? or better yet, just give an example. disclaimer: just from what I read Provided you can reach the same power state from idle, current suspend could probably also be implemented by just the freezing part and a hint to the idle-loop to provide accelerated fall-through to lowest power. /disclaimer At that point, you could probably merge the constraints. But the freezing part is also the hard part, isn't it? (I have no idea. Thomas seems to think about cgroups for that and doing smth about the timers.) Um, well, as I said, I think using suspend from idle and freezer is longer term. I think if we express the constraints as qos android can then use them to gate when to enter S3 .. which is functionally equivalent to suspend blockers. And the vanilla kernel can use them to gate power states for the drivers in suspend from idle. James -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wednesday 02 June 2010, Neil Brown wrote: On Tue, 1 Jun 2010 10:47:49 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: ... So yes, there are different use cases and we should support all of them, both I shut the lid and my laptop really stays asleep and I never miss a TXT because my phone went to sleep at a bad time. The process that initiates the suspend has a role in choosing what can wake it up. You'd need to add some all new infrastructure for that, because right now only hardware wakeup signals are regarded as (system) wakeup events (they are either interrupts or things like PCI PMEs, possibly translated to some platform signals like GPIOs or something). I think I know how to prevent these hardware wakeup events from being lost (such that the entire suspend will be aborted if one of them happens during suspend), but for the handling of more generally defined wakeup events we'd need to provide user space with information on what wakeup events are available and how to enable and disable them, among other things. 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] [MMC] omap: Remove BUG_ON for disabled interrupts
On Sat, 29 May 2010 19:27:23 -0700 Cory Maccarrone darkstar6...@gmail.com wrote: This change removes a BUG_ON for when interrupts are disabled during an MMC request. During boot, interrupts can be disabled when a request is made, causing this bug to be triggered. In reality, there's no reason this should halt the kernel, as the driver has proved reliable in spite of disabled interrupts, and additionally, there's nothing in this code that would require interrupts to be enabled. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- drivers/mmc/host/omap.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c index 2b28168..d98ddcf 100644 --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host, mmc_omap_start_command(host, req-cmd); if (host-dma_in_use) omap_start_dma(host-dma_ch); - BUG_ON(irqs_disabled()); } static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req) So we need to decide whether this should be backported into 2.6.34.x and perhaps earlier. For that decision we'll need to know the things you didn't tell us: Which drivers are affected? Under which setups is it triggering? Why aren't lots of people reporting hey my kernel went BUG? -- 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] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 22:41:14 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday 02 June 2010, Neil Brown wrote: - Would this fix the bug?? - and address the issues that suspend-blockers was created to address? - or are the requirements on user-space too onerous? In theory wakeup events can also happen after wait_for_blockers() has returned 0 and I guess we should rollback the suspend in such cases. I naively assumed this was already the case, but on a slightly closer look at the code it seems not. Presumably there is some point deep in the suspend code, probably after the call to sysdev_suspend, where interrupts are disabled and we are about to actually suspend. At that point a simple is a roll-back required test could abort the suspend. Then any driver that handles wake-up events, if it gets and event that (would normally cause a wakeup) PM_SUSPEND_PREPARE and PM_POST_SUSPEND, could set the roll-back is required flag. ?? NeilBrown -- 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] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 03 June 2010, Neil Brown wrote: On Wed, 2 Jun 2010 22:41:14 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday 02 June 2010, Neil Brown wrote: - Would this fix the bug?? - and address the issues that suspend-blockers was created to address? - or are the requirements on user-space too onerous? In theory wakeup events can also happen after wait_for_blockers() has returned 0 and I guess we should rollback the suspend in such cases. I naively assumed this was already the case, but on a slightly closer look at the code it seems not. Presumably there is some point deep in the suspend code, probably after the call to sysdev_suspend, where interrupts are disabled and we are about to actually suspend. At that point a simple is a roll-back required test could abort the suspend. Yes. Then any driver that handles wake-up events, if it gets and event that (would normally cause a wakeup) PM_SUSPEND_PREPARE and PM_POST_SUSPEND, could set the roll-back is required flag. That's my idea, but instead of setting a flag, I'd use a counter increased every time there is a wakeup event. Then, the core suspend core code would store a pre-suspend value of the counter and compare it with the current value after all wakeup event sources had been set. If they were different, the suspend would be aborted. 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] [MMC] omap: Remove BUG_ON for disabled interrupts
On Wed, Jun 2, 2010 at 2:05 PM, Andrew Morton a...@linux-foundation.org wrote: On Sat, 29 May 2010 19:27:23 -0700 Cory Maccarrone darkstar6...@gmail.com wrote: This change removes a BUG_ON for when interrupts are disabled during an MMC request. During boot, interrupts can be disabled when a request is made, causing this bug to be triggered. In reality, there's no reason this should halt the kernel, as the driver has proved reliable in spite of disabled interrupts, and additionally, there's nothing in this code that would require interrupts to be enabled. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- drivers/mmc/host/omap.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c index 2b28168..d98ddcf 100644 --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host, mmc_omap_start_command(host, req-cmd); if (host-dma_in_use) omap_start_dma(host-dma_ch); - BUG_ON(irqs_disabled()); } static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req) So we need to decide whether this should be backported into 2.6.34.x and perhaps earlier. For that decision we'll need to know the things you didn't tell us: Which drivers are affected? Under which setups is it triggering? Why aren't lots of people reporting hey my kernel went BUG? The only setup I've managed to make it trigger on is on the HTC Herald during bootup when the driver is built into the kernel (mostly because that's all I have). I believe it's related to the fact that on bootup I get many timeout errors on CMD5 while initializing the card. Each CMD5 timeout triggers that bug (I changed it to a WARN_ON to get it to boot in) due to the fact that part of the timeout code involves sending the request again. With interrupts turned off, that BUG would be triggered. I can't answer the question of why other people aren't reporting this -- I know the CMD timeouts are fairly common with this driver, and it's only within the last few kernel releases that their triggering the BUG started happening. (I had only been able to test it because I was carrying forward the MMC 16-bit patch I submitted a while ago which only recently made it in. I'm not sure if that's related or not, but I need that to use the MMC-OMAP on herald.) I imagine a better solution to this would be to fix the timeout issues so the repeated requests aren't a problem. But any hardware bugs that cause a timeout during boot would cause this bug to be triggered, which is why I'm proposing removing the BUG_ON entirely (since everything seems to work fine anyway). I don't know why interrupts are disabled at this point, but my limited googling around leads me to believe the recent LOCKDEP work may be the cause. I couldn't find enough information on that to know for sure though. I do know that the bug no longer triggers after the card initializes successfully (and presumably interrupts re-enable). My guess is that since other people aren't reporting this problem, it's not hugely important to backport. A better question in that case would be why am I seeing it? I don't understand why interrupts would be disabled at this point in bootup. - Cory -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley james.bottom...@suse.de wrote: On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: On Wed, 02 Jun 2010 10:05:11 -0500 James Bottomley james.bottom...@suse.de wrote: On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: No, they have to be two separate constraints, otherwise a constraint to block suspend would override a constraint to block a low power idle mode or the other way around. Depends. If you block the system from going into low power idle, does that mean you still want it to be fully suspended? If yes, then we do have independent constraints. If not, they have a hierarchy: * Fully Interactive (no low power idle or suspend) * Partially Interactive (may go into low power idle but not suspend) * None (may go into low power idle or suspend) Which is expressable as a ternary constraint. James But unblocking suspend at the moment is independent to getting idle. If you have the requirement to stay in the highest-idle level (i.e. best latency you can get) that does not (currently) mean, that you can not suspend. I don't understand that as a reason. If we looks at this a qos constraints, you're saying that the system may not drop into certain low power states because it might turn something off that's currently being used by a driver or a process. Suspend is certainly the lowest state of that because it turns everything off, why would it be legal to drop into that? Because the driver gets called on suspend which gives it a change to stop using it. I also couldn't find this notion of separation of idleness power from suspend blocking in the original suspend block patch set ... if you can either tell me where it is, or give me an example of the separated use cases, I'd understand better. The suspend block patchset only deals with suspend, not low power idle modes. The original wakelock patchset had two wakelock types, idle and suspend. To preserve that explicit fall-through while still having working run-time-powermanagement I think the qos-constraints need to be separated. OK, as above, why? or better yet, just give an example. The i2c bus on the Nexus One is used by the other core to turn off the power you our core when we enter the lowest power mode. This means that we cannot enter that low power mode while the i2c bus is active, so we block low power idle modes. At some point we also tries to block suspend in this case, but this caused a lot of failed suspend attempts since the frequency scaling code would try to ramp up while freezing processes which in turn aborted the process freezing attempts. disclaimer: just from what I read Provided you can reach the same power state from idle, current suspend could probably also be implemented by just the freezing part and a hint to the idle-loop to provide accelerated fall-through to lowest power. /disclaimer At that point, you could probably merge the constraints. But the freezing part is also the hard part, isn't it? (I have no idea. Thomas seems to think about cgroups for that and doing smth about the timers.) Um, well, as I said, I think using suspend from idle and freezer is longer term. I think if we express the constraints as qos android can then use them to gate when to enter S3 .. which is functionally equivalent to suspend blockers. And the vanilla kernel can use them to gate power states for the drivers in suspend from idle. James -- Arve Hjønnevå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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 15:27 -0700, Arve Hjønnevåg wrote: On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley james.bottom...@suse.de wrote: On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: On Wed, 02 Jun 2010 10:05:11 -0500 James Bottomley james.bottom...@suse.de wrote: On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: No, they have to be two separate constraints, otherwise a constraint to block suspend would override a constraint to block a low power idle mode or the other way around. Depends. If you block the system from going into low power idle, does that mean you still want it to be fully suspended? If yes, then we do have independent constraints. If not, they have a hierarchy: * Fully Interactive (no low power idle or suspend) * Partially Interactive (may go into low power idle but not suspend) * None (may go into low power idle or suspend) Which is expressable as a ternary constraint. James But unblocking suspend at the moment is independent to getting idle. If you have the requirement to stay in the highest-idle level (i.e. best latency you can get) that does not (currently) mean, that you can not suspend. I don't understand that as a reason. If we looks at this a qos constraints, you're saying that the system may not drop into certain low power states because it might turn something off that's currently being used by a driver or a process. Suspend is certainly the lowest state of that because it turns everything off, why would it be legal to drop into that? Because the driver gets called on suspend which gives it a change to stop using it. I also couldn't find this notion of separation of idleness power from suspend blocking in the original suspend block patch set ... if you can either tell me where it is, or give me an example of the separated use cases, I'd understand better. The suspend block patchset only deals with suspend, not low power idle modes. The original wakelock patchset had two wakelock types, idle and suspend. OK, so that explains why I didn't see it ... To preserve that explicit fall-through while still having working run-time-powermanagement I think the qos-constraints need to be separated. OK, as above, why? or better yet, just give an example. The i2c bus on the Nexus One is used by the other core to turn off the power you our core when we enter the lowest power mode. This means that we cannot enter that low power mode while the i2c bus is active, so we block low power idle modes. At some point we also tries to block suspend in this case, but this caused a lot of failed suspend attempts since the frequency scaling code would try to ramp up while freezing processes which in turn aborted the process freezing attempts. OK, so this is a device specific power constraint state. I suppose it makes sense to have a bunch of those, because the device isn't necessarily going to know what idle power mode it can't go into, so the cpu govenor should sort it out rather than have the device specify a minimum state. James -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 02 Jun 2010 15:41:11 -0500 James Bottomley james.bottom...@suse.de wrote: On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: On Wed, 02 Jun 2010 10:05:11 -0500 James Bottomley james.bottom...@suse.de wrote: On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: No, they have to be two separate constraints, otherwise a constraint to block suspend would override a constraint to block a low power idle mode or the other way around. Depends. If you block the system from going into low power idle, does that mean you still want it to be fully suspended? If yes, then we do have independent constraints. If not, they have a hierarchy: * Fully Interactive (no low power idle or suspend) * Partially Interactive (may go into low power idle but not suspend) * None (may go into low power idle or suspend) Which is expressable as a ternary constraint. James But unblocking suspend at the moment is independent to getting idle. If you have the requirement to stay in the highest-idle level (i.e. best latency you can get) that does not (currently) mean, that you can not suspend. I don't understand that as a reason. If we looks at this a qos constraints, you're saying that the system may not drop into certain low power states because it might turn something off that's currently being used by a driver or a process. Suspend is certainly the lowest state of that because it turns everything off, why would it be legal to drop into that? I also couldn't find this notion of separation of idleness power from suspend blocking in the original suspend block patch set ... if you can either tell me where it is, or give me an example of the separated use cases, I'd understand better. To preserve that explicit fall-through while still having working run-time-powermanagement I think the qos-constraints need to be separated. OK, as above, why? or better yet, just give an example. Hm. Maybe it is me who doesn't understand. With proposed patchset: 1. As soon as we unblock suspend we go down. (i.e. suspending) 2. While suspend is blocked, the idle-loop does it's things. (i.e. runtime power managment - can give same power-result as suspend) possible cases: 1: - qos-latency-constraints: 1ms, [here: forbids anything other than C1 idle state.] - suspend is blocked 2: - qos latency-constraints: as in 1 - suspend unblocked 3: - qos latency-constraints: infinity, cpu in lowest power state. - suspend is blocked 4: - qos latency-constraints: infinity, cpu in lowest power state. - suspend unblocked in case 2 and 4 we would suspend, regardeless of the qos-latency. in case 1 and 3 we would stay awake, regardeless of the qos-latency constraint. If only one constraint, then case 2 (or 3) wouldn't be possible. But it is possible now. A possible use case as an example? (hmm... i'm trying my imagination hard now): Your sound needs low latency, so that could be a cause for the qos-latency constraint. And unblocking suspend could nonetheless happen: For example... you have an firefox open and don't want to prevent suspend for that case when the display is turned off Cheers, Flo -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
-Original Message- From: Florian Mickler [mailto:flor...@mickler.org] Sent: Wednesday, June 02, 2010 4:06 PM To: James Bottomley Cc: Arve Hjønnevåg; Neil Brown; ty...@mit.edu; Peter Zijlstra; LKML; Alan Cox; Gross, Mark; Thomas Gleixner; Linux OMAP Mailing List; Linux PM; felipe.ba...@nokia.com Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) On Wed, 02 Jun 2010 15:41:11 -0500 James Bottomley james.bottom...@suse.de wrote: On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: On Wed, 02 Jun 2010 10:05:11 -0500 James Bottomley james.bottom...@suse.de wrote: On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: No, they have to be two separate constraints, otherwise a constraint to block suspend would override a constraint to block a low power idle mode or the other way around. Depends. If you block the system from going into low power idle, does that mean you still want it to be fully suspended? If yes, then we do have independent constraints. If not, they have a hierarchy: * Fully Interactive (no low power idle or suspend) * Partially Interactive (may go into low power idle but not suspend) * None (may go into low power idle or suspend) Which is expressable as a ternary constraint. James But unblocking suspend at the moment is independent to getting idle. If you have the requirement to stay in the highest-idle level (i.e. best latency you can get) that does not (currently) mean, that you can not suspend. I don't understand that as a reason. If we looks at this a qos constraints, you're saying that the system may not drop into certain low power states because it might turn something off that's currently being used by a driver or a process. Suspend is certainly the lowest state of that because it turns everything off, why would it be legal to drop into that? I also couldn't find this notion of separation of idleness power from suspend blocking in the original suspend block patch set ... if you can either tell me where it is, or give me an example of the separated use cases, I'd understand better. To preserve that explicit fall-through while still having working run-time-powermanagement I think the qos-constraints need to be separated. OK, as above, why? or better yet, just give an example. Hm. Maybe it is me who doesn't understand. With proposed patchset: 1. As soon as we unblock suspend we go down. (i.e. suspending) 2. While suspend is blocked, the idle-loop does it's things. (i.e. runtime power managment - can give same power-result as suspend) possible cases: 1: - qos-latency-constraints: 1ms, [here: forbids anything other than C1 idle state.] - suspend is blocked 2: - qos latency-constraints: as in 1 - suspend unblocked 3: - qos latency-constraints: infinity, cpu in lowest power state. - suspend is blocked 4: - qos latency-constraints: infinity, cpu in lowest power state. - suspend unblocked in case 2 and 4 we would suspend, regardeless of the qos-latency. in case 1 and 3 we would stay awake, regardeless of the qos-latency constraint. If only one constraint, then case 2 (or 3) wouldn't be possible. But it is possible now. A possible use case as an example? (hmm... i'm trying my imagination hard now): Your sound needs low latency, so that could be a cause for the qos-latency constraint. And unblocking suspend could nonetheless happen: For example... you have an firefox open and don't want to prevent suspend for that case when the display is turned off [mtg: ] This has been a pain point for the PM_QOS implementation. They change the constrain back and forth at the transaction level of the i2c driver. The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is. We've had a number of attempts at fixing this, but I think the proper fix is to bolt a disable C-states x interface into cpu_idle that bypases pm_qos altogether. Or, perhaps add a new pm_qos API that does the equivalent operation, overriding whatever constraint is active. --mgross -- 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] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 21:05:21 +0200 Florian Mickler flor...@mickler.org wrote: Could someone perhaps make a recap on what are the problems with the API? I have no clear eye (experience?) for that (or so it seems). Good interface design is an acquired taste. And it isn't always easy to explain satisfactorily. But let me try to explain what I see. A key aspect of a good interface is unity, and sometimes uniformity. For example, the file descriptor is a key element to the unity of the Unix (and hence Posix and Linux) interface. everything is a file and even when it isn't, everything is accessed via a file descriptor. This is one of the reasons that signals cause so much problem when programming in Unix - they aren't files, don't have file descriptors and don't look them at all. That is why signalfd was created, to try to tie signals back in to the 'file descriptor' model. So unity is important. Adding new concepts is best done as an extension of an existing concept. That means that all the infrastructure, not only code and design but also developer understanding, can be leveraged to help get the new concept *right* first time. It also means that using the new concept is easier to learn. So the problem with the wake-locks / suspend-blockers (and I've actually come to like the first name much more) is that it introduces a new concept without properly leveraging existing concepts. The new concept is opportunistic suspend, though maybe a better name would be automatic suspend - not sure. There appear to be two ways you can get opportunistic suspend leveraging already-existing concepts. One is to leverage the current power/state = mem architecture and just let userspace choose the opportune moment. The user-space daemon that chooses this moment would need full information about states of various things to do this, but sysfs is good at providing full information about what is in the kernel, and there are dozens of ways for user-space processes to communicate their state to each other. So this is all doable today without introducing new design concepts. Except there is a race between suspending and new events, so we just need to fix the race. Hence my patch. The other is to leverage the more general power management infrastructure. We can already detect when the processor won't be needed for a while, and put it into a low-power state. We can already put devices to sleep when they aren't being used. We can just generalise this so that we can detect when all devices are either unused, or capable of supporting an S3 transition, and detect when the next timer interrupt is far enough in the future that S3 latency wont be a problem - set the rtc alarm to match the next timer and go to S3. All completely transparent. (I admit I'm not entirely sure what the qos that is being discussed brings us, but I assume it is better quality rather than correctness). So there are at least two different ways that opportunistic suspend could be integrated into existing infrastructure with virtually no change of interface and no new concepts - just refining or extending existing concepts. Yet the approach used and preferred by android is to create something substantially new. Yes, it does use the existing suspend infrastructure, but in a very new and different way. Suspend is now initiated by the kernel, but in a completely different way to the ways that the kernel already initiates power saving. So we have two infrastructures for essentially one task. Looked at the other way, it moves the initiation of suspend from user-space into the kernel, and then allows user-space to tell the kernel not to suspend. That to me is very ugly. In general, the kernel should provide information to user-space, and provide services to user-space, and user-space should use that information to decide what services to request. This is the essence the policy lives in user-space maxim. The Android code has user-space giving information to the kernel, so the kernel can make a policy decision. This approach is generally less flexible and is best avoided. Just as a bit of background, let's think about some of the areas in the kernel where the kernel does make policy decisions based on user-space input. - the scheduler - based on 'nice' setting it decided who should run when - the VM - based on read-ahead settings, madvise/fadvise, recent-use heuristics, it tries to decide what to keep in memory and what to swap out. I think those are the main ones. There are other smaller fish like the choice of IO scheduler and various ways to tune network connections. But the two big ones are perfect examples of subsystems that have proven very hard to get *right*, and have been substantially re-written more than once. In each case, the difficulty wasn't how to perform the work, it was the choice of what work to perform. It probably also involved getting different sorts of information about the current state. That perspective leaves me
Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote: On Wed, 2 Jun 2010 21:02:24 +1000 Neil Brown ne...@suse.de wrote: And this decision (to block suspend) really needs to be made in the driver, not in userspace? Well, it fits. The requirement is a direct consequence of the intimate knowledge the driver has about the driven devices. That is not really true. A driver does have intimate knowledge of the device, however it does not necessarily have an idea about the data read from the device. Consider the gpio_matrix driver: Arve says that it has to continue scanning matrix once first interrupt arrvies. But it really depends on what key has been pressed - if user pressed KEY_SUSPEND or KEY_POWER it cmight be better if we did not wait for key release but initiated the action right away. The decision on how system reacts to a key press does not belong to the driver but really to userspace. -- Dmitry -- 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/8] OMAP3: Adding Smartreflex and Voltage driver support
Thara Gopinath th...@ti.com writes:
This patch series introduces smartreflex and voltage driver support
for OMAP3430 and OMAP3630. SmartReflex modules do adaptive voltage
control for real-time voltage adjustments.
Originally all the functionalities introduced in this patch
were present in arch/arm/mach-omap2/smartreflex.c file in Kevin's
pm tree. This patch series does a major rewrite of this file
and introduces a separate voltage driver. Major contributors
to the original driver are
This is excellent, thanks for the rebase/reorg/compress.
While not yet get getting to a full review of this series, I'd like it
to get some broader testing. To that end, I've replaced the pm-sr
branch in my pm tree with this series, and rebuilt a new PM branch
using it.
Note that it is also based on top of a new pm-opp branch which is
Nishanth's condensed version which is also upstream bound for the next
merge window.
I had to do a couple minor fixes to apply against v2.6.35-rc1 (mainly
fixing usage of #defines that were renamed to have a _MASK suffix.)
It currently boots fine on OMAP3EVM (no efuse values, so no SR) but
when I try it on Zoom3, I get repeated errors:
Wake up daisy chain activation failed.
I haven't fully isolated the root cause yet, but it looks like it
might be because omap3_enable_io_chain() seems confused about whether
it should be writing PM_WKEN or PM_WKST reg.
The patch below (on top of new PM branch) seems to have fixed that
problem for Zoom3.
Kevin
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e531621..207905d 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -115,7 +115,7 @@ static void omap3_enable_io_chain(void)
/* Do a readback to assure write has been done */
prm_read_mod_reg(WKUP_MOD, PM_WKEN);
- while (!(prm_read_mod_reg(WKUP_MOD, PM_WKST)
+ while (!(prm_read_mod_reg(WKUP_MOD, PM_WKEN)
OMAP3430_ST_IO_CHAIN_MASK)) {
timeout++;
if (timeout 1000) {
@@ -124,7 +124,7 @@ static void omap3_enable_io_chain(void)
return;
}
prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
-WKUP_MOD, PM_WKST);
+WKUP_MOD, PM_WKEN);
}
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3 pm: dependency between opp layer and cpufreq
Nishanth Menon menon.nisha...@gmail.com writes: On 05/30/2010 01:50 PM, Premi, Sanjeev wrote: [...] [sp] There is no mention of cpufreq not working; but specifically the support of bootarg mpurate which is independent of cpufreq. The bootarg mpurate has been existing since quite sometime. I am neither creating a new layer / replacement for cpufreq not trying to duplicate the code. The intent is simply as stated below: 1) Expose OPP layer - don't hinde it under CONFIG_CPU_FREQ. ok with this 2) Use OPP layer to: - Validate that the requested mpurate is defined in the OPP table for the device - And get the voltage corresponding to the OPP. sounds good too 3) Ensure that right freq and voltage is set - at init time - based on the mpurate. ok 4) And at some poit later break the linkage between op player amd PMIC. aah you mean a simple patch as follows? diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 2b9ebf0..bfb3d0e 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -16,7 +16,8 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o # XXX The OPP TWL/TPS code should only be included when a TWL/TPS # PMIC is selected. ifdef CONFIG_CPU_FREQ -obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o +obj-$(CONFIG_ARCH_OMAP3) += opp.o +obj-$(CONFIG_TWL4030_CORE) += opp_twl_tps.o endif # omap_device support (OMAP2+ only at the moment) -- note - opp layer was never tied to pmic - there is pmic voltage conversion apis in opp_twl_tps.c or is there more in your view? anyways for cpufreq to work at 720Mhz, you need to add that frequency and corresponding voltage to the opptable, neither exists, further mpurate should work with opp table as well, else clockframework has no direct mechanism to verify the valid OPPs on a runtime system. that was the intent of opp layer - to provide the rest of the users with a mechanism to verify, query and use opps without functional knowledge of the silicon it works on.. ofcourse, please feel free to post a patch for the missing frequencies. OK, I must admit to not reading this whole thread since I've just restructured OPP and CPUfreq support in the PM branch. OPP support is now in the pm-opp branch (based on mainline) and CPUfreq support is now in the pm-cpufreq branch (based on mainline.) Please update this patch/series against one (or both) of those branches for more discussion. FWIW, I like the name change from cpufreq34xx -- opp34xx_data, and the Makefile change above makes sense. Both of these changes should be re-submitted against my pm-opp branch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [MMC] omap: Remove BUG_ON for disabled interrupts
On Wed, Jun 2, 2010 at 4:30 PM, Andrew Morton a...@linux-foundation.org wrote: On Wed, 2 Jun 2010 15:26:52 -0700 Cory Maccarrone darkstar6...@gmail.com wrote: On Wed, Jun 2, 2010 at 2:05 PM, Andrew Morton a...@linux-foundation.org wrote: On Sat, 29 May 2010 19:27:23 -0700 Cory Maccarrone darkstar6...@gmail.com wrote: This change removes a BUG_ON for when interrupts are disabled during an MMC request. __During boot, interrupts can be disabled when a request is made, causing this bug to be triggered. __In reality, there's no reason this should halt the kernel, as the driver has proved reliable in spite of disabled interrupts, and additionally, there's nothing in this code that would require interrupts to be enabled. Signed-off-by: Cory Maccarrone darkstar6...@gmail.com --- __drivers/mmc/host/omap.c | __ __1 - __1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c index 2b28168..d98ddcf 100644 --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host, __ __ __ mmc_omap_start_command(host, req-cmd); __ __ __ if (host-dma_in_use) __ __ __ __ __ __ __ omap_start_dma(host-dma_ch); - __ __ BUG_ON(irqs_disabled()); __} __static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req) So we need to decide whether this should be backported into 2.6.34.x and perhaps earlier. For that decision we'll need to know the things you didn't tell us: Which drivers are affected? __Under which setups is it triggering? __Why aren't lots of people reporting hey my kernel went BUG? The only setup I've managed to make it trigger on is on the HTC Herald during bootup when the driver is built into the kernel (mostly because that's all I have). I believe it's related to the fact that on bootup I get many timeout errors on CMD5 while initializing the card. Each CMD5 timeout triggers that bug (I changed it to a WARN_ON to get it to boot in) due to the fact that part of the timeout code involves sending the request again. With interrupts turned off, that BUG would be triggered. I can't answer the question of why other people aren't reporting this -- I know the CMD timeouts are fairly common with this driver, and it's only within the last few kernel releases that their triggering the BUG started happening. (I had only been able to test it because I was carrying forward the MMC 16-bit patch I submitted a while ago which only recently made it in. I'm not sure if that's related or not, but I need that to use the MMC-OMAP on herald.) Do you have one of these BUG_ON() traces handy, so we can perhaps see where local interrupts got disabled? I imagine a better solution to this would be to fix the timeout issues so the repeated requests aren't a problem. But any hardware bugs that cause a timeout during boot would cause this bug to be triggered, which is why I'm proposing removing the BUG_ON entirely (since everything seems to work fine anyway). I don't know why interrupts are disabled at this point, but my limited googling around leads me to believe the recent LOCKDEP work may be the cause. I couldn't find enough information on that to know for sure though. I do know that the bug no longer triggers after the card initializes successfully (and presumably interrupts re-enable). My guess is that since other people aren't reporting this problem, it's not hugely important to backport. A better question in that case would be why am I seeing it? I don't understand why interrupts would be disabled at this point in bootup. Yes, before removing the BUG_ON() it would be most helpful to understand why it was added. It was added by : commit abfbe5f7854a083ca324282bf7e39f10bc438313 : Author: Juha Yrjola juha.yrj...@solidboot.com : AuthorDate: Wed Mar 26 16:08:57 2008 -0400 : Commit: Pierre Ossman drz...@drzeus.cx : CommitDate: Fri Apr 18 20:05:28 2008 +0200 : : MMC: OMAP: Introduce new multislot structure and change driver to use it : : Introduce new MMC multislot structure and change driver to use it. : : Note that MMC clocking is now enabled in mmc_omap_select_slot() : and disabled in mmc_omap_release_slot(). : : Signed-off-by: Juha Yrjola juha.yrj...@solidboot.com : Signed-off-by: Jarkko Lavinen jarkko.lavi...@nokia.com : Signed-off-by: Carlos Eduardo Aguiar carlos.agu...@indt.org.br : Signed-off-by: Tony Lindgren t...@atomide.com : Signed-off-by: Pierre Ossman drz...@drzeus.cx Hopefully the email still works.. Juha, do you recall why you added the BUG_ON(irqs_disabled()) to mmc_omap_start_request()? I can only get the last screenful of output from the BUG, since I don't have serial debugging capabilities: Exception stack(0xc3c25d20 to 0xc3c25d68) 5d20: 0032 c02ac86a c3c25d5c c32a9a00
Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 16:32:44 -0700 Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote: On Wed, 2 Jun 2010 21:02:24 +1000 Neil Brown ne...@suse.de wrote: And this decision (to block suspend) really needs to be made in the driver, not in userspace? Well, it fits. The requirement is a direct consequence of the intimate knowledge the driver has about the driven devices. That is not really true. A driver does have intimate knowledge of the device, however it does not necessarily have an idea about the data read from the device. Consider the gpio_matrix driver: Arve says that it has to continue scanning matrix once first interrupt arrvies. But it really depends on what key has been pressed - if user pressed KEY_SUSPEND or KEY_POWER it cmight be better if we did not wait for key release but initiated the action right away. The decision on how system reacts to a key press does not belong to the driver but really to userspace. I can't follow the gpio_matrix_driver example, but your point is obviously true. A device should never register a constraint because of the data it handles. That belongs into userspace. Or wherever the data is consumed. I'm obviously not trying to say that a network driver should block suspend while I'm on facebook. Or unblock when visiting m$.com. That would be absurd. But, there are of course places in the kernel, where some kernel code listens to data. For example the packet-filtering. Or sysrq-keys. But I don't know how that relates to suspend_blockers now... ? Mind if I rephrase the quote? From: Well, it fits. The requirement is a direct consequence of the intimate knowledge the driver has about the driven devices. To: It fits, when the requirement is a direct consequence of the intimate knowledge the driver has about the driven devices. Cheers, Flo p.s.: tsss language... what a broken concept. And yet we have to work with it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote: On Wed, 2 Jun 2010 21:02:24 +1000 Neil Brown ne...@suse.de wrote: And this decision (to block suspend) really needs to be made in the driver, not in userspace? Well, it fits. The requirement is a direct consequence of the intimate knowledge the driver has about the driven devices. That is not really true. A driver does have intimate knowledge of the device, however it does not necessarily have an idea about the data read from the device. Consider the gpio_matrix driver: Arve says that it has to continue scanning matrix once first interrupt arrvies. But it really depends on what key has been pressed - if user pressed KEY_SUSPEND or KEY_POWER it cmight be better if we did not wait for key release but initiated the action right away. The decision on how system reacts to a key press does not belong to the driver but really to userspace. If we just suspend while the keypad scan is active, a second press of KEY_POWER would not be able wake the device up. The gpio keypad matrix driver has two operating modes. No keys are pressed: all the outputs are active so a key press will generate an interrupt in one of the inputs. Keys are pressed: Activate a single output at a time so we can determine which keys are pressed. The second mode is entered when the driver gets an interrupt in the first mode. The first mode is entered if the scan detected that no keys are pressed. The driver could be modified to stop the scan on suspend and forcibly put the device back in no-keys-pressed state, but pressing additional keys connected to the same input can no longer generate any events (the input does not change). -- Arve Hjønnevå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] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 19:44:59 -0700 Arve Hjønnevåg a...@android.com wrote: On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote: On Wed, 2 Jun 2010 21:02:24 +1000 Neil Brown ne...@suse.de wrote: And this decision (to block suspend) really needs to be made in the driver, not in userspace? Well, it fits. The requirement is a direct consequence of the intimate knowledge the driver has about the driven devices. That is not really true. A driver does have intimate knowledge of the device, however it does not necessarily have an idea about the data read from the device. Consider the gpio_matrix driver: Arve says that it has to continue scanning matrix once first interrupt arrvies. But it really depends on what key has been pressed - if user pressed KEY_SUSPEND or KEY_POWER it cmight be better if we did not wait for key release but initiated the action right away. The decision on how system reacts to a key press does not belong to the driver but really to userspace. If we just suspend while the keypad scan is active, a second press of KEY_POWER would not be able wake the device up. The gpio keypad matrix driver has two operating modes. No keys are pressed: all the outputs are active so a key press will generate an interrupt in one of the inputs. Keys are pressed: Activate a single output at a time so we can determine which keys are pressed. The second mode is entered when the driver gets an interrupt in the first mode. The first mode is entered if the scan detected that no keys are pressed. The driver could be modified to stop the scan on suspend and forcibly put the device back in no-keys-pressed state, but pressing additional keys connected to the same input can no longer generate any events (the input does not change). Thanks for the detailed explanation. That helps a lot. I see that if follows that performing a suspend while keys are pressed would not be good, and keys could be pressed for arbitrarily long periods. It does not follow that the keypad driver should therefore explicitly disable suspend. It could simply inform user-space that the keypad is in the alternate scan mode, so user-space can choose not to enter suspend in at that time (i.e. policy in user-space). I can see also how one might want to express this behaviour as a PM_QOS constraint (now that I have read a bit about PM_QOS), but I cannot see that you would need to. As the keypad driver is polling during this mode, it would presumably set a timer that would fire in the near future, and the very existence of this timer (with a duration shorter than the S3 latency) would be enough to ensure S3 wasn't automatically entered by PM. At most you might use set_timer_slack to give a slightly higher upper bound to the timeout. So if we take the suspend-from-idle approach, this driver needs no annotation, and if we take the 'fix the suspend/wake-event race' then this driver needs no special treatment - just enough to close the race, and some user-space policy support. i.e. it doesn't seem to be a special case. NeilBrown -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 06:06:43PM +0200, Thomas Gleixner wrote: On Thu, 27 May 2010, Alan Stern wrote: And to answer Thomas's question: The whole reason for having in-kernel suspend blockers is so that userspace can tell the system to suspend without losing wakeup events. Suppose a key is pressed just as a user program writes mem to /sys/power/state. The keyboard driver handles the keystroke and queues an input event. Then the system suspends and doesn't wake up until some other event occurs -- even though the keypress was an important one and it should have prevented the system from suspending. With in-kernel suspend blockers and opportunistic suspend, this scenario is prevented. That is their raison-d'etre. I tend to disagree. You are still looking at suspend as some extra esoteric mechanism. We should stop doing this and look at suspend (to RAM) as an additional deep idle state, which is well defined in terms of power savings and wakeup latency. That's what I think opportunistic suspend is all about. Now if you look at our current idle states in x86 the incoming keystroke is never lost. For systems with runtime PM and deep idle states in cpuidle suspend is already fairly opportunistic. If sleep states (including suspend to RAM and CPU off) are factored in to cpuidle then it's very easy to get in to situations where everything simply shuts off automatically, which can be problematic if a platform doesn't expose any external wakeup sources. Platforms still need to be able to establish some heuristics, whether this is via blocking certain state transitions or simply defining a maximum acceptable suspend depth irrespective of latency (at least we presently don't have a clean interface for preventing entry in to impossible to recover from idle states outside of latency hints via PM QoS, or at least not one that I'm aware of). On the other hand, while this isn't that difficult for the UP case it does pose more problems for the SMP case. Presently the suspend paths (suspend-to-RAM/hibernate/kexec jump) all deal with disabling and enabling of non-boot CPUs via CPU hotplug explicitly, which will clear them from the online CPU map. We would have to rework the semantics a bit if cpuidle were also permitted to opportunistically offline CPUs. -- 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 v5 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
Hello, Tony: Could you take a look at the arch/arm patches in this series? Thanks! Changes since v3/4: - Fixed commit subjects and messages for OMAP3 related patches - Added Acked-by from Mark, and Jarkko Intro message from the original series: This series aims to correct how the McBSP FIFO is viewed, and handled. Introduction of the problem: OMAP McBSP FIFO is word structured: McBSP2 has 1024 + 256 = 1280 word long buffer, McBSP1,3,4,5 has 128 word long buffer This means, that the size of the FIFO depends on the McBSP word size configuration. For example on McBSP3: 16bit samples: size is 128 * 2 = 256 bytes 32bit samples: size is 128 * 4 = 512 bytes It is simpler to place constraint for buffer and period based on channels. McBSP3 as example again (16 or 32 bit samples): 1 channel (mono): size is 128 frames (128 words) 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) Since now the McBSP codec supports not only 16bit samples (32biut has been recently added), the FIFO size handling is no longer correct, since it has been hard wired for 16bit word length. The series changes how the users of McBSP are configuring the FIFO: It used to be 0 based (0 meant 1 word threshold). After this series users can configure the threshold in 1 base mode (1 means 1 word threshold). The platform code now provides the full size of the FIFO in words, instead of the already limited value used in the past. In ASoC omap-mcbsp code hw_rule based constraint refinement is going to be used instead of the hardwired static constraint, which was correct only in case of 16bit word length. The hw_rule is refining the minimum buffer size based on the channel number going to be used by the coming stream. In case of threshold mode additional hw_rule refines the maximum allowed period size. The series are generated agains Takashi's sound-2.6: topic/asoc branch. CCing also Eduardo, and Eero since they have worked on the original FIFO/threshold implementation. All commetns and testers are welcome! Peter --- Peter Ujfalusi (5): OMAP: McBSP: Function to query the FIFO size OMAP3: McBSP: Change the way how the FIFO is handled OMAP3: McBSP: Use the port's buffer_size when calculating tx delay ASoC: omap-mcbsp: Save, and use wlen for threshold configuration ASoC: omap-mcbsp: Place correct constraints for streams arch/arm/mach-omap2/mcbsp.c | 10 ++-- arch/arm/plat-omap/include/plat/mcbsp.h |2 + arch/arm/plat-omap/mcbsp.c | 51 ++- sound/soc/omap/omap-mcbsp.c | 112 +++--- 4 files changed, 128 insertions(+), 47 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 v5 1/5] OMAP: McBSP: Function to query the FIFO size
Users of McBSP can use the omap_mcbsp_get_fifo_size function to query
the size of the McBSP FIFO.
The function will return the FIFO size in words (the HW maximum).
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolsfonmicro.com
---
arch/arm/plat-omap/include/plat/mcbsp.h |2 ++
arch/arm/plat-omap/mcbsp.c | 14 ++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 1bd7021..e126951 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -473,6 +473,7 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold);
void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold);
u16 omap_mcbsp_get_max_tx_threshold(unsigned int id);
u16 omap_mcbsp_get_max_rx_threshold(unsigned int id);
+u16 omap_mcbsp_get_fifo_size(unsigned int id);
u16 omap_mcbsp_get_tx_delay(unsigned int id);
u16 omap_mcbsp_get_rx_delay(unsigned int id);
int omap_mcbsp_get_dma_op_mode(unsigned int id);
@@ -483,6 +484,7 @@ static inline void omap_mcbsp_set_rx_threshold(unsigned int
id, u16 threshold)
{ }
static inline u16 omap_mcbsp_get_max_tx_threshold(unsigned int id) { return 0;
}
static inline u16 omap_mcbsp_get_max_rx_threshold(unsigned int id) { return 0;
}
+static inline u16 omap_mcbsp_get_fifo_size(unsigned int id) { return 0; }
static inline u16 omap_mcbsp_get_tx_delay(unsigned int id) { return 0; }
static inline u16 omap_mcbsp_get_rx_delay(unsigned int id) { return 0; }
static inline int omap_mcbsp_get_dma_op_mode(unsigned int id) { return 0; }
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 4820cab..51d8abf 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -559,6 +559,20 @@ u16 omap_mcbsp_get_max_rx_threshold(unsigned int id)
}
EXPORT_SYMBOL(omap_mcbsp_get_max_rx_threshold);
+u16 omap_mcbsp_get_fifo_size(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ return mcbsp-pdata-buffer_size;
+}
+EXPORT_SYMBOL(omap_mcbsp_get_fifo_size);
+
#define MCBSP2_FIFO_SIZE 0x500 /* 1024 + 256 locations */
#define MCBSP1345_FIFO_SIZE0x80 /* 128 locations */
/*
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/5] OMAP3: McBSP: Change the way how the FIFO is handled
Use the actual FIFO size in words as buffer_size on OMAP3.
Change the threshold configuration to use 1 based numbering, when
specifying the allowed threshold maximum or the McBSP threshold value.
Set the default maximum threshold to (buffer_size - 0x10) intialy.
From users of McBSP, now it is expected to use this method.
Asking for threshold 1 means that the value written to threshold registers
are going to be 0, which means 1 word threshold.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolsfonmicro.com
---
arch/arm/mach-omap2/mcbsp.c | 10 +-
arch/arm/plat-omap/mcbsp.c | 30 --
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 016fe60..ed9f562 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -132,7 +132,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
@@ -142,7 +142,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x3FF,
+ .buffer_size= 0x500, /* The FIFO has 1024 + 256 locations */
},
{
.phys_base = OMAP34XX_MCBSP3_BASE,
@@ -152,7 +152,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
.phys_base = OMAP34XX_MCBSP4_BASE,
@@ -161,7 +161,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP4_IRQ_RX,
.tx_irq = INT_24XX_MCBSP4_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
.phys_base = OMAP34XX_MCBSP5_BASE,
@@ -170,7 +170,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP5_IRQ_RX,
.tx_irq = INT_24XX_MCBSP5_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x6F,
+ .buffer_size= 0x80, /* The FIFO has 128 locations */
},
};
#define OMAP34XX_MCBSP_PDATA_SZARRAY_SIZE(omap34xx_mcbsp_pdata)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 51d8abf..d883bbf 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -480,9 +480,9 @@ int omap_st_is_enabled(unsigned int id)
EXPORT_SYMBOL(omap_st_is_enabled);
/*
- * omap_mcbsp_set_tx_threshold configures how to deal
- * with transmit threshold. the threshold value and handler can be
- * configure in here.
+ * omap_mcbsp_set_rx_threshold configures the transmit threshold in words.
+ * The threshold parameter is 1 based, and it is converted (threshold - 1)
+ * for the THRSH2 register.
*/
void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
{
@@ -497,14 +497,15 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold)
}
mcbsp = id_to_mcbsp_ptr(id);
- MCBSP_WRITE(mcbsp, THRSH2, threshold);
+ if (threshold threshold = mcbsp-max_tx_thres)
+ MCBSP_WRITE(mcbsp, THRSH2, threshold - 1);
}
EXPORT_SYMBOL(omap_mcbsp_set_tx_threshold);
/*
- * omap_mcbsp_set_rx_threshold configures how to deal
- * with receive threshold. the threshold value and handler can be
- * configure in here.
+ * omap_mcbsp_set_rx_threshold configures the receive threshold in words.
+ * The threshold parameter is 1 based, and it is converted (threshold - 1)
+ * for the THRSH1 register.
*/
void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold)
{
@@ -519,7 +520,8 @@ void omap_mcbsp_set_rx_threshold(unsigned int id, u16
threshold)
}
mcbsp = id_to_mcbsp_ptr(id);
- MCBSP_WRITE(mcbsp, THRSH1, threshold);
+ if (threshold threshold = mcbsp-max_rx_thres)
+ MCBSP_WRITE(mcbsp, THRSH1, threshold - 1);
}
EXPORT_SYMBOL(omap_mcbsp_set_rx_threshold);
@@ -1696,8 +1698,16 @@ static inline void
[PATCH v5 3/5] OMAP3: McBSP: Use the port's buffer_size when calculating tx delay
Sicne the platform data's buffer_size now holds the full size of the FIFO, there is no longer need to handle the ports differently. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com Acked-by: Jarkko Nikula jhnik...@gmail.com Acked-by: Mark Brown broo...@opensource.wolsfonmicro.com --- arch/arm/plat-omap/mcbsp.c |7 +-- 1 files changed, 1 insertions(+), 6 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index d883bbf..ac09c79 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -575,8 +575,6 @@ u16 omap_mcbsp_get_fifo_size(unsigned int id) } EXPORT_SYMBOL(omap_mcbsp_get_fifo_size); -#define MCBSP2_FIFO_SIZE 0x500 /* 1024 + 256 locations */ -#define MCBSP1345_FIFO_SIZE0x80 /* 128 locations */ /* * omap_mcbsp_get_tx_delay returns the number of used slots in the McBSP FIFO */ @@ -595,10 +593,7 @@ u16 omap_mcbsp_get_tx_delay(unsigned int id) buffstat = MCBSP_READ(mcbsp, XBUFFSTAT); /* Number of slots are different in McBSP ports */ - if (mcbsp-id == 2) - return MCBSP2_FIFO_SIZE - buffstat; - else - return MCBSP1345_FIFO_SIZE - buffstat; + return mcbsp-pdata-buffer_size - buffstat; } EXPORT_SYMBOL(omap_mcbsp_get_tx_delay); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/5] ASoC: omap-mcbsp: Save, and use wlen for threshold configuration
Save the word length configuration of McBSP, and use that information
to calculate, and configure the threshold in McBSP.
Previously the calculation was only correct when the stream had 16bit
audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolsfonmicro.com
---
sound/soc/omap/omap-mcbsp.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 6f44cb4..b06d8f1 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -59,6 +59,7 @@ struct omap_mcbsp_data {
int configured;
unsigned intin_freq;
int clk_div;
+ int wlen;
};
#define to_mcbsp(priv) container_of((priv), struct omap_mcbsp_data, bus_id)
@@ -155,19 +156,21 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
int dma_op_mode = omap_mcbsp_get_dma_op_mode(mcbsp_data-bus_id);
- int samples;
+ int words;
/* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
- samples = snd_pcm_lib_period_bytes(substream) 1;
+ /* The FIFO size depends on the McBSP word configuration */
+ words = snd_pcm_lib_period_bytes(substream) /
+ (mcbsp_data-wlen / 8);
else
- samples = 1;
+ words = 1;
/* Configure McBSP internal buffer usage */
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
- omap_mcbsp_set_tx_threshold(mcbsp_data-bus_id, samples - 1);
+ omap_mcbsp_set_tx_threshold(mcbsp_data-bus_id, words);
else
- omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, samples - 1);
+ omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, words);
}
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream,
@@ -409,6 +412,7 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
}
omap_mcbsp_config(bus_id, mcbsp_data-regs);
+ mcbsp_data-wlen = wlen;
mcbsp_data-configured = 1;
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
OMAP McBSP FIFO is word structured:
McBSP2 has 1024 + 256 = 1280 word long buffer,
McBSP1,3,4,5 has 128 word long buffer
This means, that the size of the FIFO
depends on the McBSP word size configuration.
For example on McBSP3:
16bit samples: size is 128 * 2 = 256 bytes
32bit samples: size is 128 * 4 = 512 bytes
It is simpler to place constraint for buffer and period based on channels.
McBSP3 as example again (16 or 32 bit samples):
1 channel (mono): size is 128 frames (128 words)
2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
Use the second method to place hw_rule on buffer size, and in threshold
mode to period size.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolsfonmicro.com
---
sound/soc/omap/omap-mcbsp.c | 98 +-
1 files changed, 77 insertions(+), 21 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index b06d8f1..aebd3af 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -173,6 +173,50 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, words);
}
+static int omap_mcbsp_hwrule_min_buffersize(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *buffer_size = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_BUFFER_SIZE);
+ struct snd_interval *channels = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+ struct omap_mcbsp_data *mcbsp_data = rule-private;
+ struct snd_interval frames;
+ int size;
+
+ snd_interval_any(frames);
+ size = omap_mcbsp_get_fifo_size(mcbsp_data-bus_id);
+
+ frames.min = size / channels-min;
+ frames.integer = 1;
+ return snd_interval_refine(buffer_size, frames);
+}
+
+static int omap_mcbsp_hwrule_max_periodsize(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *period_size = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE);
+ struct snd_interval *channels = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+ struct snd_pcm_substream *substream = rule-private;
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
+ struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
+ struct snd_interval frames;
+ int size;
+
+ snd_interval_any(frames);
+ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+ size = omap_mcbsp_get_max_tx_threshold(mcbsp_data-bus_id);
+ else
+ size = omap_mcbsp_get_max_rx_threshold(mcbsp_data-bus_id);
+
+ frames.max = size / channels-min;
+ frames.integer = 1;
+ return snd_interval_refine(period_size, frames);
+}
+
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
@@ -185,33 +229,45 @@ static int omap_mcbsp_dai_startup(struct
snd_pcm_substream *substream,
if (!cpu_dai-active)
err = omap_mcbsp_request(bus_id);
+ /*
+* OMAP3 McBSP FIFO is word structured.
+* McBSP2 has 1024 + 256 = 1280 word long buffer,
+* McBSP1,3,4,5 has 128 word long buffer
+* This means that the size of the FIFO depends on the sample format.
+* For example on McBSP3:
+* 16bit samples: size is 128 * 2 = 256 bytes
+* 32bit samples: size is 128 * 4 = 512 bytes
+* It is simpler to place constraint for buffer and period based on
+* channels.
+* McBSP3 as example again (16 or 32 bit samples):
+* 1 channel (mono): size is 128 frames (128 words)
+* 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
+* 4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
+*/
if (cpu_is_omap343x()) {
int dma_op_mode = omap_mcbsp_get_dma_op_mode(bus_id);
- int max_period;
/*
-* McBSP2 in OMAP3 has 1024 * 32-bit internal audio buffer.
-* Set constraint for minimum buffer size to the same than FIFO
-* size in order to avoid underruns in playback startup because
-* HW is keeping the DMA request active until FIFO is filled.
-*/
- if (bus_id == 1)
- snd_pcm_hw_constraint_minmax(substream-runtime,
- SNDRV_PCM_HW_PARAM_BUFFER_BYTES,
-
