[Natty][pull-request] DRM driver for OMAP 3

[Ricardo Salveti]

On Fri, Apr 8, 2011 at 10:15 AM, Tim Gardner <tim.gardner at canonical.com> wrote:
> This looks like a maintenance nightmare. Its great that you guys have the
> display issues worked out, but its bad that none of this is upstream. There
> is no way I'm gonna accept this on the eve of the kernel freeze.

True, not all is upstream yet, as we kind of just finished the driver.

These are the status of the patches:

Upstream already:
Sumit Semwal (1):
     OMAP2, 3: DSS2: Create new file display.c for central dss driver
registration.

Not yet upstream, but included and used at the ti-omap4 branch for
Maverick and Natty:
Jeff McGee (1):
     drm: Call platform register/unregister for platform drivers.

Also used at the ti-omap4 branch:
Sebastien Jan (1):
     OMAP4: DSS: add generic notifier mechanism

New patches, but will also be applied and used at the ti-omap4 branch:
Ricardo Salveti de Araujo (5):
     drm/omap: add common scaled modes
     OMAP2: DSS2: Adding i2c_bus_num to panel_generic_dpi_data to
probe the eeprom
     OMAP: DSS2: add get_edid and is_detected support
     drm/omap: adding MODULE_ALIAS
     UBUNTU: [Config] enable CONFIG_DRM_OMAP=m and
CONFIG_OMAP2_DSS_USE_DSI_PLL=y for omap

Rob Clark (10):
     OMAP: DSS2: Expose API to get edid
     OMAP: DSS2: Add default get/check timings functions
     OMAP: DSS2: Add is_detected() driver API
     OMAP: DSS2: Add hotplug notify events
     OMAP: DSS2: Add missing color formats
     drm: psuedocolor support for ARGB modes
     drm: platform multi-device support
     fbops support for framebuffers with alpha channel
     Adding omap_gpu drm display driver
     omap2+: fix number of omap_vout resources

The good thing is that the generic changes are quite simple and most
contained for OMAP. The DRM driver itself is quite simple, basically
linking the DSS2 subsystem with DRM, and using the DRM functions to
implement the framebuffer driver.

As the user can still fix the resolution by setting it up at the
kernel command line (as we're currently using at the images), there's
no bad side effect of having and using this new driver besides getting
a new functionality.

I understand if we can't include this for natty, but don't really
think it's going to be a maintenance nightmare.

Thanks,
-- 
Ricardo Salveti de Araujo