Re: [Sm5xx-devel] SM501 framebuffer driver

[Paul Mundt <lethal@linux-sh.org>]

On Fri, Oct 13, 2006 at 05:12:04PM +0400, Andrey Volkov wrote:
> Paul Mundt wrote:
> > There's at least half a dozen of these floating around, with some
> > disagreement on the actual implementation. We had one in the old SH tree
> > that specifically registered a different framebuffer device for each
> > plane, which we had some code in DirectFB and mplayer for making use of
> > for overlays and so on.
> IMHO, its very awkward implementation for real world application,
> especially since, as ex, alpha/video planes is coupled with panel plane
> but not with CRT plane. We currently try use sm501 as two fb (crt/panel)
> devices.
> 
Awkward as it may be, there are plenty of users going with this
approach, and DirectFB has been using it for quite some time. If you
don't care for this approach, do you have a better idea for exposing
individual planes to userspace and fine-grained overlay control?
Multiple device nodes are a lot more pleasant to look at than an ioctl
abortion.

> PCI and MMIO modes of SM501 is mutually exclusive, so it should be
> selected at configure time (as I already does, check my implementation
> in svn).
> 
The driver still requires visibility of these two things. Looking at the
fb driver, it's clear you have no transparent means for gauging the
aperture size. With PCI this comes down to sizing the membar, and in the
platform case it can be statically defined at registration time too.

This will never work on a system where you have a platform bus SM501
with an SM501 on a PCI add-in board, you simply can not gaurantee that
they are exclusive.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642