• Intro
• Downloads
• Community
• Development
• News
• TALK

Talk:Drivers justification

Revision as of 11:06, 17 July 2008

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. 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. --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 :-) 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. 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. --lcuk 10:51, 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 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.

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:

1. 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.
2. We hack the GPL checking from the kernel we will ship, so no GPL violation (but loads of upset kernel developers?)
3. 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.--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). --Jaffa 11:06, 17 July 2008 (UTC)