Hi,

On Mon, Feb 18, 2013 at 03:55:33PM +0530, Santosh Shilimkar wrote:
> >>I wonder what are your ideas to sort that part out, I mean, how do you
> >>plan to implement ->set_wake() for the tty port ?"
> >
> >[1] http://marc.info/?l=linux-omap&m=136093334914275&w=2
> >
> The main need for uart wakeup is the io_ring() trigger and that needs
> to happen via generic pin control API. SYSC wakeup bit isn't something
> needs to be toggled so that can be decoupled. So again the idea is
> to make SYSC handling transparent to UART drivers and let driver toggle
> the io_ring() based on ->set_wake() as it is done today.

We're either reading different code bases or not understanding each
other. Currently this is how ->set_wake() is implemented:

serial_omap_set_wake()
 serial_omap_enable_wakeup()
  omap_uart_enable_wakeup()
   omap_hwmod_enable_wakeup()
    if (SYSC_HAS_ENAWAKEUP) {	/* true for UART */
     _enable_wakeup()
     _write_sysconfig()
    }
    set_idle_ioring_wakeup()
     if (!oh->mux || !oh->mux->enabled)
      return;

If I read the code correctly there's nothing setting oh->mux during DT
boot. The only caller to omap_hwmod_mux_init() (which allocates and
returns omap_hwmod_mux_info pointer) is
arch/arm/mach-omap2/devices.c::omap4_keyboard_init(). This has nothing
to do with UART and, even more importantly, isn't even called during a
DT boot.

So, is there something else setting oh->mux to a valid pointer and
actually making set_idle_ioring_wakeup() do something useful ?

-- 
balbi