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

[Tim Gardner]

On 04/08/2011 08:28 AM, Ricardo Salveti wrote:
> 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,

The fact that most of these patches are simple or are in use on the 
ti-omap4 branch isn't relevant. The points that are important to the 
distro kernel are a) this is a new feature and we are past feature 
freeze, b) all but one of these patches diddle in existing source in 
such a way so as to guarantee conflicts with future stable updates.

I'm quite open to experimentation in the ti-omap4 branch, but not in the 
main distro kernel.

rtg
-- 
Tim Gardner tim.gardner at canonical.com