View source for Talk:Drivers justification

List hardware here which is underutilised/undocumented


PowerVR

  3d rendering (hopefully onto 5mbit on omap2420 SARAM buffer

IVA

  Conversion from RGB to YUV, decoding video frames, scaling and blitting bitmaps

5mbit SRAM
  Possible use as an RGB framebuffer for powervr/flat x11 surface.
  Would require the IVA to convert and push this RGB data onto SDRAM "standard" surface for the Epson LCD to display on screen quickly.


<jott> lcuk: have you actually tried to investigate accessing the sram?
<lcuk> where is it... ?
<lcuk> this is what documentation is all about
<jott> lcuk: drivers/video/omap/dispc.c atleast reads "#define OMAP2_SRAM_START 0x40200000"

AFAIK it is already used. 5mbits is VGA resolution. It is currently used as 'video plane' i.e. some sort of overlay. omapfb driver support more (3) planes and this 640x480 video plane in SRAM is used for media playback by stock media player. [[User:fanoush|fanoush]]

fanoush, can you shed some light on how its used by the mediaplayer?  We realise its vga resolution but it would be a start.
also, what is the point in 3 planes when it can barely send 1 plane fast enough.  as a base enabler for 3d and faster graphics it would be an ideal start.  --[[User:lcuk|lcuk]] 21:24, 16 July 2008 (UTC)

the reason for more planes is simplicity and speed, each plane can be enabled/disabled separately and framebuffer update (sending data to epson chip) merges those planes and gives priority to the video one (i.e. sends data only from the topmost one) so it works like overlay on desktop (and is used in same way by Xv ?). The reason for using SRAM is speed and maybe dispc can also do some operations only in SRAM, it was briefly explained by dstone on mailing list at the time second OS2007 update came with significant video speedup. Also maybe some/same plane is used by camera for similar reasons. BTW this is maybe not best place to go into details :-) [[User:fanoush|fanoush]] 08:16, 17 July 2008 (UTC)

As for the media player, more correct is perhaps to say that that VGA plane in SRAM is used for implementing Xv support in xserver so anything using Xv should use it too. I'm not 100% sure about SRAM being really allocated and used but whole multiple plane support with possibility of different per-plane memory type (quite complicated code) was added to kernel with that OS update so it would be insane to write so much code and complicate stuff in a big way and then not to use it. I also believe (but can be wrong) I've seen the code with plane definitions in kernel but can't find it now. [[User:fanoush|fanoush]] 09:49, 17 July 2008 (UTC)

Agreed on the multi plane support, it can be used to help double/triple buffering.
As for actually making use of the SRAM I am not so sure.  The dispc.c omap display driver below does make use of it: its expected to, it is the driver for the direct omap2420 display.  however from what we can gather this is not loaded for the n8x0, we use the omapfb/blizzard chain which uses regular DDR.
If mediaplayer can allocate/use memory for its own private purposes, we should be able to as well. --[[User:lcuk|lcuk]] 10:51, 17 July 2008 (UTC)

as for double buffering - perhaps yes, planes are not equally fast and big but one could enable/disable one of them and draw into the other and force region update. As for dispc I believe it is _is_ used. It has remote mode and can send data over rfbi (not so much different than feeding LCD directly). So there are two similar ways - draw to sdram and push it to epson chip or draw to sram and let dispc to do it too. I believe this is used because dispc can do scaling on the fly too so for larger frames you can cheat and actually send less data and overcame slow rfbi interface this way (downscaling done by epson is useless here, you want to minimize size of source data sent, not destination). It is all pretty crazy, never seen before drawing to screen scattered over so many different drivers used in combination. As for verifying plane location it should be quite easy to add some debug code when iterating over planes and print plane memory type.  Maybe it is even printed to kernel log at boot time. [[User:fanoush|fanoush]] 12:15, 17 July 2008 (UTC)

