Re: [alsa-devel] Please help in adding ams-delta support to ASoC
On Sat, Jun 06, 2009 at 07:42:12PM +0200, Janusz Krzysztofik wrote: Is it possible that the codec speeks I2S, with 8-bit word, 1 word per frame, 2 channels at 8kHz each? Or 1 channel at 16 kHz? From what I can read in modem documentation, this should rather be one 8-bit channel at 8kHz. Anyway, can the transmission format I have seen ont the oscilloscope be matched against any format that mcbsp can be set with current code? The former is more likely. Since I2S is a stereo protocol I'd not be surprised to see a mono device choosing to transmit its data in both left and right channels for maximum interoperability with devices that do stereo. I'm still far from understanding mcbsp, but I wonder what happens if the bit clock stops ater 18th bit while maybe mcbsp expects more. Perhaps this is the cause of dma interrupts not being generated? That's certainly the sort of behaviour I'd expect to see from a programmable port like the McBSP - many of them also need to know exactly how many bit clocks there will be in order to implement I2S due to not paying attention to one of the edges of frame sync. In general things will cope if the bit clock stops providing there have been as many edges as they're expecting to get a full sample clocked in. -- To unsubscribe from this list: send the line unsubscribe 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: OMAP: sporadic hard lock-up when GPIO edge-triggered interrupts occur too fast
Hi OMAP people, I've done some more debugging on this problem, and determined that while it occurs less often, it still happens when PREMPT_RT is completely disabled (using l-o 2.6.29-omap1 with the default set of extra patches applied by the OE linux-omap_2.6.29 recipe, without having applied the -rt patchset). I am therefore reposting this to the l-o list as it seems like it could be a serious and general problem, and I'm really out of ideas for fixing it... Are there any known cases (however rare), whereby a race condition or deadlock can occur with the current GPIO interrupt code? I've seen many comments on the mailing list implying the code is quite fragile or sensitive as it is, and wonder if this is because of hardware bugs or limitations? The way the hardware works (multiple GPIO interrupts combined into one bank interrupt to the MPU, where the bank can contain both level and edge triggers) seems pretty stupid, especially for the use-case where both edge and level triggers are used on one bank. Does anyone by any chance have any patches that for example, fix this problem even at the expense of performance or latency? Many thanks, Hugo On Thu, Jun 4, 2009 at 11:51 AM, Hugo Vincenthugo.vinc...@gmail.com wrote: Hi everyone, I'm trying to debug a problem with GPIO interrupts on my OMAP3503 (Gumstix Overo) platform with kernel 2.6.29.4-rt16-omap1. While this is a sporadic lock-up, I haven't been able to reproduce it when PREEMPT_HARDIRQ is disabled. I think it might have something to do with this patch (which is applied BTW): http://patchwork.kernel.org/patch/16046/ And see this thread: http://markmail.org/message/aaqpk5jztrrypsxz Sometimes, I see a spurious IRQ message like this: Spurious irq 95: 0xffdf, please flush posted write for irq 31 that the above patch is supposed to fix, just before the system locks up. Is it possible that the interrupt handler is getting preempted between acknowledging the interrupt and the 'flush posted write', and meanwhile another interrupt from the same bank occurs? To check this hypothesis, I built the kernel with CONFIG_PREEMPT_DESKTOP=y # CONFIG_PREEMPT_RT is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y which gives a /proc/irq/irq/handler/threaded flag. When I tried disabling threading on irqs 246-249 (which are the virtual irqs for the problematic GPIO interrupts), the problem still occured. I'm not sure how to disable threading or preemption on the intermediate ISR (gpio_irq_handler() at arch/arm/plat-omap/gpio.c:959) which determines which GPIO in the bank caused the interrupt and spawns the virtual interrupts. Any ideas for debugging or narrowing down on the cause? Many thanks, Hugo -- To unsubscribe from this list: send the line unsubscribe 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-fbdev-devel] [PATCH 01/20] omapfb: Add support for the Apollon LCD
On Thu, 4 Jun 2009 20:52:26 +0300 Imre Deak imre.d...@nokia.com wrote: From: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Imre Deak imre.d...@nokia.com --- Acked-by: Krzysztof Helt krzysztof...@wp.pl -- Masz juz dosc wysokich rachunkow? Wygraj nowa mozliwosc komunikacji! Sprawdz http://link.interia.pl/f21d2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP2+: omap_device: bug fix patch for omap_device_idle()/omap_device_shutdown()
This patch fixes a crash in the _omap_device_deactivate(). It will be
rolled into the next omap_device patch series posting.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/omap_device.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index a992b88..0c54892 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -127,10 +127,12 @@ static int _omap_device_activate(struct omap_device *od,
u8 ignore_lat)
pr_debug(omap_device: %s: activating\n, od-pdev.name);
- while (od-pm_lat_level = 0) {
+ while (od-pm_lat_level 0) {
struct omap_device_pm_latency *odpl;
int act_lat = 0;
+ od-pm_lat_level--;
+
odpl = od-pm_lats + od-pm_lat_level;
if (!ignore_lat
@@ -155,7 +157,6 @@ static int _omap_device_activate(struct omap_device *od, u8
ignore_lat)
act_lat, odpl-activate_lat);
od-dev_wakeup_lat -= odpl-activate_lat;
- od-pm_lat_level--;
}
return 0;
@@ -181,7 +182,7 @@ static int _omap_device_deactivate(struct omap_device *od,
u8 ignore_lat)
pr_debug(omap_device: %s: deactivating\n, od-pdev.name);
- while (od-pm_lat_level (od-pm_lats_cnt - 1)) {
+ while (od-pm_lat_level od-pm_lats_cnt) {
struct omap_device_pm_latency *odpl;
int deact_lat = 0;
@@ -454,7 +455,7 @@ int omap_device_enable(struct platform_device *pdev)
/* Enable everything if we're enabling this device from scratch */
if (od-_state == OMAP_DEVICE_STATE_UNKNOWN)
- od-pm_lat_level = od-pm_lats_cnt - 1;
+ od-pm_lat_level = od-pm_lats_cnt;
ret = _omap_device_activate(od, IGNORE_WAKEUP_LAT);
--
1.6.3.2.202.g26c11
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
error message - SR1/SR2: VDD autocomp is not active
Hi, I have applied the latest linux-omap-pm patches to the android-2.6.29 kernel and I get the following error message: SR2: VDD autocomp is not active SR1: VDD autocomp is not active What should I do? It interferes with my touchscreen controller. If I disable the SR patches, the build works fine. If I incorporate all 204 pm patches from the linux-omap-pm branch, I get the above error. Elvis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
