* Tero.Kristo@xxxxxxxxx <Tero.Kristo@xxxxxxxxx> [080821 14:08]: > > > >-----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? Sounds good to me. Then we may be able to remove both sysfs files eventually. 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
