>-----Original Message----- >From: linux-omap-owner@xxxxxxxxxxxxxxx >[mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of ext >Tony Lindgren >Sent: 20 August, 2008 14:37 >To: Hogander Jouni (Nokia-D/Tampere) >Cc: linux-omap@xxxxxxxxxxxxxxx >Subject: Re: [PATCH 2/4] PM: Workaround for taking care of gpio clocks > >* Jouni Hogander <jouni.hogander@xxxxxxxxx> [080815 10:47]: >> In omap3 gpios 2-6 are in per domain. Functional clocks for these >> should be disabled. This patch is needed until gpio driver disables >> gpio clocks. >> >> GPIO modules in PER domain are not able to act as a wake up >source if >> PER domain is in retention. PER domain sleep transition >before MPU is >> prevented by leaving icks active. PER domain still enters retention >> together with MPU. When this happens IOPAD wake up mechanism is used >> for gpios. > >As we talked offline.. Should we pass the GPIO wake-up >configuration from board-*.c files? Or can we always >automatically do this safely on 34xx? After some investigation it seems that we can configure wake-up events for almost every GPIO from the padconfigs. There are only 2 pins that do not seem to have this functionality, however I am not sure if this is a documentation bug or what because it is strange that only 2 pins lack this capability. GPIOs 32 and 187 are missing wake-up capability from padconfig. Because of this, our proposal would be to make GPIO clock switching global, but this would be enabled from a sysfs entry pretty much like how it is in the patches now. However, this would be separated from UART clock switching. So, we would introduce two new sysfs files: uart_clocks_off_while_idle and gpio_clocks_off_while_idle. This would avoid introducing new complexity in to the idle loop. How does this sound like? -Tero -- 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
