Re: cpuidle status in mainline for Beagleboard xM
On 2 September 2011 19:14, Kevin Hilman khil...@ti.com wrote: javier Martin javier.mar...@vista-silicon.com writes: On 2 September 2011 08:05, Jarkko Nikula jarkko.nik...@bitmer.com wrote: Other usual things to check that display is off (echo 1 /sys/class/graphics/fb0/blank) and no cable to musb/otg port. Haven't tried myself with recent kernel but does EHCI and hub on XM let to idle cpu at all? At least on one board having on-board hub I had to disable or unload ehci module in order to hit the retention. I've checked that too and I've even disabled USB support in the kernel just to be sure. But still nothing: root@beagleboard:~# powertop -d -t 100 PowerTOP 1.12 (C) 2007, 2008 Intel Corporation Collecting data for 100 seconds Cn Avg residency C0 (cpu running) ( 0.0%) C0 58.5ms (100.0%) C1 0.0ms ( 0.0%) C2 0.0ms ( 0.0%) C3 0.0ms ( 0.0%) C4 0.0ms ( 0.0%) C5 0.0ms ( 0.0%) C6 0.0ms ( 0.0%) Even when CPU has been idle 100% of the time it doesn't hit any state deeper than C0. Did you allow the UARTs to idle: Yes I did: root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout [ 65.853820] omap_device: omap_uart.3: new worst case activate latency 0: 30517 [ 65.944366] omap_device: omap_uart.2: new worst case deactivate latency 0: 30517 # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4) echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout I just tested this using today's linux-omap master branch (+ merged v3.1-rc4 which includes a fix for a bootup problem.) I booted my Beagle XM with a busybox rootfs on MMC and it worked fine for me. I don't have powertop on the rootfs, but I manually dumped the sysfs files that powertop reads, so I can see the state times. After allowing the UARTs to idle, I see: # cd /sys/devices/system/cpu/cpu0 /sys/devices/system/cpu/cpu0/cpuidle # cat state?/time 43531831 8997 157215 0 3467925 0 0 OK, I've just tried with the same kernel as you did (linux-omap master + v3.1-rc4 merge) and I can't get any other state than 0: root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# cat state?/time 162570397 0 0 0 0 0 0 Just one question. Do you access the shell through UART? What I do is waiting for 20 seconds to allow the UART to suspend and then see state reports. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpuidle status in mainline for Beagleboard xM
On 2 September 2011 08:05, Jarkko Nikula jarkko.nik...@bitmer.com wrote: Other usual things to check that display is off (echo 1 /sys/class/graphics/fb0/blank) and no cable to musb/otg port. Haven't tried myself with recent kernel but does EHCI and hub on XM let to idle cpu at all? At least on one board having on-board hub I had to disable or unload ehci module in order to hit the retention. I've checked that too and I've even disabled USB support in the kernel just to be sure. But still nothing: root@beagleboard:~# powertop -d -t 100 PowerTOP 1.12 (C) 2007, 2008 Intel Corporation Collecting data for 100 seconds CnAvg residency C0 (cpu running)( 0.0%) C0 58.5ms (100.0%) C10.0ms ( 0.0%) C20.0ms ( 0.0%) C30.0ms ( 0.0%) C40.0ms ( 0.0%) C50.0ms ( 0.0%) C60.0ms ( 0.0%) Even when CPU has been idle 100% of the time it doesn't hit any state deeper than C0. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpuidle status in mainline for Beagleboard xM
Hi Kevin, thanks for your help. CPU is staying in C0 probably because UARTs are not being idled, so SoC cannot hit deeper idle states. Try the following at the command line to to enable UART idle timeouts, so the SoC can attempt idle after the timeout period # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4) echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout After 5 seconds of inactivity on the UARTs, you should see the SoC hitting deeper C-states. I've tried that but it still doesn't hit any C-state deeper than 0. I'll try the same test using your pm branch you pointed me out and post the results. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
tidspbridge: problems executing sample apps
Hi, we have a Beagleboard xM (DM3730) and we are currently working with stable kernel 2.6.39 and we have compiled the tisdpbridge in the staging directory. In order to test basic DSP functionality we are using userspace-dspbridge from git repository git://dev.omapzoom.org/pub/scm/tidspbridge/userspace-dspbridge.git and commit 9c64192758fd066d1a3f50867919e7aa21f04387 And the following version of needed packages are being used: bios_5_41_07_24 TI_CGT_C6000_6.1.17 xdctools_3_20_06_81 1- If I try prebuilt binaries (both for DSP side and userspace) I get an execution error: root@beagleboard:/dspbridge# ./ping.out DSP device detected !! DSPNode[ 30.530944] DSPTrace: PING: **PING_TI_create: retval = 0x0 ** [ 30.530975] PING: PING_TI_execute: Entered ... [ 30.530975] Create succeeded[ 30.545135] DSPTrace: PING: PING_TI_execute: Received ping from GPP: cmd = 0xbebe0001; cnt = 0x200596aa [ 30.545166] DSPNode_registerNotify succeeded DSPNode_run succeeded Ping: Id 1.00 Msg 0.00 Mem 15408.00 DSPNode_GetMessage failed: 0xffc2 Ping: Id 1.00 Msg 1.00 Mem 15408.00 DSPNode_GetMessage failed: 0xffc2 2- If I compile only MPU samples and use DSP prebuilt binaries it works fine. 3- If I compile both DSP side and MPU side samples it also gives an execution error: root@beagleboard:/dspbridge# ./cexec.out ddspbase_tiomap3430.dof64P DSP device detected !! [ 45.862640] proc_load: Processor Loaded ddspbase_tiomap3430.dof64P [ 45.876892] proc_start: dsp in running state DSPProcessor_Sta[ 45.881927] procwrap_detach: deprecated dspbridge ioctl rt succeeded. Hit any key to terminate cexec. root@beagleboard:/dspbridge# ./ping.out DSP device detec[ 64.484649] procwrap_detach: deprecated dspbridge ioctl ted !! DSPNode_Create failed: 0xffe3 In order to achieve option (3) I had to apply the attached patch to fix some build errors and I had to copy libstdc++.so.5 to /usr/lib32/ since I am on a 64bit machine http://mirror.ovh.net/ubuntu//pool/universe/g/gcc-3.3/libstdc++5_3.3.6-15ubuntu4_i386.deb Do you know what combination of DSP bios, TI CGT and xdctools is most suitable for using with tidspbridge in kernel 2.6.39? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com diff --git a/source/product.mak b/source/product.mak index 892faf5..1996366 100755 --- a/source/product.mak +++ b/source/product.mak @@ -13,12 +13,12 @@ # # DSP BIOS -SABIOS_VER = 5.33.04 -SABIOS_VER_2 = 5_33_04 +SABIOS_VER = 5.41.07.24 +SABIOS_VER_2 = 5_41_07_24 # CodeGen Tools CGT55_VER = 3.2.2 -CGT6X_VER = 6.0.7 +CGT6X_VER = 6.1.17 # Framework components FC_VER = 1_10_04 diff --git a/source/samplemakefile b/source/samplemakefile index 4d11610..ac9f772 100755 --- a/source/samplemakefile +++ b/source/samplemakefile @@ -83,8 +83,8 @@ BRIDGE_EXPORT_PACKAGES = dsp/ti/dspbridge/dsp/bridge_product SAMPLE_PACKAGES = samples/dsp -DLL_FILES=$(wildcard $(SAMPLE_PACKAGES)/*.dll64P)) -DOF_FILES=$(wildcard $(SAMPLE_PACKAGES)/*.dof64P)) +DLL_FILES=$(wildcard $(SAMPLE_PACKAGES)/*.dll64P) +DOF_FILES=$(wildcard $(SAMPLE_PACKAGES)/*.dof64P) .samples: .bridge_samples @@ -144,7 +144,7 @@ ifneq ($(DLL_FILES),) $(CP) -f $(DLL_FILES) $(TARGETDIR)/dspbridge/ endif ifneq ($(DOF_FILES),) - $(CP) -f $(DOF_FILES)/ $(TARGETDIR)/dspbridge/ + $(CP) -f $(DOF_FILES) $(TARGETDIR)/dspbridge/ endif #.execute_version_script: version.ksh $(VERSION_FILE) diff --git a/source/samples/dsp/ddspbase.tci b/source/samples/dsp/ddspbase.tci index 1746adc..d968cab 100755 --- a/source/samples/dsp/ddspbase.tci +++ b/source/samples/dsp/ddspbase.tci @@ -19,6 +19,8 @@ * */ +var chipType = environment[config.chipType]; + /* bridge default is 512, that's not enough sometimes */ var traceSize = 512;
Re: [PATCH v2 2/2] OMAP3BEAGLE: Add support for mt9p031 sensor driver.
On 22 May 2011 15:49, Igor Grinberg grinb...@compulab.co.il wrote:
Hi Javier,
linux-omap should be CC'ed - added.
In addition to Koen's comments, some comments below.
On 05/20/11 16:47, Javier Martin wrote:
isp.h file has to be included as a temporal measure
since clocks of the isp are not exposed yet.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 127
++-
1 files changed, 123 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..f52e6ae 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,15 +24,20 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
-
+#include linux/gpio.h
Why include this for second time?
Good catch, I'll fix it.
[snip]
@@ -309,6 +357,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+ * Power on camera interface - only on pre-production, not
+ * needed on production boards
+ */
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
Why not gpio_request_one()?
Just to follow the same approach as in the rest of the code.
Maybe a further patch could change all gpio_request() uses to
gpio_request_one().
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +508,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -463,15 +522,16 @@ static struct i2c_board_info __initdata
beagle_i2c_boardinfo[] = {
};
static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
- {
- I2C_BOARD_INFO(eeprom, 0x50),
- },
+ {
+ I2C_BOARD_INFO(eeprom, 0x50),
+ },
};
This part of the hunk is not related to the patch
and should be in a separate (cleanup) patch.
Sure, I'll fix it.
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+ omap_register_i2c_bus(2, 100, NULL, 0); /* Enable I2C2 for camera */
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
@@ -654,6 +714,60 @@ static void __init beagle_opp_init(void)
return;
}
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+ int ret;
+
+ ret = isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+ return 0;
+}
Why do you need ret variable here, if you always return zero?
You are right, it's not needed any longer.
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO(mt9p031, 0x48),
+ .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
static void __init omap3_beagle_init(void
Re: cpufreq support for the Beagleboard.
Hi, thank you for your fast answer. I've been testing the repository you pointed me and I found that only 300MHz and 600MHz can be selected in the Beagleboard xM. Couldn't we work until 1000MHz? Do you know what's left for those patches to enter mainline? Is anybody working on it? Thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap3: beaglexm: fix user button.
User push button in Beagleboard xM is 4 instead of 7.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 46d814a..abf87d1 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -615,6 +615,10 @@ static void __init omap3_beagle_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
+ /* xM version uses pin 4 instead of 7 for user button */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ gpio_buttons[0].gpio = 4;
+ }
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_serial_init();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
