Dasgupta, Romit | 1 Mar 04:25 2009
Picon

RE: omap3 cpuidle interrupt latency

I think the original code had checks in 3 places but as you say it might have changed in linux-omap. I feel the
right way to do this is to add a latency (using pm_qos) so that the CPU idle driver doesn't even attempt
deeper idle states. Ideally we should use PM_QOS_NETWORK_LATENCY but the menu governor seems to check
only PM_QOS_CPU_DMA_LATENCY class. I am not sure why menu governor does not check the other classes of
latency. But for now I think if we add to PM_QOS_CPU_DMA_LATENCY when we detect some network activity and
remove latency req after a while of network inactivity. 

Thanks,
-Romit

________________________________________
From: linux-omap-owner <at> vger.kernel.org [linux-omap-owner <at> vger.kernel.org] On Behalf Of Premi,
Sanjeev [premi <at> ti.com]
Sent: Saturday, February 28, 2009 11:22 PM
To: linux-omap <at> vger.kernel.org
Subject: omap3 cpuidle interrupt latency

I have noticed large interrupt latency when the cpuidle is enabled.
e.g. response time for ping goes from avg 10-20ms to 800-1000ms.
(I am at HEAD of the 'pm' branch)

The IRQs and FIQs are disabled at the beginning of the function
omap3_enter_idle() but WFI is executed much later in _omap_sram_idle().
In between, there is only one check for pending IRQs - omap_irq_pending()

If any interrupt occurs beyond this point is it considered by the WFI?

To reduce this latency, I am planning to do either/both of thse:
- Add more checks for pending IRQs
- Reduce the time for which the IRQs and FIQs are disabled
(Continue reading)

Woodruff, Richard | 1 Mar 05:05 2009
Picon

RE: omap3 cpuidle interrupt latency

Part of it is a poor prediction.  A while back, I had hacked in a simple irq time stamp and used a kind of crude
running average over all irq sources. Then I added this info into cpuidle for next state prediction. It did
improve latency a quite a bit.  Simple idea is irqs might cluster and there is always a little activity after irq.

The effect of this is easily seen on musb driver. It uses some kind of streaming api where data is only sent up
after a bunch of irqs have brought in data above some threshold.  CPUidle doesn't take this kind of thing
into account well and will choose a poor cstate which causes effective throughput to drop.

I did post some of this code on linux pm.  I did get a response from one power person at Intel.  He indicated that
cpuidle wasn't so good at in this aspect and that they were looking at a similar but different approach to
the issue.  He didn't like the idea of extra overhead on each irq.  It was pretty minor to me.

It would be nice if this device could dynamically set constraints (say by using a short kernel timer during
activity or set/remove pm_qos latency) or the prediction aspect of cpuidle could be improved using rules
feed from things like interrupt source.

Regards
Richard W.

> -----Original Message-----
> From: linux-omap-owner <at> vger.kernel.org [mailto:linux-omap-
> owner <at> vger.kernel.org] On Behalf Of Dasgupta, Romit
> Sent: Saturday, February 28, 2009 9:25 PM
> To: Premi, Sanjeev; linux-omap <at> vger.kernel.org
> Subject: RE: omap3 cpuidle interrupt latency
>
> I think the original code had checks in 3 places but as you say it might have
> changed in linux-omap. I feel the right way to do this is to add a latency
> (using pm_qos) so that the CPU idle driver doesn't even attempt deeper idle
> states. Ideally we should use PM_QOS_NETWORK_LATENCY but the menu governor
(Continue reading)

Dasgupta, Romit | 1 Mar 07:48 2009
Picon

RE: omap3 cpuidle interrupt latency

It would be nice if this device could dynamically set constraints (say by using a short kernel timer during
activity or set/remove pm_qos latency) or the prediction aspect of cpuidle could be improved using rules
feed from things like interrupt source.

[Romit] I was thinking that in the irq handler we should add a requirement via the pm_qos or via the
constraint framework (not sure if linux-omap has this) and set some kind of a timer (the idea is to keep
arming the timer for clustered or rather closely spaced irq instances). If after a while the timer expires
we release the latency req. This way perhaps we can handle the latency problem. Again, I am not sure why the
menu governor only looks into the PM_QOS_CPU_DMA_LATENCY class only. I was thinking that it should look
into other classes as well.

Thanks,
-Romit--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Premi, Sanjeev | 1 Mar 21:01 2009
Picon

