lkml.org 
[lkml]   [2010]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RESEND][PATCHv2 4/4] OMAP: DSS2: Add Innolux 7" display for DEVKIT8000
    From
    Date
    On Fri, 2010-02-19 at 13:57 +0100, ext Thomas Weber wrote:
    > Tomi Valkeinen wrote:
    > > On Fri, 2010-02-12 at 06:55 +0100, ext Jaya Kumar wrote:
    > >
    > >> On Fri, Feb 12, 2010 at 3:41 AM, Thomas Weber <swirl@gmx.li> wrote:
    > >>
    > >
    > > [snip]
    > >
    > >
    > >>> +
    > >>> +static struct omap_video_timings innolux_at_timings = {
    > >>> + .x_res = 800,
    > >>> + .y_res = 480,
    > >>> +
    > >>> + .pixel_clock = 40000,
    > >>> +
    > >>> + .hsw = 48,
    > >>> + .hfp = 1,
    > >>> + .hbp = 1,
    > >>> +
    > >>> + .vsw = 3,
    > >>> + .vfp = 12,
    > >>> + .vbp = 25,
    > >>> +};
    > >>> +
    > >>> +static int innolux_at_panel_probe(struct omap_dss_device *dssdev)
    > >>> +{
    > >>> + dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
    > >>> + OMAP_DSS_LCD_IHS;
    > >>> + dssdev->panel.acb = 0x28;
    > >>> + dssdev->panel.timings = innolux_at_timings;
    > >>> +
    > >>> + return 0;
    > >>> +}
    > >>> +
    > >>>
    > >> Hi Thomas, Tomi,
    > >>
    > >> Just curious, does this patch imply that code like this needs to be
    > >> written for every single LCD type and resolution that can be connected
    > >> to omap2? Maybe there is a better way, like a common table of timings
    > >> and values that can be selected with a module option or even
    > >> autodetected.
    > >>
    > >
    > > Yes, it is true that currently you need to write these for every LCD. I
    > > have been thinking this issue, and I think we can make a common driver.
    > >
    > > However, it's not just selecting timings, as LCDs can have also other
    > > characteristics than just the video timings. For example, some may have
    > > power on/off line, some reset enable/disable, some need 50ms after
    > > reset, some 80ms after reset etc.
    > >
    > > But if we manage to get a sane set of those settings into the table, we
    > > could perhaps cover most of the "dummy" LCDs with it.
    > >
    > > This change doesn't probably need any changes to the DSS core, only for
    > > the panel driver. Any takers for this task? =)
    > >
    > > 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
    > >
    > >
    > >
    > Hello,
    >
    > sorry but I am not able to take the task.
    > Make it sense to rework this patch or do you want first the changes to
    > the panel driver?

    I probably won't have time to implement this generic panel driver yet.
    However, I will be merging some DSS driver model changes (sent to
    mailing lists) soon, after which this patch needs to be changed a bit.

    The changes can be found from
    http://gitorious.org/linux-omap-dss2/linux/commits/work but they may
    still change a bit.

    Tomi




    \
     
     \ /
      Last update: 2010-02-23 12:57    [W:0.025 / U:32.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site