* Ladislav Michl <ladis@xxxxxxxxxxxxxx> [171128 14:31]: > On Tue, Nov 28, 2017 at 06:11:31AM -0800, Tony Lindgren wrote: > > * Ladislav Michl <ladis@xxxxxxxxxxxxxx> [171128 09:42]: > > > On Tue, Nov 28, 2017 at 10:30:54AM +0100, Greg KH wrote: > > > > bit-banging an ir decoder, ugh, you are in for a world of hurt. Can't > > > > you put a chip on the device that does this for you in hardware? > > > > > > OMAP has DM timer which can be externally trigered on edge. Perfect for > > > that purpose. But I cannot pinmux its input as hw designers did poor job. > > > And there are thousands of devices deployed. > > > > > > So it is about a lot of soldering or providing software solution. > > > > > > > Anyway, good luck! > > > > > > A little pointer would increase "luck" by several order of magnitudes. > > > > Hmm did you already try limiting cpuidle to C1 only in /sys? > > I have CONFIG_CPU_IDLE=n, which should be the same. Is that right? You will then use the omap3_pm_idle() that does not know much anything about latencies. > > From what I recall you just set the latency to less than C2 > > has. The cpuidle latencies are in struct omap3_idle_statedata > > omap3_idle_data[]. > > I disabled cpuidle and frequency scaling completely. The only thing that > make jitter difference is CONFIG_PM (see original thread). Right as then omap3_pm_idle() is disabled and only WFI is done :) Limiting things to C1 with cpuidle is probably what you need for having USB also working. > There's lot of pm_wkup interrupts with CONFIG_PM - order of magnitude > more than gp_timer. Hmm yeah that is true. And idling and waking up devices also takes some time. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
