headers
Woodruff, Richard | 13 Feb 2008 23:15
Picon
Favicon

A thing of power beauty cpu-idle on arm.

Hi,

A bit of fun is working is slowly working its way to the tree.  After a
couple teaks and a little c-state patch from Kevin Hilman it looks like
powertop will be able to live on ARM/OMAP3.

Our first pass of internal code has come together enough to have cpuidle
+ cpufreq running ++.  Hopefully, after some time and more work that
reference can be leveraged to see the same on kernel.org.  Lots of work
to do on that path...

If the png picture makes it, it can be seen given the load which was
running, all C-States have been touched and most P-States!  The P-State
picture only has ARM displayed, might be nice to see if Intel is open to
listing speed for the other asymmetric processors and the IO domain.
Given the background load residency isn't so great, but OFF mode is
being touched.

In the current definition:
	C0 - wfi
	C1 - wfi + dtick
	C2 - mpu-retention, core-active
	C3 - mpu-off, core-active
	C4 - mpu-ret, core-ret
	C5 - mpu-off, core-ret
	C6 - mpu-off, core-off  (0-volts)

Thanks to Adam Belay for cpuidle work!

Regards,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tony Lindgren | 16 Feb 2008 00:20
Gravatar

Re: A thing of power beauty cpu-idle on arm.

* Woodruff, Richard <r-woodruff2 <at> ti.com> [080213 14:16]:
> Hi,
> 
> A bit of fun is working is slowly working its way to the tree.  After a
> couple teaks and a little c-state patch from Kevin Hilman it looks like
> powertop will be able to live on ARM/OMAP3.
> 
> Our first pass of internal code has come together enough to have cpuidle
> + cpufreq running ++.  Hopefully, after some time and more work that
> reference can be leveraged to see the same on kernel.org.  Lots of work
> to do on that path...
> 
> If the png picture makes it, it can be seen given the load which was
> running, all C-States have been touched and most P-States!  The P-State
> picture only has ARM displayed, might be nice to see if Intel is open to
> listing speed for the other asymmetric processors and the IO domain.
> Given the background load residency isn't so great, but OFF mode is
> being touched.
> 
> In the current definition:
> 	C0 - wfi
> 	C1 - wfi + dtick
> 	C2 - mpu-retention, core-active
> 	C3 - mpu-off, core-active
> 	C4 - mpu-ret, core-ret
> 	C5 - mpu-off, core-ret
> 	C6 - mpu-off, core-off  (0-volts)
> 
> Thanks to Adam Belay for cpuidle work!
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pandita, Vikram | 20 Feb 2008 06:47
Picon
Favicon

OMAP34xx EHCI bulk OUT CRC16 complementing

USB EHCI/OHCI experts

On omap-git v2.6.25-rc2, TI OMAP34xx EHCI controller, we are seeing a strange behavior on a bulk OUT 512
byte transfer.

We can see through the CATC that the 512 byte goes out successfully but there are many Turnaround/Timeout
Errors and retries before the packet goes out successfully. 
The retries could range from 0 to 10 or more.

The error packets have 'CRC16 complemented' as per Section 8.6.4 page 234-235 that says for probably a data
under-run condition:
"An error for high-speed must be forced by taking the currently calculated CRC and complementing it before
transmitting it."

We have confirmed that our Memory (SDRAM) access have a much higher bandwidth available "not" to cause data
under-run condition.

Where in EHCI stack should I debug for this issue? 

I am checking: qh_append_tds()
Not sure how this "Dummy" qtd is implemented. Anything to do with this? 

Is there a way to slow-down the OUT transfers on EHCI if that helps in debugging? 

Regards
Permalink | Reply | 2 comments |
headers
David Brownell | 22 Feb 2008 23:07

Re: OMAP34xx EHCI bulk OUT CRC16 complementing

On Tuesday 19 February 2008, Pandita, Vikram wrote:
> USB EHCI/OHCI experts
> 
> On omap-git v2.6.25-rc2, TI OMAP34xx EHCI controller, we are seeing a
> strange behavior on a bulk OUT 512 byte transfer. 
> 
> We can see through the CATC that the 512 byte goes out successfully
> but there are many Turnaround/Timeout Errors and retries before the
> packet goes out successfully.   
> The retries could range from 0 to 10 or more.
> 
> The error packets have 'CRC16 complemented' as per Section 8.6.4
> page 234-235 that says for probably a data under-run condition: 
> "An error for high-speed must be forced by taking the currently
> calculated CRC and complementing it before transmitting it." 
> 
> We have confirmed that our Memory (SDRAM) access have a much higher
> bandwidth available "not" to cause data under-run condition. 
> 
> Where in EHCI stack should I debug for this issue? 

Doesn't sound like an EHCI driver issue.  I'd want to track
what's going on deeper inside the silicon than ARM instruction
set handling ... ;)

> Is there a way to slow-down the OUT transfers on EHCI if that
> helps in debugging?  

You could issue URBs with single packets.  If you're not using
the "usbtest" framework, you should start ... that command line
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Brownell | 25 Feb 2008 04:14

[patch 2.6.25-rc3] omap-keypad buildfix

Build fixes:

drivers/input/keyboard/omap-keypad.c: In function 'omap_kp_probe':
drivers/input/keyboard/omap-keypad.c:418: warning: 'row_idx' is used uninitialized in this function
drivers/input/keyboard/omap-keypad.c:421: warning: 'col_idx' is used uninitialized in this function

