The old omapfb support

The old omapfb support

[Tomi Valkeinen]

Hi Tony, All,

Due to the recent SRAM discussion I started removing SRAM support from
the new omapdss and omapfb driver, which was quite a simple task. Then I
realized that the old omapfb driver also contains SRAM code, removing of
which which wasn't such a simple task. I think I got that solved, but it
needs still cleaning up.

But this again reminded me of the mess of having two display drivers,
the old omapfb and the new DSS2. Many of the OMAP2 boards using the old
driver should be quite easy to port to DSS2, with the exception of N800.
DSS2 doesn't support OMAP1, so there's not much that can be done with
those boards currently.

What is the status of OMAP1 support in general? Is having a working
framebuffer for OMAP1 boards something we need? 

Will there be a single kernel config containing OMAP1 and OMAP2+ support
in the future? This will cause problems, as the old and new display
drivers cannot coexist currently.

I have never worked with an OMAP1 board, and I don't own one, and thus I
don't have any experience on OMAP1 display HW. This will make any work I
do on OMAP1 omapfb slightly difficult, but if there's clear need for
OMAP1 fb, then I think the only way to go is to convert the old omapfb
driver to an OMAP1 framebuffer driver.

But whatever is decided on OMAP1 fb, I'll start converting the OMAP2
drivers to the new DSS2.

 Tomi

Re: The old omapfb support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [110419 15:17]:
> Hi Tony, All,
> 
> Due to the recent SRAM discussion I started removing SRAM support from
> the new omapdss and omapfb driver, which was quite a simple task. Then I
> realized that the old omapfb driver also contains SRAM code, removing of
> which which wasn't such a simple task. I think I got that solved, but it
> needs still cleaning up.

OK
 
> But this again reminded me of the mess of having two display drivers,
> the old omapfb and the new DSS2. Many of the OMAP2 boards using the old
> driver should be quite easy to port to DSS2, with the exception of N800.
> DSS2 doesn't support OMAP1, so there's not much that can be done with
> those boards currently.
> 
> What is the status of OMAP1 support in general? Is having a working
> framebuffer for OMAP1 boards something we need? 

There are people actively using omap1 boards with the framebuffer, so
let's not mess with that except to remove the SRAM support.
 
> Will there be a single kernel config containing OMAP1 and OMAP2+ support
> in the future? This will cause problems, as the old and new display
> drivers cannot coexist currently.

This will not happen any time soon (if ever) because of issues supporting
anything below ARMv6 together with ARMv6 and 7 in the same kernel binary.
 
> I have never worked with an OMAP1 board, and I don't own one, and thus I
> don't have any experience on OMAP1 display HW. This will make any work I
> do on OMAP1 omapfb slightly difficult, but if there's clear need for
> OMAP1 fb, then I think the only way to go is to convert the old omapfb
> driver to an OMAP1 framebuffer driver.

Yeh we can just make old omapfb depends on ARCH_OMAP1.
 
> But whatever is decided on OMAP1 fb, I'll start converting the OMAP2
> drivers to the new DSS2.

OK great.

Tony

Re: The old omapfb support

[Michael Büsch]

On Tue, 2011-04-19 at 15:30 +0300, Tony Lindgren wrote: 
> > But this again reminded me of the mess of having two display drivers,
> > the old omapfb and the new DSS2. Many of the OMAP2 boards using the old
> > driver should be quite easy to port to DSS2, with the exception of N800.
> > DSS2 doesn't support OMAP1, so there's not much that can be done with
> > those boards currently.

> Yeh we can just make old omapfb depends on ARCH_OMAP1.

As he said, the old omapfb code is used on n8x0, which is OMAP2.

-- 
Greetings Michael.

Re: The old omapfb support

[Tomi Valkeinen]

On Tue, 2011-04-19 at 14:34 +0200, Michael Büsch wrote:
> On Tue, 2011-04-19 at 15:30 +0300, Tony Lindgren wrote: 
> > > But this again reminded me of the mess of having two display drivers,
> > > the old omapfb and the new DSS2. Many of the OMAP2 boards using the old
> > > driver should be quite easy to port to DSS2, with the exception of N800.
> > > DSS2 doesn't support OMAP1, so there's not much that can be done with
> > > those boards currently.
> 
> > Yeh we can just make old omapfb depends on ARCH_OMAP1.
> 
> As he said, the old omapfb code is used on n8x0, which is OMAP2.

