Editing Talk:Drivers justification

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

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.

== SRAM notes/discussion ==

:irc question:
::<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"
::<overflo> 
 144 #define OMAP2_SRAM_START 0x40200000
 145 /* Maximum size, in reality this is smaller if SRAM is partially locked. */
 146 #define OMAP2_SRAM_SIZE 0xa0000 /* 640k */
:: these locations are used as ram by ARM7 (IVA Processor)

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

:::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)

:::Now that's interesting, it is not in SRAM indeed. At least in Diablo/N810. Will check OS2007/N800 but most probably it will be similar.
::: omapfb: s1d13745 LCD controller rev 1 initialized (CNF pins 3)
::: omapfb: region0 phys 80600000 virt ffa01000 size=770048 type=0
::: omapfb: region1 phys 80700000 virt ffabd000 size=786432 type=0
::: omapfb: region2 phys 87c00000 virt ffb7d000 size=1572864 type=0
::: omapfb: Framebuffer initialized. Total vram 3129344 planes 3
:::So why they added plane support in SRAM is beyond me 8-0 [[User:fanoush|fanoush]] 14:35, 17 July 2008 (UTC)

:::Huh, I was right after all. This is OS2007/N800
::: omapfb: region0 phys 87e00000 virt ffa01000 size=770048 type=0
::: omapfb: region1 phys 4022f000 virt d002f000 size=462848 type=1
::: omapfb: region2 phys 87f00000 virt ffabd000 size=770048 type=0
::: omapfb: Framebuffer initialized. Total vram 2002944 planes 3
:::I wonder why they disabled it in OS2008 (or maybe Diablo?) --[[User:fanoush|fanoush]] 15:51, 17 July 2008 (UTC)

:::fanoush, very interesting indeed and would appear to confirm the need for clear documentation.  --[[User:lcuk|lcuk]] 21:10, 17 July 2008 (UTC)

:::The 2.6.18 kernel has it defined in arch/arm/mach-omap2/board-n800.c, second plane is defined in SRAM with size 640x480x12bpp. This is no longer true since first 2.6.21 kernel used in OS2008 (defined in same source). True that planes are defined to be much larger so they would no longer fit into SRAM. The third plane now has space for two full 800x480 frames. --[[User:fanoush|fanoush]] 06:33, 18 July 2008 (UTC)

== justification point ==

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 IP holder 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 for free 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 at this moment, 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 certain qualified people 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.

== example fast cpu rendering ==

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:

# <irony>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.</irony>
# <irony>We hack the GPL checking from the kernel we will ship, so no GPL violation (but loads of upset kernel developers?)</irony>
# 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)
::Good to see that we are in the same page. The first two options are listed as mathematical possibilities but in real terms are No-Go. About the third option, in principle I see a problem combining "community member" and "NDA" since normally NDAs are signed with individuals in companies or other types or organizations (e.g. universities, research centers...). In any case the organization that helps external developers getting contracts signed is Forum Nokia. Kate Alhola is the Maemo contact there and in fact she is interested and working in finding a way to get this puzzle sorted out in some way. I have sent her a link to this page. You know her as well. looks like a way to see if it's possible to move forward. In any case I keep the feedback channel open in my side and I will report here anything new.--[[User:qgil|qgil]] 18:06, 17 July 2008 (UTC)
:Note: The 2. alternative, just disabling the GPL check is really not on option that Nokia can do at all, it was just mentioned indicating there is no good and acceptable way that Nokia can do for shipping the driver. [[User:kate|kate]] 08:52, 21 July 2008 (UTC)

We are having discussions with TI if we could find reasonable terms to get driver released to developers. At the moment i see two options:
# We get from TI version that fills our requirement about being GPL compliant 
# TI/Imagination technologies will directly distribute version in their download page [http://www.imgtec.com/powervr/insider/sdkdownloads/index.asp#GLES1b]
# If there is some volunteer from community that is willing to fix the driver, I can try to help get NDA or other reasonable terms for it. 
[[User:kate|kate]] 10:52, 21 July 2008 (UTC)

*bump: for anyone monitoring this page, can we have a written update please?  --[[User:lcuk|lcuk]] 16:58, 30 October 2008 (UTC)

qgil stated, [http://internettablettalk.com/forums/showthread.php?p=237998#post237998 on 30-Oct-2008]: "For what I know, the situation is still [unchanged] ... [T]he ball is currently not in Nokia's terrain and the Fremantle release has little to do with all this topic. :/" --[[User:qole|qole]] 23:06, 3 November 2008 (UTC)

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/Talk:Drivers_justification"

Personal tools

Navigation

Views

Editing Talk:Drivers justification

@@ Line 2: / Line 2: @@
-==PowerVR==
+PowerVR
 d rendering (hopefully onto 5mbit on omap2420 SARAM buffer
-==IVA==
+IVA
    Conversion from RGB to YUV, decoding video frames, scaling and blitting bitmaps
-==5mbit SRAM==
+mbit 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.