i was under the impression the dispc framebuffer driver was used on ti development boards within monte-vista and not touched or initialized at all by maemo at present.  we initialize omapfb and talk to the blizzard low level interface without mention of any on OMAP memory (technically the blizzard doesn't even know or care that it is sitting on an OMAP motherboard).
With the omapfb, there are multiple planes and from what I understand all are allocated in standard SDRAM.
The way I am thinking of utilizing the SRAM would be to allocate a buffer similar to the dispc SRAM based frambuffer, then after rendering, update a frame by pushing the data out to the already allocated blizzard SDRAM buffer (using the IVA to perform RGB->YUV conversion if required per the display mode) and then tell blizzard to update.
Sure, its a longer path but right now (because of lack of information) I am not sure we can tell the powervr to render directly to SDRAM.  If it is possible it may also give applications a fast RGB pixelbuffer to do non 3d fancy things which are limited at present by SDRAM access speeds.  --[[Special:Contributions/80.0.224.233|80.0.224.233]] 13:31, 17 July 2008 (UTC)
I believe the ompafb we do use was originally created to support the omap1 processor family which had to use an external lcd because it did not have a SRAM framebuffer or direct video out from the chip (it didnt have its own graphics card).  --[[Special:Contributions/80.0.224.233|80.0.224.233]] 13:52, 17 July 2008 (UTC)


http://mxr.maemo.org/diablo/source/kernel-source-diablo-2.6.21/kernel-source/drivers/video/omap/dispc.c

Word "justification" in the title implies that we are supposed to justify it to Nokia (or other IP holder) why we need this information. For good justification, we have to show what value <b>IP holder</b> gets from disclosing information, not what value the community gets. Here is the justification I suggest:

* Among Maemo community there are many people who are willing to perform <b>for free</b> work that companies would have to hire embedded software engineers to do.
* Some of these people have already proven that they have enough qualification to do the job.
* An embedded software engineer costs company at least $75,000 on the average. Thus, if somebody does the same work for free, this leads to direct cost savings to IP holders.
* Even if a project is of no direct interest to the IP holder <b>at this moment</b>, there is no cost to the IP holder, so there is no risk.
* Just about any popular system functionality extension to the Maemo platform (A2DP, rotated display, etc.) greatly increases value of the platform to end users (not necessarily developers). Therefore, even if the company sees no direct use for the feature, it still helps the company to sell more products.

What do we expect from Nokia and other IP holders:

* Give <b>certain qualified people</b> from the Maemo community access to documentation after signing all proper NDAs.
* Give these people some qualified advice from engineers inside the company.
* Accept work from these people and integrate it into official software releases as necessary.



selfless link to liqbase, whether it needs to be seen on the frontpage to show the differences to normal rendering?

http://www.youtube.com/watch?v=PUPp_mE7rwI

== The GPL violation issue ==

I have started circulating the draft and I got already some interesting feedback.

So we have a driver used strictly internally and strictly for R&D purposes. This driver was done for the 2.4 kernel. When moved to 2.6 we have problems with GPL license violations, which we could ''solve'' in three ways:

# Keep the driver as it is and leave the driver installation to you. This way we do not distribute GPL violating drivers, but this way you are using GPL violating drivers.
# We hack the GPL checking from the kernel we will ship, so no GPL violation (but loads of upset kernel developers?)
# We spend a lot of time and money rewriting the driver to be shippable without any kernel changes or violations (not very feasible on our side, I tell you)

Note that in the points above we are not even mentioning TI, who needs to agree in the game since at the end they are the ones licensing the driver.

This is not last word. I will be posting here feedback as I get it.--[[User:qgil|qgil]] 10:12, 17 July 2008 (UTC)
:IANAL, but I don't think (1) is viable: the driver is still a derived work, even if you don't bundle it yourself. (2) would cause so much negative press as to be unbelievable and would cause serious harm to the platform (and so the community). One possible option would be to contract an external community member (or members) under NDA to receive the driver and its source with the understanding that it is not for distribution. For all intents and purposes this is therefore still Nokia internal use. That developer can then do option (3). --[[User:jaffa|Jaffa]] 11:06, 17 July 2008 (UTC)