RE: omap3 cpuidle interrupt latency

> -----Original Message-----
> From: Dasgupta, Romit 
> Sent: Sunday, March 01, 2009 12:18 PM
> To: Woodruff, Richard; Premi, Sanjeev; linux-omap <at> vger.kernel.org
> Subject: RE: omap3 cpuidle interrupt latency
> 
> It would be nice if this device could dynamically set 
> constraints (say by using a short kernel timer during 
> activity or set/remove pm_qos latency) or the prediction 
> aspect of cpuidle could be improved using rules feed from 
> things like interrupt source.

Despite all constraints; the latency concern is still valid.

The constraints would either prevent idle state transition;
or in the idle processing we could still have repeat of current
situation - though less often.

I feel checking for pending interrupt before executing WFI
would help. Will try in the morning.

> [Romit] I was thinking that in the irq handler we should add 
> a requirement via the pm_qos or via the constraint framework 
> (not sure if linux-omap has this) and set some kind of a 
> timer (the idea is to keep arming the timer for clustered or 
> rather closely spaced irq instances). If after a while the 
> timer expires we release the latency req. This way perhaps we 
> can handle the latency problem. Again, I am not sure why the 
> menu governor only looks into the PM_QOS_CPU_DMA_LATENCY 
> class only. I was thinking that it should look into other 
(Continue reading)

Premi, Sanjeev | 1 Mar 21:08 2009
Picon

RE: omap3evm resume from touchscreen


> -----Original Message-----
> From: linux-omap-owner <at> vger.kernel.org 
> [mailto:linux-omap-owner <at> vger.kernel.org] On Behalf Of Dev Kumar
> Sent: Saturday, February 28, 2009 1:30 PM
> To: Linux Omap
> Subject: omap3evm resume from touchscreen
> 
> Hello,
> 
> I have recently started working on Linux and using OMAP3EVM.
> I am able to test suspend-resume with serial console. Not the 
> touchscreen.

Are you using a TI release?

> 
> Is my configuration not right?

Assuming you are referring to kernel configuration; did you make any changes?

> 
> /dev
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in the body of a message to 
> majordomo <at> vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 
> --
(Continue reading)

TK, Pratheesh Gangadhar | 1 Mar 21:49 2009
Picon

RE: omap3 cpuidle interrupt latency


> -----Original Message-----
> From: linux-omap-owner <at> vger.kernel.org [mailto:linux-omap-
> owner <at> vger.kernel.org] On Behalf Of Premi, Sanjeev
> Sent: Monday, March 02, 2009 1:31 AM
> To: Dasgupta, Romit; Woodruff, Richard; linux-omap <at> vger.kernel.org
> Subject: RE: omap3 cpuidle interrupt latency
> 
> > -----Original Message-----
> > From: Dasgupta, Romit
> > Sent: Sunday, March 01, 2009 12:18 PM
> > To: Woodruff, Richard; Premi, Sanjeev; linux-omap <at> vger.kernel.org
> > Subject: RE: omap3 cpuidle interrupt latency
> >
> > It would be nice if this device could dynamically set
> > constraints (say by using a short kernel timer during
> > activity or set/remove pm_qos latency) or the prediction
> > aspect of cpuidle could be improved using rules feed from
> > things like interrupt source.
> 
> Despite all constraints; the latency concern is still valid.
> 
> The constraints would either prevent idle state transition;
> or in the idle processing we could still have repeat of current
> situation - though less often.
> 
> I feel checking for pending interrupt before executing WFI
> would help. Will try in the morning.

Moving time keeping functions out of interrupt disabled context may also help. Something like this
(Continue reading)

DongSoo(Nathaniel) Kim | 2 Mar 01:19 2009
Picon

[OMAPZOOM][PATCH] CAM: Make omap3 camera interface driver more generic for external camera devices.

Hello.

 Since I was working on omap3 and external ISP device, I found some
hard coded thing in camera interface codes which make dependency on
sensor or ISP device. With that code, we cannot make omap3 camera
interface driver generic for every target board.
It makes dependency on camera device mounted on target board, and
therefore we need to modify omap3 camera interface driver when we do
our porting job.

 Please find following patch which I tried to make more generic for
omap3 camera interface driver. Just designate expecting colorspace
from external camera module in board file, then no need to modify
try_pix_parm() function.
Any comments will be welcomed.

Cheers,

Nate