But as I also said, the old OMAP2 panel drivers can be ported to the new
DSS driver. I just mentioned N800 because the panel driver for N800 is
rather difficult to port and will require more work than the other OMAP2
panel drivers.

 Tomi


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

Re: The old omapfb support

[Michael Büsch]

On Tue, 2011-04-19 at 15:41 +0300, Tomi Valkeinen wrote: 
> On Tue, 2011-04-19 at 14:34 +0200, Michael Büsch wrote:
> > On Tue, 2011-04-19 at 15:30 +0300, Tony Lindgren wrote: 
> > > > But this again reminded me of the mess of having two display drivers,
> > > > the old omapfb and the new DSS2. Many of the OMAP2 boards using the old
> > > > driver should be quite easy to port to DSS2, with the exception of N800.
> > > > DSS2 doesn't support OMAP1, so there's not much that can be done with
> > > > those boards currently.
> > 
> > > Yeh we can just make old omapfb depends on ARCH_OMAP1.
> > 
> > As he said, the old omapfb code is used on n8x0, which is OMAP2.
> 
> But as I also said, the old OMAP2 panel drivers can be ported to the new
> DSS driver. I just mentioned N800 because the panel driver for N800 is
> rather difficult to port and will require more work than the other OMAP2
> panel drivers.

So if you first port the stuff and then add the depends-on OMAP1, I'm
fine with it.

-- 
Greetings Michael.

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

Re: The old omapfb support

[Tomi Valkeinen]

On Tue, 2011-04-19 at 14:45 +0200, Michael Büsch wrote:
> On Tue, 2011-04-19 at 15:41 +0300, Tomi Valkeinen wrote: 
> > On Tue, 2011-04-19 at 14:34 +0200, Michael Büsch wrote:
> > > On Tue, 2011-04-19 at 15:30 +0300, Tony Lindgren wrote: 
> > > > > But this again reminded me of the mess of having two display drivers,
> > > > > the old omapfb and the new DSS2. Many of the OMAP2 boards using the old
> > > > > driver should be quite easy to port to DSS2, with the exception of N800.
> > > > > DSS2 doesn't support OMAP1, so there's not much that can be done with
> > > > > those boards currently.
> > > 
> > > > Yeh we can just make old omapfb depends on ARCH_OMAP1.
> > > 
> > > As he said, the old omapfb code is used on n8x0, which is OMAP2.
> > 
> > But as I also said, the old OMAP2 panel drivers can be ported to the new
> > DSS driver. I just mentioned N800 because the panel driver for N800 is
> > rather difficult to port and will require more work than the other OMAP2
> > panel drivers.
> 
> So if you first port the stuff and then add the depends-on OMAP1, I'm
> fine with it.

Does the display even work on N8x0 with mainline kernel? I don't see any
code for it in the board file.

 Tomi



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

Re: The old omapfb support

[Michael Büsch]

On Wed, 2011-04-20 at 11:06 +0300, Tomi Valkeinen wrote: 
> > So if you first port the stuff and then add the depends-on OMAP1, I'm
> > fine with it.
> 
> Does the display even work on N8x0 with mainline kernel? I don't see any
> code for it in the board file.

It needs some additional glue code, which can be found here:
https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.38/301-nokia-board-additional.patch
But with that code it works fine.

-- 
Greetings Michael.

Re: The old omapfb support

[Tomi Valkeinen]

On Wed, 2011-04-20 at 13:18 +0200, Michael Büsch wrote:
> On Wed, 2011-04-20 at 11:06 +0300, Tomi Valkeinen wrote: 
> > > So if you first port the stuff and then add the depends-on OMAP1, I'm
> > > fine with it.
> > 
> > Does the display even work on N8x0 with mainline kernel? I don't see any
> > code for it in the board file.
> 
> It needs some additional glue code, which can be found here:
> https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.38/301-nokia-board-additional.patch
> But with that code it works fine.

