[Natty][pull-request] DRM driver for OMAP 3
tim.gardner at canonical.com
Fri Apr 8 15:10:23 UTC 2011
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
> 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.
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.
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team