These variables are useful when cpu_is_omap24xx(), and otherwise just
for probe() cleanup.

Signed-off-by: David Brownell <dbrownell <at> users.sourceforge.net>
---
The OMAP tree has the same bug.

 drivers/input/keyboard/omap-keypad.c |    3 +++
 1 files changed, 3 insertions(+)

--- a/drivers/input/keyboard/omap-keypad.c	2008-02-24 18:50:32.000000000 -0800
+++ b/drivers/input/keyboard/omap-keypad.c	2008-02-24 19:10:17.000000000 -0800
 <at>  <at>  -352,6 +352,9  <at>  <at>  static int __init omap_kp_probe(struct p
 			}
 			omap_set_gpio_direction(row_gpios[row_idx], 1);
 		}
+	} else {
+		col_idx = 0;
+		row_idx = 0;
 	}

 	setup_timer(&omap_kp->timer, omap_kp_timer, (unsigned long)omap_kp);
-
To unsubscribe from this list: send the line "unsubscribe linux-input" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juha Kuikka | 27 Feb 2008 04:00
Picon

Problem in twl4030_gpio.c

Hi,

twl4030 gpio driver has a problem which causes the pull up/down registers to
be reset with every call to twl4030_request_gpio().

Below is a patch that fixes this.

--- twl4030_gpio.c.org  2008-02-26 18:52:57.000000000 -0800
+++ twl4030_gpio.c      2008-02-26 18:53:35.000000000 -0800
 <at>  <at>  -332,13 +332,13  <at>  <at> 
                        gpio_twl4030_write(REG_GPIO_CTRL,
                                        MASK_GPIO_CTRL_GPIO_ON);
                        ret = gpio_twl4030_write(REG_GPIO_SIH_CTRL, 0x00);
+                        ret =
+                            twl4030_i2c_write(TWL4030_MODULE_GPIO,
clear_pull,
+                                              REG_GPIOPUPDCTR1, 5);
                }
                if (!ret)
                        gpio_usage_count |= (0x1 << gpio);

-               ret =
-               twl4030_i2c_write(TWL4030_MODULE_GPIO, clear_pull,
-                               REG_GPIOPUPDCTR1, 5);
        }
        up(&gpio_sem);
        return ret;

 - Juha
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anil Sasidharan | 27 Feb 2008 10:46

Android porting onto OMAP2430

Hi,

        I've applied the android m5-r14 kernel patch (received from
 Raymond) to my 2.6.22 based kernel source and built a new kernel image.
 The system, dev, data directories are pulled out from the emulator
 (m5-r14 SDK release) and added into my current rootFS. The results of
 my experiments are given below:

 1. rootFS on NFS mount
 --------------------------------
 1. Once the device boots up completely and shows the console prompt,
 the following commands are issued.

 date -s 022711302008 (to set the system date) umask 000

 mount -t tmpfs tmpfs /tmp
 mount -t proc proc /proc
 mount -t sysfs sysfs /sys

 rm -rf /tmp/*
 chmod -R a+rw /data /tmp

 export ANDROID_ASSETS=/system/app
 export ANDROID_BOOTLOGO=1
 export ANDROID_DATA=/data
 export ANDROID_ROOT=/system
 export BOOTCLASSPATH=/system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/framework-tests.jar
 export DRM_CONTENT=/data/drm/content
 export EXTERNAL_STORAGE=/sdcard
 export IFS='
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dirk Behme | 27 Feb 2008 16:52

Don't use this list any more


 From time to time there are still some mails to this list, some CC, 
but some only to this list:

This list is outdated!

You should use new OMAP list linux-omap <at> vger.kernel.org

http://vger.kernel.org/vger-lists.html#linux-omap

and not post to

linux-omap-open-source <at> linux.omap.com

any more! And I think it is time to stop CC this list as well.

Hopefully this will be the last mail to this list ;)

Dirk
Permalink | Reply | 2 comments |
headers
Antti P Miettinen | 28 Feb 2008 13:15
Picon
Picon
Favicon

Re: Don't use this list any more

Dirk Behme <dirk.behme <at> googlemail.com> writes:
> You should use new OMAP list linux-omap <at> vger.kernel.org

I'd like to follow the list via gmane.org but I'm unsure about how the
mirroring should be arranged. I suppose the sensible thing would be
for the existing gmane.org group to start following the new list. But
importing the marc archive would not be sensible as the group already
has the traffic of the old list.

I asked Lars and Tony but did not receive any reply.

--

-- 
http://www.iki.fi/~ananaza/
Permalink | Reply | 1 comment |
headers
Tony Lindgren | 29 Feb 2008 14:35
Gravatar

Re: Don't use this list any more

* Antti P Miettinen <ananaza <at> iki.fi> [080228 04:21]:
> Dirk Behme <dirk.behme <at> googlemail.com> writes:
> > You should use new OMAP list linux-omap <at> vger.kernel.org
> 
> I'd like to follow the list via gmane.org but I'm unsure about how the
> mirroring should be arranged. I suppose the sensible thing would be
> for the existing gmane.org group to start following the new list. But
> importing the marc archive would not be sensible as the group already
> has the traffic of the old list.
> 
> I asked Lars and Tony but did not receive any reply.

Well I don't know if I can do anything about the gmane.org stuff..
Marc should have the old archives there at:

http://marc.info/?l=linux-omap

Tony
Permalink | Reply | 0 comments |

Gmane