Re: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, 2009-12-15 at 10:58 +0100, ext Sergey Lapin wrote:
> dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98
> OMAP: OMAPFB: add omapdss device
> 
>     The upcoming new display subsystem driver is divided to two devices,
>     omapdss and omapfb, of which omapdss handles the actual hardware.
> 
>     This patch adds a dummy omapdss platform device for the current omapfb
>     driver, which is then used to get the clocks. This will make it possible
>     for the current and the new display drivers to co-exist.
> 
>     Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx>
>     Acked-by: Tony Lindgren <tony@xxxxxxxxxxx>
> 
> breaks old omapfb.

I didn't look at this further, but I quickly tested with OMAP3 SDP
board, reverting the patch that makes SDP use DSS2, and it seems to work
fine with the old omapfb.

Perhaps you have more kernel debug options enabled, and then it
complains about missing release function. I'll look at it tomorrow.

> 
> [   17.234466] Registering platform device 'omapdss'. Parent at platform
> [   17.237548] device: 'omapdss': device_add
> [   17.241180] bus: 'platform': add device omapdss
> [   17.244964] PM: Adding info for platform:omapdss
> [   17.250244] omapfb: DISPC version 3.0 initialized
> [   17.253326] omapfb omapfb: can't get ick
> [   17.257324] PM: Removing info for platform:omapdss
> [   17.261291] bus: 'platform': remove device omapdss
> [   17.265411] ------------[ cut here ]------------
> [   17.271545] WARNING: at drivers/base/core.c:131 device_release+0x68/0x7c()
> [   17.279510] Device 'omapdss' does not have a release() function, it
> is broken and must be fixed.
> [   17.281433] Modules linked in:
> [   17.290008] [<c003a9dc>] (unwind_backtrace+0x0/0xdc) from
> [<c0062330>] (warn_slowpath_common+0x48/0x60)
> [   17.298583] [<c0062330>] (warn_slowpath_common+0x48/0x60) from
> [<c0062380>] (warn_slowpath_fmt+0x24/0x30)
> [   17.306610] [<c0062380>] (warn_slowpath_fmt+0x24/0x30) from
> [<c01fcd2c>] (device_release+0x68/0x7c)
> [   17.314453] [<c01fcd2c>] (device_release+0x68/0x7c) from
> [<c01b23cc>] (kobject_release+0x5c/0x70)
> [   17.321746] [<c01b23cc>] (kobject_release+0x5c/0x70) from
> [<c01b3208>] (kref_put+0x5c/0x6c)
> [   17.328887] [<c01b3208>] (kref_put+0x5c/0x6c) from [<c01d9a78>]
> (hx8340_init+0x89c/0x8d8)
> [   17.336822] [<c01d9a78>] (hx8340_init+0x89c/0x8d8) from
> [<c01d5018>] (omapfb_do_probe+0x38c/0x970)
> [   17.345123] [<c01d5018>] (omapfb_do_probe+0x38c/0x970) from
> [<c01d9af8>] (gnome5_panel_probe+0xc/0x18)
> [   17.353515] [<c01d9af8>] (gnome5_panel_probe+0xc/0x18) from
> [<c0201014>] (platform_drv_probe+0x18/0x1c)
> [   17.362243] [<c0201014>] (platform_drv_probe+0x18/0x1c) from
> [<c01fff60>] (driver_probe_device+0x100/0x1e8)
> [   17.370727] [<c01fff60>] (driver_probe_device+0x100/0x1e8) from
> [<c02000a8>] (__driver_attach+0x60/0x84)
> [   17.378753] [<c02000a8>] (__driver_attach+0x60/0x84) from
> [<c01ff658>] (bus_for_each_dev+0x44/0x74)
> [   17.386871] [<c01ff658>] (bus_for_each_dev+0x44/0x74) from
> [<c01fef80>] (bus_add_driver+0x140/0x2d0)
> [   17.394989] [<c01fef80>] (bus_add_driver+0x140/0x2d0) from
> [<c020039c>] (driver_register+0xa8/0x130)
> [   17.403106] [<c020039c>] (driver_register+0xa8/0x130) from
> [<c0034364>] (do_one_initcall+0x5c/0x1b4)
> [   17.410858] [<c0034364>] (do_one_initcall+0x5c/0x1b4) from
> [<c0008588>] (kernel_init+0xa0/0x124)
> [   17.418640] [<c0008588>] (kernel_init+0xa0/0x124) from [<c0035f80>]
> (kernel_thread_exit+0x0/0x8)
> [   17.422363] ---[ end trace da227214a82491b7 ]---
> [   17.427520] omapfb omapfb: controller initialization failed (-2)
> [   17.433715] driver: 'gnome5_lcd': driver_bound: bound to device 'gnome5_lcd'
> [   17.440948] bus: 'platform': really_probe: bound device gnome5_lcd
> to driver gnome5_lcd
> 
> Any ideas?
> 
> Also - is there some guidelines on porting old RFBI-based driver to DSS2?

No, and currently the DSS2 RFBI support may not work. I don't have
hardware to test it, and the DSS driver has changed around it. Can
anyone confirm that the RFBI support works, and does anyone have public
RFBI drivers?

But basically RFBI drivers and DSI command mode panels (panel-taal.c for
example) should be somewhat similar. One thing to note is that the
current model doesn't support separate controller (or "buffer") chips
and panels very neatly, although it should work.

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux