Hi all, I have worked through all documentation I have, to improve all the driver settings (but still not successful).
Some more observations: * it is quite tricky to calculate the correct clock frequencies for pixel clock, hs-lane clock and low-power clock - but I have packed that into (I hope) well documented macros * one problem is that the MIPI data transmission must have some % higher bandwidth than the display will generate (to add margin for framing and error correction) * but the kernel appears to limit the MIPI clock to 450 MHz (which appears to be ok for OMAP4 but OMAP5 should be able to run up to >600 MHz) * anyways this can be addressed for the moment by making the pixel clock slower (reducing the refresh rate to 50 Hz)
Well, although the panel frequencies appear to be ok:
[ 45.991607] DSI: Data rate on 1 DSI lane 864 Mbps [ 45.991607] DSI: Clock lane freq 432000000 Hz
[ 46.488250] DISPC: channel 0 xres 1080 yres 1920 [ 46.488281] DISPC: pck 120000 [ 46.488281] DISPC: hsw 10 hfp 10 hbp 100 vsw 10 vfp 10 vbp 60 [ 46.488281] DISPC: vsync_level 0 hsync_level 0 data_pclk_edge 1 de_level 0 sync_pclk_edge 0 [ 46.488311] DISPC: hsync 100000Hz, vsync 50Hz
the main symptom is still:
[ 3.641601] omapdss DSI error: DSI error, irqstatus 400a0 [ 3.647247] DSI: DSI IRQ: 0x400a0: RESYNC PLL_LOCK SYNC_LOST
[ 46.505615] omapdss DSI error: DSI error, irqstatus 401a0 [ 46.505615] DSI: DSI IRQ: 0x401a0: RESYNC PLL_LOCK PLL_UNLOCK SYNC_LOST
shortly (20ms) after the DSI panel reports successful power on.
And I have added some code to read the actual_backlight intensity from the panel - but it gives a communication timeout. Note that this function should IMHO not need the high-speed clock to work (correctly):
root@gta04:~# cat /sys/devices/ocp.3/dss.10/0.dsi/display0/backlight/r63311/actual_brightness [ 67.482238] dsi: r63311_get_brightness() [ 67.980895] omapdss DSI error: Failed to receive BTA [ 67.986145] omapdss DSI error: dsi_vc_dcs_read(ch 1, cmd 0x52) failed [ 67.994049] r63311 display0: read cmd/reg(0) failed: -5 [ 67.999725] dsi: -5=r63311_read(00) [ 68.003417] dsi: read 0 0 root@gta04:~#
This means that the video data stream has some problems that must be within the OMAP.
I will now try two things: a) experiment without any display adapter (this should not make a difference) b) modify the display adapter to use a dedicated GPIO for the panel reset (currently it is shared with the I2C devices which may make problems when suspending the panel)
The latest kernel source is in branch "pyra-mipi".
(BTW: can we have some public GitWeb access to link to patches/branches?).
BR, Nikolaus
Am Thu, 6 Feb 2014 17:14:59 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
I have worked through all documentation I have, to improve all the driver settings (but still not successful).
Okay - so time to ask TI or some other one who knows more about MIPI?
Some more observations:
- it is quite tricky to calculate the correct clock frequencies for
pixel clock, hs-lane clock and low-power clock - but I have packed that into (I hope) well documented macros
- one problem is that the MIPI data transmission must have some %
higher bandwidth than the display will generate (to add margin for framing and error correction)
- but the kernel appears to limit the MIPI clock to 450 MHz (which
appears to be ok for OMAP4 but OMAP5 should be able to run up to >600 MHz)
Does the kernel you're using support the OMAP5 or only the OMAP4? Could that be an issue here?
- anyways this can be addressed for the moment by making the pixel
clock slower (reducing the refresh rate to 50 Hz)
Well - do we know that the LCD support 50Hz? (we do hope so, but we don't know)
Well, although the panel frequencies appear to be ok:
[ 45.991607] DSI: Data rate on 1 DSI lane 864 Mbps [ 45.991607] DSI: Clock lane freq 432000000 Hz
[ 46.488250] DISPC: channel 0 xres 1080 yres 1920 [ 46.488281] DISPC: pck 120000 [ 46.488281] DISPC: hsw 10 hfp 10 hbp 100 vsw 10 vfp 10 vbp 60 [ 46.488281] DISPC: vsync_level 0 hsync_level 0 data_pclk_edge 1 de_level 0 sync_pclk_edge 0 [ 46.488311] DISPC: hsync 100000Hz, vsync 50Hz
the main symptom is still:
[ 3.641601] omapdss DSI error: DSI error, irqstatus 400a0 [ 3.647247] DSI: DSI IRQ: 0x400a0: RESYNC PLL_LOCK SYNC_LOST
[ 46.505615] omapdss DSI error: DSI error, irqstatus 401a0 [ 46.505615] DSI: DSI IRQ: 0x401a0: RESYNC PLL_LOCK PLL_UNLOCK SYNC_LOST
shortly (20ms) after the DSI panel reports successful power on.
Hm.... Sync lost... so the timings seem to be incorrect, I guess.
And I have added some code to read the actual_backlight intensity from the panel - but it gives a communication timeout. Note that this function should IMHO not need the high-speed clock to work (correctly):
A communication timeout would also happen if timings are not in sync, correct?
So either communication lines are not working properly or they are trying to communicate with different clockrates (which apparently would lead to a timeout).
root@gta04:~# root@cat /sys/devices/ocp.3/dss.10/0.dsi/display0/backlight/r63311/actual_brightness [ 67.482238] dsi: r63311_get_brightness() [ 67.980895] omapdss DSI error: Failed to receive BTA [ 67.986145] omapdss DSI error: dsi_vc_dcs_read(ch 1, cmd 0x52) failed [ 67.994049] r63311 display0: read cmd/reg(0) failed: -5 [ 67.999725] dsi: -5=r63311_read(00) [ 68.003417] dsi: read 0 0 root@gta04:~#
This means that the video data stream has some problems that must be within the OMAP.
I will now try two things: a) experiment without any display adapter (this should not make a difference) b) modify the display adapter to use a dedicated GPIO for the panel reset (currently it is shared with the I2C devices which may make problems when suspending the panel)
Okay.
The latest kernel source is in branch "pyra-mipi". (BTW: can we have some public GitWeb access to link to patches/branches?).
Right, forgot about that. It's now public (http://git.openpandora.org)
Are you planning to ask other guys (TI Support forums?) for help with that GIT?
Am 06.02.2014 um 21:34 schrieb Michael Mrozek:
Am Thu, 6 Feb 2014 17:14:59 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
I have worked through all documentation I have, to improve all the driver settings (but still not successful).
Okay - so time to ask TI or some other one who knows more about MIPI?
Maybe. I will try to trace the issue down tomorrow what this interrupt really means.
At the moment I think it is not even a MIPI related thing, but OMAP/Linux clock and DSS.
But give me some time to find the real question that needs to be answered.
Some more observations:
- it is quite tricky to calculate the correct clock frequencies for
pixel clock, hs-lane clock and low-power clock - but I have packed that into (I hope) well documented macros
- one problem is that the MIPI data transmission must have some %
higher bandwidth than the display will generate (to add margin for framing and error correction)
- but the kernel appears to limit the MIPI clock to 450 MHz (which
appears to be ok for OMAP4 but OMAP5 should be able to run up to >600 MHz)
Does the kernel you're using support the OMAP5 or only the OMAP4? Could that be an issue here?
The kernel supports OMAP5 - but I don't know if the DSS in this variant was already upgraded to the wider limits.
- anyways this can be addressed for the moment by making the pixel
clock slower (reducing the refresh rate to 50 Hz)
Well - do we know that the LCD support 50Hz? (we do hope so, but we don't know)
Yes, we don't know.
Well, although the panel frequencies appear to be ok:
[ 45.991607] DSI: Data rate on 1 DSI lane 864 Mbps [ 45.991607] DSI: Clock lane freq 432000000 Hz
[ 46.488250] DISPC: channel 0 xres 1080 yres 1920 [ 46.488281] DISPC: pck 120000 [ 46.488281] DISPC: hsw 10 hfp 10 hbp 100 vsw 10 vfp 10 vbp 60 [ 46.488281] DISPC: vsync_level 0 hsync_level 0 data_pclk_edge 1 de_level 0 sync_pclk_edge 0 [ 46.488311] DISPC: hsync 100000Hz, vsync 50Hz
the main symptom is still:
[ 3.641601] omapdss DSI error: DSI error, irqstatus 400a0 [ 3.647247] DSI: DSI IRQ: 0x400a0: RESYNC PLL_LOCK SYNC_LOST
[ 46.505615] omapdss DSI error: DSI error, irqstatus 401a0 [ 46.505615] DSI: DSI IRQ: 0x401a0: RESYNC PLL_LOCK PLL_UNLOCK SYNC_LOST
shortly (20ms) after the DSI panel reports successful power on.
Hm.... Sync lost... so the timings seem to be incorrect, I guess.
Yes, that is what I also guess. And it is a problem on the OMAP side because it is the same if no panel is connected at all.
And I have added some code to read the actual_backlight intensity from the panel - but it gives a communication timeout. Note that this function should IMHO not need the high-speed clock to work (correctly):
A communication timeout would also happen if timings are not in sync, correct?
So either communication lines are not working properly or they are trying to communicate with different clockrates (which apparently would lead to a timeout).
Or we have two problems that interfere and make it a little difficult to debug one.
root@gta04:~# root@cat /sys/devices/ocp.3/dss.10/0.dsi/display0/backlight/r63311/actual_brightness [ 67.482238] dsi: r63311_get_brightness() [ 67.980895] omapdss DSI error: Failed to receive BTA [ 67.986145] omapdss DSI error: dsi_vc_dcs_read(ch 1, cmd 0x52) failed [ 67.994049] r63311 display0: read cmd/reg(0) failed: -5 [ 67.999725] dsi: -5=r63311_read(00) [ 68.003417] dsi: read 0 0 root@gta04:~#
This means that the video data stream has some problems that must be within the OMAP.
I will now try two things: a) experiment without any display adapter (this should not make a difference) b) modify the display adapter to use a dedicated GPIO for the panel reset (currently it is shared with the I2C devices which may make problems when suspending the panel)
Okay.
The latest kernel source is in branch "pyra-mipi". (BTW: can we have some public GitWeb access to link to patches/branches?).
Right, forgot about that. It's now public (http://git.openpandora.org)
Thanks!
Are you planning to ask other guys (TI Support forums?) for help with that GIT?
Ah, good diea. My original idea behind is that I can attach a direkt link to some commit diff on this mailing list to explain what I mean...
And, using gitweb makes it simpler to see what I have done 2 weeks ago than going git commandline.
BR, Nikolaus
Ok, latest news after peeking and poking into Linux, I have fixed the SYNC_LOST issue:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=commit;h=b...
That was quite complex. The problem is that the only controls we have are struct omap_video_timings and omap_dss_dsi_videomode_timings which can be set in the driver. From these, the guts of Linux calculate some register settings for the OMAP5. Depending on their correctness, the DSI stays in sync or does not.
Now, there is no simple formula that tells what to specify in the driver for those structs to get some expected output. Rather I can only find out fro the register settings what the OMAP5 is doing. And then modify the controls to set other register values.
The required information to understand that is unfortunately spread over several documents and locations: * OMAP TRM * Linux kernel source * Driver source * some special Spread Sheet by TI to visualize what the OMAP is doing - if you know the register values * Linux kernel log * cat /sys/kernel/debug/omapdss/clk * cat /sys/kernel/debug/omapdss/dsi1_regs
What increases the complexity is that the same divider value or clock signal has at least 3 different names in these information sources. And if I e.g. look into the dsi1_regs I have to find and analyse the hex code as a bit pattern in the TRM to see what it is doing.
But finally I found out: * DSI needs its own view on the hsync and vsync pulses vs. front/back porch (Austastlücke) - and that must be fully synchronized with the DISPC * so it is not sufficient to define that like for a RGB panel just for the DISPC * there are rounding effects to consider * not all combinations of values are possible - this may e.g. be the reason why I always did get 450 MHz yesterday
Well, the author of the Linux DSS API could have made life much easier for us if we would not even have to specify a pixel clock but only the horizontal and vertical size + pulses and a frame rate. Everything else should be possible to be calculated in the kernel - if I can do it manually by using this spreadsheet. So Linux seems to provide a half-hearted solution. At least the 3.8 DSS. I know that there is a complete rewrite in 3.14 - but that is still -rc1. [Sidenote: I don't know if such a DSS framework exists for the Z3770 Atom at all - ok, looks as if there is work in progress: http://www.spinics.net/lists/intel-gfx/msg37329.html].
But after digging through that mess back and forth I finally found a combination that appears to work. At least there are no more DSI PLL and SYNC errors. Meaning we should see a steady data stream on the MIPI port.
Next step will be to debug if I can really see these signals with the scope and to check if the reset impulse is applied correctly. And if the data lanes have correct polarity.
So it turns out that the step-by-step approach to remove road blocks is better than trying everything in one big bang :)
Well, this is something where TI *could* have helped - but either slower (because if I post a question it may take a while until they answer) or I would have had to understand it anyways what they are talking about.
But Panel still remains black. So let's address the next road-block :)
BR, Nikolaus
But Panel still remains black. So let's address the next road-block :)
Still black - but for the first time I can "detect" if a panel is connected... I.e. some communication is working:
With panel connected:
root@gta04:~# cat /sys/devices/ocp.3/dss.10/0.dsi/display0/backlight/r63311/actual_brightness [ 414.299407] dsi: r63311_get_brightness() [ 414.311004] omapdss DSI error: dsi_vc_read_rx_fifo(ch 1 type DCS) failed [ 414.318481] omapdss DSI error: dsi_vc_dcs_read(ch 1, cmd 0x52) failed [ 414.325592] r63311 display0: read cmd/reg(0) failed: -5 [ 414.331756] dsi: -5=r63311_read(00) [ 414.335784] dsi: read 0
With no panel connected:
root@gta04:~# cat /sys/devices/ocp.3/dss.10/0.dsi/display0/backlight/r63311/actual_brightness [ 263.789581] dsi: r63311_get_brightness() [ 264.292175] omapdss DSI error: Failed to receive BTA [ 264.297393] omapdss DSI error: dsi_vc_dcs_read(ch 1, cmd 0x52) failed [ 264.304229] r63311 display0: read cmd/reg(0) failed: -5 [ 264.309783] dsi: -5=r63311_read(00) [ 264.313476] dsi: read 0
You see the difference?
It is "Failed to receive BTA"
BTA is the MIPI abbreviation for "bus turn around". This means if the panel is connected it responds by sending data back to the OMAP. If it is not connected, that fails of course...
Ok, this is a strong indication that the electrical things (almost) work - but still may be one more roadblock.
And that there is something in the programming sequence for the panel after power-on.
BR, Nikolaus
Am Fri, 7 Feb 2014 15:56:03 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
wow, thanks, great work :D
About the black panel:
The Renesas chip seems to have pattern generator included: http://www.rsp.renesas.com/en/news/2012/news20120418.htm
Do we know how we can trigger that?
It would at least help telling us if the initial sequence starting the panel and timings are the issue or whether it is the picture transmission itself.
But Panel still remains black. So let's address the next road-block :)
Still black - but for the first time I can "detect" if a panel is connected... I.e. some communication is working:
With panel connected:
root@gta04:~# root@cat /sys/devices/ocp.3/dss.10/0.dsi/display0/backlight/r63311/actual_brightness [ 414.299407] dsi: r63311_get_brightness() [ 414.311004] omapdss DSI error: dsi_vc_read_rx_fifo(ch 1 type DCS) failed [ 414.318481] omapdss DSI error: dsi_vc_dcs_read(ch 1, cmd 0x52) failed [ 414.325592] r63311 display0: read cmd/reg(0) failed: -5 [ 414.331756] dsi: -5=r63311_read(00) [ 414.335784] dsi: read 0
With no panel connected:
root@gta04:~# root@cat /sys/devices/ocp.3/dss.10/0.dsi/display0/backlight/r63311/actual_brightness [ 263.789581] dsi: r63311_get_brightness() [ 264.292175] omapdss DSI error: Failed to receive BTA [ 264.297393] omapdss DSI error: dsi_vc_dcs_read(ch 1, cmd 0x52) failed [ 264.304229] r63311 display0: read cmd/reg(0) failed: -5 [ 264.309783] dsi: -5=r63311_read(00) [ 264.313476] dsi: read 0
You see the difference?
It is "Failed to receive BTA"
BTA is the MIPI abbreviation for "bus turn around". This means if the panel is connected it responds by sending data back to the OMAP. If it is not connected, that fails of course...
Ok, this is a strong indication that the electrical things (almost) work - but still may be one more roadblock.
And that there is something in the programming sequence for the panel after power-on.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 07.02.2014 um 16:15 schrieb Michael Mrozek:
Am Fri, 7 Feb 2014 15:56:03 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
wow, thanks, great work :D
About the black panel:
The Renesas chip seems to have pattern generator included: http://www.rsp.renesas.com/en/news/2012/news20120418.htm
Do we know how we can trigger that?
Great idea!
Unfortunately no. It is not described in the panel data sheet. And we have no data sheet for the Renesas chip. Maybe the other one has something similar.
It could even be something as simple as a black framebuffer contents :) But I don't think so since I did look a little at the output signals and it looks more like non-black pixel data.
It would at least help telling us if the initial sequence starting the panel and timings are the issue or whether it is the picture transmission itself.
My idea for further debugging is to get the backlight control working. The intensity is driven by the panel and can be controlled through some MIPI command.
So as soon as I can write and read back the intensity, the communication should be working basically.
What I currently suspect is that the enabling sequence has some bug. And therefore the panel refuses to accept to turn on backlight and refuses to return the actual_brightness...
But Panel still remains black. So let's address the next road-block :)
Still black - but for the first time I can "detect" if a panel is connected... I.e. some communication is working:
With panel connected:
root@gta04:~# root@cat /sys/devices/ocp.3/dss.10/0.dsi/display0/backlight/r63311/actual_brightness [ 414.299407] dsi: r63311_get_brightness() [ 414.311004] omapdss DSI error: dsi_vc_read_rx_fifo(ch 1 type DCS) failed [ 414.318481] omapdss DSI error: dsi_vc_dcs_read(ch 1, cmd 0x52) failed [ 414.325592] r63311 display0: read cmd/reg(0) failed: -5 [ 414.331756] dsi: -5=r63311_read(00) [ 414.335784] dsi: read 0
With no panel connected:
root@gta04:~# root@cat /sys/devices/ocp.3/dss.10/0.dsi/display0/backlight/r63311/actual_brightness [ 263.789581] dsi: r63311_get_brightness() [ 264.292175] omapdss DSI error: Failed to receive BTA [ 264.297393] omapdss DSI error: dsi_vc_dcs_read(ch 1, cmd 0x52) failed [ 264.304229] r63311 display0: read cmd/reg(0) failed: -5 [ 264.309783] dsi: -5=r63311_read(00) [ 264.313476] dsi: read 0
You see the difference?
It is "Failed to receive BTA"
BTA is the MIPI abbreviation for "bus turn around". This means if the panel is connected it responds by sending data back to the OMAP. If it is not connected, that fails of course...
Ok, this is a strong indication that the electrical things (almost) work - but still may be one more roadblock.
And that there is something in the programming sequence for the panel after power-on.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
And that there is something in the programming sequence for the panel after power-on.
Most likely. I am starting to read register values as described in the Panel data sheet plus some more with description scattered around several places...
Currently I am adding some code to read all available registers - and if I do a mistake (register does not exist or has >1 byte contents I already get reasonable error messages).
It starts to look like that we have to send one or two more "standard" commands that are not included in the panel data sheet.
So still no backlight - but close.
If we had the official R63311 data sheet... But Renesas is Japanese and a little closed.
The one for the R61523 is similar so that I can learn a lot - but it is definitively not exactly the same command set.
BR, Nikolaus
Am Fri, 7 Feb 2014 20:05:50 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
And that there is something in the programming sequence for the panel after power-on.
Most likely. I am starting to read register values as described in the Panel data sheet plus some more with description scattered around several places...
The Google Nexus 5 uses the same screen - maybe the kernel is available somewhere (Cyanogenmod?) with a driver?
I know we can't use the driver, but the startup sequence should be readable from there, shouldn't it?
Currently I am adding some code to read all available registers - and if I do a mistake (register does not exist or has >1 byte contents I already get reasonable error messages).
It starts to look like that we have to send one or two more "standard" commands that are not included in the panel data sheet.
So still no backlight - but close.
If we had the official R63311 data sheet... But Renesas is Japanese and a little closed.
The one for the R61523 is similar so that I can learn a lot - but it is definitively not exactly the same command set.
BR, Nikolaus _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 07.02.2014 um 21:46 schrieb Michael Mrozek:
Am Fri, 7 Feb 2014 20:05:50 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
And that there is something in the programming sequence for the panel after power-on.
Most likely. I am starting to read register values as described in the Panel data sheet plus some more with description scattered around several places...
The Google Nexus 5 uses the same screen - maybe the kernel is available somewhere (Cyanogenmod?) with a driver?
I know we can't use the driver, but the startup sequence should be readable from there, shouldn't it?
Oh yes, that is a good idea! And now as we better understand the acronyms it should be easier to analyse such a driver.
and we should be able to find how it sets the backlight level.
Currently I am adding some code to read all available registers - and if I do a mistake (register does not exist or has >1 byte contents I already get reasonable error messages).
It starts to look like that we have to send one or two more "standard" commands that are not included in the panel data sheet.
So still no backlight - but close.
If we had the official R63311 data sheet... But Renesas is Japanese and a little closed.
The one for the R61523 is similar so that I can learn a lot - but it is definitively not exactly the same command set.
BR, Nikolaus _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 07.02.2014 um 21:46 schrieb Michael Mrozek:
Am Fri, 7 Feb 2014 20:05:50 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
And that there is something in the programming sequence for the panel after power-on.
Most likely. I am starting to read register values as described in the Panel data sheet plus some more with description scattered around several places...
The Google Nexus 5 uses the same screen - maybe the kernel is available somewhere (Cyanogenmod?) with a driver?
I know we can't use the driver, but the startup sequence should be readable from there, shouldn't it?
I have tried to locate Android kernels and both (Faux, Cyanogenmod) I have found for the "LG Nexus 5" = "Hammerhead" don't configure MIPI but LVDS and some Chimei panel:
CONFIG_FB_MSM_LVDS=y CONFIG_FB_MSM_LVDS_CHIMEI_WXGA=y
The cyanogen mod kernel config is here:
https://github.com/CyanogenMod/android_kernel_lge_hammerhead/blob/cm-11.0/ar...
So are you sure that the Nexus 5 (hammerhead) uses exactly the same panel or just a similar one (same dimensions)? Or are there two versions of the Nexus 5 that can be mixed up?
What makes me also wonder is why LG should use a Chimei panel. And ours is not W(U)XGA but Full HD
But there may also be some LVDS - MIPI bridge inside the Nexus - but what would that be good for...
And yes, there is a Renesas driver in Cyanogenmod:
https://github.com/CyanogenMod/android_kernel_lge_hammerhead/blob/cm-11.0/dr...
but it is not clear for which Renesas chip that is.
Any ideas?
BR, Nikolaus
Am Sat, 8 Feb 2014 10:43:48 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
I have tried to locate Android kernels and both (Faux, Cyanogenmod) I have found for the "LG Nexus 5" = "Hammerhead" don't configure MIPI but LVDS and some Chimei panel:
That's weird... The Nexus 5 has a 1080x1920 display, that's for sure...
http://www.google.com/nexus/5/ http://www.gsmarena.com/lg_nexus_5-5705.php
CONFIG_FB_MSM_LVDS=y CONFIG_FB_MSM_LVDS_CHIMEI_WXGA=y
The cyanogen mod kernel config is here:
https://github.com/CyanogenMod/android_kernel_lge_hammerhead/blob/cm-11.0/ar...
So are you sure that the Nexus 5 (hammerhead) uses exactly the same panel or just a similar one (same dimensions)? Or are there two versions of the Nexus 5 that can be mixed up?
I don't think so... I got the information that it's the same panel from MSC, regarding lifetime, as they mentioned explicitely that it's a smartphone display and might not be available if the phone is eol...
What makes me also wonder is why LG should use a Chimei panel. And ours is not W(U)XGA but Full HD
Well, we know for sure it has to be fullhd. That's what all spec sites of the Nexus 5 say.
But there may also be some LVDS - MIPI bridge inside the Nexus - but what would that be good for...
And yes, there is a Renesas driver in Cyanogenmod:
https://github.com/CyanogenMod/android_kernel_lge_hammerhead/blob/cm-11.0/dr...
but it is not clear for which Renesas chip that is.
Any ideas?
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 08.02.2014 um 12:08 schrieb Michael Mrozek:
Am Sat, 8 Feb 2014 10:43:48 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
I have tried to locate Android kernels and both (Faux, Cyanogenmod) I have found for the "LG Nexus 5" = "Hammerhead" don't configure MIPI but LVDS and some Chimei panel:
That's weird... The Nexus 5 has a 1080x1920 display, that's for sure...
http://www.google.com/nexus/5/ http://www.gsmarena.com/lg_nexus_5-5705.php
CONFIG_FB_MSM_LVDS=y CONFIG_FB_MSM_LVDS_CHIMEI_WXGA=y
The cyanogen mod kernel config is here:
https://github.com/CyanogenMod/android_kernel_lge_hammerhead/blob/cm-11.0/ar...
So are you sure that the Nexus 5 (hammerhead) uses exactly the same panel or just a similar one (same dimensions)? Or are there two versions of the Nexus 5 that can be mixed up?
I don't think so... I got the information that it's the same panel from MSC, regarding lifetime, as they mentioned explicitely that it's a smartphone display and might not be available if the phone is eol...
What makes me also wonder is why LG should use a Chimei panel. And ours is not W(U)XGA but Full HD
Well, we know for sure it has to be fullhd. That's what all spec sites of the Nexus 5 say.
Well, I have found a little more infos and people discussing about old and new models.
It appears that what we are looking for is not exactly the Nexus 5 but the LG-D821.
http://www.unwiredview.com/2013/09/09/lg-d820-d821-is-not-the-new-google-nex... http://en.wikipedia.org/wiki/Nexus_5#Release
So it is quite confusing and there might be several variants.
For the LG-D821 the service manual was leaked (Google "LG-D821 service manual"). That includes the schematics (Snapdragon...) and definitively shows a MIPI interface. But no schematics or part numbers for the display module...
But what I have not yet found is: * the display spec for the D821 * a kernel source specifically mentioning the D821 (just the hammerhead sources but without MIPI configs)
Hm. This does not yet fit together...
But there may also be some LVDS - MIPI bridge inside the Nexus - but what would that be good for...
And yes, there is a Renesas driver in Cyanogenmod:
https://github.com/CyanogenMod/android_kernel_lge_hammerhead/blob/cm-11.0/dr...
but it is not clear for which Renesas chip that is.
Any ideas?
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Okay, as we might be able to get other SoCs (Allwinner / Qualcomm) as well, I wanted to test out how much power consumption the OMAP5 has.
Not an easy task with our devboard... I did some quick measurements:
Without even being powered up, the devboard uses 0,21W... so I guess the EVM is not really optimized...? Nikolaus, any idea where these 0,21W come from? (maybe the serial USB connector?)
Well, as soon as I switch the EVM on, it eats up 2,25W (which is quite a lot!)
That's with the Pyra PCB, an HDMI Monitor and an USB keyboard connected, nothing else (no Ethernet).
It stays steady at 2,25W, even when X has fully booted and nothing at all is happening.
Running the PSX emulator goes up to 4W.
Removing the USB keyboard lowers the consumption of about 0,15W.
Using stress to get 100% CPU usage on both cores increases the power consumption up to about 6,25W.
Quite a bit of power usage!
Pandoras battery (15,84Wh) would be drained in 2,5hours full load from the EVM and in about 7 hours when doing nothing...
And PSX playing would be roughly 4 hours, which works fine for 9 - 10 hours on the current Pandora (with LCD).
That's not a long battery time, and right now, it's without any LCD and Wifi attached or using the Vivante / SGX.
I know everything on the EVM is currently active. All three USB ports, Ethernet, MIPI, HDMI, probably audio, etc.
Is there a way we can estimate how much power our final PCB would need? Can we find out how much power the SoC itself uses (without all the EVM stuff around?)
Do we know if we are even using power saving features of the SoC yet? (it doesn't sound like we do, as it seems weird to me that booting needs as much power as sitting around idling).
If the SoC doesn't do anything, it shouldn't use more than 0,5 W, right?
So, anyone has any ideas how we can test that?
Am 12.02.2014 um 01:20 schrieb Michael Mrozek:
Is there a way we can estimate how much power our final PCB would need? Can we find out how much power the SoC itself uses (without all the EVM stuff around?)
Yes,
according to the EVM Reference Guide (swcu130) secion 4.2 there are some 30 mOhm 0.5% resistors on the board so that we can measure the current at several places individually.
Another idea is to break into U-Boot console and measure then. Most certainly it is running in single core low clock (300 MHz?) mode.
If I remember correctly my first experiment the whole EVM did draw ~400mA at 5V.
Am Wed, 12 Feb 2014 07:39:33 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Is there a way we can estimate how much power our final PCB would need? Can we find out how much power the SoC itself uses (without all the EVM stuff around?)
Yes, according to the EVM Reference Guide (swcu130) secion 4.2 there are some 30 mOhm 0.5% resistors on the board so that we can measure the current at several places individually.
Okay... the I'll check the reference guide to see which ones I need to use tol test it.
Another idea is to break into U-Boot console and measure then. Most certainly it is running in single core low clock (300 MHz?) mode.
Hm, it uses 2W straight when I switch it on, doesn't sound like single core 300MHz...
If I remember correctly my first experiment the whole EVM did draw ~400mA at 5V.
Same here, which would be the 2W in idling I was talking about.
I'll do measurements for the Pandora today, to get some comparison values.
Am 12.02.2014 um 10:16 schrieb Michael Mrozek:
Am Wed, 12 Feb 2014 07:39:33 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Is there a way we can estimate how much power our final PCB would need? Can we find out how much power the SoC itself uses (without all the EVM stuff around?)
Yes, according to the EVM Reference Guide (swcu130) secion 4.2 there are some 30 mOhm 0.5% resistors on the board so that we can measure the current at several places individually.
Okay... the I'll check the reference guide to see which ones I need to use tol test it.
Another idea is to break into U-Boot console and measure then. Most certainly it is running in single core low clock (300 MHz?) mode.
Hm, it uses 2W straight when I switch it on, doesn't sound like single core 300MHz...
U-Boot has no power management - except low CPU clock.
If I remember correctly my first experiment the whole EVM did draw ~400mA at 5V.
Same here, which would be the 2W in idling I was talking about.
It is the same as an OMAP3 (BB or GTA04 values) draws in idle mode. This means unless there is power management, the CPU enables all clocks for all system components. By switching off some parts it is possible to get it down to 150-200 mA.
You must go to "suspend" mode or an improved power management scheme to get below.
I'll do measurements for the Pandora today, to get some comparison values.
Yes, that would definitively help us to understand the figures.
One more thought about the TI tablet comparison. The panel backlight is drawing energy roughly proportional to the area of the display. So 2W for a 7 inch panel is quite typical.
BR, Nikolaus
Am Wed, 12 Feb 2014 10:28:46 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Okay... the I'll check the reference guide to see which ones I need to use tol test it.
Another idea is to break into U-Boot console and measure then. Most certainly it is running in single core low clock (300 MHz?) mode.
Hm, it uses 2W straight when I switch it on, doesn't sound like single core 300MHz...
U-Boot has no power management - except low CPU clock.
So the additional power management features will lower the power consumption even when using the clockspeed?
I thought they'll just lower the clockspeed when it's not used.
Just came to my mind - is it possible to disable/enable cores on-the-fly?
So can we switch to single core / dual core mode while running?
If I remember correctly my first experiment the whole EVM did draw ~400mA at 5V.
Same here, which would be the 2W in idling I was talking about.
It is the same as an OMAP3 (BB or GTA04 values) draws in idle mode. This means unless there is power management, the CPU enables all clocks for all system components. By switching off some parts it is possible to get it down to 150-200 mA.
Okay. Do we know whether power management mode is enabled in our current kernellll?
You must go to "suspend" mode or an improved power management scheme to get below.
Well, suspend is not usable when running ;)
I get about 10 hours battery life with a Pandora and a 15,84Wh battery. The same should be possible with the Pyra when running approx. the same speed. It should still be 7 - 8 hours when doing some advanced stuff, but hopefully, it shouldn't be less than 5 hours.
Otherwise, I'll really thing about changing the battery... Or we put another battery behind the LCD :) Then people could change one battery on-the-fly, and as the LCD is so thin, it wouldn't even affect the lid thickness tha much :P
Okay, did some power consumption tests with my Pandora.
The display uses about 0,5W (lowest brightness), should be about the same with the new one.
While booting, the Pandora used about 2 - 2,5W (so similar like the OMAP5 devboard). Without display that would be 1,5 - 2W. However, the Pandora had all features like USB, etc. completely disabled, so it might be the same here.
After it has booted into the OS, consumption goes down to 0,85 W (or 0,35W without display). When only moving the mouse, consumption goes up to 1,5 W (or 1W without display), it goes down to 0,35W when you stop moving the mouse. That's a pretty good sign power management is active here :)
On the OMAP5 devboard, it stayed at a steady 2 - 2,25W when using the desktop, but that was with all features enabled (HDMI, network, USB, etc.) and running with 2 Cores.
As power consumption never went down, I'm pretty sure there was no power management active. We just don't know at what clockspeed the 2 Cores were running right now.
When using the Playstation emulator (same config as on the OMAP5 devboard), power consumption goes up to about 3W (or 2,5W without the display). However, once again, the power consumption was going up and down all the time, depending on how much CPU power the PSX emulator was using.
As a reminder, PSX emulation on the OMAP5 went up to 4W, and it didn't go up and down, it stayed that way.
So if Power Management really is switched off on the OMAP5 right now and we can enable / disable cores on-the-fly, we should be pretty good here.
Additionally, the XServer is still running using fbdev only, without any hardware acceleration (which will probably lower the power usage as well).
Maybe enabling power management is something we should look into soon, so we can do some real life tests with power management enabled.
On Wed, Feb 12, 2014 at 2:18 PM, Michael Mrozek EvilDragon@openpandora.org wrote:
... As power consumption never went down, I'm pretty sure there was no power management active. We just don't know at what clockspeed the 2 Cores were running right now.
We do, cpufreq is on and is switching between 500MHz and 1.5GHz, see: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
When using the Playstation emulator (same config as on the OMAP5 devboard), power consumption goes up to about 3W (or 2,5W without the display). However, once again, the power consumption was going up and down all the time, depending on how much CPU power the PSX emulator was using.
As a reminder, PSX emulation on the OMAP5 went up to 4W, and it didn't go up and down, it stayed that way.
The config is not really comparable, on pandora the PSX emu spends almost all time on emulation, while on OMAP5 it's Xorg and SDL eating everything for copying data around, only minor CPU time is spent for actual emulation. In other words, on OMAP5 the CPU has to do much more work than on pandora because of Xorg and SDL slowness.
So if Power Management really is switched off on the OMAP5 right now and we can enable / disable cores on-the-fly, we should be pretty good here.
Well at least cpufreq is working, so I'd say it has partial powersaving.
Additionally, the XServer is still running using fbdev only, without any hardware acceleration (which will probably lower the power usage as well).
FYI we also currently have it like that on pandora, only the video overlay is accelerated on pandora and not on OMAP5. I wouldn't put too many expectetions here..
Maybe enabling power management is something we should look into soon, so we can do some real life tests with power management enabled.
Powersaving on OMAPs is extremely complicated, you know yourself how long it took to get it working on pandora..
Gražvydas
Am Wed, 12 Feb 2014 15:32:20 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
As power consumption never went down, I'm pretty sure there was no power management active. We just don't know at what clockspeed the 2 Cores were running right now
We do, cpufreq is on and is switching between 500MHz and 1.5GHz, see: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
Ah, okay, I'll check that tonight then!
As a reminder, PSX emulation on the OMAP5 went up to 4W, and it didn't go up and down, it stayed that way.
The config is not really comparable, on pandora the PSX emu spends almost all time on emulation, while on OMAP5 it's Xorg and SDL eating everything for copying data around, only minor CPU time is spent for actual emulation. In other words, on OMAP5 the CPU has to do much more work than on pandora because of Xorg and SDL slowness.
Okay... so it's still our slow Xorg and SDL then.
So if Power Management really is switched off on the OMAP5 right now and we can enable / disable cores on-the-fly, we should be pretty good here.
Well at least cpufreq is working, so I'd say it has partial powersaving.
Hmm, but it doesn't really seem to clock down when doing nothing. I'll try what it does when X is not running, just at the CPU core.
Do you know what happens when you use both cores? Do they run at the same clockspeed or can one run with 1,5GHz and the other with 0,5GHz?
Running PSX emulation uses 70% on one core, the other core doesn't do much (though Linux sometimes seems to move the tasks around, so the 70% are sometimes on one then on the other core).
So if both cores are clocked higher even though just one core is being used actually, that would also increas power usage.
Additionally, the XServer is still running using fbdev only, without any hardware acceleration (which will probably lower the power usage as well).
FYI we also currently have it like that on pandora, only the video overlay is accelerated on pandora and not on OMAP5. I wouldn't put too many expectetions here..
Hmm... but even on lower resolutions moving X Windows around seems a lot slower than on the Pandora, so something is different here.
Maybe enabling power management is something we should look into soon, so we can do some real life tests with power management enabled.
Powersaving on OMAPs is extremely complicated, you know yourself how long it took to get it working on pandora..
Yes - is it that much different on the OMAP5 than on the OMAP3? I thought TI stuff is pretty similar, so we might be able to use it on the OMAP5 with minor changes.
On Wed, Feb 12, 2014 at 3:44 PM, Michael Mrozek EvilDragon@openpandora.org wrote:
Am Wed, 12 Feb 2014 15:32:20 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
So if Power Management really is switched off on the OMAP5 right now and we can enable / disable cores on-the-fly, we should be pretty good here.
Well at least cpufreq is working, so I'd say it has partial powersaving.
Hmm, but it doesn't really seem to clock down when doing nothing. I'll try what it does when X is not running, just at the CPU core.
Do you know what happens when you use both cores? Do they run at the same clockspeed or can one run with 1,5GHz and the other with 0,5GHz?
According to the manual, there is only single clock generator, so both cores always run at the same clock. Some forum posters claim that Snapdragon has a feature to clock cores independently, supposedly unique feature. No idea about other SoCs..
Running PSX emulation uses 70% on one core, the other core doesn't do much (though Linux sometimes seems to move the tasks around, so the 70% are sometimes on one then on the other core).
So if both cores are clocked higher even though just one core is being used actually, that would also increas power usage.
Probably, unless the other one can go to sleep. but even if there are small tasks for the other core, it has to do them at full power.. That's why big.Little thing was developed, and OMAP lacks it. But still I think the other core should end up spending most of it's time sleeping and ignoring the fast clock, otherwise you wouldn't see power usage difference between fully loading just one core and both of them.
Additionally, the XServer is still running using fbdev only, without any hardware acceleration (which will probably lower the power usage as well).
FYI we also currently have it like that on pandora, only the video overlay is accelerated on pandora and not on OMAP5. I wouldn't put too many expectetions here..
Hmm... but even on lower resolutions moving X Windows around seems a lot slower than on the Pandora, so something is different here.
I forgot that there's NEON-optimized pixman library (which is responsible for window redrawing) on pandora, and all Debian packages are compiled without NEON because of that stupid Tegra2 SoC (Tegra2 had no NEON but was popular at it's time). So that's the disadvantage of Debian.. OTOH I don't know if those pixman optimizations were even ever merged to mainline pixman project, it might be only available as patches on Angstrom/OE only.
Maybe enabling power management is something we should look into soon, so we can do some real life tests with power management enabled.
Powersaving on OMAPs is extremely complicated, you know yourself how long it took to get it working on pandora..
Yes - is it that much different on the OMAP5 than on the OMAP3? I thought TI stuff is pretty similar, so we might be able to use it on the OMAP5 with minor changes.
Yes it's different, it needs it's own code, even though a bit of it is shared on all newer OMAPs..
Grazvydas
Am Wed, 12 Feb 2014 16:11:52 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
Hmm, but it doesn't really seem to clock down when doing nothing. I'll try what it does when X is not running, just at the CPU core. Do you know what happens when you use both cores? Do they run at the same clockspeed or can one run with 1,5GHz and the other with 0,5GHz?
According to the manual, there is only single clock generator, so both cores always run at the same clock. Some forum posters claim that Snapdragon has a feature to clock cores independently, supposedly unique feature. No idea about other SoCs..
Okay... well, then it totally makes sense to include a single-core mode into the OS. Should be enough for most stuff (as it should be about twice as fast as 1GHz Pandora), and even a sleeping core eats a bit of power.
Question is whether that can be changed on-the-fly or not.
Running PSX emulation uses 70% on one core, the other core doesn't do much (though Linux sometimes seems to move the tasks around, so the 70% are sometimes on one then on the other core). So if both cores are clocked higher even though just one core is being used actually, that would also increas power usage.
Probably, unless the other one can go to sleep. but even if there are small tasks for the other core, it has to do them at full power..
And as our Debian currently moves tasks between both cores around, the second one probably never really sleeps at all.
That's why big.Little thing was developed, and OMAP lacks it. But still I think the other core should end up spending most of it's time sleeping and ignoring the fast clock, otherwise you wouldn't see power usage difference between fully loading just one core and both of them.
Well, I've never loaded one CPU full. I played PSX, but that used between 60 - 75% on one core and I used stress to put stress on both CPUs.
I'll see if I can do more tests tonight. Is there a way in userspace to disable cpufreq and set the cpuspeed manually?
Working with fixed speeds should make measuring easier ;)
FYI we also currently have it like that on pandora, only the video overlay is accelerated on pandora and not on OMAP5. I wouldn't put too many expectetions here..
Hmm... but even on lower resolutions moving X Windows around seems a lot slower than on the Pandora, so something is different here
I forgot that there's NEON-optimized pixman library (which is responsible for window redrawing) on pandora, and all Debian packages are compiled without NEON because of that stupid Tegra2 SoC (Tegra2 had no NEON but was popular at it's time). So that's the disadvantage of Debian.. OTOH I don't know if those pixman optimizations were even ever merged to mainline pixman project, it might be only available as patches on Angstrom/OE only.
Oh... okay... so that means we really need to recompile the basic Debian packages ourselves and put them in our own repositories.
I can imagine that pixman using NEON uses less power as well, compared to having X do all the stuff without any optimizations.
For stuff like LibreOffice or FireFox it probably isn't much different compiling them with NEON or without, the powerusage shouldn't be too high anyways.
But at least for the basic libraries that are being used all the time.
Maybe enabling power management is something we should look into soon, so we can do some real life tests with power management enabled.
Powersaving on OMAPs is extremely complicated, you know yourself how long it took to get it working on pandora..
Yes - is it that much different on the OMAP5 than on the OMAP3? I thought TI stuff is pretty similar, so we might be able to use it on the OMAP5 with minor changes.
Yes it's different, it needs it's own code, even though a bit of it is shared on all newer OMAPs..
Okay, thanks for the information. Should we ask at the TI EVM boards if someone is working on power management features in the kernel?
On Wed, Feb 12, 2014 at 4:44 PM, Michael Mrozek EvilDragon@openpandora.org wrote:
Am Wed, 12 Feb 2014 16:11:52 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben: I'll see if I can do more tests tonight. Is there a way in userspace to disable cpufreq and set the cpuspeed manually?
Working with fixed speeds should make measuring easier ;)
Yes it's the same as on desktop, install cpufrequtils and change governors, performance governor should use max clock and userspace one should allow changing clock by writing to /sys/devices/system/cpu/cpu0/cpufreq/* files.
Yes it's different, it needs it's own code, even though a bit of it is shared on all newer OMAPs..
Okay, thanks for the information. Should we ask at the TI EVM boards if someone is working on power management features in the kernel?
You can try, but such questions are usually left unanswered..
Grazvydas
Am Wed, 12 Feb 2014 17:01:23 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
Working with fixed speeds should make measuring easier ;)
Yes it's the same as on desktop, install cpufrequtils and change governors, performance governor should use max clock and userspace one should allow changing clock by writing to /sys/devices/system/cpu/cpu0/cpufreq/* files.
Thanks, that works.
I did some testings, and it seems there really is something weird going on here, could probably need a lot of optimizations.
First, according to cpufreq-info -l, there are only three clock speeds available: 500MHz, 1GHz, 1,5GHz.
So the lowest setting the EVM should do would be 500MHz. That's quite high, but it seems it's fixed like that in the kernel.
Now for the interesting part: When I set the CPU speed manually, I can see an increase of the powerconsumption when going from 1GHz to 1,5GHz (about 0,1A with 5V) However, there's absolutely no difference between 500MHz and 1GHz.
Which is pretty weird.
I used powertop to do some more measurements. (Didn't think it would work, but it seems to do so on the BeagleBone: http://zeldor.biz/2012/11/beaglebone-optimize-power-consumption/)
When the CPU Speed is manually set to 1,5GHz, Frequency Stats show after a bit of waiting: 100%: 1,5GHz 0%: 1GHz 0%: 500MHz 0%: Idle
When switching the CPU speed to 1GHz, it shows: 0,1%: 1,5GHz 99,9%: 1GHz 0%: 500MHz 0%: Idle
And when switching the CPU speed to 500MHz: 0,1%: 1,5GHz 99,9%: 1GHz 0%: 500MHz 0%: Idle
Here are the measurements I did with various clock speeds with the multimeter:
Just sitting in X, doing nothing:
500MHz: 0,559 A 1GHz: 0,559 A 1,5GHz: 0,625 A
Using stress to get 100% CPU:
500MHz: 0,843 A 1GHz: 0,843 A 1,5GHz: 1,289 A
It looks like for some reason the clock won't go lower than 1GHz right now (both based on Powertop reports and the power consumption doesn't change)
Something seems broken here.
I wonder what the difference under full load for 500MHz should really be, compared to 1GHz. From 1GHz to 1,5GHz it's 350mA, so would that mean I would go down to approx. 0,5A when maxing both cores at 500MHz?
These values are with all features enabled on the PCB, with Ethernet, HDMI, USB keyboard and our devboard connected.
That wouldn't be that bad.
According to ARM, a CortexA9 should have a performance increase of about 50% compared to an A8 at same clock speed, and the A15 again a 50% increase to an A9.
This would mean... a 1,2GHz CortexA8 would be as fast as a 800MHz CortexA9, which would be as fast as a 533MHz CortexA15. Or am I getting something wrong? (so with 1,5GHz CortexA15 dualcore, it would be like 6 Pandoras...?)
If the SoC runs at 500MHz with both cores and would use 0,5A max. (including all that stuff on the EVM enabled), that would be 2 Pandoras with full load using 2,5W.
If that's true, then that's pretty good (would be 6,5h battery time). If we disable one core and set one to 500MHz, it would be like a 1GHz Pandora at 13h battery time under full load...
Anyways, I'll see if it's possible to increase the battery size a bit. With 1,5GHz, it really starts to eat battery, though I doubt under normal circumstances it would need full load...
A tool that might also help: https://github.com/omapconf/omapconf/wiki
ondemand-governor might also not be OMAP-optimized yet.
Seems like for OMAP, cpufreq_transition_latency should be set to 30ms. https://blueprints.launchpad.net/linaro-power-kernel/+spec/improve-cpufreq-o... http://lists.linaro.org/pipermail/linaro-dev/2010-November/001636.html
Right now, it's set to 300ms.
Am 13.02.2014 um 01:41 schrieb Michael Mrozek:
Am Wed, 12 Feb 2014 17:01:23 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
Working with fixed speeds should make measuring easier ;)
Yes it's the same as on desktop, install cpufrequtils and change governors, performance governor should use max clock and userspace one should allow changing clock by writing to /sys/devices/system/cpu/cpu0/cpufreq/* files.
Thanks, that works.
I did some testings, and it seems there really is something weird going on here, could probably need a lot of optimizations.
First, according to cpufreq-info -l, there are only three clock speeds available: 500MHz, 1GHz, 1,5GHz.
So the lowest setting the EVM should do would be 500MHz. That's quite high, but it seems it's fixed like that in the kernel.
Now for the interesting part: When I set the CPU speed manually, I can see an increase of the powerconsumption when going from 1GHz to 1,5GHz (about 0,1A with 5V) However, there's absolutely no difference between 500MHz and 1GHz.
Which is pretty weird.
Indeed.
I used powertop to do some more measurements. (Didn't think it would work, but it seems to do so on the BeagleBone: http://zeldor.biz/2012/11/beaglebone-optimize-power-consumption/)
When the CPU Speed is manually set to 1,5GHz, Frequency Stats show after a bit of waiting: 100%: 1,5GHz 0%: 1GHz 0%: 500MHz 0%: Idle
When switching the CPU speed to 1GHz, it shows: 0,1%: 1,5GHz 99,9%: 1GHz 0%: 500MHz 0%: Idle
And when switching the CPU speed to 500MHz: 0,1%: 1,5GHz 99,9%: 1GHz 0%: 500MHz 0%: Idle
Here are the measurements I did with various clock speeds with the multimeter:
Just sitting in X, doing nothing:
500MHz: 0,559 A 1GHz: 0,559 A 1,5GHz: 0,625 A
Using stress to get 100% CPU:
500MHz: 0,843 A 1GHz: 0,843 A 1,5GHz: 1,289 A
It looks like for some reason the clock won't go lower than 1GHz right now (both based on Powertop reports and the power consumption doesn't change)
That is quite unexpected.
Something seems broken here.
I wonder what the difference under full load for 500MHz should really be, compared to 1GHz. From 1GHz to 1,5GHz it's 350mA, so would that mean I would go down to approx. 0,5A when maxing both cores at 500MHz?
Not necessarily. It may be non-linear if going >1GHz.
These values are with all features enabled on the PCB, with Ethernet, HDMI, USB keyboard and our devboard connected.
That wouldn't be that bad.
According to ARM, a CortexA9 should have a performance increase of about 50% compared to an A8 at same clock speed, and the A15 again a 50% increase to an A9.
Ok, that fits with my rough figures of factor 8 for my FPU test.
This would mean... a 1,2GHz CortexA8 would be as fast as a 800MHz CortexA9, which would be as fast as a 533MHz CortexA15. Or am I getting something wrong? (so with 1,5GHz CortexA15 dualcore, it would be like 6 Pandoras...?)
If the SoC runs at 500MHz with both cores and would use 0,5A max. (including all that stuff on the EVM enabled), that would be 2 Pandoras with full load using 2,5W.
If that's true, then that's pretty good (would be 6,5h battery time). If we disable one core and set one to 500MHz, it would be like a 1GHz Pandora at 13h battery time under full load...
Anyways, I'll see if it's possible to increase the battery size a bit. With 1,5GHz, it really starts to eat battery, though I doubt under normal circumstances it would need full load...
A tool that might also help: https://github.com/omapconf/omapconf/wiki
Cool!
ondemand-governor might also not be OMAP-optimized yet.
Seems like for OMAP, cpufreq_transition_latency should be set to 30ms. https://blueprints.launchpad.net/linaro-power-kernel/+spec/improve-cpufreq-o... http://lists.linaro.org/pipermail/linaro-dev/2010-November/001636.html
Right now, it's set to 300ms.
Ok, this might keep the CPU in higher frequency for longer time than needed. Maybe even something as simple as the heartbeat daemon/task may keep it triggered...
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On Wed, Feb 12, 2014 at 2:20 AM, Michael Mrozek EvilDragon@openpandora.org wrote:
Okay, as we might be able to get other SoCs (Allwinner / Qualcomm) as well, I wanted to test out how much power consumption the OMAP5 has.
Not an easy task with our devboard... I did some quick measurements:
Without even being powered up, the devboard uses 0,21W... so I guess the EVM is not really optimized...? Nikolaus, any idea where these 0,21W come from? (maybe the serial USB connector?)
Well, as soon as I switch the EVM on, it eats up 2,25W (which is quite a lot!)
How is this measured, and at which point?
...
Do we know if we are even using power saving features of the SoC yet? (it doesn't sound like we do, as it seems weird to me that booting needs as much power as sitting around idling).
It doesn't look like it has full idle powersaving to me too, but on load it should be close to what we'll get I guess. The problem is we don't know how much various peripherals that we don't need draw on that board..
Grazvydas
Am 12.02.2014 um 14:07 schrieb Grazvydas Ignotas:
On Wed, Feb 12, 2014 at 2:20 AM, Michael Mrozek EvilDragon@openpandora.org wrote:
Okay, as we might be able to get other SoCs (Allwinner / Qualcomm) as well, I wanted to test out how much power consumption the OMAP5 has.
Not an easy task with our devboard... I did some quick measurements:
Without even being powered up, the devboard uses 0,21W... so I guess the EVM is not really optimized...? Nikolaus, any idea where these 0,21W come from? (maybe the serial USB connector?)
Well, as soon as I switch the EVM on, it eats up 2,25W (which is quite a lot!)
How is this measured, and at which point?
...
Do we know if we are even using power saving features of the SoC yet? (it doesn't sound like we do, as it seems weird to me that booting needs as much power as sitting around idling).
It doesn't look like it has full idle powersaving to me too, but on load it should be close to what we'll get I guess. The problem is we don't know how much various peripherals that we don't need draw on that board..
Yes, that is an important point. E.g. the Ethernet chip is likely enabled and drawing quite a lot of power without being used. And we would have to study the data sheet of the Ethernet chip to see if it goes <1mA if the Reset is activated. If yes, we can force a permanent chip reset by manipulating the PinMux and pullup/down. This is just a minor modification to the Device Tree file.
Am Wed, 12 Feb 2014 15:07:32 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
Without even being powered up, the devboard uses 0,21W... so I guess the EVM is not really optimized...? Nikolaus, any idea where these 0,21W come from? (maybe the serial USB connector?)
Well, as soon as I switch the EVM on, it eats up 2,25W (which is quite a lot!)
How is this measured, and at which point?
5V connector before EVM, so I'm measuring the FULL EVM with all peripherals, not just the SoC.
Do we know if we are even using power saving features of the SoC yet? (it doesn't sound like we do, as it seems weird to me that booting needs as much power as sitting around idling).
It doesn't look like it has full idle powersaving to me too, but on load it should be close to what we'll get I guess. The problem is we don't know how much various peripherals that we don't need draw on that board..
Yes, exactly. However, if we get power saving enabled for idle state, we can assume how much those components need approximately.
However, Nikolaus mentioned there are some resistors on the EVM where you can measure the SoC power consumption directly, I'll look into that as well.
Am Wed, 12 Feb 2014 15:07:32 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
Do we know if we are even using power saving features of the SoC yet? (it doesn't sound like we do, as it seems weird to me that booting needs as much power as sitting around idling).
It doesn't look like it has full idle powersaving to me too, but on load it should be close to what we'll get I guess.
One other thing: Enabling powersaving should also help on load. As mentioned, when running the PSX emulator, the power consumption on the Pandora was varying quite a lot.
Seems like the TI powersaving is really fast - as soon as not the full CPU is being used, it goes down immediately.
So unless someone codes a program that is PERMANENTLY under full load (can't really imagine that on the OMAP5, DreamCast, PSP and N64 would be even close to full usage), power saving should also improve the battery time on more demanding programs.
I'm not that scared about full load, but it makes me feel like there really isn't a use-case for us for even faster A15 processors - they will just need even more power when being fully used.
According to the internet, the Snapdragon 800 is capped to 2W on Smartphones and 4W on tablets... so they don't even use its full power here as well.
Okay, I just checked the NDA documents. While I didn't find anything about power consumption, I found some tests on the heat development of the OMAP5, and they lined out their scenario there (swpa195b.pdf)
They were running a tablet and the power consumption in their scenario was like this:
Total system Power: (Total System Power includes other components such as PMIC, display, etc.) 6034 mW
OMAP Power: 4128 mW
Memory: 200 mW
The OMAP reached a temperature of 90°C, according to their documents, proper cooling could cool it down about 20°C (which would match what I measured, about 70 - 74°C maximum temperature when fully stressing both cores).
We don't know if they were running at full power, but it probably makes sense if you want to test out heating.
So it seems with full power the OMAP5 uses about 4128mW (2W per core). Our EVM was using 6250mW, so 2000mW is everything else except the OMAP5 (memory, USB, HDMI, etc.)
In our case that would mean that right now idling around the SoC should use 250mW... which would be a lot better.
It seems like components really need quite some power. Disconnecting the HDMI monitor lowers power consumption of 200mW.
Disconnecting the HDMI monitor, the Pyra PCB and the USB keyboard lowers the total power consumption to less than 2W when idling.
Disabling these components will probably save quite a bit of power (it does in the Pandora).
Any easy way we can do that?
Anyways, I've sent the TI OMAP5 dev team an eMail about the power consumption, and whether they did any tests.
One of the devs (Arno) mentioned in August: "We are targeting to have the OMAP543x in the 2W when all the power features will be implemented."
I can't imagine he meant that it will use 2W when idling...
Am 07.02.2014 um 20:05 schrieb Dr. H. Nikolaus Schaller:
And that there is something in the programming sequence for the panel after power-on.
Most likely. I am starting to read register values as described in the Panel data sheet plus some more with description scattered around several places...
Currently I am adding some code to read all available registers - and if I do a mistake (register does not exist or has >1 byte contents I already get reasonable error messages).
It starts to look like that we have to send one or two more "standard" commands that are not included in the panel data sheet.
So still no backlight - but close.
If we had the official R63311 data sheet... But Renesas is Japanese and a little closed.
The one for the R61523 is similar so that I can learn a lot - but it is definitively not exactly the same command set.
Ah, I got it. I have found a data sheet from some Sharp LS059T1SX01 panel that also carries the R63311 chip inside and they have a programming sequence *including* backlight.
It turns out that one has to send *two* bytes for the set brightness command! And expect *two* bytes for the read command... Well, after knowing that I can find that information even in our data sheet.
Now I can read back some registers and the contents make sense. At least partially.
Although it still does not work (backlight also is black), I think this is already some success because it means that we can really program the panel.
Maybe I should add some sysfs nodes to be able to read/write arbitrary commands from user space for improved debugging. Instead of recompiling and rebooting the kernel each time.
Now it is time for a break and do other things...
BR, Nikolaus
Am Fri, 7 Feb 2014 21:58:44 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
But the programming sequence for the Sharp display should be different from the LG one, isn't it?
Or are you trying to find out how to program the RS?
Great success though, thanks :) And enjoy your well-deserved rest. :)
Am 07.02.2014 um 20:05 schrieb Dr. H. Nikolaus Schaller:
And that there is something in the programming sequence for the panel after power-on.
Most likely. I am starting to read register values as described in the Panel data sheet plus some more with description scattered around several places...
Currently I am adding some code to read all available registers - and if I do a mistake (register does not exist or has >1 byte contents I already get reasonable error messages).
It starts to look like that we have to send one or two more "standard" commands that are not included in the panel data sheet.
So still no backlight - but close.
If we had the official R63311 data sheet... But Renesas is Japanese and a little closed.
The one for the R61523 is similar so that I can learn a lot - but it is definitively not exactly the same command set.
Ah, I got it. I have found a data sheet from some Sharp LS059T1SX01 panel that also carries the R63311 chip inside and they have a programming sequence *including* backlight.
It turns out that one has to send *two* bytes for the set brightness command! And expect *two* bytes for the read command... Well, after knowing that I can find that information even in our data sheet.
Now I can read back some registers and the contents make sense. At least partially.
Although it still does not work (backlight also is black), I think this is already some success because it means that we can really program the panel.
Maybe I should add some sysfs nodes to be able to read/write arbitrary commands from user space for improved debugging. Instead of recompiling and rebooting the kernel each time.
Now it is time for a break and do other things...
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 07.02.2014 um 22:04 schrieb Michael Mrozek:
Am Fri, 7 Feb 2014 21:58:44 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
But the programming sequence for the Sharp display should be different from the LG one, isn't it?
Yes, it is not the same - but since I don't think that the panel manufacturer can modify the controller chip arbitrarily, I think the set of commands is defined by the chip and not the panel. Only some device ID or gamma curves may be programmable.
Or are you trying to find out how to program the RS?
Yes.
Great success though, thanks :) And enjoy your well-deserved rest. :)
Am 07.02.2014 um 20:05 schrieb Dr. H. Nikolaus Schaller:
And that there is something in the programming sequence for the panel after power-on.
Most likely. I am starting to read register values as described in the Panel data sheet plus some more with description scattered around several places...
Currently I am adding some code to read all available registers - and if I do a mistake (register does not exist or has >1 byte contents I already get reasonable error messages).
It starts to look like that we have to send one or two more "standard" commands that are not included in the panel data sheet.
So still no backlight - but close.
If we had the official R63311 data sheet... But Renesas is Japanese and a little closed.
The one for the R61523 is similar so that I can learn a lot - but it is definitively not exactly the same command set.
Ah, I got it. I have found a data sheet from some Sharp LS059T1SX01 panel that also carries the R63311 chip inside and they have a programming sequence *including* backlight.
It turns out that one has to send *two* bytes for the set brightness command! And expect *two* bytes for the read command... Well, after knowing that I can find that information even in our data sheet.
Now I can read back some registers and the contents make sense. At least partially.
Although it still does not work (backlight also is black), I think this is already some success because it means that we can really program the panel.
Maybe I should add some sysfs nodes to be able to read/write arbitrary commands from user space for improved debugging. Instead of recompiling and rebooting the kernel each time.
Now it is time for a break and do other things...
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel