06 Dec, 2011

22 commits


01 Dec, 2011

1 commit

  • Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent
    names, especially for the RGB formats. Component order and byte order are
    now strictly specified for each format.

    The RGB format naming follows a convention where the components names
    and sizes are listed from left to right, matching the order within a
    single pixel from most significant bit to least significant bit.

    The YUV format names vary more. For the 4:2:2 packed formats and 2
    plane formats use the fourcc. For the three plane formats the
    name includes the plane order and subsampling information using the
    standard subsampling notation. Some of those also happen to match
    the official fourcc definition.

    The fourccs for for all the RGB formats and some of the YUV formats
    I invented myself. The idea was that looking at just the fourcc you
    get some idea what the format is about without having to decode it
    using some external reference.

    Signed-off-by: Ville Syrjälä
    Signed-off-by: Dave Airlie

    Ville Syrjälä
     

30 Nov, 2011

1 commit


29 Nov, 2011

1 commit

  • Commit 308e5bcbdb10 ("drm: add an fb creation ioctl that takes a pixel
    format v5") missed one spot needing to be fixed up in the __BIG_ENDIAN
    case.

    Fixes build error:

    drivers/gpu/drm/radeon/radeon_fb.c: In function
    'radeonfb_create_pinned_object':
    drivers/gpu/drm/radeon/radeon_fb.c:144:18: error: 'struct drm_mode_fb_cmd2'
    has no member named 'bpp'

    Signed-off-by: Stephen Rothwell
    Signed-off-by: Dave Airlie

    Dave Airlie
     

28 Nov, 2011

3 commits


25 Nov, 2011

1 commit


16 Nov, 2011

11 commits

  • * drm-gma500-alanc:
    gma500: Now connect up to the DRM build to finish the job
    gma500: fixup build versus latest header changes.
    gma500: Add support for Cedarview
    gma500: Add Oaktrail support
    gma500: Add Poulsbo support
    gma500: Add the core DRM files and headers
    gma500: Add the i2c bus support
    gma500: Add the glue to the various BIOS and firmware interfaces
    gma500: Add device framework
    gma500: introduce the framebuffer support code
    gma500: introduce the GTT and MMU handling logic
    gma500: GEM and GEM glue
    gma500: Move the basic driver out of staging

    Dave Airlie
     
  • Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • Signed-off-by: Dave Airlie

    Dave Airlie
     
  • Again this is similar but has some differences so we have a set of plug in
    support. This does make the driver bigger than is needed in some respects
    but the tradeoff for maintainability is huge.

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • Oaktrail (GMA600) is found on some tablet/slate PC type systems. It's a bit
    different to the GMA500 but similar enough it makes sense to plug it into
    the same driver.

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • This provides the specific code for Poulsbo, some of which is also used for
    the later chipsets. We support the GTT, the 2D engine (for console), and
    the display setup/management. We do not support 3D or the video overlays.

    In theory enough public info is available to do the video overlay work
    but that represents a large task.

    Framebuffer X will run nicely with this but do *NOT* use the VESA X
    server at the same time as KMS. With a Dell mini 10 things like Xfce4 are
    nice and usable even when compositing as the CPU has a good path to the
    memory.

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • Not really a nice way to split this up further for submission. This
    provides all the DRM interfacing logic, the headers and relevant glue.

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • Again this might be a candidate for sharing later.

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • Some of this should one day become a library shared by i915 and gma500 I
    suspct. Best however to deal with that later once it is all nice and
    stably merged.

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • The devices have various internal differences so we have some abstractions
    to hide the ugly differences and we then wrap them up in standard
    interfaces. Add these bits

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox
     
  • We support 2D acceleration on some devices but we try and do tricks with
    the GTT as a starting point as this is far faster. The GTT logic could be
    improved further but for most display sizes it already makes a pretty good
    decision.

    Signed-off-by: Alan Cox
    Signed-off-by: Dave Airlie

    Alan Cox