On Fri, Jun 18, 2010 at 3:15 AM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > "Govindraj.R" <govindraj.raja@xxxxxx> writes: > >> This patch makes the following: >> - Adds missing wakeup padding register handling. >> - Fixes a hardcode to use PER module ONLY on UART3. >> - Muxmode usage needed for uart4 for 3630, for padconf >> wakeup on uart4_rx line. uart4_rx signal is available >> under mode-2 in gpmc_wait3. Thus have to ensure we are >> in right mux mode before accesing any padconf register. >> So ensure right mux mode for uarti padconf access. > > I think this mux-mode handling should be done as a separate patch with > more description as exactly what problem this is solving. > > Presumably, whatever problem you're solving not unique to 3630 UART4 > as the UARTs on the other platforms can be muxed with other > peripherals as well. > > Based on the way it's being mux'd (and continually re-mux'd) in this > patch, it looks like the mux settings for that pin are being > dynamically changed elsewhere in the code. If that's the case, then > that should be better understood, and this code should likely re-mux > to the original settings when its done. > > Kevin Since padconf and mux_mode value is populated based on a cpu_check I thought other platforms might not be affected Actually uart4_rx in available under CONTROL_PADCONF_GPMC_WAIT2[31:16] in mux_mode 2 I am not sure whether this gpmc line is used or not. I was just trying to be cautious in read and write for uart4_rx Ensuring that I am using right mux mode wrt uart Yes I do agree that I can corrupt gpmc_wait2 padconf if used by other peripheral. So any thought how do we handle rx wakeup if not available as an seperate padconf as in this case uart4_rx I mean if uart_rx_padconf is not available straight forward and available under a muxmode Regards, Govindraj.R > -- > 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 > -- --- Regards, Govindraj.R -- 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
