| Message ID | 1253230586-931-1-git-send-email-mike@android.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Kevin Hilman |
| Headers | show |
On Thu, Sep 17, 2009 at 4:36 PM, Mike Chan <mike@android.com> wrote: > Signed-off-by: Mike Chan <mike@android.com> > --- >  drivers/video/omap2/dss/dispc.c |   6 ++++- >  drivers/video/omap2/dss/dsi.c  |  50 +++++++++++++++++++++++++++++++++++--- >  2 files changed, 51 insertions(+), 5 deletions(-) > > diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c > index d061d75..4216466 100644 > --- a/drivers/video/omap2/dss/dispc.c > +++ b/drivers/video/omap2/dss/dispc.c > @@ -484,13 +484,17 @@ static inline void enable_clocks(bool enable) >  bool dispc_go_busy(enum omap_channel channel) >  { >     int bit; > +    bool ret; > >     if (channel == OMAP_DSS_CHANNEL_LCD) >         bit = 5; /* GOLCD */ >     else >         bit = 6; /* GODIGIT */ > > -    return REG_GET(DISPC_CONTROL, bit, bit) == 1; > +    enable_clocks(1); > +    ret = REG_GET(DISPC_CONTROL, bit, bit) == 1; > +    enable_clocks(0); > +    return ret; >  } > >  void dispc_go(enum omap_channel channel) > diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c > index 5e3d653..e9d8a5f 100644 > --- a/drivers/video/omap2/dss/dsi.c > +++ b/drivers/video/omap2/dss/dsi.c > @@ -1186,6 +1186,9 @@ int dsi_pll_init(bool enable_hsclk, bool enable_hsdiv) >     if (r) >         goto err1; > > +    enable_clocks(0); > +    dsi_enable_pll_clock(0); > + >     DSSDBG("PLL init done\n"); > >     return 0; > @@ -1199,11 +1202,9 @@ err0: > >  void dsi_pll_uninit(void) >  { > -    enable_clocks(0); > -    dsi_enable_pll_clock(0); > - >     dsi.pll_locked = 0; >     dsi_pll_power(DSI_PLL_POWER_OFF); > + >     regulator_disable(dsi.vdds_dsi_reg); >     DSSDBG("PLL uninit done\n"); >  } > @@ -1848,6 +1849,9 @@ static int dsi_vc_send_bta_sync(int channel) > >     INIT_COMPLETION(dsi.bta_completion); > > +    enable_clocks(1); > +    dsi_enable_pll_clock(1); > + >     dsi_vc_enable_bta_irq(channel); > >     r = dsi_vc_send_bta(channel); > @@ -1870,6 +1874,9 @@ static int dsi_vc_send_bta_sync(int channel) >  err: >     dsi_vc_disable_bta_irq(channel); > > +    enable_clocks(0); > +    dsi_enable_pll_clock(0); > + >     return r; >  } > > @@ -1921,6 +1928,9 @@ static int dsi_vc_send_long(int channel, u8 data_type, u8 *data, u16 len, >         return -EINVAL; >     } > > +    enable_clocks(1); > +    dsi_enable_pll_clock(1); > + >     dsi_vc_write_long_header(channel, data_type, len, ecc); > >     /*dsi_vc_print_status(0); */ > @@ -1964,6 +1974,9 @@ static int dsi_vc_send_long(int channel, u8 data_type, u8 *data, u16 len, >         dsi_vc_write_long_payload(channel, b1, b2, b3, 0); >     } > > +    enable_clocks(0); > +    dsi_enable_pll_clock(0); > + >     return r; >  } > > @@ -1979,6 +1992,9 @@ static int dsi_vc_send_short(int channel, u8 data_type, u16 data, u8 ecc) >                 channel, >                 data_type, data & 0xff, (data >> 8) & 0xff); > > +    enable_clocks(1); > +    dsi_enable_pll_clock(1); > + >     if (FLD_GET(dsi_read_reg(DSI_VC_CTRL(channel)), 16, 16)) { >         DSSERR("ERROR FIFO FULL, aborting transfer\n"); >         return -EINVAL; > @@ -1990,6 +2006,9 @@ static int dsi_vc_send_short(int channel, u8 data_type, u16 data, u8 ecc) > >     dsi_write_reg(DSI_VC_SHORT_PACKET_HEADER(channel), r); > > +    enable_clocks(0); > +    dsi_enable_pll_clock(0); > + >     return 0; >  } > > @@ -2775,13 +2794,15 @@ static int dsi_update_thread(void *data) >             break; > >         dsi_bus_lock(); > - >         if (dsi.update_mode == OMAP_DSS_UPDATE_DISABLED || >                 kthread_should_stop()) { >             dsi_bus_unlock(); >             break; >         } > > +        enable_clocks(1); > +        dsi_enable_pll_clock(1); > + >         dsi_perf_mark_setup(); > >         if (dsi.update_region.dirty) { > @@ -2872,6 +2893,9 @@ static int dsi_update_thread(void *data) > >         complete_all(&dsi.update_completion); > > +        enable_clocks(0); > +        dsi_enable_pll_clock(0); > + >         dsi_bus_unlock(); > >         /* XXX We need to give others chance to get the bus lock. Is > @@ -3068,6 +3092,9 @@ static int dsi_display_enable(struct omap_dss_device *dssdev) >     if (dsi.update_mode == OMAP_DSS_UPDATE_AUTO) >         dsi_start_auto_update(dssdev); > > +    enable_clocks(0); > +    dsi_enable_pll_clock(0); > + >     dsi_bus_unlock(); >     mutex_unlock(&dsi.lock); > > @@ -3101,6 +3128,9 @@ static void dsi_display_disable(struct omap_dss_device *dssdev) >     dsi.update_mode = OMAP_DSS_UPDATE_DISABLED; >     dssdev->state = OMAP_DSS_DISPLAY_DISABLED; > > +    enable_clocks(1); > +    dsi_enable_pll_clock(1); > + >     dsi_display_uninit_dispc(dssdev); > >     dsi_display_uninit_dsi(dssdev); > @@ -3128,6 +3158,9 @@ static int dsi_display_suspend(struct omap_dss_device *dssdev) >     dsi.update_mode = OMAP_DSS_UPDATE_DISABLED; >     dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED; > > +    enable_clocks(1); > +    dsi_enable_pll_clock(1); > + >     dsi_display_uninit_dispc(dssdev); > >     dsi_display_uninit_dsi(dssdev); > @@ -3181,6 +3214,9 @@ static int dsi_display_resume(struct omap_dss_device *dssdev) >     if (dsi.update_mode == OMAP_DSS_UPDATE_AUTO) >         dsi_start_auto_update(dssdev); > > +    enable_clocks(0); > +    dsi_enable_pll_clock(0); > + >     dsi_bus_unlock(); >     mutex_unlock(&dsi.lock); > > @@ -3325,6 +3361,9 @@ static int dsi_display_enable_te(struct omap_dss_device *dssdev, bool enable) > >     dsi_bus_lock(); > > +    enable_clocks(1); > +    dsi_enable_pll_clock(1); > + >     dsi.te_enabled = enable; > >     if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE) > @@ -3332,6 +3371,9 @@ static int dsi_display_enable_te(struct omap_dss_device *dssdev, bool enable) > >     dsi_set_te(dssdev, enable); >  end: > +    enable_clocks(0); > +    dsi_enable_pll_clock(0); > + >     dsi_bus_unlock(); > >     return 0; > -- > 1.5.4.5 > > Tomi this is based off of our android-omap-2.6.29 branch. -- Mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, If you disable the clocks to allow RET, you also allow OFF mode. And resuming from OFF mode hasn't been implemented for DSI, if I recall right. And when I was testing it, it didn't seem to be trivial with the DSI PLL. That's why currently you need to disable the display to turn off the clocks, and the whole DSI block is re-configured when enabling the display again. Tomi On Fri, 2009-09-18 at 01:36 +0200, ext Mike Chan wrote: > Signed-off-by: Mike Chan <mike@android.com> > --- > drivers/video/omap2/dss/dispc.c | 6 ++++- > drivers/video/omap2/dss/dsi.c | 50 +++++++++++++++++++++++++++++++++++--- > 2 files changed, 51 insertions(+), 5 deletions(-) > > diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c > index d061d75..4216466 100644 > --- a/drivers/video/omap2/dss/dispc.c > +++ b/drivers/video/omap2/dss/dispc.c > @@ -484,13 +484,17 @@ static inline void enable_clocks(bool enable) > bool dispc_go_busy(enum omap_channel channel) > { > int bit; > + bool ret; > > if (channel == OMAP_DSS_CHANNEL_LCD) > bit = 5; /* GOLCD */ > else > bit = 6; /* GODIGIT */ > > - return REG_GET(DISPC_CONTROL, bit, bit) == 1; > + enable_clocks(1); > + ret = REG_GET(DISPC_CONTROL, bit, bit) == 1; > + enable_clocks(0); > + return ret; > } > > void dispc_go(enum omap_channel channel) > diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c > index 5e3d653..e9d8a5f 100644 > --- a/drivers/video/omap2/dss/dsi.c > +++ b/drivers/video/omap2/dss/dsi.c > @@ -1186,6 +1186,9 @@ int dsi_pll_init(bool enable_hsclk, bool enable_hsdiv) > if (r) > goto err1; > > + enable_clocks(0); > + dsi_enable_pll_clock(0); > + > DSSDBG("PLL init done\n"); > > return 0; > @@ -1199,11 +1202,9 @@ err0: > > void dsi_pll_uninit(void) > { > - enable_clocks(0); > - dsi_enable_pll_clock(0); > - > dsi.pll_locked = 0; > dsi_pll_power(DSI_PLL_POWER_OFF); > + > regulator_disable(dsi.vdds_dsi_reg); > DSSDBG("PLL uninit done\n"); > } > @@ -1848,6 +1849,9 @@ static int dsi_vc_send_bta_sync(int channel) > > INIT_COMPLETION(dsi.bta_completion); > > + enable_clocks(1); > + dsi_enable_pll_clock(1); > + > dsi_vc_enable_bta_irq(channel); > > r = dsi_vc_send_bta(channel); > @@ -1870,6 +1874,9 @@ static int dsi_vc_send_bta_sync(int channel) > err: > dsi_vc_disable_bta_irq(channel); > > + enable_clocks(0); > + dsi_enable_pll_clock(0); > + > return r; > } > > @@ -1921,6 +1928,9 @@ static int dsi_vc_send_long(int channel, u8 data_type, u8 *data, u16 len, > return -EINVAL; > } > > + enable_clocks(1); > + dsi_enable_pll_clock(1); > + > dsi_vc_write_long_header(channel, data_type, len, ecc); > > /*dsi_vc_print_status(0); */ > @@ -1964,6 +1974,9 @@ static int dsi_vc_send_long(int channel, u8 data_type, u8 *data, u16 len, > dsi_vc_write_long_payload(channel, b1, b2, b3, 0); > } > > + enable_clocks(0); > + dsi_enable_pll_clock(0); > + > return r; > } > > @@ -1979,6 +1992,9 @@ static int dsi_vc_send_short(int channel, u8 data_type, u16 data, u8 ecc) > channel, > data_type, data & 0xff, (data >> 8) & 0xff); > > + enable_clocks(1); > + dsi_enable_pll_clock(1); > + > if (FLD_GET(dsi_read_reg(DSI_VC_CTRL(channel)), 16, 16)) { > DSSERR("ERROR FIFO FULL, aborting transfer\n"); > return -EINVAL; > @@ -1990,6 +2006,9 @@ static int dsi_vc_send_short(int channel, u8 data_type, u16 data, u8 ecc) > > dsi_write_reg(DSI_VC_SHORT_PACKET_HEADER(channel), r); > > + enable_clocks(0); > + dsi_enable_pll_clock(0); > + > return 0; > } > > @@ -2775,13 +2794,15 @@ static int dsi_update_thread(void *data) > break; > > dsi_bus_lock(); > - > if (dsi.update_mode == OMAP_DSS_UPDATE_DISABLED || > kthread_should_stop()) { > dsi_bus_unlock(); > break; > } > > + enable_clocks(1); > + dsi_enable_pll_clock(1); > + > dsi_perf_mark_setup(); > > if (dsi.update_region.dirty) { > @@ -2872,6 +2893,9 @@ static int dsi_update_thread(void *data) > > complete_all(&dsi.update_completion); > > + enable_clocks(0); > + dsi_enable_pll_clock(0); > + > dsi_bus_unlock(); > > /* XXX We need to give others chance to get the bus lock. Is > @@ -3068,6 +3092,9 @@ static int dsi_display_enable(struct omap_dss_device *dssdev) > if (dsi.update_mode == OMAP_DSS_UPDATE_AUTO) > dsi_start_auto_update(dssdev); > > + enable_clocks(0); > + dsi_enable_pll_clock(0); > + > dsi_bus_unlock(); > mutex_unlock(&dsi.lock); > > @@ -3101,6 +3128,9 @@ static void dsi_display_disable(struct omap_dss_device *dssdev) > dsi.update_mode = OMAP_DSS_UPDATE_DISABLED; > dssdev->state = OMAP_DSS_DISPLAY_DISABLED; > > + enable_clocks(1); > + dsi_enable_pll_clock(1); > + > dsi_display_uninit_dispc(dssdev); > > dsi_display_uninit_dsi(dssdev); > @@ -3128,6 +3158,9 @@ static int dsi_display_suspend(struct omap_dss_device *dssdev) > dsi.update_mode = OMAP_DSS_UPDATE_DISABLED; > dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED; > > + enable_clocks(1); > + dsi_enable_pll_clock(1); > + > dsi_display_uninit_dispc(dssdev); > > dsi_display_uninit_dsi(dssdev); > @@ -3181,6 +3214,9 @@ static int dsi_display_resume(struct omap_dss_device *dssdev) > if (dsi.update_mode == OMAP_DSS_UPDATE_AUTO) > dsi_start_auto_update(dssdev); > > + enable_clocks(0); > + dsi_enable_pll_clock(0); > + > dsi_bus_unlock(); > mutex_unlock(&dsi.lock); > > @@ -3325,6 +3361,9 @@ static int dsi_display_enable_te(struct omap_dss_device *dssdev, bool enable) > > dsi_bus_lock(); > > + enable_clocks(1); > + dsi_enable_pll_clock(1); > + > dsi.te_enabled = enable; > > if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE) > @@ -3332,6 +3371,9 @@ static int dsi_display_enable_te(struct omap_dss_device *dssdev, bool enable) > > dsi_set_te(dssdev, enable); > end: > + enable_clocks(0); > + dsi_enable_pll_clock(0); > + > dsi_bus_unlock(); > > return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen <tomi.valkeinen@nokia.com> wrote: > Hi, > > If you disable the clocks to allow RET, you also allow OFF mode. And > resuming from OFF mode hasn't been implemented for DSI, if I recall > right. And when I was testing it, it didn't seem to be trivial with the > DSI PLL. > You can limiting the pwrdm next state to RET when being called from cpuidle. > That's why currently you need to disable the display to turn off the > clocks, and the whole DSI block is re-configured when enabling the > display again. > Display enable/disable should only be called when you turn on / off the screen, I'm not sure how this applies to getting the dss_pwrdm to enter RET on idle while scren is on. We haven't tested OFF, but having all power domains enter RET while screen is on and device idle (no rendering) can give significant (~2x) battery life improvements, depending on your hardware of course. -- Mike >  Tomi > > > On Fri, 2009-09-18 at 01:36 +0200, ext Mike Chan wrote: >> Signed-off-by: Mike Chan <mike@android.com> >> --- >>  drivers/video/omap2/dss/dispc.c |   6 ++++- >>  drivers/video/omap2/dss/dsi.c  |  50 +++++++++++++++++++++++++++++++++++--- >>  2 files changed, 51 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c >> index d061d75..4216466 100644 >> --- a/drivers/video/omap2/dss/dispc.c >> +++ b/drivers/video/omap2/dss/dispc.c >> @@ -484,13 +484,17 @@ static inline void enable_clocks(bool enable) >>  bool dispc_go_busy(enum omap_channel channel) >>  { >>    int bit; >> +   bool ret; >> >>    if (channel == OMAP_DSS_CHANNEL_LCD) >>        bit = 5; /* GOLCD */ >>    else >>        bit = 6; /* GODIGIT */ >> >> -   return REG_GET(DISPC_CONTROL, bit, bit) == 1; >> +   enable_clocks(1); >> +   ret = REG_GET(DISPC_CONTROL, bit, bit) == 1; >> +   enable_clocks(0); >> +   return ret; >>  } >> >>  void dispc_go(enum omap_channel channel) >> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c >> index 5e3d653..e9d8a5f 100644 >> --- a/drivers/video/omap2/dss/dsi.c >> +++ b/drivers/video/omap2/dss/dsi.c >> @@ -1186,6 +1186,9 @@ int dsi_pll_init(bool enable_hsclk, bool enable_hsdiv) >>    if (r) >>        goto err1; >> >> +   enable_clocks(0); >> +   dsi_enable_pll_clock(0); >> + >>    DSSDBG("PLL init done\n"); >> >>    return 0; >> @@ -1199,11 +1202,9 @@ err0: >> >>  void dsi_pll_uninit(void) >>  { >> -   enable_clocks(0); >> -   dsi_enable_pll_clock(0); >> - >>    dsi.pll_locked = 0; >>    dsi_pll_power(DSI_PLL_POWER_OFF); >> + >>    regulator_disable(dsi.vdds_dsi_reg); >>    DSSDBG("PLL uninit done\n"); >>  } >> @@ -1848,6 +1849,9 @@ static int dsi_vc_send_bta_sync(int channel) >> >>    INIT_COMPLETION(dsi.bta_completion); >> >> +   enable_clocks(1); >> +   dsi_enable_pll_clock(1); >> + >>    dsi_vc_enable_bta_irq(channel); >> >>    r = dsi_vc_send_bta(channel); >> @@ -1870,6 +1874,9 @@ static int dsi_vc_send_bta_sync(int channel) >>  err: >>    dsi_vc_disable_bta_irq(channel); >> >> +   enable_clocks(0); >> +   dsi_enable_pll_clock(0); >> + >>    return r; >>  } >> >> @@ -1921,6 +1928,9 @@ static int dsi_vc_send_long(int channel, u8 data_type, u8 *data, u16 len, >>        return -EINVAL; >>    } >> >> +   enable_clocks(1); >> +   dsi_enable_pll_clock(1); >> + >>    dsi_vc_write_long_header(channel, data_type, len, ecc); >> >>    /*dsi_vc_print_status(0); */ >> @@ -1964,6 +1974,9 @@ static int dsi_vc_send_long(int channel, u8 data_type, u8 *data, u16 len, >>        dsi_vc_write_long_payload(channel, b1, b2, b3, 0); >>    } >> >> +   enable_clocks(0); >> +   dsi_enable_pll_clock(0); >> + >>    return r; >>  } >> >> @@ -1979,6 +1992,9 @@ static int dsi_vc_send_short(int channel, u8 data_type, u16 data, u8 ecc) >>                channel, >>                data_type, data & 0xff, (data >> 8) & 0xff); >> >> +   enable_clocks(1); >> +   dsi_enable_pll_clock(1); >> + >>    if (FLD_GET(dsi_read_reg(DSI_VC_CTRL(channel)), 16, 16)) { >>        DSSERR("ERROR FIFO FULL, aborting transfer\n"); >>        return -EINVAL; >> @@ -1990,6 +2006,9 @@ static int dsi_vc_send_short(int channel, u8 data_type, u16 data, u8 ecc) >> >>    dsi_write_reg(DSI_VC_SHORT_PACKET_HEADER(channel), r); >> >> +   enable_clocks(0); >> +   dsi_enable_pll_clock(0); >> + >>    return 0; >>  } >> >> @@ -2775,13 +2794,15 @@ static int dsi_update_thread(void *data) >>            break; >> >>        dsi_bus_lock(); >> - >>        if (dsi.update_mode == OMAP_DSS_UPDATE_DISABLED || >>                kthread_should_stop()) { >>            dsi_bus_unlock(); >>            break; >>        } >> >> +       enable_clocks(1); >> +       dsi_enable_pll_clock(1); >> + >>        dsi_perf_mark_setup(); >> >>        if (dsi.update_region.dirty) { >> @@ -2872,6 +2893,9 @@ static int dsi_update_thread(void *data) >> >>        complete_all(&dsi.update_completion); >> >> +       enable_clocks(0); >> +       dsi_enable_pll_clock(0); >> + >>        dsi_bus_unlock(); >> >>        /* XXX We need to give others chance to get the bus lock. Is >> @@ -3068,6 +3092,9 @@ static int dsi_display_enable(struct omap_dss_device *dssdev) >>    if (dsi.update_mode == OMAP_DSS_UPDATE_AUTO) >>        dsi_start_auto_update(dssdev); >> >> +   enable_clocks(0); >> +   dsi_enable_pll_clock(0); >> + >>    dsi_bus_unlock(); >>    mutex_unlock(&dsi.lock); >> >> @@ -3101,6 +3128,9 @@ static void dsi_display_disable(struct omap_dss_device *dssdev) >>    dsi.update_mode = OMAP_DSS_UPDATE_DISABLED; >>    dssdev->state = OMAP_DSS_DISPLAY_DISABLED; >> >> +   enable_clocks(1); >> +   dsi_enable_pll_clock(1); >> + >>    dsi_display_uninit_dispc(dssdev); >> >>    dsi_display_uninit_dsi(dssdev); >> @@ -3128,6 +3158,9 @@ static int dsi_display_suspend(struct omap_dss_device *dssdev) >>    dsi.update_mode = OMAP_DSS_UPDATE_DISABLED; >>    dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED; >> >> +   enable_clocks(1); >> +   dsi_enable_pll_clock(1); >> + >>    dsi_display_uninit_dispc(dssdev); >> >>    dsi_display_uninit_dsi(dssdev); >> @@ -3181,6 +3214,9 @@ static int dsi_display_resume(struct omap_dss_device *dssdev) >>    if (dsi.update_mode == OMAP_DSS_UPDATE_AUTO) >>        dsi_start_auto_update(dssdev); >> >> +   enable_clocks(0); >> +   dsi_enable_pll_clock(0); >> + >>    dsi_bus_unlock(); >>    mutex_unlock(&dsi.lock); >> >> @@ -3325,6 +3361,9 @@ static int dsi_display_enable_te(struct omap_dss_device *dssdev, bool enable) >> >>    dsi_bus_lock(); >> >> +   enable_clocks(1); >> +   dsi_enable_pll_clock(1); >> + >>    dsi.te_enabled = enable; >> >>    if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE) >> @@ -3332,6 +3371,9 @@ static int dsi_display_enable_te(struct omap_dss_device *dssdev, bool enable) >> >>    dsi_set_te(dssdev, enable); >>  end: >> +   enable_clocks(0); >> +   dsi_enable_pll_clock(0); >> + >>    dsi_bus_unlock(); >> >>    return 0; > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Fri, 2009-09-18 at 19:33 +0200, ext Mike Chan wrote: > On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen > <tomi.valkeinen@nokia.com> wrote: > > Hi, > > > > If you disable the clocks to allow RET, you also allow OFF mode. And > > resuming from OFF mode hasn't been implemented for DSI, if I recall > > right. And when I was testing it, it didn't seem to be trivial with the > > DSI PLL. > > > > You can limiting the pwrdm next state to RET when being called from cpuidle. No, you _must_ limit it to RET. Otherwise the DSI will break down. So we can either keep the dsi code as it is now, or explicitely disable OFF mode and then apply your patch. But your patch alone won't work. In the long run I think we anyway need to somehow dynamically manage the power state. I haven't measured it but I believe resuming from OFF will have a bit of a penalty, as (I think) DSI PLL etc. will have to reinitialized. But it would still be good to allow RET whenever possible, and OFF only after some period of inactivity. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomi Valkeinen <tomi.valkeinen@nokia.com> writes: > Hi, > > On Fri, 2009-09-18 at 19:33 +0200, ext Mike Chan wrote: >> On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen >> <tomi.valkeinen@nokia.com> wrote: >> > Hi, >> > >> > If you disable the clocks to allow RET, you also allow OFF mode. And >> > resuming from OFF mode hasn't been implemented for DSI, if I recall >> > right. And when I was testing it, it didn't seem to be trivial with the >> > DSI PLL. >> > >> >> You can limiting the pwrdm next state to RET when being called from cpuidle. > > No, you _must_ limit it to RET. Otherwise the DSI will break down. So we > can either keep the dsi code as it is now, or explicitely disable OFF > mode and then apply your patch. But your patch alone won't work. Or could add a hack to this patch so that 'enable_off_mode' doesn't affect DSS_MOD until DSS has off-mode support. > In the long run I think we anyway need to somehow dynamically manage the > power state. I haven't measured it but I believe resuming from OFF will > have a bit of a penalty, as (I think) DSI PLL etc. will have to > reinitialized. But it would still be good to allow RET whenever > possible, and OFF only after some period of inactivity. This is the purpose of latency constraints. These can be used when the latency of going OFF will cause a problem. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2009-09-22 at 16:54 +0200, ext Kevin Hilman wrote: > Tomi Valkeinen <tomi.valkeinen@nokia.com> writes: > > > Hi, > > > > On Fri, 2009-09-18 at 19:33 +0200, ext Mike Chan wrote: > >> On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen > >> <tomi.valkeinen@nokia.com> wrote: > >> > Hi, > >> > > >> > If you disable the clocks to allow RET, you also allow OFF mode. And > >> > resuming from OFF mode hasn't been implemented for DSI, if I recall > >> > right. And when I was testing it, it didn't seem to be trivial with the > >> > DSI PLL. > >> > > >> > >> You can limiting the pwrdm next state to RET when being called from cpuidle. > > > > No, you _must_ limit it to RET. Otherwise the DSI will break down. So we > > can either keep the dsi code as it is now, or explicitely disable OFF > > mode and then apply your patch. But your patch alone won't work. > > Or could add a hack to this patch so that 'enable_off_mode' doesn't > affect DSS_MOD until DSS has off-mode support. Is this something that the driver can do with the current PM API? The thing is, most of the DSS has off-mode support, only DSI and RFBI is missing the support. So optimally we would allow full PM normally, but when DSI display is in use, only allow RET. > > > In the long run I think we anyway need to somehow dynamically manage the > > power state. I haven't measured it but I believe resuming from OFF will > > have a bit of a penalty, as (I think) DSI PLL etc. will have to > > reinitialized. But it would still be good to allow RET whenever > > possible, and OFF only after some period of inactivity. > > This is the purpose of latency constraints. These can be used when > the latency of going OFF will cause a problem. I think this is a different problem. My understanding of the PM latency functionality is that they control how quickly MPU responds to interrupts, or how quickly the HW module is awake after clk_enable(). The problem here is that there's bunch of DSI initialization that needs to be done after the DSS module has woken up. The DSI PLL needs to be configured and locked, complex IO has to be configured etc. I don't know how long those take (should make some measurements at some point), but I imagine they are not anywhere near instant. And the latency from those things is what I'm concerned about. So it would be beneficial if the DSS driver could define easily what DSS PM level is allowed. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomi Valkeinen <tomi.valkeinen@nokia.com> writes: > On Tue, 2009-09-22 at 16:54 +0200, ext Kevin Hilman wrote: >> Tomi Valkeinen <tomi.valkeinen@nokia.com> writes: >> >> > Hi, >> > >> > On Fri, 2009-09-18 at 19:33 +0200, ext Mike Chan wrote: >> >> On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen >> >> <tomi.valkeinen@nokia.com> wrote: >> >> > Hi, >> >> > >> >> > If you disable the clocks to allow RET, you also allow OFF mode. And >> >> > resuming from OFF mode hasn't been implemented for DSI, if I recall >> >> > right. And when I was testing it, it didn't seem to be trivial with the >> >> > DSI PLL. >> >> > >> >> >> >> You can limiting the pwrdm next state to RET when being called from cpuidle. >> > >> > No, you _must_ limit it to RET. Otherwise the DSI will break down. So we >> > can either keep the dsi code as it is now, or explicitely disable OFF >> > mode and then apply your patch. But your patch alone won't work. >> >> Or could add a hack to this patch so that 'enable_off_mode' doesn't >> affect DSS_MOD until DSS has off-mode support. > > Is this something that the driver can do with the current PM API? The > thing is, most of the DSS has off-mode support, only DSI and RFBI is > missing the support. So optimally we would allow full PM normally, but > when DSI display is in use, only allow RET. There's not an official API for this, but for testing, you could just set the next state for the DSS_MOD to be off. This would be overridden whenever someone changes the enable_off_mode flag. In general, we don't want drivers restricting states at that level. We'd rather the drivers use the OMAP PM layer to define/declare its constraints. >> >> > In the long run I think we anyway need to somehow dynamically manage the >> > power state. I haven't measured it but I believe resuming from OFF will >> > have a bit of a penalty, as (I think) DSI PLL etc. will have to >> > reinitialized. But it would still be good to allow RET whenever >> > possible, and OFF only after some period of inactivity. >> >> This is the purpose of latency constraints. These can be used when >> the latency of going OFF will cause a problem. > > I think this is a different problem. My understanding of the PM latency > functionality is that they control how quickly MPU responds to > interrupts, or how quickly the HW module is awake after clk_enable(). That's only part of the story. > The problem here is that there's bunch of DSI initialization that needs > to be done after the DSS module has woken up. The DSI PLL needs to be > configured and locked, complex IO has to be configured etc. I don't know > how long those take (should make some measurements at some point), but I > imagine they are not anywhere near instant. And the latency from those > things is what I'm concerned about. So it would be beneficial if the DSS > driver could define easily what DSS PM level is allowed. Actually, the OMAP PM layer is meant to handle device wakeup latencies as well. See Documentation/arm/OMAP/omap_pm, and the set_max_dev_wakeup_lat() hook in particular. For example, if you know that DSS wakeup from OFF takes X usecs and the driver has set a max device wakeup latency < X, then DSS will never go to OFF. The same can be done to prevent RET for even faster wakeup. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2009-09-23 at 17:44 +0200, ext Kevin Hilman wrote: > Tomi Valkeinen <tomi.valkeinen@nokia.com> writes: > > > On Tue, 2009-09-22 at 16:54 +0200, ext Kevin Hilman wrote: > >> Tomi Valkeinen <tomi.valkeinen@nokia.com> writes: > >> > >> > Hi, > >> > > >> > On Fri, 2009-09-18 at 19:33 +0200, ext Mike Chan wrote: > >> >> On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen > >> >> <tomi.valkeinen@nokia.com> wrote: > >> >> > Hi, > >> >> > > >> >> > If you disable the clocks to allow RET, you also allow OFF mode. And > >> >> > resuming from OFF mode hasn't been implemented for DSI, if I recall > >> >> > right. And when I was testing it, it didn't seem to be trivial with the > >> >> > DSI PLL. > >> >> > > >> >> > >> >> You can limiting the pwrdm next state to RET when being called from cpuidle. > >> > > >> > No, you _must_ limit it to RET. Otherwise the DSI will break down. So we > >> > can either keep the dsi code as it is now, or explicitely disable OFF > >> > mode and then apply your patch. But your patch alone won't work. > >> > >> Or could add a hack to this patch so that 'enable_off_mode' doesn't > >> affect DSS_MOD until DSS has off-mode support. > > > > Is this something that the driver can do with the current PM API? The > > thing is, most of the DSS has off-mode support, only DSI and RFBI is > > missing the support. So optimally we would allow full PM normally, but > > when DSI display is in use, only allow RET. > > There's not an official API for this, but for testing, you could just > set the next state for the DSS_MOD to be off. This would be overridden > whenever someone changes the enable_off_mode flag. > > In general, we don't want drivers restricting states at that level. > We'd rather the drivers use the OMAP PM layer to define/declare its > constraints. If I want to disable OFF mode for DSS with constraints, doesn't it mean that I need to dig out a magic number, and use it as the max wakeup latency, and that latency will then limit DSS from going to OFF mode? > > >> > >> > In the long run I think we anyway need to somehow dynamically manage the > >> > power state. I haven't measured it but I believe resuming from OFF will > >> > have a bit of a penalty, as (I think) DSI PLL etc. will have to > >> > reinitialized. But it would still be good to allow RET whenever > >> > possible, and OFF only after some period of inactivity. > >> > >> This is the purpose of latency constraints. These can be used when > >> the latency of going OFF will cause a problem. > > > > I think this is a different problem. My understanding of the PM latency > > functionality is that they control how quickly MPU responds to > > interrupts, or how quickly the HW module is awake after clk_enable(). > > That's only part of the story. > > > The problem here is that there's bunch of DSI initialization that needs > > to be done after the DSS module has woken up. The DSI PLL needs to be > > configured and locked, complex IO has to be configured etc. I don't know > > how long those take (should make some measurements at some point), but I > > imagine they are not anywhere near instant. And the latency from those > > things is what I'm concerned about. So it would be beneficial if the DSS > > driver could define easily what DSS PM level is allowed. > > Actually, the OMAP PM layer is meant to handle device wakeup latencies > as well. See Documentation/arm/OMAP/omap_pm, and the > set_max_dev_wakeup_lat() hook in particular. > > For example, if you know that DSS wakeup from OFF takes X usecs and > the driver has set a max device wakeup latency < X, then DSS will > never go to OFF. The same can be done to prevent RET for even faster > wakeup. The doc says "set_max_dev_wakeup_lat() function to constrain the device wakeup latency (from clk_enable() to accessibility)". I understood "accessibility" meaning that the HW registers can be accessed, and also as registers should be accessible after clk_enable(), it would mean that clk_enable will block at most the defined wakeup latency. If it is not like that, and the driver initialization is included, how does the PM layer know how long it takes for the DSS driver to reconfigure the DSS hardware from OFF mode? Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomi Valkeinen wrote: > On Wed, 2009-09-23 at 17:44 +0200, ext Kevin Hilman wrote: >> Tomi Valkeinen <tomi.valkeinen@nokia.com> writes: >> >>> On Tue, 2009-09-22 at 16:54 +0200, ext Kevin Hilman wrote: >>>> Tomi Valkeinen <tomi.valkeinen@nokia.com> writes: >>>> >>>>> Hi, >>>>> >>>>> On Fri, 2009-09-18 at 19:33 +0200, ext Mike Chan wrote: >>>>>> On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen >>>>>> <tomi.valkeinen@nokia.com> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> If you disable the clocks to allow RET, you also allow OFF mode. And >>>>>>> resuming from OFF mode hasn't been implemented for DSI, if I recall >>>>>>> right. And when I was testing it, it didn't seem to be trivial with the >>>>>>> DSI PLL. >>>>>>> >>>>>> You can limiting the pwrdm next state to RET when being called from cpuidle. >>>>> No, you _must_ limit it to RET. Otherwise the DSI will break down. So we >>>>> can either keep the dsi code as it is now, or explicitely disable OFF >>>>> mode and then apply your patch. But your patch alone won't work. >>>> Or could add a hack to this patch so that 'enable_off_mode' doesn't >>>> affect DSS_MOD until DSS has off-mode support. >>> Is this something that the driver can do with the current PM API? The >>> thing is, most of the DSS has off-mode support, only DSI and RFBI is >>> missing the support. So optimally we would allow full PM normally, but >>> when DSI display is in use, only allow RET. >> There's not an official API for this, but for testing, you could just >> set the next state for the DSS_MOD to be off. This would be overridden >> whenever someone changes the enable_off_mode flag. >> >> In general, we don't want drivers restricting states at that level. >> We'd rather the drivers use the OMAP PM layer to define/declare its >> constraints. > > If I want to disable OFF mode for DSS with constraints, doesn't it mean > that I need to dig out a magic number, and use it as the max wakeup > latency, and that latency will then limit DSS from going to OFF mode? Yes, the various wakeup times for RET and OFF should be measured so that smart decisions can be made. >>>>> In the long run I think we anyway need to somehow dynamically manage the >>>>> power state. I haven't measured it but I believe resuming from OFF will >>>>> have a bit of a penalty, as (I think) DSI PLL etc. will have to >>>>> reinitialized. But it would still be good to allow RET whenever >>>>> possible, and OFF only after some period of inactivity. >>>> This is the purpose of latency constraints. These can be used when >>>> the latency of going OFF will cause a problem. >>> I think this is a different problem. My understanding of the PM latency >>> functionality is that they control how quickly MPU responds to >>> interrupts, or how quickly the HW module is awake after clk_enable(). >> That's only part of the story. >> >>> The problem here is that there's bunch of DSI initialization that needs >>> to be done after the DSS module has woken up. The DSI PLL needs to be >>> configured and locked, complex IO has to be configured etc. I don't know >>> how long those take (should make some measurements at some point), but I >>> imagine they are not anywhere near instant. And the latency from those >>> things is what I'm concerned about. So it would be beneficial if the DSS >>> driver could define easily what DSS PM level is allowed. >> Actually, the OMAP PM layer is meant to handle device wakeup latencies >> as well. See Documentation/arm/OMAP/omap_pm, and the >> set_max_dev_wakeup_lat() hook in particular. >> >> For example, if you know that DSS wakeup from OFF takes X usecs and >> the driver has set a max device wakeup latency < X, then DSS will >> never go to OFF. The same can be done to prevent RET for even faster >> wakeup. > > The doc says "set_max_dev_wakeup_lat() function to constrain the device > wakeup latency (from clk_enable() to accessibility)". I understood > "accessibility" meaning that the HW registers can be accessed, and also > as registers should be accessible after clk_enable(), it would mean that > clk_enable will block at most the defined wakeup latency. Not exactly, clk_enable() doesn't actually block. Rather, the max latencies are intended to be used when considering which C-state to enter. If a C-state has a wakeup latency longer than any of the latency constraints set (MPU or device) then that C-state will not be entered. In this way you effectively prevent OFF mode (deeper C-state) by setting a max latency which is shorter than the wakeup latency of OFF mode. Right now you could do it simply by setting a max MPU wakeup latency, but we really need to measure the various device wakeup latencies so we can use them as well. > If it is not like that, and the driver initialization is included, how > does the PM layer know how long it takes for the DSS driver to > reconfigure the DSS hardware from OFF mode? Currently it doesn't, but if you were measure it, we can use those numbers in the decision making process. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2009-09-24 at 17:52 +0200, ext Kevin Hilman wrote: > Tomi Valkeinen wrote: > > If it is not like that, and the driver initialization is included, how > > does the PM layer know how long it takes for the DSS driver to > > reconfigure the DSS hardware from OFF mode? > > Currently it doesn't, but if you were measure it, we can use those > numbers in the decision making process. Ok, now I see. However, I'm not sure if that will work. The problem is that the wakeup latency depends on many things. When using DPI/RFBI the wakeup is very fast. With SDI it's probably a bit slower and with DSI even slower. And at least with DSI PLL, the wakeup time depends on the frequencies used (according to TRM), and in some cases it can be optimized, in some cases not. So I don't think there's one single value that fits all. Also, I still think it would be better if the driver was also able to prevent OFF mode explicitely. Defining the max-wakeup-lat with a magic number sounds a bit prone to breaking up. But perhaps, as you said, when drivers work properly they don't have to care about OFF mode as such, but only about the wakeup latency, and thus the max-wakeup-lat is enough. I'm just not quite sure about that, as OFF mode may have side effects as the module is totally powered off, while with RET the side effects should be minimal. I don't have any concrete example about the side effects, but one particular thing I'm thinking about is DSI PLL. If DSS is in RET, I believe DSI PLL works normally. But if the DSS is reset via OFF mode, I believe DSI PLL is also reset. But I'm not sure if DSI PLL is ever needed while DSS would be off, so this may be theoretical =). Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index d061d75..4216466 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -484,13 +484,17 @@ static inline void enable_clocks(bool enable) bool dispc_go_busy(enum omap_channel channel) { int bit; + bool ret; if (channel == OMAP_DSS_CHANNEL_LCD) bit = 5; /* GOLCD */ else bit = 6; /* GODIGIT */ - return REG_GET(DISPC_CONTROL, bit, bit) == 1; + enable_clocks(1); + ret = REG_GET(DISPC_CONTROL, bit, bit) == 1; + enable_clocks(0); + return ret; } void dispc_go(enum omap_channel channel) diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index 5e3d653..e9d8a5f 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -1186,6 +1186,9 @@ int dsi_pll_init(bool enable_hsclk, bool enable_hsdiv) if (r) goto err1; + enable_clocks(0); + dsi_enable_pll_clock(0); + DSSDBG("PLL init done\n"); return 0; @@ -1199,11 +1202,9 @@ err0: void dsi_pll_uninit(void) { - enable_clocks(0); - dsi_enable_pll_clock(0); - dsi.pll_locked = 0; dsi_pll_power(DSI_PLL_POWER_OFF); + regulator_disable(dsi.vdds_dsi_reg); DSSDBG("PLL uninit done\n"); } @@ -1848,6 +1849,9 @@ static int dsi_vc_send_bta_sync(int channel) INIT_COMPLETION(dsi.bta_completion); + enable_clocks(1); + dsi_enable_pll_clock(1); + dsi_vc_enable_bta_irq(channel); r = dsi_vc_send_bta(channel); @@ -1870,6 +1874,9 @@ static int dsi_vc_send_bta_sync(int channel) err: dsi_vc_disable_bta_irq(channel); + enable_clocks(0); + dsi_enable_pll_clock(0); + return r; } @@ -1921,6 +1928,9 @@ static int dsi_vc_send_long(int channel, u8 data_type, u8 *data, u16 len, return -EINVAL; } + enable_clocks(1); + dsi_enable_pll_clock(1); + dsi_vc_write_long_header(channel, data_type, len, ecc); /*dsi_vc_print_status(0); */ @@ -1964,6 +1974,9 @@ static int dsi_vc_send_long(int channel, u8 data_type, u8 *data, u16 len, dsi_vc_write_long_payload(channel, b1, b2, b3, 0); } + enable_clocks(0); + dsi_enable_pll_clock(0); + return r; } @@ -1979,6 +1992,9 @@ static int dsi_vc_send_short(int channel, u8 data_type, u16 data, u8 ecc) channel, data_type, data & 0xff, (data >> 8) & 0xff); + enable_clocks(1); + dsi_enable_pll_clock(1); + if (FLD_GET(dsi_read_reg(DSI_VC_CTRL(channel)), 16, 16)) { DSSERR("ERROR FIFO FULL, aborting transfer\n"); return -EINVAL; @@ -1990,6 +2006,9 @@ static int dsi_vc_send_short(int channel, u8 data_type, u16 data, u8 ecc) dsi_write_reg(DSI_VC_SHORT_PACKET_HEADER(channel), r); + enable_clocks(0); + dsi_enable_pll_clock(0); + return 0; } @@ -2775,13 +2794,15 @@ static int dsi_update_thread(void *data) break; dsi_bus_lock(); - if (dsi.update_mode == OMAP_DSS_UPDATE_DISABLED || kthread_should_stop()) { dsi_bus_unlock(); break; } + enable_clocks(1); + dsi_enable_pll_clock(1); + dsi_perf_mark_setup(); if (dsi.update_region.dirty) { @@ -2872,6 +2893,9 @@ static int dsi_update_thread(void *data) complete_all(&dsi.update_completion); + enable_clocks(0); + dsi_enable_pll_clock(0); + dsi_bus_unlock(); /* XXX We need to give others chance to get the bus lock. Is @@ -3068,6 +3092,9 @@ static int dsi_display_enable(struct omap_dss_device *dssdev) if (dsi.update_mode == OMAP_DSS_UPDATE_AUTO) dsi_start_auto_update(dssdev); + enable_clocks(0); + dsi_enable_pll_clock(0); + dsi_bus_unlock(); mutex_unlock(&dsi.lock); @@ -3101,6 +3128,9 @@ static void dsi_display_disable(struct omap_dss_device *dssdev) dsi.update_mode = OMAP_DSS_UPDATE_DISABLED; dssdev->state = OMAP_DSS_DISPLAY_DISABLED; + enable_clocks(1); + dsi_enable_pll_clock(1); + dsi_display_uninit_dispc(dssdev); dsi_display_uninit_dsi(dssdev); @@ -3128,6 +3158,9 @@ static int dsi_display_suspend(struct omap_dss_device *dssdev) dsi.update_mode = OMAP_DSS_UPDATE_DISABLED; dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED; + enable_clocks(1); + dsi_enable_pll_clock(1); + dsi_display_uninit_dispc(dssdev); dsi_display_uninit_dsi(dssdev); @@ -3181,6 +3214,9 @@ static int dsi_display_resume(struct omap_dss_device *dssdev) if (dsi.update_mode == OMAP_DSS_UPDATE_AUTO) dsi_start_auto_update(dssdev); + enable_clocks(0); + dsi_enable_pll_clock(0); + dsi_bus_unlock(); mutex_unlock(&dsi.lock); @@ -3325,6 +3361,9 @@ static int dsi_display_enable_te(struct omap_dss_device *dssdev, bool enable) dsi_bus_lock(); + enable_clocks(1); + dsi_enable_pll_clock(1); + dsi.te_enabled = enable; if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE) @@ -3332,6 +3371,9 @@ static int dsi_display_enable_te(struct omap_dss_device *dssdev, bool enable) dsi_set_te(dssdev, enable); end: + enable_clocks(0); + dsi_enable_pll_clock(0); + dsi_bus_unlock(); return 0;
Signed-off-by: Mike Chan <mike@android.com> --- drivers/video/omap2/dss/dispc.c | 6 ++++- drivers/video/omap2/dss/dsi.c | 50 +++++++++++++++++++++++++++++++++++--- 2 files changed, 51 insertions(+), 5 deletions(-)