Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss
Hi Tomi, On Wednesday, 18 October 2017 12:56:12 EET Tomi Valkeinen wrote: > On 18/10/17 12:46, Tomi Valkeinen wrote: > > On 13/10/17 17:58, Laurent Pinchart wrote: > >> Hello, > >> > >> This patch series merges the omapdrm and omapdss drivers into a single > >> driver called omapdrm. The split in two drivers was historical, in order > >> to support the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver > >> supports DRM/KMS only there's no need to keep two seperate drivers. [snip] > >> The series has been tested on a Pandaboard with the DVI and HDMI output. > > > > Here's what I get on AM5 EVM: [snip] > [ 14.783558] dmm 4e00.dmm: initialized all PAT entries > [ 14.805775] DSS: OMAP DSS rev 6.1 > [ 14.809989] omapdss_dss 5800.dss: bound 58001000.dispc (ops > dispc_component_ops [omapdrm]) > [ 14.821844] omapdss_dss 5800.dss: bound 5804.encoder (ops > hdmi5_component_ops [omapdrm]) > [ 14.833482] omapdss_dss 5800.dss: master bind failed: -517 > > When I remove modules, something is left enabled as I get: > > [ 99.623954] platform 5800.dss: enabled after unload, idling I initially thought this would disappear after fixing the other issues, but it seems to be a problem of its own, which I have thus investigated. I had to trace through the runtime PM code to understand what was going on, which wasn't a pleasant experience, but I managed to find the root cause and to create a fix. The culprit is initialization of runtime PM in the DSS component master bind handler coupled with probe deferral from within that handler. The bind handler performs the following sequence of PM operations: pm_runtime_enable(dev); pm_runtime_get_sync(dev); ... (access the hardware to read the device revision) ... pm_runtime_put_sync(dev); If a failure occurs at this point, the error path calls pm_runtime_disable() to balance the pm_runtime_enable() call. Now it should be noted that the bind handler is called when one of the component registers itself, which happens in the component's probe handler. Furthermore, as the components are children of the DSS, the device core calls pm_runtime_get_sync() on the DSS platform device before calling the component's probe handler. This increases the DSS power usage count but doesn't runtime resume the device, as runtime PM is disabled at that point. The bind handler is thus called with runtime PM disabled, with the device runtime suspended, but with the power usage count larger than 0. The pm_runtime_get_sync() call will thus further increase the power usage count and runtime resume the device. The pm_runtime_put_sync() handler will decrease the power usage count to a non-zero value and will thus not suspend the device. Finally, the pm_runtime_disable() call will disable runtime PM, preventing the pm_runtime_put() call in the device core from runtime suspending the device. The DSS device is thus left powered on. To fix this, I've created a patch that moves the runtime PM initialization code (as well as most of the rest of the initialization code) from the bind handler to the probe handler. I'll post it in v2 of this series. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss
Hi, On 13/10/17 17:58, Laurent Pinchart wrote: > Hello, > > This patch series merges the omapdrm and omapdss drivers into a single driver > called omapdrm. The split in two drivers was historical, in order to support > the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports DRM/KMS only > there's no need to keep two seperate drivers. I've picked the following patches from the beginning of the series for v4.16. I would have picked a few more, but started to get conflicts. drm: omapdrm: Deconstruct the omap_drv.h header. drm: omapdrm: venc: Return error code on OF parsing failure drm: omapdrm: dpi: Remove dpi_data port_initialized field drm: omapdrm: dss: Make dss_dump_clocks() function static drm: omapdrm: dss: Set the DMA coherent mask drm: omapdrm: Remove unused omap_dss_find_device() function drm: omapdrm: Pass drm_device to omap_gem_resume() drm: omapdrm: dpi: Don't treat GPIO probe deferral as an error Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 13/10/17 17:58, Laurent Pinchart wrote: > Hello, > > This patch series merges the omapdrm and omapdss drivers into a single driver > called omapdrm. The split in two drivers was historical, in order to support So how do the loadtime and runtime dependencies go with this series? In the current mainline, it's kind of clear: We have omapdss, and the panel and encoder drivers register themselves to omapdss. So panels and encoders depend on omapdss. On top of that we have omapdrm which then uses both omapdss and panels. Unloading happens in reverse order. With only omapdrm, the panels and encoders must depend on that. But omapdrm will use the panels, so there's a runtime dependency that way. Do we need to use sysfs's unbind first to remove some drivers, before module unloading is possible? Which ones? Does it work? Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 18/10/17 12:46, Tomi Valkeinen wrote: > Hi Laurent, > > On 13/10/17 17:58, Laurent Pinchart wrote: >> Hello, >> >> This patch series merges the omapdrm and omapdss drivers into a single driver >> called omapdrm. The split in two drivers was historical, in order to support >> the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports DRM/KMS only >> there's no need to keep two seperate drivers. >> >> The series starts with a few cleanups (01/48 to 03/48) and quickly proceeds >> to >> merging the omapdss and omapdss-base modules (04/48). It then prepares the >> omapdss code (05/48 to 08/48), perform a few more cleanups (09/48 to 11/48) >> and prepares the omapdrm code (12/48). >> >> Patches 13/48 to 19/48 prepare the connector, encoder and panel drivers. All >> those drivers defer probing when their video source can't be found at probe >> time. This would cause endless probe deferral when merging omapdrm and >> omapdss >> as the drivers need omapdss to be fully initialized to probe successfully, >> but >> cause omapdrm to defer probing when they're not available. >> >> Patch 20/48 merges the omapdrm and omapdss drivers. >> >> The next patches are added bonuses that start removal of global variables >> from >> the driver. The code relies heavily on global variables for objects that are >> instance-specific, and should thus be dynamically allocated. Most of the >> patches change internal APIs to pass objects to driver functions (21/48 to >> 28/48, 36/48, 39/48 to 41/38, 43/48 to 45/48) with a few miscellaneous >> cleanups (29/48, 35/48, 37/48, 38/48, 42/48). Patches 30/48 to 34/48 and >> 46/48 >> then allocate instance objects dynamically to replace global variables, and >> patches 47/48 and 48/48 move global variables to existing instance objects. >> >> The series has been tested on a Pandaboard with the DVI and HDMI output. > > Here's what I get on AM5 EVM: > > # ./s-drm-new > [ 17.535638] sysrq: SysRq : Changing Loglevel > [ 17.540179] sysrq: Loglevel set to 9 > insmod nfs/work/linux/sound/soc/omap/snd-soc-omap-hdmi-audio.ko > insmod nfs/work/linux/drivers/media/cec/cec.ko > insmod nfs/work/linux/drivers/video/fbdev/core/cfbcopyarea.ko > insmod nfs/work/linux/drivers/video/fbdev/core/cfbimgblt.ko > insmod nfs/work/linux/drivers/video/fbdev/core/cfbfillrect.ko > insmod nfs/work/linux/drivers/gpu/drm/drm.ko > insmod nfs/work/linux/drivers/gpu/drm/drm_kms_helper.ko > insmod nfs/work/linux/drivers/gpu/drm/omapdrm/omapdrm.ko > [ 17.966444] dmm 4e00.dmm: initialized all PAT entries > [ 18.004857] DSS: OMAP DSS rev 6.1 > [ 18.010743] omapdss_dss 5800.dss: bound 58001000.dispc (ops > dispc_component_ops [omapdrm]) > [ 18.025076] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-dai <-> > 5804.encoder mapping ok > [ 18.050076] omapdss_dss 5800.dss: bound 5804.encoder (ops > hdmi5_component_ops [omapdrm]) > [ 18.074540] omapdss_dss 5800.dss: master bind failed: -517 If I disable HDMI audio, the spam goes away, and I just get: [ 14.783558] dmm 4e00.dmm: initialized all PAT entries [ 14.805775] DSS: OMAP DSS rev 6.1 [ 14.809989] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 14.821844] omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops [omapdrm]) [ 14.833482] omapdss_dss 5800.dss: master bind failed: -517 When I remove modules, something is left enabled as I get: [ 99.623954] platform 5800.dss: enabled after unload, idling If, after loading omapdrm as above, I also load encoder/panel drivers, I get a picture after a spam of "omapdss_dss 5800.dss: master bind failed: -517" and "alloc_contig_range: [fd874, fd875) PFNs busy" messages. But then, I can't unload any modules as they are all in use. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss
Hi Laurent, Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 13/10/17 17:58, Laurent Pinchart wrote: > Hello, > > This patch series merges the omapdrm and omapdss drivers into a single driver > called omapdrm. The split in two drivers was historical, in order to support > the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports DRM/KMS only > there's no need to keep two seperate drivers. > > The series starts with a few cleanups (01/48 to 03/48) and quickly proceeds to > merging the omapdss and omapdss-base modules (04/48). It then prepares the > omapdss code (05/48 to 08/48), perform a few more cleanups (09/48 to 11/48) > and prepares the omapdrm code (12/48). > > Patches 13/48 to 19/48 prepare the connector, encoder and panel drivers. All > those drivers defer probing when their video source can't be found at probe > time. This would cause endless probe deferral when merging omapdrm and omapdss > as the drivers need omapdss to be fully initialized to probe successfully, but > cause omapdrm to defer probing when they're not available. > > Patch 20/48 merges the omapdrm and omapdss drivers. > > The next patches are added bonuses that start removal of global variables from > the driver. The code relies heavily on global variables for objects that are > instance-specific, and should thus be dynamically allocated. Most of the > patches change internal APIs to pass objects to driver functions (21/48 to > 28/48, 36/48, 39/48 to 41/38, 43/48 to 45/48) with a few miscellaneous > cleanups (29/48, 35/48, 37/48, 38/48, 42/48). Patches 30/48 to 34/48 and 46/48 > then allocate instance objects dynamically to replace global variables, and > patches 47/48 and 48/48 move global variables to existing instance objects. > > The series has been tested on a Pandaboard with the DVI and HDMI output. Here's what I get on AM5 EVM: # ./s-drm-new [ 17.535638] sysrq: SysRq : Changing Loglevel [ 17.540179] sysrq: Loglevel set to 9 insmod nfs/work/linux/sound/soc/omap/snd-soc-omap-hdmi-audio.ko insmod nfs/work/linux/drivers/media/cec/cec.ko insmod nfs/work/linux/drivers/video/fbdev/core/cfbcopyarea.ko insmod nfs/work/linux/drivers/video/fbdev/core/cfbimgblt.ko insmod nfs/work/linux/drivers/video/fbdev/core/cfbfillrect.ko insmod nfs/work/linux/drivers/gpu/drm/drm.ko insmod nfs/work/linux/drivers/gpu/drm/drm_kms_helper.ko insmod nfs/work/linux/drivers/gpu/drm/omapdrm/omapdrm.ko [ 17.966444] dmm 4e00.dmm: initialized all PAT entries [ 18.004857] DSS: OMAP DSS rev 6.1 [ 18.010743] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 18.025076] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-dai <-> 5804.encoder mapping ok [ 18.050076] omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops [omapdrm]) [ 18.074540] omapdss_dss 5800.dss: master bind failed: -517 [ 18.083499] DSS: OMAP DSS rev 6.1 [ 18.088284] alloc_contig_range: [fd874, fd875) PFNs busy [ 18.095583] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) # [ 18.113296] alloc_contig_range: [fd8c0, fd8e0) PFNs busy [ 18.119651] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-dai <-> 5804.encoder mapping ok [ 18.134440] omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops [omapdrm]) [ 18.154449] omapdss_dss 5800.dss: master bind failed: -517 [ 18.163344] DSS: OMAP DSS rev 6.1 [ 18.167982] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 18.179600] alloc_contig_range: [fd8c0, fd8e0) PFNs busy [ 18.185013] alloc_contig_range: [fd8e0, fd900) PFNs busy [ 18.190805] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-dai <-> 5804.encoder mapping ok [ 18.203003] omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops [omapdrm]) [ 18.219239] omapdss_dss 5800.dss: master bind failed: -517 [ 18.228977] DSS: OMAP DSS rev 6.1 [ 18.232446] alloc_contig_range: [fd874, fd875) PFNs busy [ 18.238816] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 18.250433] alloc_contig_range: [fd8c0, fd8e0) PFNs busy [ 18.255847] alloc_contig_range: [fd8e0, fd900) PFNs busy [ 18.261406] alloc_contig_range: [fd9a0, fd9c0) PFNs busy [ 18.267156] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-dai <-> 5804.encoder mapping ok [ 18.279429] omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops [omapdrm]) [ 18.297217] omapdss_dss 5800.dss: master bind failed: -517 [ 18.305306] DSS: OMAP DSS rev 6.1 [ 18.309734] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 18.321303] alloc_contig_range: [fd8c0, fd8e0) PFNs busy [ 18.326830] alloc_contig_range: [fd8e0, fd900) PFNs busy [ 18.332468] omap-hdmi-audio omap-hdmi-audio.2.auto:
Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss
Hi Sebastian, On Wednesday, 18 October 2017 01:29:56 EEST Sebastian Reichel wrote: > On Fri, Oct 13, 2017 at 05:58:56PM +0300, Laurent Pinchart wrote: > > This patch series merges the omapdrm and omapdss drivers into a single > > driver called omapdrm. The split in two drivers was historical, in order > > to support the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports > > DRM/KMS only there's no need to keep two seperate drivers. > > > > The series starts with a few cleanups (01/48 to 03/48) and quickly > > proceeds to merging the omapdss and omapdss-base modules (04/48). It then > > prepares the omapdss code (05/48 to 08/48), perform a few more cleanups > > (09/48 to 11/48) and prepares the omapdrm code (12/48). > > > > Patches 13/48 to 19/48 prepare the connector, encoder and panel drivers. > > All those drivers defer probing when their video source can't be found at > > probe time. This would cause endless probe deferral when merging omapdrm > > and omapdss as the drivers need omapdss to be fully initialized to probe > > successfully, but cause omapdrm to defer probing when they're not > > available. > > > > Patch 20/48 merges the omapdrm and omapdss drivers. > > > > The next patches are added bonuses that start removal of global variables > > from the driver. The code relies heavily on global variables for objects > > that are instance-specific, and should thus be dynamically allocated. > > Most of the patches change internal APIs to pass objects to driver > > functions (21/48 to 28/48, 36/48, 39/48 to 41/38, 43/48 to 45/48) with a > > few miscellaneous cleanups (29/48, 35/48, 37/48, 38/48, 42/48). Patches > > 30/48 to 34/48 and 46/48 then allocate instance objects dynamically to > > replace global variables, and patches 47/48 and 48/48 move global > > variables to existing instance objects. > > > > The series has been tested on a Pandaboard with the DVI and HDMI output. > > Nice cleanup! :) And great review ! :-) Thank you. There will be more coming, probably another cleanup round before I start moving the encoder, connector and panel drivers to drm_bridge and drm_panel. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss
Hi Laurent, On Fri, Oct 13, 2017 at 05:58:56PM +0300, Laurent Pinchart wrote: > This patch series merges the omapdrm and omapdss drivers into a single driver > called omapdrm. The split in two drivers was historical, in order to support > the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports DRM/KMS only > there's no need to keep two seperate drivers. > > The series starts with a few cleanups (01/48 to 03/48) and quickly proceeds to > merging the omapdss and omapdss-base modules (04/48). It then prepares the > omapdss code (05/48 to 08/48), perform a few more cleanups (09/48 to 11/48) > and prepares the omapdrm code (12/48). > > Patches 13/48 to 19/48 prepare the connector, encoder and panel drivers. All > those drivers defer probing when their video source can't be found at probe > time. This would cause endless probe deferral when merging omapdrm and omapdss > as the drivers need omapdss to be fully initialized to probe successfully, but > cause omapdrm to defer probing when they're not available. > > Patch 20/48 merges the omapdrm and omapdss drivers. > > The next patches are added bonuses that start removal of global variables from > the driver. The code relies heavily on global variables for objects that are > instance-specific, and should thus be dynamically allocated. Most of the > patches change internal APIs to pass objects to driver functions (21/48 to > 28/48, 36/48, 39/48 to 41/38, 43/48 to 45/48) with a few miscellaneous > cleanups (29/48, 35/48, 37/48, 38/48, 42/48). Patches 30/48 to 34/48 and 46/48 > then allocate instance objects dynamically to replace global variables, and > patches 47/48 and 48/48 move global variables to existing instance objects. > > The series has been tested on a Pandaboard with the DVI and HDMI output. Nice cleanup! :) -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/48] omapdrm: Merge omapdrm and omapdss
Hello, This patch series merges the omapdrm and omapdss drivers into a single driver called omapdrm. The split in two drivers was historical, in order to support the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports DRM/KMS only there's no need to keep two seperate drivers. The series starts with a few cleanups (01/48 to 03/48) and quickly proceeds to merging the omapdss and omapdss-base modules (04/48). It then prepares the omapdss code (05/48 to 08/48), perform a few more cleanups (09/48 to 11/48) and prepares the omapdrm code (12/48). Patches 13/48 to 19/48 prepare the connector, encoder and panel drivers. All those drivers defer probing when their video source can't be found at probe time. This would cause endless probe deferral when merging omapdrm and omapdss as the drivers need omapdss to be fully initialized to probe successfully, but cause omapdrm to defer probing when they're not available. Patch 20/48 merges the omapdrm and omapdss drivers. The next patches are added bonuses that start removal of global variables from the driver. The code relies heavily on global variables for objects that are instance-specific, and should thus be dynamically allocated. Most of the patches change internal APIs to pass objects to driver functions (21/48 to 28/48, 36/48, 39/48 to 41/38, 43/48 to 45/48) with a few miscellaneous cleanups (29/48, 35/48, 37/48, 38/48, 42/48). Patches 30/48 to 34/48 and 46/48 then allocate instance objects dynamically to replace global variables, and patches 47/48 and 48/48 move global variables to existing instance objects. The series has been tested on a Pandaboard with the DVI and HDMI output. Laurent Pinchart (48): drm: omapdrm: dpi: Don't treat GPIO probe deferral as an error drm: omapdrm: Pass drm_device to omap_gem_resume() drm: omapdrm: Remove unused omap_dss_find_device() function drm: omapdrm: Merge the omapdss and omapdss-base modules drm: omapdrm: dss: Set the DMA coherent mask drm: omapdrm: dss: Make dss_dump_clocks() function static drm: omapdrm: dpi: Remove dpi_data port_initialized field drm: omapdrm: venc: Return error code on OF parsing failure drm: omapdrm: Deconstruct the omap_drv.h header. drm: omapdrm: Use kernel integer types drm: omapdrm: Use unsigned int type drm: omapdrm: Split init and cleanup from probe and remove functions drm: omapdrm: connector-analog-tv: Remove tvc_of_match forward declaration drm: omapdrm: displays: Remove OF node check in connector drivers drm: omapdrm: displays: Remove OF node check in encoder drivers drm: omapdrm: displays: Remove OF node check in panel drivers drm: omapdrm: displays: Get connector source at connect time drm: omapdrm: displays: Get panel source at connect time drm: omapdrm: displays: Get encoder source at connect time drm: omapdrm: Merge the omapdrm and omapdss drivers drm: omapdrm: dss: Support passing private data to debugfs show handlers drm: omapdrm: dss: Pass DSS private structure to runtime PM functions drm: omapdrm: dss: Pass PLL pointer to dss_ctrl_pll_enable() drm: omapdrm: sdi: Pass DSS pointer to dss_sdi_*() functions drm: omapdrm: dss: Pass DSS pointer to dss_ops operations drm: omapdrm: dss: Pass DSS pointer to dss_get_*_clk_source() drm: omapdrm: dss: Pass DSS pointer to dss clock functions drm: omapdrm: dss: Pass DSS pointer to remaining dss functions drm: omapdrm: dss: Remove dss_get_hdmi_venc_clk_source() function drm: omapdrm: dss: Allocate the DSS private data structure dynamically drm: omapdrm: hdmi4: Allocate the omap_hdmi data structure dynamically drm: omapdrm: hdmi5: Allocate the omap_hdmi data structure dynamically drm: omapdrm: venc: Allocate the venc private data structure dynamically drm: omapdrm: sdi: Allocate the sdi private data structure dynamically drm: omapdrm: dsi: Make wait_for_bit_change() return a status drm: omapdrm: dsi: Pass the dsi_data pointer to internal functions drm: omapdrm: dsi: Combine two commonly used inline functions drm: omapdrm: dsi: Use dev pointer directly in dsi_bind() function drm: omapdrm: dsi: Store the struct device pointer in struct dsi_data drm: omapdrm: dsi: Don't pass channel to dispc init/uninit functions drm: omapdrm: dss: Pass omap_dss_device pointer to dss_mgr_*() functions drm: omapdrm: dss: Remove unused functions prototypes drm: omapdrm: dss: Pass omap_drm_private pointer to dss_mgr_ops drm: omapdrm: dispc: Pass DISPC pointer to dispc_ops operations drm: omapdrm: dispc: Pass DISPC pointer to remaining dispc API functions drm: omapdrm: dispc: Allocate the dispc private data structure dynamically drm: omapdrm: dss: Store the debugfs root directory in struct dss_device drm: omapdrm: dss: Store the registered plls array in struct dss_device drivers/gpu/drm/omapdrm/Kconfig|5 +- drivers/gpu/drm/omapdrm/Makefile | 25 +
