Maemo Wiki Mirror - User contributions [en]

Talk:Drivers justification

2008-07-20T07:09:09Z

81.208.74.179: /* SRAM notes/discussion */

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:

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

Talk:Drivers justification

2008-07-20T07:05:39Z

81.208.74.179: /* SRAM notes/discussion */

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>
145 /* Maximum size, in reality this is smaller if SRAM is partially locked. */
146 #define OMAP2_SRAM_SIZE 0xa0000 /* 640k */
this location is user 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:

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

Talk:Drivers justification

2008-07-20T07:04:27Z

81.208.74.179: /* SRAM notes/discussion */

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> 145 /* Maximum size, in reality this is smaller if SRAM is partially locked. */
146 #define OMAP2_SRAM_SIZE 0xa0000 /* 640k */
this location is user 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:

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

Drivers justification

2008-07-19T15:39:39Z

81.208.74.179: /* IVA */

== Overview ==

The Nokia Internet Tablets contain a number of components which are not documented or utilised at all.
We believe these components are holding back further development and advancement of the platform.

If we had drivers and documentation for each element we could get the most out of our devices.

== PowerVR MBX ==

The N8x0 devices contain a 3D graphics processor, which is currently not used. We (the
Maemo.org community) would like to ask Nokia to release a driver for this component so
that we can develop more advanced GUIs, games and <...>.

With desktop computers, 2D and 3D effects are becoming the norm (e.g. Windows Aero on Vista, Quartz on Mac OS X, and Compiz
on Linux desktops). Embedded devices such as the iPhone are also using graphics
acceleration (in that case a PowerVR too) to provide very polished, visually pleasing, and interesting interfaces to the their respective "desktops" and making that acceleration available to applications as well.

We believe that having access to the graphics acceleration hardware on the N8x0 will
allow developers to create new and compelling interfaces, applications and games, which
will give us a head-start in developing for future Nokia Internet Tablet devices (which
will presumably have 3D acceleration available from the outset).

Therefore, we would like to ask Nokia to make available to us the PowerVR driver and
OpenGL ES implementation. We understand that the driver in question has some issues (e.g.
stability, awkward implementation details - console must be left open, etc.), but it
would be a great help.

Ideally we would like the source code for the driver, support library and OpenGL ES library,
but we understand that this is ImgTech's IP and therefore they will probably be unwilling
to support this; as a second we would like a binary-blob style driver, which can then be
used with different Linux kernels, but we do not know whether this is the form the
current driver takes, or if it would entail extra effort and expense for Nokia (it would
surely be in Texas Instruments' and ImgTech's best interest to do this, to push the use
and acceptance of their technology, but that is a moot point in this discussion). As a
last option, we would simply like access to the existing binary driver, support library
and OpenGL ES library.

== IVA ==

The OMAP2420 contains something called an IVA (imaging and video accelerator), which we
are told<ref name=TIOMAP2420>http://focus.ti.com/pdfs/wtbu/TI_omap2420.pdf</ref> is able to do full motion video
encoding/decoding at up to 30fps and also fast JPEG compression/decompression. This
hardware is not used at present, but is apparently able to do quite a lot. The Internet
Tablets are currently limited by the LCD controller bandwidth, but are also limited by
the ARM CPU in the quality and size of the videos they are able to decode.

We would like to know why the IVA is not being used, and if possible to obtain technical
information about it to allow us to program and use it. We understand that it consists of
an ARM7 core plus some coprocessors to speed up a variety of operations including VLC
(variable length coding/decoding) and iMX (programmable parallel operations).

Being able to use this IVA would greatly enhance the abilities of the Internet Tablets as
a multimedia device for both photos/photo manipulation and video watching (currently
videos must be encoded specifically for it, which is fine as they become smaller, but
with cheaper microSD storage available now, the convenience of having the same data files
outweighs the inefficiency of storage).

It's also likely that the additional processing power could enable better support of newer, more efficient codecs, such as h264, that currently require too much CPU power to be generally useful. As h264 video podcasts intended for use with iPods are popular, but usually have bitrates too high for the tablets to handle, this would be a great improvement in usefulness.

== 5 Mbit SRAM Framebuffer ==

The OMAP2420 contains a 5Mbit SRAM buffer which is meant to allow a VGA display.<ref name=TIOMAP2420/>
According to our research, this buffer is not being utilised by this device.
We believe this buffer may be used as a fast destination render target for the PowerVR.
This onchip framebuffer will provide a very fast RGB surface for use in X11 and SDL gaming.

This is semi documented within http://mxr.maemo.org/diablo/source/kernel-source-diablo-2.6.21/kernel-source/drivers/video/omap/dispc.c

== Bringing it together ==

On their own each component has limited purpose and use, however a work flow which involves rendering 3d objects with the PowerVR (or 2d from the CPU or IVA) onto the 5Mbit SRAM buffer which can then be converted from RGB to YUV and copied to main DDR memory by the IVA would allow us to achieve improved performance over the current all software approach.
We have software which successfully confirms there is enough bandwidth between the main memory and the Epson LCD chip using a specialised YUV mode, however it will require the help of the hardware components listed above to bring these benefits to all software running on the device.

== References ==

<references/>