05 Oct, 2011

3 commits

  • The Freescale DIU video controller supports five video "modes", but only
    the first two are used by the driver. The other three are special modes
    that don't make sense for a framebuffer driver. Therefore, there's no
    point in keeping a global variable that indicates which mode we're
    supposed to use.

    Signed-off-by: Timur Tabi
    Signed-off-by: Florian Tobias Schandinat

    Timur Tabi
     
  • Move several macros and structures from the Freescale DIU driver's header
    file into the source file, because they're only used by that file. Also
    delete a few unused macros.

    The diu and diu_ad structures cannot be moved because they're being used
    by the MPC5121 platform file. A future patch eliminate the need for
    the platform file to access these structs, so they'll be moved also.

    Signed-off-by: Timur Tabi
    Signed-off-by: Florian Tobias Schandinat

    Timur Tabi
     
  • Use the _IOx macros to define the ioctl commands, instead of hard-coded
    numbers. Unfortunately, the original definitions of MFB_SET_PIXFMT and
    MFB_GET_PIXFMT used the wrong value for the size, so these macros have
    new values now. To avoid breaking binary compatibility with older
    applications, we retain support for the original values, but the driver
    displays a warning message if they're used.

    Also remove the FBIOGET_GWINFO and FBIOPUT_GWINFO ioctls. FBIOPUT_GWINFO
    was never implemented, and FBIOGET_GWINFO was never used by any
    application.

    Signed-off-by: Timur Tabi
    Signed-off-by: Florian Tobias Schandinat

    Timur Tabi
     

19 Sep, 2011

3 commits


24 Jun, 2011

1 commit

  • The Freescale DIU framebuffer driver defines two constants, MIN_PIX_CLK and
    MAX_PIX_CLK, that are supposed to represent the lower and upper limits of
    the pixel clock. These values, however, are true only for one platform
    clock rate (533MHz) and only for the MPC8610. So the actual range for
    the pixel clock is chip-specific, which means the current values are almost
    always wrong. The chance of an out-of-range pixel clock being used are also
    remote.

    Rather than try to detect an out-of-range clock in the DIU driver, we depend
    on the board-specific pixel clock function (e.g. p1022ds_set_pixel_clock)
    to clamp the pixel clock to a supported value.

    Signed-off-by: Timur Tabi
    Signed-off-by: Paul Mundt

    Timur Tabi
     

15 Nov, 2010

1 commit


02 Aug, 2010

1 commit