Ok, thanks. I found an N810 from my HW stash, but as I don't have a
serial adapter for it, kernel work will be rather difficult. I'll port
the display driver, but I'm probably not able to test it at all.

 Tomi


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

Re: The old omapfb support

[Michael Büsch]

On Wed, 2011-04-20 at 14:31 +0300, Tomi Valkeinen wrote: 
> On Wed, 2011-04-20 at 13:18 +0200, Michael Büsch wrote:
> > On Wed, 2011-04-20 at 11:06 +0300, Tomi Valkeinen wrote: 
> > > > So if you first port the stuff and then add the depends-on OMAP1, I'm
> > > > fine with it.
> > > 
> > > Does the display even work on N8x0 with mainline kernel? I don't see any
> > > code for it in the board file.
> > 
> > It needs some additional glue code, which can be found here:
> > https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.38/301-nokia-board-additional.patch
> > But with that code it works fine.
> 
> Ok, thanks. I found an N810 from my HW stash, but as I don't have a
> serial adapter for it, kernel work will be rather difficult. I'll port
> the display driver, but I'm probably not able to test it at all.

Ok thanks. I'll test it. I have access to the serial console.

Also see the other patches in that SVN directory. If all those
patches are applied, it does boot on 2.6.38. I'm not sure which
ones are really required to make it boot. So you should probably first
try to boot with the old driver to check if your setup works.

-- 
Greetings Michael.

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

N8x0 display support (was: Re: The old omapfb support)

[Tomi Valkeinen]

On Tue, 2011-04-19 at 14:45 +0200, Michael Büsch wrote:
> On Tue, 2011-04-19 at 15:41 +0300, Tomi Valkeinen wrote: 
> > On Tue, 2011-04-19 at 14:34 +0200, Michael Büsch wrote:
> > > On Tue, 2011-04-19 at 15:30 +0300, Tony Lindgren wrote: 
> > > > > But this again reminded me of the mess of having two display drivers,
> > > > > the old omapfb and the new DSS2. Many of the OMAP2 boards using the old
> > > > > driver should be quite easy to port to DSS2, with the exception of N800.
> > > > > DSS2 doesn't support OMAP1, so there's not much that can be done with
> > > > > those boards currently.
> > > 
> > > > Yeh we can just make old omapfb depends on ARCH_OMAP1.
> > > 
> > > As he said, the old omapfb code is used on n8x0, which is OMAP2.
> > 
> > But as I also said, the old OMAP2 panel drivers can be ported to the new
> > DSS driver. I just mentioned N800 because the panel driver for N800 is
> > rather difficult to port and will require more work than the other OMAP2
> > panel drivers.
> 
> So if you first port the stuff and then add the depends-on OMAP1, I'm
> fine with it.

I've now got a beta version of N800 display support for DSS2 ready, and
I can get a picture on the screen.

However, it's quite difficult to port all of the blizzard.c code, as the
new DSS2 doesn't support some of the weird things there. Also, I don't
have N800 schematics and Blizzard documentation, so properly porting
everything needs reverse engineering the code.

There is some PLL code in the blizzard.c, purpose of which I don't
understand. The new driver seems to work fine without the PLL code.

Then blizzard seems to support YUV420 mode, and currently there's no
support for controller specific modes in the DSS2, so I've left that
out.

Blizzard driver also contains auto-update code, which adds a
considerable amount of code to it. I don't want to add that code to the
new driver, because my opinion is that manual update displays should be
used like manual update displays. N800's user space should handle it
properly, as far as I know, but it is not possible to use the
framebuffer console with only manual update mode.

I experimented a bit with FB framework's deferred IO support, which
indeed allows us to use fb console quite easily. However, a proper
support for deferred IO would need more code and careful thinking how to
do it.

So, my question is: what are the uses of N800's display with the
mainline kernel? Are we happy with just having basic display
functionality, or do people need all the features in the older blizzard
driver? If latter, I wonder if there's somebody who wants to develop
this further?

If somebody wants to give it a try/look, my N800 development (based
on .39-rc3) branch can be found from:

git://gitorious.org/linux-omap-dss2/linux.git n800

I'll of course send proper patches when thing are more finalized.

 Tomi


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

Re: N8x0 display support (was: Re: The old omapfb support)

