On Mon, Dec 17, 2012 at 10:36:10AM -0600, Rob Clark wrote:
On Mon, Dec 17, 2012 at 9:26 AM, Sekhar Nori nori.sek...@gmail.com wrote:
Hi Rob,
On Monday, December 17, 2012, Rob Clark wrote:
On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark robdcl...@gmail.com wrote:
I'm not very
Hello,
mode may be used uninitialized; the case 0 looks wrong (in
drivers/media/platform/omap/omap_vout.c)
this issue was raised in May 2012 already
(http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/48617)
will Vaibhav submit a patch?
static int
drivers/media/platform/omap/omap_vout.c: In function ‘omapvid_init’:
drivers/media/platform/omap/omap_vout.c:380:17: warning: ‘mode’ may be used
uninitialized in this function [-Wuninitialized]
drivers/media/platform/omap/omap_vout.c:330:23: note: ‘mode’ was declared here
this issue was raised
Hi Steve,
On Sat, Dec 29, 2012 at 05:19:08PM +0800, steve.zhan wrote:
Hi,
It is good idea add this feature.
1: Can we let the ret = hwspin_lock_tests(ops, hwlock); add after
hwspin_lock_register_single have return
succeed, that can avoid test duplicated Or error lockid. Of course, If
Hi Steve,
On Sun, Dec 30, 2012 at 10:13:08PM +0800, steve.zhan wrote:
Hi,
Acked-by: Steve zhan zhanzhe...@gmail.com
I'd rather not test the spinlocks after they are registering as they
might already be in use by then.
Why? I think user must use it after hwspin_lock_register
This series implements a hwmod flag that can be set on OMAP IP blocks
to indicate that the MPU should not be allowed to enter WFI when the
IP blocks are active. It also drops what appears to be unnecessary
SRAM code used by the OMAP2xxx PM code, using an inline WFI instead.
- Paul
---
Paul
There shouldn't be any need to jump to SRAM code if the OMAP CORE
clockdomain (and consequently the SDRAM controller and CORE PLL) stays
active during MPU WFI. The SRAM code should only be needed when the RAM
enters self-refresh. So in the case where CORE stays active, just call
WFI directly
Apparently, on some OMAPs, the MPU can't be allowed to enter WFI while
certain peripherals are active. It's not clear why, and it's likely
that there is simply some other bug in the driver or integration code.
But since the likelihood that anyone will have the time to track these
problems down in
Use the HWMOD_BLOCK_WFI flag in the hwmod data to prevent the MPU from
entering WFI when the I2C devices are active. No idea why this is needed;
this could certainly bear further investigation if anyone is interested.
The objective here is to remove some custom code from the OMAP24xx PM
code.
According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable
to wake the ARM up from WFI:
http://www.spinics.net/lists/arm-kernel/msg174734.html
Further troubleshooting was unable to narrow the problem down. So we
don't have much choice other than to block WFI when the EMAC is
10 matches
Mail list logo
