> -----Original Message----- > From: Kevin Hilman [mailto:[email protected]] > Sent: Thursday, December 02, 2010 4:24 PM > To: Cousson, Benoit > Cc: Basak, Partha; ABRAHAM, KISHON VIJAY; Paul Walmsley; linux- > [email protected]; Kamat, Nishant; Varadarajan, Charulatha; Datta, > Shubhrajyoti; [email protected]; [email protected]; > Raja, Govindraj > Subject: Re: [PATCH 6/7] [RFC] OMAP: hwmod: SYSCONFIG register > modification for MCBSP > > "Cousson, Benoit" <[email protected]> writes: > > [...] > > > > > The issue is not really for the mcbsp but for the serial that need to > > handle the 3 different states. > > > > if (enable) { > > /** > > * Errata 2.15: [UART]:Cannot Acknowledge Idle Requests > > * in Smartidle Mode When Configured for DMA Operations. > > */ > > if (uart->dma_enabled) > > idlemode = HWMOD_IDLEMODE_FORCE; > > else > > idlemode = HWMOD_IDLEMODE_SMART; > > } else { > > idlemode = HWMOD_IDLEMODE_NO; > > } > > > > You do need to explicitly set the 3 modes, hence the following 3 > APIs: > > omap_device_force_idle > > omap_device_no_idle > > omap_device_smart_idle
I am OK with Benoit's 3 + 1 API approach, 3 individual set functions and one common function to restore back to the value as dictated by the flag. What do you say guys? > > > > You can potentially add another API to restore the default idle mode: > > > > omap_device_default_idle > > > > That seems much simpler than 3 pairs of APIs. > > My $0.02... based on the fact that we already have some IPs needing to > conrol all 3 modes, I think having the 3 functions above is better than > having 3 pairs of request/release functions. > > Kevin > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