[Jarkko Nikula]

On Fri, 29 Apr 2011 16:33:39 +0300
Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:

> However, it's quite difficult to port all of the blizzard.c code, as the
> new DSS2 doesn't support some of the weird things there. Also, I don't
> have N800 schematics and Blizzard documentation, so properly porting
> everything needs reverse engineering the code.
> 
http://www.nmacleod.com/nokia/schematics/

-- 
Jarkko

Re: N8x0 display support (was: Re: The old omapfb support)

[Michael Büsch]

On Fri, 2011-04-29 at 16:33 +0300, Tomi Valkeinen wrote: 
> So, my question is: what are the uses of N800's display with the
> mainline kernel? Are we happy with just having basic display
> functionality, or do people need all the features in the older blizzard
> driver?

Well, not sure.
The OpenWRT project runs an X server on the n810.
It does so by using the X.org "omapfb" driver module, which
accesses the hardware through /dev/fb0.
http://git.pingu.fi/xf86-video-omapfb/

So we basically need that to work in one way or another.
Another thing that we require is turning off the display for
power saving reasons. We currently do this through
FBIOBLANK ioctl with parameters FB_BLANK_POWERDOWN/FB_BLANK_UNBLANK.
(The backlight is turned off by other means with the device asic)

-- 
Greetings Michael.

Re: N8x0 display support (was: Re: The old omapfb support)

[Michael Büsch]

On Fri, 2011-04-29 at 23:04 +0200, Michael Büsch wrote: 
> On Fri, 2011-04-29 at 16:33 +0300, Tomi Valkeinen wrote: 
> > So, my question is: what are the uses of N800's display with the
> > mainline kernel? Are we happy with just having basic display
> > functionality, or do people need all the features in the older blizzard
> > driver?
> 
> Well, not sure.
> The OpenWRT project runs an X server on the n810.
> It does so by using the X.org "omapfb" driver module, which
> accesses the hardware through /dev/fb0.
> http://git.pingu.fi/xf86-video-omapfb/
> 
> So we basically need that to work in one way or another.
> Another thing that we require is turning off the display for
> power saving reasons. We currently do this through
> FBIOBLANK ioctl with parameters FB_BLANK_POWERDOWN/FB_BLANK_UNBLANK.
> (The backlight is turned off by other means with the device asic)

Oh and we currently run the framebuffer in auto-update mode.
I don't have any idea what would be needed to get it working
in manual update mode.

-- 
Greetings Michael.

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

Re: N8x0 display support (was: Re: The old omapfb support)

[Tomi Valkeinen]

On Fri, 2011-04-29 at 23:04 +0200, Michael Büsch wrote:
> On Fri, 2011-04-29 at 16:33 +0300, Tomi Valkeinen wrote: 
> > So, my question is: what are the uses of N800's display with the
> > mainline kernel? Are we happy with just having basic display
> > functionality, or do people need all the features in the older blizzard
> > driver?
> 
> Well, not sure.
> The OpenWRT project runs an X server on the n810.
> It does so by using the X.org "omapfb" driver module, which
> accesses the hardware through /dev/fb0.
> http://git.pingu.fi/xf86-video-omapfb/

A quick grep shows that there's some manual update support in that tree.
However, all the OMAPFB_UPDATE_WINDOW calls are in omapfb-xv-blizzard.c,
and to me it looks like manual-update is used when Xv is being used, and
auto-update otherwise. So that probably needs some work, either in the
driver or in X.

Perhaps I'll see if I can add deferred IO support to omapfb driver,
which would be turned on when a manual-update display is set to
auto-update mode. That's not exactly the same as auto update, but I
guess it should work for almost all the cases.

While I don't like having auto-update for manual-update displays, I
guess it's still good to have for testing and prototyping purposes.

> So we basically need that to work in one way or another.
> Another thing that we require is turning off the display for
> power saving reasons. We currently do this through
> FBIOBLANK ioctl with parameters FB_BLANK_POWERDOWN/FB_BLANK_UNBLANK.
> (The backlight is turned off by other means with the device asic)

Blanking works with FBIOBLANK. It also turns off the backlight. The
backlight brightness can be controlled
via /sys/class/backlight/display0/

 Tomi


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