Re: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
On Thu, 2010-01-07 at 12:05 +0100, Tomi Valkeinen wrote: > On Thu, 2009-12-17 at 15:51 +0100, ext Sergey Lapin wrote: > > On Wed, Dec 16, 2009 at 2:21 PM, Tomi Valkeinen > > wrote: > > > Hi, > > > > > > On Tue, 2009-12-15 at 17:01 +0100, ext Sergey Lapin wrote: > > >> On Tue, Dec 15, 2009 at 6:22 PM, Tomi Valkeinen > > >> wrote: > > >> > 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 > > >> >> Acked-by: Tony Lindgren > > >> >> > > >> >> 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. > > > > > > rfbi.c was still using omapfb device to get the clocks. Can you try this > > > patch? > > > > > > > > > >From 33b78006fb0387e21d5f780338d821621ecad929 Mon Sep 17 00:00:00 2001 > > > From: Tomi Valkeinen > > > Date: Wed, 16 Dec 2009 13:18:07 +0200 > > > Subject: [PATCH] OMAP: OMAPFB: fix clk_get for RFBI > > > > > > omapfb platform device was still used to get clocks inside rfbi.c > > If you add #include to this patch, > > then problem is fixed. > > Hmm, where do you need to add that include? n770 compiles ok for me. > > I pushed this patch and another patch fixing the warning to master > branch in my tree: > http://gitorious.org/linux-omap-dss2/linux > > Can you try them out? The commits are > 3a2cbca3a3703ecd77c6fe633543ea0926b95564 and > c47f085ecf6d024c8850177694c702d814563580 Sorry, I was too hasty. The release function should return void, not int. The new patches are 3a2cbca3a3703ecd77c6fe633543ea0926b95564 and ed18458714274525545349a2c35cf32f4a17f166 Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
On Tue, 2010-01-05 at 18:32 +0100, ext Paul Walmsley wrote: > Hi Tomi, > > On Tue, 15 Dec 2009, Tomi Valkeinen wrote: > > > 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 > > > Acked-by: Tony Lindgren > > > > > > 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. > > This also affects omap_2430sdp_defconfig on 2430SDP: I pushed patches fixing thisto master branch in my tree: http://gitorious.org/linux-omap-dss2/linux Can you try them out on 2320sdp? The commits are 3a2cbca3a3703ecd77c6fe633543ea0926b95564 and c47f085ecf6d024c8850177694c702d814563580 Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
On Thu, 2009-12-17 at 15:51 +0100, ext Sergey Lapin wrote: > On Wed, Dec 16, 2009 at 2:21 PM, Tomi Valkeinen > wrote: > > Hi, > > > > On Tue, 2009-12-15 at 17:01 +0100, ext Sergey Lapin wrote: > >> On Tue, Dec 15, 2009 at 6:22 PM, Tomi Valkeinen > >> wrote: > >> > 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 > >> >> Acked-by: Tony Lindgren > >> >> > >> >> 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. > > > > rfbi.c was still using omapfb device to get the clocks. Can you try this > > patch? > > > > > > >From 33b78006fb0387e21d5f780338d821621ecad929 Mon Sep 17 00:00:00 2001 > > From: Tomi Valkeinen > > Date: Wed, 16 Dec 2009 13:18:07 +0200 > > Subject: [PATCH] OMAP: OMAPFB: fix clk_get for RFBI > > > > omapfb platform device was still used to get clocks inside rfbi.c > If you add #include to this patch, > then problem is fixed. Hmm, where do you need to add that include? n770 compiles ok for me. I pushed this patch and another patch fixing the warning to master branch in my tree: http://gitorious.org/linux-omap-dss2/linux Can you try them out? The commits are 3a2cbca3a3703ecd77c6fe633543ea0926b95564 and c47f085ecf6d024c8850177694c702d814563580 Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
Hi Tomi, On Tue, 15 Dec 2009, Tomi Valkeinen wrote: > 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 > > Acked-by: Tony Lindgren > > > > 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. This also affects omap_2430sdp_defconfig on 2430SDP: omapfb omapfb: timeout waiting for FRAME DONE [ cut here ] WARNING: at drivers/base/core.c:131 device_release+0x68/0x7c() Device 'omapdss' does not have a release() function, it is broken and must be fixed. Modules linked in: [] (unwind_backtrace+0x0/0xdc) from [] (warn_slowpath_common+0x48/0x60) [] (warn_slowpath_common+0x48/0x60) from [] (warn_slowpath_fmt+0x24/0x30) [] (warn_slowpath_fmt+0x24/0x30) from [] (device_release+0x68/0x7c) [] (device_release+0x68/0x7c) from [] (kobject_release+0x60/0x74) [] (kobject_release+0x60/0x74) from [] (kref_put+0x5c/0x6c) [] (kref_put+0x5c/0x6c) from [] (omapfb_free_resources+0xec/0x130) [] (omapfb_free_resources+0xec/0x130) from [] (omapfb_do_probe+0x6dc/0x810) [] (omapfb_do_probe+0x6dc/0x810) from [] (sdp2430_panel_probe+0xc/0x18) [] (sdp2430_panel_probe+0xc/0x18) from [] (platform_drv_probe+0x18/0x1c) [] (platform_drv_probe+0x18/0x1c) from [] (driver_probe_device+0xa0/0x14c) [] (driver_probe_device+0xa0/0x14c) from [] (__driver_attach+0x60/0x84) [] (__driver_attach+0x60/0x84) from [] (bus_for_each_dev+0x44/0x74) [] (bus_for_each_dev+0x44/0x74) from [] (bus_add_driver+0x9c/0x224) [] (bus_add_driver+0x9c/0x224) from [] (driver_register+0xa8/0x130) [] (driver_register+0xa8/0x130) from [] (do_one_initcall+0x5c/0x1b4) [] (do_one_initcall+0x5c/0x1b4) from [] (kernel_init+0xa0/0x124) [] (kernel_init+0xa0/0x124) from [] (kernel_thread_exit+0x0/0x8) ---[ end trace da227214a82491b7 ]--- - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
On Wed, Dec 16, 2009 at 2:21 PM, Tomi Valkeinen wrote: > Hi, > > On Tue, 2009-12-15 at 17:01 +0100, ext Sergey Lapin wrote: >> On Tue, Dec 15, 2009 at 6:22 PM, Tomi Valkeinen >> wrote: >> > 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 >> >> Acked-by: Tony Lindgren >> >> >> >> 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. > > rfbi.c was still using omapfb device to get the clocks. Can you try this > patch? > > > >From 33b78006fb0387e21d5f780338d821621ecad929 Mon Sep 17 00:00:00 2001 > From: Tomi Valkeinen > Date: Wed, 16 Dec 2009 13:18:07 +0200 > Subject: [PATCH] OMAP: OMAPFB: fix clk_get for RFBI > > omapfb platform device was still used to get clocks inside rfbi.c If you add #include to this patch, then problem is fixed. > > Signed-off-by: Tomi Valkeinen Tested-by: Sergey Lapin > --- > drivers/video/omap/dispc.c |2 +- > drivers/video/omap/omapfb.h |2 ++ > drivers/video/omap/rfbi.c |4 ++-- > 3 files changed, 5 insertions(+), 3 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
Hi,
On Tue, 2009-12-15 at 17:01 +0100, ext Sergey Lapin wrote:
> On Tue, Dec 15, 2009 at 6:22 PM, Tomi Valkeinen
> wrote:
> > 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
> >> Acked-by: Tony Lindgren
> >>
> >> 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.
rfbi.c was still using omapfb device to get the clocks. Can you try this
patch?
>From 33b78006fb0387e21d5f780338d821621ecad929 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen
Date: Wed, 16 Dec 2009 13:18:07 +0200
Subject: [PATCH] OMAP: OMAPFB: fix clk_get for RFBI
omapfb platform device was still used to get clocks inside rfbi.c
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap/dispc.c |2 +-
drivers/video/omap/omapfb.h |2 ++
drivers/video/omap/rfbi.c |4 ++--
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index c7c6455..e40146a 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -189,7 +189,7 @@ static struct {
struct omapfb_color_key color_key;
} dispc;
-static struct platform_device omapdss_device = {
+struct platform_device omapdss_device = {
.name = "omapdss",
.id = -1,
};
diff --git a/drivers/video/omap/omapfb.h b/drivers/video/omap/omapfb.h
index 46e4714..0a4988e 100644
--- a/drivers/video/omap/omapfb.h
+++ b/drivers/video/omap/omapfb.h
@@ -224,4 +224,6 @@ extern int omapfb_update_window_async(struct fb_info *fbi,
void (*callback)(void *),
void *callback_data);
+extern struct platform_device omapdss_device;
+
#endif /* __OMAPFB_H */
diff --git a/drivers/video/omap/rfbi.c b/drivers/video/omap/rfbi.c
index fed7b1b..36af8ba 100644
--- a/drivers/video/omap/rfbi.c
+++ b/drivers/video/omap/rfbi.c
@@ -83,13 +83,13 @@ static inline u32 rfbi_read_reg(int idx)
static int rfbi_get_clocks(void)
{
- rfbi.dss_ick = clk_get(rfbi.fbdev->dev, "ick");
+ rfbi.dss_ick = clk_get(&omapdss_device.dev, "ick");
if (IS_ERR(rfbi.dss_ick)) {
dev_err(rfbi.fbdev->dev, "can't get ick\n");
return PTR_ERR(rfbi.dss_ick);
}
- rfbi.dss1_fck = clk_get(rfbi.fbdev->dev, "dss1_fck");
+ rfbi.dss1_fck = clk_get(&omapdss_device.dev, "dss1_fck");
if (IS_ERR(rfbi.dss1_fck)) {
dev_err(rfbi.fbdev->dev, "can't get dss1_fck\n");
clk_put(rfbi.dss_ick);
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
>> 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? Well, in tree, drivers/video/omap/hwa742.c is driver for RFBI-based display driver with hwa742 controller. I think porting Nokia 770 to DSS2 could be nice example... Actually, old RFBI driver is very limited comparing to OMAP3 features, and supports only 16bit color mode (hardcoded). I'd like to see OMAP3 features there, some of them are trivial to add, I have some patches for that, but they are simply bad approach because they are based on old driver, hardcode values, use hackish approaches. So, I'd like to see "the right way", so I could move farther with them and toss that messy junk. Thanks a lot, S. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
On Tue, Dec 15, 2009 at 6:22 PM, Tomi Valkeinen
wrote:
> 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
>> Acked-by: Tony Lindgren
>>
>> 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.
I have to patch like this to make it work without reverting:
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 8bdcc9c..2848a87 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3137,6 +3137,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK("omapdss", "dss2_fck", &dss2_alwon_fck, CK_343X),
CLK("omapdss", "ick", &dss_ick_3430es1, CK_3430ES1),
CLK("omapdss", "ick", &dss_ick_3430es2, CK_3430ES2),
+ CLK("omapfb", "dss1_fck", &dss1_alwon_fck_3430es1, CK_3430ES1),
+ CLK("omapfb", "dss1_fck", &dss1_alwon_fck_3430es2, CK_3430ES2),
+ CLK("omapfb", "tv_fck", &dss_tv_fck,CK_343X),
+ CLK("omapfb", "video_fck",&dss_96m_fck, CK_343X),
+ CLK("omapfb", "dss2_fck", &dss2_alwon_fck, CK_343X),
+ CLK("omapfb", "ick", &dss_ick_3430es1, CK_3430ES1),
+ CLK("omapfb", "ick", &dss_ick_3430es2, CK_3430ES2),
CLK(NULL, "cam_mclk", &cam_mclk, CK_343X),
CLK(NULL, "cam_ick", &cam_ick, CK_343X),
CLK(NULL, "csi2_96m_fck", &csi2_96m_fck, CK_343X),
Thanks a lot,
S.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
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 > Acked-by: Tony Lindgren > > 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] [] (unwind_backtrace+0x0/0xdc) from > [] (warn_slowpath_common+0x48/0x60) > [ 17.298583] [] (warn_slowpath_common+0x48/0x60) from > [] (warn_slowpath_fmt+0x24/0x30) > [ 17.306610] [] (warn_slowpath_fmt+0x24/0x30) from > [] (device_release+0x68/0x7c) > [ 17.314453] [] (device_release+0x68/0x7c) from > [] (kobject_release+0x5c/0x70) > [ 17.321746] [] (kobject_release+0x5c/0x70) from > [] (kref_put+0x5c/0x6c) > [ 17.328887] [] (kref_put+0x5c/0x6c) from [] > (hx8340_init+0x89c/0x8d8) > [ 17.336822] [] (hx8340_init+0x89c/0x8d8) from > [] (omapfb_do_probe+0x38c/0x970) > [ 17.345123] [] (omapfb_do_probe+0x38c/0x970) from > [] (gnome5_panel_probe+0xc/0x18) > [ 17.353515] [] (gnome5_panel_probe+0xc/0x18) from > [] (platform_drv_probe+0x18/0x1c) > [ 17.362243] [] (platform_drv_probe+0x18/0x1c) from > [] (driver_probe_device+0x100/0x1e8) > [ 17.370727] [] (driver_probe_device+0x100/0x1e8) from > [] (__driver_attach+0x60/0x84) > [ 17.378753] [] (__driver_attach+0x60/0x84) from > [] (bus_for_each_dev+0x44/0x74) > [ 17.386871] [] (bus_for_each_dev+0x44/0x74) from > [] (bus_add_driver+0x140/0x2d0) > [ 17.394989] [] (bus_add_driver+0x140/0x2d0) from > [] (driver_register+0xa8/0x130) > [ 17.403106] [] (driver_register+0xa8/0x130) from > [] (do_one_initcall+0x5c/0x1b4) > [ 17.410858] [] (do_one_initcall+0x5c/0x1b4) from > [] (kernel_init+0xa0/0x124) > [ 17.418640] [] (kernel_init+0xa0/0x124) from [] > (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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