From f8062b8678fa8f8d9e694fb796431cf340112fa3 Mon Sep 17 00:00:00 2001
From: Dongsoo Kim <dongsoo45.kim <at> samsung.com>
Date: Thu, 26 Feb 2009 20:32:18 +0900
Subject: [PATCH] CAM: Make try_pix_parm() negotiable with board
specific sensor config.
 Removed hard coded pixelformat in camera interface driver

Signed-off-by: Dongsoo Kim <dongsoo45.kim <at> samsung.com>
---
 arch/arm/mach-omap2/board-3430sdp.c |    6 ++++++
(Continue reading)

Lopez Cruz, Misael | 2 Mar 02:54 2009
Picon

Re: [PATCH 1/3] ASoC: Add GPIO support for jack reporting interface

> > * Create a new structure "snd_soc_jack_gpio" holding info 
> > specific for a gpio pin like: gpio, irq, irqflags,
> > irqhandler, private data (to be passed to irqhandler).
> 
> Yes, roughly.  The jack_gpio will also need to know the 
> status bits to update and which jack to update.  I'd expect 
> something along the lines
> of:
> 
> struct snd_soc_jack_gpio {
> 	struct snd_soc_jack *jack;
> 	int report;         /* Value to report when jack detected */
> 	int invert_report;  /* Report presence when GPIO low */
> 	int gpio;           /* GPIO to read */
> };
> 
> possibly with some other data stored (eg, a debounce time).  
> You can use gpio_to_irq() to get the interrupt number.
> 
> If the machine drivers need to customise the IRQ handler code 
> itself then it's probably getting to the point where another 
> detection method should be written, though perhaps I'm 
> missing something?

Well, customise the IRQ handler itself probably not since the
irq handler only needs to queue a work for doing the actual
detection/report. There can be a generic detection/report function
for gpio, I was thinking in something like:

void gpio_detect(struct snd_soc_jack_gpio *gpio)
(Continue reading)

DongSoo(Nathaniel) Kim | 2 Mar 03:22 2009
Picon

[OMAPZOOM][PATCH] CAM: Make PACK8 mode on CCDC work only with CCIR-656

Hello,

Besides the patch I've posted couple of hours ago, there is one more
thing in omap3 ispccdc.c.
According to omap3 datasheet, PACK8 could be enabled only when
CCDC_SYN_MODE is with CCIR-656 mode.
If you try to use external camera module with ITU-R.601 mode without
this patch, you could face weird data from your camera interface.
Please find following patch, and any comments will be welcomed.

Cheers,

Nate

From 23425c97233c93f9b572351d8a93a13ae3cb3188 Mon Sep 17 00:00:00 2001
From: Dongsoo Kim <dongsoo45.kim <at> samsung.com>
Date: Mon, 2 Mar 2009 11:01:14 +0900
Subject: [PATCH 2/2] CAM: Make PACK8 mode on CCDC work only with CCIR-656
 Signed-off-by: Dongsoo Kim <dongsoo45.kim <at> samsung.com>

---
 drivers/media/video/isp/ispccdc.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c
index 8f7e896..2945c6f 100644
--- a/drivers/media/video/isp/ispccdc.c
+++ b/drivers/media/video/isp/ispccdc.c
 <at>  <at>  -762,7 +762,8  <at>  <at>  void ispccdc_config_sync_if(struct ispccdc_syncif syncif)
(Continue reading)

Kim Kyuwon | 2 Mar 03:37 2009
Picon

Suggestion regarding the ordering of GPIO MUX configurations

Hi All.

The current order of GPIO mux configurations is not sorted. It seems
that all new GPIO MUX configurations are being inserted to the end as
shown in next code

/* arch/arm/plat-omap/include/mach/mux.h */
791         AH8_34XX_GPIO29,
792         J25_34XX_GPIO170,
793         AF26_34XX_GPIO0,
794         AF22_34XX_GPIO9,
795         L8_34XX_GPIO63,
796         AF6_34XX_GPIO140_UP,
797         AE6_34XX_GPIO141,
798         AF5_34XX_GPIO142,
799         AE5_34XX_GPIO143,
800         AG4_34XX_GPIO134,
801         U8_34XX_GPIO54,
802         AE4_34XX_GPIO136,

I wonder if we can sort the order of GPIO MUX configurations and then
insert new MUXs at right position. Can I ask your opinions?

Regards,

Kim Kyuwon.
--

-- 
Q1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
(Continue reading)


Gmane