Unknown L3 interrupt/error
I'm trying to bring up a custom OMAP4 board and I get this error as soon as the EHCI USB controller is initialized: WARNING: at /local/new_kernel/arch/arm/mach-omap2/omap_l3_noc.c:99 l3_interrupt_handler+0x114/0x174() L3 standard error: TARGET:ABE at address 0x0 Can someone enlighten me what this means and what might be causing it? That USB controller is working fine in U-Boot. n.b. I'm working from the Ubuntu 12.04 kernel sources git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git ti-ubuntu-3.4-1485.7 Thanks for any pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: [RFC/PATCH 0/3] OMAP3 I2C/SCCB support
On 2012-06-26 10:20, Laurent Pinchart wrote:
Hi Jean-Philippe,
On Tuesday 26 June 2012 16:49:35 jean-philippe francois wrote:
2012/6/26 Laurent Pinchartlaurent.pinch...@ideasonboard.com:
Hi everybody,
While trying to use an OV7725 camera sensor with an OMAP3 system I ran
into a couple of issues related to the sensor communication protocol.
Instead of using the obiquitous I2C protocol, Omnivision invited the SCCB
communication bus, very similar to I2C but different enough not to be
compatible.
I have been using omnivision sensor without being aware of this issue,
and without any i2c reliability issue either.
Here is typical code I use :
/* This function is used to read value from register for i2c client */
static int ov2710_read(struct i2c_client *client, unsigned short reg,
unsigned char *val)
{
int err = 0;
unsigned char outbuf[] = {(reg8)0xff, reg0xff};
According to the SCCB specification (or at least the version I've found)
register addresses are 8-bit. The OV2710 might just be I2C-compatible.
unsigned char inbuf[1];
struct i2c_msg msg[] = {
{ .addr = client-addr, .flags = 0, .buf = outbuf, .len = 2 },
{ .addr = client-addr, .flags = I2C_M_RD, .buf = inbuf, .len = 1 },
};
err = i2c_transfer(client-adapter, msg, 2);
/* error handling and pass by ref handling */
}
The ov772x driver uses i2c_smbus_write_byte_data() and
i2c_smbus_read_byte_data(). The later calls
i2c_smbus_xfer(client-adapter, client-addr, client-flags,
I2C_SMBUS_READ, I2C_SMBUS_BYTE_DATA,data);
which calls i2c_smbus_xfer_emulated() for hosts that don't support SMBus
transfers natively, and that's pretty much equivalent to your above code
(except for the 8/16 bit register address).
It might be a good idea to implement i2c_smbus_*-like functions for 16-bit
register addresses in the I2C core, they could be reused across drivers.
Is the point of this patch to avoid writing such functions again and again
in every ov driver ?
No, but that's a good idea as well :-)
What is solved in practice by this patch that is not solved by a regular i2c
transfer ?
The above code will not ignore acks/nacks and will not generate a stop
condition between the two messages. The SCCB specification states that
acks/nacks must be ignored and that a stop condition must be generated. The
OV7725 handles acks/nacks correctly, but chokes if no stop condition is
generated. The point of this patch set is to fix both problems (although the
acks/nacks issue might be theoretical only).
How does it choke? I've had success talking to the OV8820 using the
normal I2C driver as well.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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
MUSB problem
I'm running 3.3.0 on an OMAP DM3730, with SMSC75xx connected via the MUSB device. I get this error continually although the device (and network channel) seem happy: musb_ep_program 835: broken !rx_reinit, ep2 csr a200 What does it mean? How do I fix it (i.e. keep it from happening)? Note: disabling DMA isn't really an option as the whole point of the SMSC75xx is to get gigabit ethernet and I doubt that's possible without DMA :-) Thanks for any pointers/ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: MUSB problem
On 2012-04-25 06:19, Gary Thomas wrote: I'm running 3.3.0 on an OMAP DM3730, with SMSC75xx connected via the MUSB device. I get this error continually although the device (and network channel) seem happy: musb_ep_program 835: broken !rx_reinit, ep2 csr a200 What does it mean? How do I fix it (i.e. keep it from happening)? Note: disabling DMA isn't really an option as the whole point of the SMSC75xx is to get gigabit ethernet and I doubt that's possible without DMA :-) Thanks for any pointers/ideas Actually, I was too hasty saying that this worked even with this error. I can ping out from my board, but any higher level of traffic, e.g. SSH into the box, falls over :-( The problems vanish when I disable MUSB DMA. What gives? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: PM related performance degradation on OMAP3
majordomo info at http://vger.kernel.org/majordomo-info.html -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: PM related performance degradation on OMAP3
On 2012-04-12 08:14, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: On 2012-04-11 13:17, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: [...] I fear I'm seeing similar problems with 3.3. I have my board (similar to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network performance on 3.3. For example, if I use TFTP to download a large file (~35MB), I get this: 3.0: 42.5 sec 3.3: 625.0 sec That's a factor of 15 worse! This might not be the same problem. What is the NIC being used, and does it have GPIO interrupts? My board uses SMSC911x with GPIO interrupt signal. OK, then your problem is almost certainly solved by my GPIO triggering fix, and not related to Grazvytas' problem. If it's using GPIO interrupts, then you likely need this patch from mainline (v3.4-rc1) I tried to just pick up the patch you [sort of] quoted below, but had a hard time applying it to my kernel. I've tried to just pick up the latest files from the mainline kernel, but so far I've nothing that builds Oh, right. Sorry about that. Yeah, that patch actually has dependencies on other GPIO changes that were queued for v3.4 (and not in v3.3.) If you're on v3.3, just pull the branch below[1] which is based on v3.3-rc2. Pulling that into a v3.3 should build just fine. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/fixes/gpio This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. I am interested in having PM working as I'm designing a battery powered portable unit, so I need to keep pursuing this. Note: I noticed that when I built with CONFIG_PM off and no other changes, my EHCI USB didn't work properly. Should this be the case? Thanks again for your help -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: PM related performance degradation on OMAP3
On 2012-04-12 10:57, Kevin Hilman wrote: +Felipe for EHCI question Gary Thomasg...@mlbassoc.com writes: [...] This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. And does a CONFIG_PM=n kernel get you back to your v3.0 performance? Correct. I am interested in having PM working as I'm designing a battery powered portable unit, so I need to keep pursuing this. So do I. :) Note: I noticed that when I built with CONFIG_PM off and no other changes, my EHCI USB didn't work properly. Should this be the case? Probably not, but haven't tested EHCI USB. I've Cc'd Felipe to see if he has any ideas why EHCI wouldn't work with CONFIG_PM=n. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: PM related performance degradation on OMAP3
On 2012-04-12 12:08, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: On 2012-04-12 10:57, Kevin Hilman wrote: +Felipe for EHCI question Gary Thomasg...@mlbassoc.com writes: [...] This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. And does a CONFIG_PM=n kernel get you back to your v3.0 performance? Correct. OK, I just tried your TFTP experiment on a 3530/Overo board with the same smsc911x NIC that has GPIO interrupts, and I don't see much difference between a PM-enabled v3.0 and a PM-enabled v3.3. Are you TFTP'ing the file to an MMC filesystem?Can you try to a ramdisk[1]? If you're using MMC, it could be MMC driver changes since v3.0 that are actually causing your performance hit. I'm testing to a ramdisk, so we're on the same page. Could you send me your config file so I can compare? Maybe I have something dumb in my settings that aggravates things. Also, what's your performance on 3.4-rc2? The linux-media tree I started from is a bit post v3.3, so there might be something else causing this. In my experiment, I TFTP'd a 24Mb file to a ramdisk, to make sure no other drivers were invovled, and didn't see any major differences between v3.0, v3.3, and v3.3 CONFIG_PM disabled. Below are my results. As you can see, all the results seem to be pretty close to the same. This test was not on a controlled, isolated network, so the differences are probably explained by other network activity: - v3.0 vanilla: PM enabled, CPUidle enabled - Received 25362406 bytes in 35.5 seconds - Received 25362406 bytes in 44.9 seconds - Received 25362406 bytes in 49.0 seconds - Received 25362406 bytes in 36.2 seconds - Received 25362406 bytes in 56.3 seconds - Received 25362406 bytes in 65.2 seconds - Received 25362406 bytes in 37.0 seconds - v3.3: PM enabled, CPUidle enabled + GPIO fix (my for_3.4/fixes/gpio branch) + smsc911x regulator boot fix (Tony's omap/fix-smsc911x-regulator branch) - Received 25362406 bytes in 32.1 seconds - Received 25362406 bytes in 29.8 seconds - Received 25362406 bytes in 33.5 seconds - Received 25362406 bytes in 44.5 seconds - Received 25362406 bytes in 39.2 seconds - Received 25362406 bytes in 57.0 seconds - Received 25362406 bytes in 49.6 seconds - v3.3: CONFIG_PM=n + branches above + fix from Grazvydas for !CONFIG_PM case: [PATCH] ARM: OMAP: sram: fix BUG in dpll code for !PM case + disable CONFIG_OMAP_WATCHDOG which fails to boot when CONFIG_PM=y - Received 25362406 bytes in 34.1 seconds - Received 25362406 bytes in 33.9 seconds - Received 25362406 bytes in 34.9 seconds - Received 25362406 bytes in 37.8 seconds - Received 25362406 bytes in 40.0 seconds - Received 25362406 bytes in 37.6 seconds - Received 25362406 bytes in 34.4 seconds Kevin [1] simple steps to make a ramdisk mkfs.ext2 /dev/ram0 mkdir /tmp/rd mount /dev/ram0 /tmp/rd cd /tmp/rd then TFTP file here -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: PM related performance degradation on OMAP3
On 2012-04-12 16:03, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: On 2012-04-12 12:08, Kevin Hilman wrote: Gary Thomasg...@mlbassoc.com writes: On 2012-04-12 10:57, Kevin Hilman wrote: +Felipe for EHCI question Gary Thomasg...@mlbassoc.comwrites: [...] This worked a treat, thanks. My network performance is better now, but still not what it was. The same TFTP transfer now takes 71 seconds, so about 50% slower than on the 3.0 kernel. Applying the second [unnamed] patch (arch/arm/mach-omap2/cpuidle34xx.c) made no difference. And does a CONFIG_PM=n kernel get you back to your v3.0 performance? Correct. OK, I just tried your TFTP experiment on a 3530/Overo board with the same smsc911x NIC that has GPIO interrupts, and I don't see much difference between a PM-enabled v3.0 and a PM-enabled v3.3. Are you TFTP'ing the file to an MMC filesystem?Can you try to a ramdisk[1]? If you're using MMC, it could be MMC driver changes since v3.0 that are actually causing your performance hit. I'm testing to a ramdisk, so we're on the same page. Could you send me your config file so I can compare? Maybe I have something dumb in my settings that aggravates things. Below is the Kconfig snippet[1] I append to a default omap2plus_defconfig to enable CPUidle, CPUfreq and some debug. Rebuild with that appended and these settings override the default ones. I used omap2plus_defcnfig plus this snippit for v3.0, v3.3 and v3.4-rc2 tests. Also, what's your performance on 3.4-rc2? The linux-media tree I started from is a bit post v3.3, so there might be something else causing this. I just tried with vanilla v3.4-rc2, and I see basically the same results. Between 35 and 50 seconds for the 24Mb file transfer, which is similar to the v3.0 and v3.3 results. Kevin [1] CONFIG_CPU_IDLE=y CONFIG_PM_ADVANCED_DEBUG=y CONFIG_PM_SLEEP_ADVANCED_DEBUG=y CONFIG_PM_GENERIC_DOMAINS=y CONFIG_OMAP_SMARTREFLEX=y CONFIG_OMAP_SMARTREFLEX_CLASS3=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_ARM_OMAP2PLUS_CPUFREQ=y CONFIG_REGULATOR_OMAP_SMPS=y CONFIG_DEBUG_LL=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_USER=y CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_SECTION_MISMATCH=y These settings made no difference. I just reverified my results to xfer a 39MB file to ramdisk: 3.0 + PM = 39sec 3.3 + PM = 70sec 3.3 - PM = 48sec so it's not quite the same as 3.0 was, but closer. BTW, your results normalized to mine would be 3.3 + PM = 56sec I wish I knew why I'm seeing a big difference between +PM/-PM and you don't. Is there some way to compare your source tree (the one you built for v3.3) and mine? I'm not very good with GIT so I'm not quite sure how to do it. Sorry for being so much trouble, I'm just in search of all the performance I can get out of my system :-) Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: PM related performance degradation on OMAP3
On 2012-04-06 16:50, Grazvydas Ignotas wrote: Hello, I'm DMA seeing performance loss related to CONFIG_PM on OMAP3. # CONFIG_PM is set: echo 3 /proc/sys/vm/drop_caches # file copy from NAND (using NAND driver in DMA mode) dd if=/mnt/tmp/a of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 9.088714 seconds, 3.5MB/s # file read from SD (hsmmc uses DMA) dd if=/dev/mmcblk0 of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 2.065460 seconds, 15.5MB/s # CONFIG_PM not set: # NAND dd if=/mnt/tmp/a of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 5.653534 seconds, 5.7MB/s # SD dd if=/dev/mmcblk0 of=/dev/null bs=1M count=32 33554432 bytes (32.0MB) copied, 1.919007 seconds, 16.7MB/s While SD card performance loss is not that bad (~7%), NAND one is worrying (~39%). I've tried disabling/enabling CONFIG_CPU_IDLE, also cpuidle states over sysfs, it did not have any significant effect. Is there something else to try? I'm guessing this is caused by CPU wakeup latency to service DMA interrupts? I've noticed that if I keep CPU busy, the loss is reduced almost completely. Talking about cpuidle, what's the difference between C1 and C2 states? They look mostly the same. Then there is omap3_do_wfi, it seems to be unconditionally putting SDRC on self-refresh, would it make sense to just do wfi in higher power states, like OMAP4 seems to be doing? I fear I'm seeing similar problems with 3.3. I have my board (similar to the BeagleBoard) ported to 3.0 and 3.3. I'm seeing terrible network performance on 3.3. For example, if I use TFTP to download a large file (~35MB), I get this: 3.0: 42.5 sec 3.3: 625.0 sec That's a factor of 15 worse! I'd like to try building without CONFIG_PM, but when I disabled this, my kernel fails to come up. Can someone point me to the magic to build without CONFIG_PM, or possibly send me a working config file? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: PM related performance degradation on OMAP3
On 2012-04-11 11:23, Grazvydas Ignotas wrote: On Wed, Apr 11, 2012 at 5:59 PM, Gary Thomasg...@mlbassoc.com wrote: I'd like to try building without CONFIG_PM, but when I disabled this, my kernel fails to come up. Can someone point me to the magic to build without CONFIG_PM, or possibly send me a working config file? You probably need this patch: http://marc.info/?l=linux-omapm=133374930011086w=2 If it still won't boot, you'll need to enable earlyprintk both in .config and as kernel argument to see where it dies. That does help, but there are lots of tracebacks like these: [0.588500] [ cut here ] [0.588531] WARNING: at drivers/video/omap2/dss/dispc.c:404 dss_driver_probe+0x44/0xd8() [0.588562] Modules linked in: [0.588592] [c0012204] (unwind_backtrace+0x0/0xf8) from [c002b81c] (warn_slowpath_common+0x4c/0x64) [0.588623] [c002b81c] (warn_slowpath_common+0x4c/0x64) from [c002b850] (warn_slowpath_null+0x1c/0x24) [0.588623] [c002b850] (warn_slowpath_null+0x1c/0x24) from [c022609c] (dss_driver_probe+0x44/0xd8) [0.588653] [c022609c] (dss_driver_probe+0x44/0xd8) from [c0273e10] (driver_probe_device+0x70/0x1e4) [0.588684] [c0273e10] (driver_probe_device+0x70/0x1e4) from [c0274018] (__driver_attach+0x94/0x98) [0.588714] [c0274018] (__driver_attach+0x94/0x98) from [c027270c] (bus_for_each_dev+0x50/0x7c) [0.588745] [c027270c] (bus_for_each_dev+0x50/0x7c) from [c0273664] (bus_add_driver+0x184/0x244) [0.588775] [c0273664] (bus_add_driver+0x184/0x244) from [c02742bc] (driver_register+0x78/0x12c) [0.588775] [c02742bc] (driver_register+0x78/0x12c) from [c00085a0] (do_one_initcall+0x34/0x178) [0.588806] [c00085a0] (do_one_initcall+0x34/0x178) from [c061d7dc] (kernel_init+0x78/0x114) [0.588836] [c061d7dc] (kernel_init+0x78/0x114) from [c000e0d0] (kernel_thread_exit+0x0/0x8) [0.588867] ---[ end trace 1b75b31a2719ed24 ]--- I also had to disable the watchdog to get it up. That said, with CONFIG_PM disabled, my network performance is back to what it was in 3.0 :-) Note: I also had CONFIG_PM disabled in that kernel build, so I don't know for sure what the performance might be with that version if it were enabled. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
OMAP3530 with no TWL4030 power controller
I have an OMAP3530 (DM3730) board which uses a very simple power controller (TPS65910A1). This controller does not support many of the power supplies, etc, that are common on the TWL4030 and similar devices. I'm using Linux 3.0. How can I remove the reliance on the TWL devices? Simply disabling PM in my configuration isn't enough - that generates a bunch of undefined references. Also, there are many places where power supply stuff is accessed, outside of PM, in particular DSS2 which has a terrible time. Here's what I get when I disabled PM and REGULATOR support: arch/arm/mach-omap2/built-in.o: In function `omap_set_pwrdm_state': /local/linux-3.0/arch/arm/mach-omap2/pm.c:122: undefined reference to `pwrdm_read_next_pwrst' /local/linux-3.0/arch/arm/mach-omap2/pm.c:126: undefined reference to `pwrdm_read_pwrst' /local/linux-3.0/arch/arm/mach-omap2/pm.c:127: undefined reference to `pwrdm_read_pwrst' /local/linux-3.0/arch/arm/mach-omap2/pm.c:133: undefined reference to `pwrdm_wait_transition' /local/linux-3.0/arch/arm/mach-omap2/pm.c:138: undefined reference to `pwrdm_set_next_pwrst' /local/linux-3.0/arch/arm/mach-omap2/pm.c:153: undefined reference to `pwrdm_set_lowpwrstchange' /local/linux-3.0/arch/arm/mach-omap2/pm.c:159: undefined reference to `pwrdm_wait_transition' /local/linux-3.0/arch/arm/mach-omap2/pm.c:160: undefined reference to `pwrdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': /local/linux-3.0/arch/arm/mach-omap2/omap_hwmod.c:2638: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `_clkdm_clk_hwmod_disable': /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:895: undefined reference to `pwrdm_clkdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `clkdm_allow_idle': /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:786: undefined reference to `pwrdm_clkdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `_clkdm_clk_hwmod_enable': /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:869: undefined reference to `pwrdm_wait_transition' /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:870: undefined reference to `pwrdm_clkdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `_clkdm_register': /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:79: undefined reference to `pwrdm_lookup' /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:93: undefined reference to `pwrdm_add_clkdm' arch/arm/mach-omap2/built-in.o: In function `omap2_clk_disable_unused': /local/linux-3.0/arch/arm/mach-omap2/clock.c:442: undefined reference to `pwrdm_clkdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_infrastructure': /local/linux-3.0/arch/arm/mach-omap2/io.c:355: undefined reference to `omap3xxx_voltagedomains_init' /local/linux-3.0/arch/arm/mach-omap2/io.c:356: undefined reference to `omap3xxx_powerdomains_init' Any ideas? I'd like to keep my changes to the kernel to a minimum, -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP3530 with no TWL4030 power controller
On 2012-02-06 16:45, Tony Lindgren wrote: * Gary Thomasg...@mlbassoc.com [120206 09:14]: I have an OMAP3530 (DM3730) board which uses a very simple power controller (TPS65910A1). This controller does not support many of the power supplies, etc, that are common on the TWL4030 and similar devices. I'm using Linux 3.0. How can I remove the reliance on the TWL devices? Simply disabling PM in my configuration isn't enough - that generates a bunch of undefined references. Also, there are many places where power supply stuff is accessed, outside of PM, in particular DSS2 which has a terrible time. Here's what I get when I disabled PM and REGULATOR support: Yes it should be possible to support other PMIC other than TWL chips too.. What you're seeing is a bug. This will be a bit more of a change than just another PMIC since this device isn't much of a power manager (other than at the very lowest level to handle power up sequencing, etc). It's good to hear that it _should_ work and I look forward to ideas on how to _make_ it work. For now, I've left PM and REGULATOR enabled so I can at least build the kernel and with just a few changes, I can get the kernel to boot to a prompt. I do need to work out the uglyness of what I've had to do though :-) Thanks arch/arm/mach-omap2/built-in.o: In function `omap_set_pwrdm_state': /local/linux-3.0/arch/arm/mach-omap2/pm.c:122: undefined reference to `pwrdm_read_next_pwrst' /local/linux-3.0/arch/arm/mach-omap2/pm.c:126: undefined reference to `pwrdm_read_pwrst' /local/linux-3.0/arch/arm/mach-omap2/pm.c:127: undefined reference to `pwrdm_read_pwrst' /local/linux-3.0/arch/arm/mach-omap2/pm.c:133: undefined reference to `pwrdm_wait_transition' /local/linux-3.0/arch/arm/mach-omap2/pm.c:138: undefined reference to `pwrdm_set_next_pwrst' /local/linux-3.0/arch/arm/mach-omap2/pm.c:153: undefined reference to `pwrdm_set_lowpwrstchange' /local/linux-3.0/arch/arm/mach-omap2/pm.c:159: undefined reference to `pwrdm_wait_transition' /local/linux-3.0/arch/arm/mach-omap2/pm.c:160: undefined reference to `pwrdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': /local/linux-3.0/arch/arm/mach-omap2/omap_hwmod.c:2638: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `_clkdm_clk_hwmod_disable': /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:895: undefined reference to `pwrdm_clkdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `clkdm_allow_idle': /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:786: undefined reference to `pwrdm_clkdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `_clkdm_clk_hwmod_enable': /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:869: undefined reference to `pwrdm_wait_transition' /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:870: undefined reference to `pwrdm_clkdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `_clkdm_register': /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:79: undefined reference to `pwrdm_lookup' /local/linux-3.0/arch/arm/mach-omap2/clockdomain.c:93: undefined reference to `pwrdm_add_clkdm' arch/arm/mach-omap2/built-in.o: In function `omap2_clk_disable_unused': /local/linux-3.0/arch/arm/mach-omap2/clock.c:442: undefined reference to `pwrdm_clkdm_state_switch' arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_infrastructure': /local/linux-3.0/arch/arm/mach-omap2/io.c:355: undefined reference to `omap3xxx_voltagedomains_init' /local/linux-3.0/arch/arm/mach-omap2/io.c:356: undefined reference to `omap3xxx_powerdomains_init' Any ideas? I'd like to keep my changes to the kernel to a minimum, Sounds like there should be empty functions for the prdm_* functions in this case. Kevin might have some patches to fix this already. Regards, Tony -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP3530 vs DM3730
On 2012-01-25 04:07, Tomi Valkeinen wrote:
On Mon, 2012-01-23 at 06:46 -0700, Gary Thomas wrote:
On 2012-01-22 22:06, Hiremath, Vaibhav wrote:
On Sat, Jan 21, 2012 at 21:46:38, Gary Thomas wrote:
I'm running the public 3.0 kernel on my boards. I have some boards
which can have either OMAP3530 or DM3730 (newer boards have the
newer part, but everything else is the same).
On the OMAP3530, I can enable the graphics overlay on the TV (S-Video)
output via the attached script. On the DM3730 boards, this crashes
the kernel hard :-(
Can you share the kernel crash log here?
Sadly, no, as it just locks up tight. At this point, I can only
reset manually. I've tried sifting through the dmesg log (_log_buf)
in U-Boot, but I don't see any tell-tale trace of why it crashes.
Further investigation shows that it's not really a problem between 3530 and
3730, sorry. I thought I had a 3530 system where it worked, but trying it
again today, it also fails. It seems to always fail when I enable fb2 as an
overlay using the TV as the manager.
I know this worked as far back as 2.6.28 and it works again in 3.2. I've
isolated where the kernel fails to the function dispc_pclk_rate(). This
function is quite different in 3.2 than 3.0, so I back-stitched it like
this:
unsigned long dispc_pclk_rate(enum omap_channel channel)
{
unsigned long r;
if (dispc_mgr_is_lcd(channel)) {
int pcd;
u32 l;
l = dispc_read_reg(DISPC_DIVISORo(channel));
pcd = FLD_GET(l, 7, 0);
r = dispc_lclk_rate(channel);
return r / pcd;
} else {
unsigned long venc_get_pixel_clock(void);
return venc_get_pixel_clock();
}
}
I think this commit fixes the crash:
c3dc6a7afb47735b82a4c0061e814454a649dbfc
Your changes above seems to be ok for omap3.
The kernel no longer crashes hard, but now I get these error messages
printed when I enable the overlay:
omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
omapdss DISPC error: GO bit not down for channel 1
omapdss DISPC error: VID2_FIFO_UNDERFLOW, disabling VID2
omapdss DISPC error: SYNC_LOST_DIGIT, disabling TV
So does everything work if you use the LCD? And the problems only appear
when you enable the tv-output?
You could try a bit more step-by-step approach in your script. First
enable GFX overlay on the LCD, and resize it so that it fits to both LCD
and TV. See that it works ok. Then enable the TV-out. Then move the GFX
overlay to the TV. etc.
Also, if you have your test setup working on newer kernel, and it
doesn't work on older, you could get dumps of the dss registers and
compare those. (debugfs/omapdss/dispc and venc).
Hmm. Actually, your script is missing something: it doesn't set the
input_size, i.e. the framebuffer size for fb2. You should set it before
enabling the overlay (fbset -xres $w -vxres $w -yres $h -vyres $h).
I haven't tested tv-out for a while, but I could give it a try on
BeagleBoard. Although I don't have an s-video cable, but I guess it's
enough if I don't see the underflows =).
Thanks, I played around with this a bit and found an error in the
script I was running. I have some systems which have only TV, so
their kernels only expose one display(*). My other systems have both
LCD and TV. I was trying the [TV only] script on a system with both
which led to the underflow errors. When I use the right script on
the right machine, it's working fine.
Sorry for the noise
(*) The choice to expose only valid displays was done to minimize the
possible confusion for our [less sophisticated] users.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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: OMAP3530 vs DM3730
On 2012-01-22 22:06, Hiremath, Vaibhav wrote:
On Sat, Jan 21, 2012 at 21:46:38, Gary Thomas wrote:
I'm running the public 3.0 kernel on my boards. I have some boards
which can have either OMAP3530 or DM3730 (newer boards have the
newer part, but everything else is the same).
On the OMAP3530, I can enable the graphics overlay on the TV (S-Video)
output via the attached script. On the DM3730 boards, this crashes
the kernel hard :-(
Can you share the kernel crash log here?
Sadly, no, as it just locks up tight. At this point, I can only
reset manually. I've tried sifting through the dmesg log (_log_buf)
in U-Boot, but I don't see any tell-tale trace of why it crashes.
Further investigation shows that it's not really a problem between 3530 and
3730, sorry. I thought I had a 3530 system where it worked, but trying it
again today, it also fails. It seems to always fail when I enable fb2 as an
overlay using the TV as the manager.
I know this worked as far back as 2.6.28 and it works again in 3.2. I've
isolated where the kernel fails to the function dispc_pclk_rate(). This
function is quite different in 3.2 than 3.0, so I back-stitched it like
this:
unsigned long dispc_pclk_rate(enum omap_channel channel)
{
unsigned long r;
if (dispc_mgr_is_lcd(channel)) {
int pcd;
u32 l;
l = dispc_read_reg(DISPC_DIVISORo(channel));
pcd = FLD_GET(l, 7, 0);
r = dispc_lclk_rate(channel);
return r / pcd;
} else {
unsigned long venc_get_pixel_clock(void);
return venc_get_pixel_clock();
}
}
The kernel no longer crashes hard, but now I get these error messages
printed when I enable the overlay:
omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
omapdss DISPC error: GO bit not down for channel 1
omapdss DISPC error: VID2_FIFO_UNDERFLOW, disabling VID2
omapdss DISPC error: SYNC_LOST_DIGIT, disabling TV
Is there any hope of getting this operation to work in 3.0?
This same operation seems to be fixed on the 3.2 (public) kernel, but
it's difficult for me to upgrade to that kernel for some other reasons.
Does anyone have an idea why this might happen? where to look to
isolate the bug(s)?
I tried to back-port the 3.2 DSS code into my 3.0 kernel, but my
simple attempt was pretty much a failure... If I can, I'd like to
figure out how to just fix the 3.0 code, rather than the full-scale
import of the 3.2 code.
Thanks for any ideas/pointers
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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
DSS: OMAP3530 vs DM3730
I'm running the public 3.0 kernel on my boards. I have some boards
which can have either OMAP3530 or DM3730 (newer boards have the
newer part, but everything else is the same).
On the OMAP3530, I can enable the graphics overlay on the TV (S-Video)
output via the attached script. On the DM3730 boards, this crashes
the kernel hard :-(
This same operation seems to be fixed on the 3.2 (public) kernel, but
it's difficult for me to upgrade to that kernel for some other reasons.
Does anyone have an idea why this might happen? where to look to
isolate the bug(s)?
I tried to back-port the 3.2 DSS code into my 3.0 kernel, but my
simple attempt was pretty much a failure... If I can, I'd like to
figure out how to just fix the 3.0 code, rather than the full-scale
import of the 3.2 code.
Thanks for any ideas/pointers
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
#! /bin/sh
#
# This script will put the TV (S-Video) into graphics mode,
# mapped onto /dev/fb2
#
ovl0=/sys/devices/platform/omapdss/overlay0
ovl1=/sys/devices/platform/omapdss/overlay1
ovl2=/sys/devices/platform/omapdss/overlay2
mgr0=/sys/devices/platform/omapdss/manager0
mgr1=/sys/devices/platform/omapdss/manager1
lcd=/sys/devices/platform/omapdss/display0
tv=/sys/devices/platform/omapdss/display1
fb0=/sys/class/graphics/fb0
fb1=/sys/class/graphics/fb1
fb2=/sys/class/graphics/fb2
#MODE=${MODE:-ntsc}
MODE=${MODE:-pal}
echo 0 $tv/enabled
echo ${MODE} $tv/timings
w=`cat $tv/timings | cut -d , -f 2 | cut -d / -f 1`
h=`cat $tv/timings | cut -d , -f 3 | cut -d / -f 1`
echo ... Setting ${MODE} mode, Width = ${w}, Height = ${h}
echo 0 $ovl2/enabled
echo 2 $fb2/overlays
echo $w,$h $ovl2/output_size
echo tv $ovl2/manager
mem=$((w*h*4))
echo $mem $fb2/size
echo 1 $ovl2/enabled
echo 1 $tv/enabled
fbset -fb /dev/fb2 -nonstd 1
OMAP3 DSS2 - VENC timings
I'm running a frame buffer console on a TV device via the VENC. The video timings don't see to be quite right as Tux is about 1/2 off the screen - both directions, i.e. his head and right side have been cut off as they are outside the viewable area. Also, when I send data to the device (via /dev/tty1) which has 90x35 characters, I lose 4 characters on each end of every line. Is there something I can do about this? I've looked at the timings in drivers/video/omap2/dss/venc.c Also, how can I select NTSC vs PAL setups via the command line? I have only the one video device VENC. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
sys_clkout2
What's the best way to enable sys_clkout2 (DM3730, latest kernel)? I've managed to set it up properly and it runs in U-Boot, but the kernel is disabling it. It's a bit of a tangle trying to figure out not only what piece of code is undoing my work, but how to get the clock to keep running. I want the clkout_cntrl register set to 0x8a, so any guidance on how to make this happen would be greatly appreciated. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: sys_clkout2
On 2011-12-13 14:56, Paul Walmsley wrote: On Tue, 13 Dec 2011, Gary Thomas wrote: What's the best way to enable sys_clkout2 (DM3730, latest kernel)? I've managed to set it up properly and it runs in U-Boot, but the kernel is disabling it. It's a bit of a tangle trying to figure out not only what piece of code is undoing my work, but how to get the clock to keep running. It's probably getting disabled by omap2_clk_disable_unused() in mach-omap2/clock.c, which runs at the end of kernel init. I want the clkout_cntrl register set to 0x8a, so any guidance on how to make this happen would be greatly appreciated. I presume you have some external device that relies on sys_clkout2 for its clock input? Precisely. Do I need to do anything special to control how the clock is configured, e.g. div src settings? If the device has a Linux driver associated with it, the clean way to fix it would be to add a clkdev line for it into mach-omap2/clock3xxx_data.c. Something like CLK(devname,fck,sys_clkout2, CK_3XXX), where devname is the name of your device. Then add some code into that driver to enable and disable the clock as needed. Something like ... struct clk *c; c = clk_get(dev_name(dev), fck); WARN(IS_ERR(c), cannot clk_get() device functional clock); clk_enable(c); ... and then clk_disable() it later in your driver when you don't need it. If you don't have a driver, you can hack a quick one up that just deals with the clock, and add it to your board file. Or if you just want a dirty hack, you can probably get away with just adding the ENABLE_ON_INIT flag to the sys_clkout2 .flags field in mach-omap2/clock3xxx_data.c. Thanks, I'll give this a try when I have eyes on the hardware (Wednesday) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: [PATCH v2 0/5] OMAP3EVM: Add support for MT9T111 sensor
On 2011-09-27 07:40, Deepthy Ravi wrote: This patchset -adds support for MT9T111 sensor on omap3evm. Currently the sensor driver supports only VGA resolution. -enables MT9T111 sensor in omap2plus_defconfig. This is dependent on the following patchset http://www.spinics.net/lists/linux-media/msg37270.html which adds YUYV input support for OMAP3ISP. And is applied on top of rc1-for-3.2 of gliakhovetski/v4l-dvb.git Why not use the same base as Lennart? The set is based on http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-omap3isp-next --- Changes in v2: As per the discussion here, https://lkml.org/lkml/2011/9/20/280 the existing mt9t112 driver is reused for adding support for mt9t111 sensor. Deepthy Ravi (3): [media] v4l: Add support for mt9t111 sensor driver ispccdc: Configure CCDC_SYN_MODE register omap2plus_defconfig: Enable omap3isp and MT9T111 sensor drivers Vaibhav Hiremath (2): omap3evm: Enable regulators for camera interface omap3evm: Add Camera board init/hookup file arch/arm/configs/omap2plus_defconfig|9 + arch/arm/mach-omap2/Makefile|5 + arch/arm/mach-omap2/board-omap3evm-camera.c | 185 arch/arm/mach-omap2/board-omap3evm.c| 26 + drivers/media/video/Kconfig |7 + drivers/media/video/Makefile|1 + drivers/media/video/mt9t111_reg.h | 1367 +++ drivers/media/video/mt9t112.c | 320 ++- drivers/media/video/omap3isp/ispccdc.c | 11 +- include/media/mt9t111.h | 45 + 10 files changed, 1937 insertions(+), 39 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c create mode 100644 drivers/media/video/mt9t111_reg.h create mode 100644 include/media/mt9t111.h -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
On 2011-09-27 16:31, Mauro Carvalho Chehab wrote: Em 19-09-2011 12:31, Hiremath, Vaibhav escreveu: -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Friday, September 16, 2011 6:36 PM To: Ravi, Deepthy Cc: linux-me...@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org; mche...@infradead.org; g.liakhovet...@gmx.de; Hiremath, Vaibhav Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl Hi Deepthy, On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote: On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote: On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote: From: Vaibhav Hiremathhvaib...@ti.com In order to support TVP5146 (for that matter any video decoder), it is important to support G/S/ENUM_STD ioctl on /dev/videoX device node. Why so ? Shouldn't it be queried on the subdev output pad directly ? Because standard v4l2 application for analog devices will call these std ioctls on the streaming device node. So it's done on /dev/video to make the existing apllication work. Existing applications can't work with the OMAP3 ISP (and similar complex embedded devices) without userspace support anyway, either in the form of a GStreamer element or a libv4l plugin. I still believe that analog video standard operations should be added to the subdev pad operations and exposed through subdev device nodes, exactly as done with formats. [Hiremath, Vaibhav] Laurent, I completely agree with your point that, existing application will not work without setting links properly. But I believe the assumption here is, media-controller should set the links (along with pad formants) and all existing application should work as is. Isn't it? Yes. The way it is being done currently is, set the format at the pad level which is same as analog standard resolution and use existing application for streaming... Yes. I am ok, if we add s/g/enum_std api support at sub-dev level but this should also be supported on streaming device node. Agreed. Standards selection should be done at device node, just like any other device. So how do you handle a part like the TVP5150 that is standard agnostic? That device can sense the standard from the input signal and sets the result appropriately. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: [Q] No message from Kernel (Howto start debug?)
On 2011-07-28 07:15, Arno Steffen wrote: Maybe you are so kind to give me a hint: Try to migrate from Kernel 33 to 37. Currently I don't see any message after Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... From what I understand kernel starts with start_kernel()). What is best way to find out which part is failing? At which point I do a printk to see what's going on, or at least set a GPIO Pin of the processor? How to debug without any external tools like JTAG. Start with your bootargs - likely ttyS2 became ttyO2 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: NAND flash update via serial debug console
On 01/20/2011 10:21 AM, Elvis Dowson wrote: Hi, Is it possible to flash NAND via the serial debug console for OMAP35xx devices? If you have U-Boot running, you can download whatever you need via Y-Modem (loady command) and then update the NAND as needed. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
Camera/ISP questions
Sorry for cross-posting, but I'm not sure where best to get help :-( I'm working on an OMAP/3530 board (similar to the BeagleBoard, but of local design). I'm using the 2.6.32+ kernel from Angstrom which has the DVSDK support, including ISP camera support using V4L2. My camera is NTSC or PAL composite input through a TVP5150m1 decoder into the ISP, using 8 bit BT-656 data. This mostly works, but I'm suffering some strange problems. My queries to the TI forums have not yielded any [useful] feedback, so I'm hoping someone on these lists can help. I'm wondering if the BT-656 data from the TVP5150m1 device is compatible with the ISP, based on the comments in TRM 12.1.1 which implies that interlaced data is not supported via BT-656 and I'm pretty sure the data from the TVP _is_ interlaced since it came from an interlaced TV/video camera. Of course, I could be reading this incorrectly... My problem is the raw data from the ISP (UYVY422, grabbed using gstreamer v4l2src (*)) does not seem to be quite right. If I just look at it, e.g. gst-launch v4l2src ! 'video/x-raw-yuv,width=720,height=576,format=(fourcc)UYVY' ! \ ffmpegcolorspace ! 'video/x-raw-yuv,format=(fourcc)YV12' ! xvimagesink the images will tear and streak if there is any motion. Sometimes, there are ghosts (faded after-images) left behind that last for many seconds. Eventually, they will clear up, especially if the image becomes more static. If I try to do much more processing of these images, e.g. encode them into some compressed format like H264, the results are horrible. (*) I also wrote a very simple program to grab the data from the camera instead of using gstreamer v4l2src. This produces the same poorly constructed UYVY stream, so I don't think the problem is in the v4l2src component (but it _could_ be in the v4l2 kernel code, but it doesn't really do anything with the camera data except for managing the DMA+buffers) I created a known data source (not from the camera interface), using ffmpeg to produce a UYVY422 data file from an MP4 that I know looks good. I used this to test the back-end of the pipeline. It does not suffer these problems, even when the image has lots of motion. What leads me to think this is all about the camera/ISP path is that if I introduce a scaling component, I get even stranger results. For example, this pipeline gst-launch v4l2src always-copy=FALSE ! video/x-raw-yuv,width=720,height=576 ! \ TIVidResize name=qos-scaler contiguousInputFrame=TRUE ! \ 'video/x-raw-yuv,format=(fourcc)UYVY,width=320,height=240' ! ffmpegcolorspace ! 'video/x-raw-yuv,format=(fourcc)YV12' ! xvimagesink often has a Venetian-blind look - alternating good data with dark grey bars (that seem to have the desired data underneath). The image tearing and ghosting is much exaggerated. Running that same pipeline with the known good UYVY data file does not exhibit these behaviours. Does anyone have any ideas what might be causing these problems? Ever seen such before? Any ideas what I can look at or, if necessary, a better place to ask? I'm pretty sure I'm up against hardware problems (could be the design, could be the driver or configuration). If anyone has ideas or can help and need to see any of these data, I'll gladly provide them. Thanks for any help/ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP 3530 McBSP Frame Sync errors
On 09/13/2010 03:07 AM, Grazvydas Ignotas wrote: On Thu, Sep 9, 2010 at 6:56 PM, Gary Thomasg...@mlbassoc.com wrote: I'm trying to use McBSP4 with an external CODEC which is a slave device (i.e. the OMAP generates the Frame Sync pulses) In this mode, the BSP is purely the master of these signals. What can it possibly mean to get Frame Sync errors in this case (I'm reading from the external CODEC)? FYI, my registers look like this: PCR0: 0x0f0f RCR1: 0x0040, RCR2: 0x8041 XCR1: 0x0040, XCR2: 0x8041 SRGR1: 0x0f07, SRGR2: 0x101f Any ideas or help? Have you set the right McBSP source clock? It's in DEVCONF1/2 registers. Yes, the channel works fine, but I only occasionally get errant Frame Sync errors. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
OMAP 3530 McBSP Frame Sync errors
I'm trying to use McBSP4 with an external CODEC which is a slave device (i.e. the OMAP generates the Frame Sync pulses) In this mode, the BSP is purely the master of these signals. What can it possibly mean to get Frame Sync errors in this case (I'm reading from the external CODEC)? FYI, my registers look like this: PCR0: 0x0f0f RCR1: 0x0040, RCR2: 0x8041 XCR1: 0x0040, XCR2: 0x8041 SRGR1: 0x0f07, SRGR2: 0x101f Any ideas or help? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
DSS2 V4L2
I'm trying to get the DVSDK (3.01.00.03) working. It uses 2.6.32 + DSS2 + V4L2. What I'm having trouble with is how to configure/create/setup a video overlay such that I get V4L2 device for the display. In particular, what magic is required to create /dev/video1? Note: I'd be glad to send this question to a more targeted list, but the only one mentioned in the DVSDK documentation does not really exist :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS2 V4L2
On 04/19/2010 06:58 AM, Koen Kooi wrote: Op 19 apr 2010, om 14:29 heeft Gary Thomas het volgende geschreven: I'm trying to get the DVSDK (3.01.00.03) working. It uses 2.6.32 + DSS2 + V4L2. What I'm having trouble with is how to configure/create/setup a video overlay such that I get V4L2 device for the display. In particular, what magic is required to create /dev/video1? The trick is usually do not create2 framebuffers. My understanding is that an overlay can either be a framebuffer or a v4l device, but not both. That was it, thanks! -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
DVSDK on OMAP/3530
I'm trying to run the DVSDK 3.01.00.03 on an OMAP/3530 board which is not the OMAP3EVM (close, but from a different manufacturer). I've ported my board specifics to the kernel that comes with the DVSDK and everything seems to work. Except for the video demos :-( When I try to run 'decode', it attempts to open the device '/dev/video1' which I've deduced is a display in video mode. However, I can't figure out where or how that device is supposed to be created. I've compared my kernel config with the standard EVM config and all of the VIDEO/DSS/FB options match. Can someone give me some help/guidance? note: I'm not sure the best place to ask this - the DVSDK getting started guide refers to omap3530_dvevm_b...@list.ti.com but I cannot find it... Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: [ASK] OMAP 3430 LDP Trouble
On 04/06/2010 02:40 PM, Tar Gz wrote: i don't know, i'm forget to setting up my environment variable mmcinit or my sd card can't booting / bootablebut if i'm boot from nadn and can enter prompt, my ldp board can read my sd card...can load kernel from my sd card You'll be much better off figuring out how to boot from the SD card. There are many how to documents on this for the OMAP - just follow the cookbook. Then you'll have the pieces you need to repair your NAND copy and move on. On 4/7/10, Gary Thomasg...@mlbassoc.com wrote: On 04/06/2010 02:27 PM, Tar Gz wrote: yes, i can't boot from nand because i erase it and i can't boot from my sd card.. Why can't you boot from the SD card? okey i will try boot from serial..hope this help best regards, Aldyth M On 4/7/10, Gadiyar, Anandgadi...@ti.com wrote: Gadiyar, Anand wrote: Tar Gz wrote: if NAND support is currently missing for OMAP3430 LDP,,how i boot my ldp again like before?...any idea? snip If I understand you correctly, you now have a non-booting LDP, and want to get a bootloader flashed on it? You may need to do a serial boot. Maybe this (old, and no longer maintained) page will help? https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP Audio
On 02/17/2010 03:26 AM, Peter Ujfalusi wrote: On Wednesday 17 February 2010 09:03:39 ext Jarkko Nikula wrote: On Tue, 16 Feb 2010 11:19:25 -0700 Gary Thomasg...@mlbassoc.com wrote: I need to connect the OMAP (3530) to a 24bit CODEC. So far my attempts at getting this to go have not gone well. Then I ran across this comment in sound/soc/omap/omap-pcm.c: /* * Note: Regardless of interface data formats supported by OMAP McBSP * or EAC blocks, internal representation is always fixed 16-bit/sample */ Does this mean that this setup is just not supported? even though the hardware can handle it? Yep, comment is bit misleading but true until some patch will remove it. IRCC, the EAC was limited to 16-bit and also there wasn't need and HW to test other formats than S16_LE in McBSP DAI. Thanks for any pointers or ideas on how to get this going. I would first start adding support for the S32_LE into omap-pcm.c (DMA part). Worth to look this thread: http://mailman.alsa-project.org/pipermail/alsa-devel/2010-January/024704.ht ml Then add support for this format to the omap-mcbsp.c (link configuration part). Next step would be to add support for the S24_LE on 4-byte boundaries. I.e. the DMA is moving 32-bit samples between the memory and McBSP but only 24-bits are transferred over the McBSP and codec. Hmmm, I think this is a bit more complicated than that at least on OMAP3. I think the DMA engine should also move 24 bit words. This is dictated by the McBSP FIFO: it has a notion of word size, and it is expecting that the DMA engine will move THRESHOLD number of words. So if the McBSP is configured for 24 bit words, than the DMA word size has to match that. Apart from this, the constraint set for the period bytes need to be changed since as you change the word size in McBSP you will have different amount of actual bytes for the FIFO (the FIFO size is in words, and the maximum word size is 32 bit). Thanks for the help. I'm pretty sure I understand how to change the McBSP code (omap-mcbsp.c) to handle the various formats, but I'm a bit lost in the DMA setup (omap-pcm.c). How do I identify the code/width in omap_pcm_prepare()? Has no one ever used the OMAP/McBSP with data sizes other than 16 bits?? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP Audio
On 02/17/2010 04:17 AM, Peter Ujfalusi wrote: On Wednesday 17 February 2010 12:43:56 ext Gary Thomas wrote: On 02/17/2010 03:26 AM, Peter Ujfalusi wrote: On Wednesday 17 February 2010 09:03:39 ext Jarkko Nikula wrote: On Tue, 16 Feb 2010 11:19:25 -0700 Gary Thomasg...@mlbassoc.com wrote: I need to connect the OMAP (3530) to a 24bit CODEC. So far my attempts at getting this to go have not gone well. Then I ran across this comment in sound/soc/omap/omap-pcm.c: /* * Note: Regardless of interface data formats supported by OMAP McBSP * or EAC blocks, internal representation is always fixed 16-bit/sample */ Does this mean that this setup is just not supported? even though the hardware can handle it? Yep, comment is bit misleading but true until some patch will remove it. IRCC, the EAC was limited to 16-bit and also there wasn't need and HW to test other formats than S16_LE in McBSP DAI. Thanks for any pointers or ideas on how to get this going. I would first start adding support for the S32_LE into omap-pcm.c (DMA part). Worth to look this thread: http://mailman.alsa-project.org/pipermail/alsa-devel/2010-January/024704 .ht ml Then add support for this format to the omap-mcbsp.c (link configuration part). Next step would be to add support for the S24_LE on 4-byte boundaries. I.e. the DMA is moving 32-bit samples between the memory and McBSP but only 24-bits are transferred over the McBSP and codec. Hmmm, I think this is a bit more complicated than that at least on OMAP3. I think the DMA engine should also move 24 bit words. This is dictated by the McBSP FIFO: it has a notion of word size, and it is expecting that the DMA engine will move THRESHOLD number of words. So if the McBSP is configured for 24 bit words, than the DMA word size has to match that. Apart from this, the constraint set for the period bytes need to be changed since as you change the word size in McBSP you will have different amount of actual bytes for the FIFO (the FIFO size is in words, and the maximum word size is 32 bit). Thanks for the help. I'm pretty sure I understand how to change the McBSP code (omap-mcbsp.c) to handle the various formats, but I'm a bit lost in the DMA setup (omap-pcm.c). How do I identify the code/width in omap_pcm_prepare()? After looking at the TRM of OMAP, the sDMA has support for 8, 16 and 32 bit data types. So I'm not really sure how to configure McBSP and sDMA in case of 24 bit packed format. I would go with a trial and error method and find it out how it is working... Has no one ever used the OMAP/McBSP with data sizes other than 16 bits?? At least I can not recall. I have had a plan to add support for these, but it got delayed and delayed ;) How about sending padded data (24 bits in 32) which is what my CODEC wants anyway? Would this be easier to set up? How? (Again, I'm a bit fuzzy on how to tell omap_pcm_prepare that I need to be moving 24 or 32 bit chunks) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP Audio
On 02/17/2010 10:45 AM, Jarkko Nikula wrote: On Wed, 17 Feb 2010 05:01:53 -0700 Gary Thomasg...@mlbassoc.com wrote: After looking at the TRM of OMAP, the sDMA has support for 8, 16 and 32 bit data types. So I'm not really sure how to configure McBSP and sDMA in case of 24 bit packed format. I would go with a trial and error method and find it out how it is working... So it looks that the memory representation must be 32-bit. How about sending padded data (24 bits in 32) which is what my CODEC wants anyway? Would this be easier to set up? How? (Again, I'm a bit fuzzy on how to tell omap_pcm_prepare that I need to be moving 24 or 32 bit chunks) Internal representation and link configuration are separate things: DMA- McBSP rx/tx reg- [FIFO] - McBSP receiver/transmitter As Peter found, due the DMA and McBSP FIFO, the DMA configuration must be 32-bit. But I suppose the McBSP receiver/ransmitter could be configured to transmit only 24-bits. The OMAP35x Applications Processor Multi-Channel Buffered Serial Port (McBSP) TRM (SPRUFD1C) seems to have some examples for different data lengths than internal word length. Worth to look and try with trial and error method using oscilloscope :-) Thanks. I'd really like to understand how to set things up to generate the data I see in TRM: Figure 21-11 shows an example with 24 bits data (MSB first) and 8 padding bits at ‘0’. This matches my CODEC. Any clues? BTW, I was able to set things up for 32 bit PCM data, based on the email thread you pointed at. Still need the funky 24 bit stuff though. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP Audio
On 02/17/2010 10:56 AM, Mark Brown wrote: On Wed, Feb 17, 2010 at 10:51:11AM -0700, Gary Thomas wrote: Thanks. I'd really like to understand how to set things up to generate the data I see in TRM: Figure 21-11 shows an example with 24 bits data (MSB first) and 8 padding bits at ?0?. This matches my CODEC. Any clues? Does your CODEC actually need the padding bits to be zero? What you're describing sounds an awful lot like 32 bit data that just has the LSB ignored. I don't think it matters. The real problem is how to get 24 bits of data aligned to the right place in the 32 bit frame. TRM implies that the hardware can do this, I've just not figured out the magic... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
OMAP Audio
I need to connect the OMAP (3530) to a 24bit CODEC. So far my attempts at getting this to go have not gone well. Then I ran across this comment in sound/soc/omap/omap-pcm.c: /* * Note: Regardless of interface data formats supported by OMAP McBSP * or EAC blocks, internal representation is always fixed 16-bit/sample */ Does this mean that this setup is just not supported? even though the hardware can handle it? Thanks for any pointers or ideas on how to get this going. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: compilation error
On 02/12/2010 03:13 AM, Niamathullah sharief wrote: Hello, can anyone tell me while compilaing dbus-1.2.20 i am getting the folllowing error checking for XML_ParserCreate_MM in -lexpat... no configure: error: Could not find expat.h, check config.log for failed attempts what is wrong?what i should install?i installed libexpat also. still i get the same error. please help me As previously mentioned, this list is for discussion of the Linux kernel on OMAP, not user/support questions. You should take them to a more appropriate list. What higher level of software are you trying to run on your OMAP board (distribution, if you want to call it that)? Some examples might be: * OpenEmbedded, Poky, etc * 0xdroid, rowboat, etc * Ubuntu Each of these projects has their own user-level support lists and you'll find much better answers there. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: ARM tollchain support
On 12/15/2009 05:57 AM, Shilimkar, Santosh wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Niamathullah sharief Sent: Tuesday, December 15, 2009 6:22 PM To: linux-omap@vger.kernel.org Subject: ARM tollchain support Hello, I am trying to install ARM tollchain in my GCC. But i am not getting to install correctly. When i try to compile an u boot image i am getting the following errors in last few lines .. make[1]: Leaving directory `/home/ariem/Desktop/u-boot-200901-lange51/tools' make -C examples all make[1]: execvp: /home/ariem/CodeSourcery/Sourcery_G++_Lite/lib/gcc: Permission denied make[1]: Entering directory `/home/ariem/Desktop/u-boot-200901-lange51/examples' /bin/sh: /home/ariem/CodeSourcery/Sourcery_G++_Lite/lib/gcc: is a directory dirname: missing operand Try `dirname --help' for more information. /bin/sh: /home/ariem/CodeSourcery/Sourcery_G++_Lite/lib/gcc: is a directory dirname: missing operand Try `dirname --help' for more information. /home/ariem/CodeSourcery/Sourcery_G++_Lite/lib/gcc -Os -fno-strict-aliasing -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x9780 -I/home/ariem/Desktop/u-boot-200901-lange51/include -fno-builtin -ffreestanding -nostdinc -isystem -pipe -DCONFIG_ARM -D__ARM__ -Wall -Wstrict-prototypes -c -o hello_world.o hello_world.c make[1]: execvp: /home/ariem/CodeSourcery/Sourcery_G++_Lite/lib/gcc: Permission denied make[1]: *** [hello_world.o] Error 127 make[1]: Leaving directory `/home/ariem/Desktop/u-boot-200901-lange51/examples' make: *** [examples] Error 2 ar...@ariem-desktop:~/Desktop/u-boot-200901-lange51$ what will be the error. can anyone tell me. i think the path exported is wrong. please help me How are you exporting the path ? Can you copy paste that here That's not the problem - the tools have not been installed properly. It looks to me like Niamathullah sharief (I never know which name is prominent) is trying to use tools installed by another user (ariem). I assume that 'sharief' does not have access to 'ariem's home directory, thus this fails. Get the tools installed into a common directory and this should start working. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: u-boot for omap3
On 12/03/2009 11:57 AM, Weng, Wending wrote: Hi, In the u-boot for omap3evm I use, cleanup_before_linux(in cpu/omap3/cpu.c or cpu/arm_cortexa8/cpu.c) turns off L2 cache by mistake, it should not. This causes serious performance problem for me. The following line #ifndef CONFIG_L2_OFF should be #ifdef CONFIG_L2_OFF. #ifndef CONFIG_L2_OFF /* turn off L2 cache */ l2cache_disable(); /* invalidate L2 cache also */ v7_flush_dcache_all(get_device_type()); #endif Are you sure? The version I have re-enables the L2 cache just a few lines below that: == #ifndef CONFIG_L2_OFF /* turn off L2 cache */ l2_cache_disable(); /* invalidate L2 cache also */ v7_flush_dcache_all(get_device_type()); #endif i = 0; /* mem barrier to sync up things */ asm(mcr p15, 0, %0, c7, c10, 4: :r(i)); #ifndef CONFIG_L2_OFF l2_cache_enable(); #endif == n.b. I'm using git://git.denx.de/u-boot.git -Original Message- From: Pandita, Vikram [mailto:vikram.pand...@ti.com] Sent: December 3, 2009 1:40 PM To: Weng, Wending; linux-omap@vger.kernel.org; Tom Subject: RE: u-boot for omap3 -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Weng, Wending Sent: Thursday, December 03, 2009 12:32 PM To: linux-omap@vger.kernel.org Subject: u-boot for omap3 Hi all, Anybody knows who takes care of u-boot for omap3, I wish to fix a L2 cahe related bug if Tom Rix is the Arm u-boot maintainer. Omap3 falls as one of the silicon he maintains. In reality, there are always internal/forked versions of the upstream that get used. Like for zoom boards I maintain it at dev.omapzoom.org /bootloader/* it's not done yet. Regards Wending -- 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 -- 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 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Problem trying to pull particular commit from PM tree
On 11/18/2009 02:58 PM, Peter Barada wrote: On Wed, 2009-11-18 at 08:57 -0800, Tony Lindgren wrote: * Peter Baradapet...@logicpd.com [091118 06:20]: Is it possible to back up in time on the PM tree to find a particular commit, even across rebasings? I'm interested in the commit used by TI to base their AM3517 work on which is: [Commit:ef25c2a0e0]: OMAP3: PM: defconfig: enable SRF by default. I tried: git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git git checkout -b pm origin/pm git reset --hard ef25c2a0 But that came back with: fatal: ambiguous argument 'ef25c2a0': unknown revision or path not in the working tree. My git 'fu' is pretty weak. Any ideas why this doesn't work? Thanks in advance! Maybe ef25c2a0e0 is some TI internal commit? I wouldn't think so. Their comment in the release notes is: This release package includes a series of patches on top of the pm branch maintained at http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=pm;. Baseline: [Commit:ef25c2a0e0]: OMAP3: PM: defconfig: enable SRF by default. 1) How can I search the linux-omap git world to see if the commit string exists? 2) When trees are rebased, are the previous commits in the tree lost - i.e. if tree A has commits A', A'', etc, and is rebased on tree B(which does not have the commits A', A'' in it), are the commits A', A'', etc lost? Did you try specifying the entire key 'ef25c2a0e0', not just 'ef25c2a0'? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Restart after 4 min of operation?
On 11/02/2009 08:35 PM, Bill Gatliff wrote: Guys: Can someone give me any ideas as to why my Beagleboard-like platform would spontaneously restart after precisely four minutes of operation? No OOPS, no nothing. This is with 2.6.32-rc5. BeagleBoard like? More details are probably required for much help. How do you power it? My BeagleBoard is powered via the OTG. I've seen it reset if I hang too much on the USB host port (exceed the meager power budget) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Restart after 4 min of operation?
On 11/03/2009 11:37 AM, Bill Gatliff wrote: Gadiyar, Anand wrote: I suspect a watchdog timer of some kind, but I haven't got a clue which one. Turns out I had disabled watchdog timer support in my kernel. Re-enabling it seems to have addressed the problem--- the system has run for more than 5 minutes now. :) Apparently, the default for the OMAP watchdog timer is armed at reset? Interesting. I'm pretty sure this is set up in U-Boot. If I were you, I'd ask the customer for the U-Boot modifications so you can check what they've done. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
DSS2 clocking
I'm using DSS2, currently just with a frame buffer to a [VGA/RGB] monitor. I'm trying to understand how to set the timing parameters for my device. The simple 'omapfb.mode=1024x768...@75' doesn't quite cut it for some of the devices I need to use. Questions: * How can I get different pixel clocks? I seem to always end up with 61714285: # cat /tmp/dbg/omapdss/clk - dss - internal clk count 2 dss_ick 83001 dss1_alwon_fck 123428570 1 dss2_alwon_fck 13000 dss_tv_fck 54000 dss_96m_fck 96000 - dispc - dispc fclk source = dss1_alwon_fclk pixel clk = 123428570 / 1 / 2 = 61714285 * How can I control the waveform? In particular, the size and shape of the porches? My display seems to need these settings: 61714,1024/26/162/136,768/3/29/6 I'd like to get this behaviour, either from the boot line or ideally by default. * The display also seems to want the sync pulses to be asserted low (inverted?). Currently, I have this hard-wired into my display device, but I'd also like this to be adjustable. Thanks for any pointers, etc. Note: I'm using Tomi's tree from roughly late July http://www.bat.org/~tomba/git/linux-omap-dss.git 7ae220f46384b34e72b8c3b0c2075a674a3f74fe Thanks for any pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
DSS2 frame buffer problem
I have a new board that I'd like to run a frame buffer 800x600x24 When I boot, I get this error: omapfb: failed to allocate framebuffer This board is derived from a board I'm already running DSS2 at 800x600x16 on. What do I need to change to get this to work? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS2 frame buffer problem
On 10/13/2009 06:59 AM, Tomi Valkeinen wrote: On Tue, 2009-10-13 at 14:55 +0200, ext Gary Thomas wrote: I have a new board that I'd like to run a frame buffer 800x600x24 When I boot, I get this error: omapfb: failed to allocate framebuffer This board is derived from a board I'm already running DSS2 at 800x600x16 on. What do I need to change to get this to work? Most likely you need to allocate more VRAM with vram boot option, in board file or kernel config option (CONFIG_OMAP2_VRAM_SIZE). Thanks, that was it. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
X-loader / U-Boot query
I have a new board - OMAP 3530 with 512MB DRAM NAND I've build X-loader and U-Boot for it and it mostly comes up. The sources I used (based on recommendations from the BeagleBoard pages) were: http://git.gitorious.org/x-load-omap3/mainline.git git://git.denx.de/u-boot.git I had to make a small change to get it to recognize the larger NAND FLASH device. The problem I have now is that it's only seeing 1/2 (256MB) of the available DRAM. * Does anyone know how to get it to see all 512MB? * Is there a better place to ask/discuss these questions? A cursory look around did not point to anything fresh (most of the web pages Wikis I looked are are _years_ old) Thanks for any help/pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: X-loader / U-Boot query
On 10/08/2009 09:14 AM, Menon, Nishanth wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Adam Machalek Sent: Thursday, October 08, 2009 9:47 AM To: Gary Thomas Cc: linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c Function do_sdrc_init() There is an assumption that the RAM size on each CS is maximum of 128M. See this line: writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | DEEPPD | DDR_SDRAM,sdrc_base-cs[cs].mcfg); This discussion should really be taken to u-boot mailing list. Yes, any additional patches would be good to have.. Where is that list?? I did ask this question in the original email... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: X-loader / U-Boot query
On 10/08/2009 09:54 AM, Syed Mohammed, Khasim wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Thursday, October 08, 2009 10:17 AM To: Menon, Nishanth Cc: Adam Machalek; linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query On 10/08/2009 09:14 AM, Menon, Nishanth wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Adam Machalek Sent: Thursday, October 08, 2009 9:47 AM To: Gary Thomas Cc: linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c Function do_sdrc_init() There is an assumption that the RAM size on each CS is maximum of 128M. See this line: writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | DEEPPD | DDR_SDRAM,sdrc_base-cs[cs].mcfg); This discussion should really be taken to u-boot mailing list. Yes, any additional patches would be good to have.. Where is that list?? I did ask this question in the original email... Sorry, I have not seen all the thread. Are you using x-loader? Then your DDR configuration happens in x-loader and not in u-boot as it skips it. In that case your question should be on x-loader and this is the right list to discuss the same. If you use u-boot for RAM configuration then you should be on NOR flash. I'm definitely using x-loader (followed by U-Boot). Where is this set in X-loader? Is there any guidance for using the larger DRAM devices? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
USB confusion
What are the options to have USB Host support on the normal USB channels (i.e. not the OTG port)? This used to work on my platform but things stopped when I upgraded to the latest kernel :-( n.b. OTG host and gadget still work fine. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: USB confusion
On 09/01/2009 05:42 AM, Gary Thomas wrote: What are the options to have USB Host support on the normal USB channels (i.e. not the OTG port)? This used to work on my platform but things stopped when I upgraded to the latest kernel :-( n.b. OTG host and gadget still work fine. Thanks Following up on this, I made sure that CONFIG_USB_EHCI_HCD was defined. Now I see these messages: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver Clock usbhost_48m_fck didn't enable in 10 tries ehci-omap: probe of ehci-omap.0 failed with error -22 Any ideas what else I might be missing? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: USB confusion
On 09/01/2009 12:14 PM, Steve Sakoman wrote: On Tue, Sep 1, 2009 at 4:42 AM, Gary Thomasg...@mlbassoc.com wrote: What are the options to have USB Host support on the normal USB channels (i.e. not the OTG port)? This used to work on my platform but things stopped when I upgraded to the latest kernel :-( I had the same experience with Overo and posted a patch a couple of weeks ago to get it working (ARM: OMAP3: Overo: Fix EHCI initialization) That fixed it (more precisely, the indirectly referenced patch 'fix phy_reset' fixed my problem) Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
LCD blanking?
I have a system with an LCD, running Tomi's DSS2 support. One problem I'm having is that after a while, the LCD blanks out (I do have fbcon support enabled so I can use it as a glass TTY - no keyboard) How can I keep this from happening? Once it does, is there any way to get it back on (remember, no keyboard)? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Can't mount proc filesystem
Tar Gz wrote: hi all i try to develop linux 2.6.26 kernel with omap patch but when i'm booting, i'm enter busybox and running /etc/init.d/rcS but failed to mount proc filesystem...i have enabled kernel /rpoc filesystems support but it's still can't mounting..any idea? You should not be running /etc/init.d/rcS manually. The log you sent previously shows it has already run. What makes you think that /proc wasn't mounted? Why are you running /etc/init.d/rcS by hand? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Can't mount proc filesystem
Tar Gz wrote: because my kernel booting and enter the busybox manually how to enter to shell like bash? The busybox shell is already running. It's more like 'sh' than 'bash' What do you want to do that you don't think you can?? On 8/23/09, Gary Thomas g...@mlbassoc.com wrote: Tar Gz wrote: hi all i try to develop linux 2.6.26 kernel with omap patch but when i'm booting, i'm enter busybox and running /etc/init.d/rcS but failed to mount proc filesystem...i have enabled kernel /rpoc filesystems support but it's still can't mounting..any idea? You should not be running /etc/init.d/rcS manually. The log you sent previously shows it has already run. What makes you think that /proc wasn't mounted? Why are you running /etc/init.d/rcS by hand? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Can't mount proc filesystem
Tar Gz wrote: hemmm you're right... if i want to run bash, i must declare bash shell in the /etc/inittab ? No, you'd have to build 'bash' and include it in your file system. What's wrong with the busybox shell? What are you trying to do that it can't? On 8/23/09, Gary Thomas g...@mlbassoc.com wrote: Tar Gz wrote: because my kernel booting and enter the busybox manually how to enter to shell like bash? The busybox shell is already running. It's more like 'sh' than 'bash' What do you want to do that you don't think you can?? On 8/23/09, Gary Thomas g...@mlbassoc.com wrote: Tar Gz wrote: hi all i try to develop linux 2.6.26 kernel with omap patch but when i'm booting, i'm enter busybox and running /etc/init.d/rcS but failed to mount proc filesystem...i have enabled kernel /rpoc filesystems support but it's still can't mounting..any idea? You should not be running /etc/init.d/rcS manually. The log you sent previously shows it has already run. What makes you think that /proc wasn't mounted? Why are you running /etc/init.d/rcS by hand? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Booting from busy box failed
Tar Gz wrote: hi all, i try to using linux 2.6.26-omap1 at omap3430 it's my env variable OMAP34XX LAB # print bootdelay=3 baudrate=115200 filesize=34a8 bootfile=uImage bootargs=console=ttyS2,115200n8 rw root=/dev/mmcblk0p2 rootdelay=2 mem=128M #mmcinit #fatload mmc 0 8030 #bootm 8030 ** Starting System Init for OMAP3430LAB Release: 0.1 ** Saving kernel ring buffer : OK Mounting devpts : OK Starting syslogd : OK Starting klogd : OK Mounting filesystems : OK Please press Enter to activate this console. BusyBox v1.6.1 (2008-07-17 12:54:29 CDT) Built-in shell (ash) Enter 'help' for a list of built-in commands. # then i try to type : # /etc/init.d/rcS Mounting proc : mount: mounting /proc on /proc failed Error in /proc filesystem - init aborted Does the directory [mount point] '/proc' exist? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Booting from busy box failed
Tar Gz wrote: directory /proc in the second partition(my filesystem) and my kernel configure to support proc filesystems...any idea? First of all, don't top post :-( Why are you running /etc/init.d/rcS manually? It looks to me like it already ran /proc should already be mounted. What does the output of mount show? On 8/20/09, Gary Thomas g...@mlbassoc.com wrote: Tar Gz wrote: hi all, i try to using linux 2.6.26-omap1 at omap3430 it's my env variable OMAP34XX LAB # print bootdelay=3 baudrate=115200 filesize=34a8 bootfile=uImage bootargs=console=ttyS2,115200n8 rw root=/dev/mmcblk0p2 rootdelay=2 mem=128M #mmcinit #fatload mmc 0 8030 #bootm 8030 ** Starting System Init for OMAP3430LAB Release: 0.1 ** Saving kernel ring buffer : OK Mounting devpts : OK Starting syslogd : OK Starting klogd : OK Mounting filesystems : OK Please press Enter to activate this console. BusyBox v1.6.1 (2008-07-17 12:54:29 CDT) Built-in shell (ash) Enter 'help' for a list of built-in commands. # then i try to type : # /etc/init.d/rcS Mounting proc : mount: mounting /proc on /proc failed Error in /proc filesystem - init aborted Does the directory [mount point] '/proc' exist? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Audio on OMAP3
Mark Brown wrote: On Sun, Aug 09, 2009 at 02:34:18PM -0600, Gary Thomas wrote: Thanks. How is this normally configured - ALSA or OSS? It's all ALSA. There is some OSS emulation for ALSA. Sorry for being dense, but I'm just trying to understand how to get this going. I turned on the SOC+ALSA support (there didn't seem to be an easy way to configure just the TWL4030 driver) and I got this: Advanced Linux Sound Architecture Driver Version 1.0.20. Platform driver 'soc-audio' needs updating - please use dev_pm_ops No device for DAI AD73311 Asahi Kasei AK4104 ALSA SoC Codec Driver No device for DAI AK4535 Cirrus Logic CS4270 ALSA SoC Codec Driver No device for DAI PCM3008 HiFi No device for DAI SSM2602 No device for DAI tlv320aic23 No device for DAI tlv320aic3x No device for DAI twl4030 No device for DAI twl4030 Voice No device for DAI UDA134X No device for DAI UDA1380 No device for DAI UDA1380 No device for DAI UDA1380 No device for DAI WM8510 HiFi No device for DAI WM8728 No device for DAI WM8750 No device for DAI WM8971 No device for DAI WM8990 ADC/DAC Primary ALSA device list: No soundcards found. Is there more configury/setup required, beyond just enabling the drivers? Is there an example board that uses this? Is the code in the mainline linux-omap tree? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Audio on OMAP3
Gary Thomas wrote: Mark Brown wrote: On Sun, Aug 09, 2009 at 02:34:18PM -0600, Gary Thomas wrote: Thanks. How is this normally configured - ALSA or OSS? It's all ALSA. There is some OSS emulation for ALSA. Sorry for being dense, but I'm just trying to understand how to get this going. I turned on the SOC+ALSA support (there didn't seem to be an easy way to configure just the TWL4030 driver) and I got this: Advanced Linux Sound Architecture Driver Version 1.0.20. Platform driver 'soc-audio' needs updating - please use dev_pm_ops No device for DAI AD73311 Asahi Kasei AK4104 ALSA SoC Codec Driver No device for DAI AK4535 Cirrus Logic CS4270 ALSA SoC Codec Driver No device for DAI PCM3008 HiFi No device for DAI SSM2602 No device for DAI tlv320aic23 No device for DAI tlv320aic3x No device for DAI twl4030 No device for DAI twl4030 Voice No device for DAI UDA134X No device for DAI UDA1380 No device for DAI UDA1380 No device for DAI UDA1380 No device for DAI WM8510 HiFi No device for DAI WM8728 No device for DAI WM8750 No device for DAI WM8971 No device for DAI WM8990 ADC/DAC Primary ALSA device list: No soundcards found. Is there more configury/setup required, beyond just enabling the drivers? Is there an example board that uses this? Is the code in the mainline linux-omap tree? I found some in sound/soc/omap/... - trying to understand them now. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Audio on OMAP3
Mark Brown wrote: On Mon, Aug 10, 2009 at 07:19:33AM -0600, Gary Thomas wrote: Sorry for being dense, but I'm just trying to understand how to get this going. I turned on the SOC+ALSA support (there didn't seem to be an easy way to configure just the TWL4030 driver) and You need to provide a machine-specific driver which tells the McBSP and TWL4030 drivers how they are connected together on your particular board. There are several examples of this for standard reference boards in the OMAP directory - if your audio hardware is based closely enough on one of those then you should be able to just use the same driver. My hardware is much like the Beagle, so I started with that driver. Got it going fine, thanks. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
Audio on OMAP3
How is audio supported on OMAP3? In particular via the TWL4030/TPS659x0 chip? Is anyone working on this? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Audio on OMAP3
Mark Brown wrote: On Sun, Aug 09, 2009 at 11:25:33AM -0600, Gary Thomas wrote: How is audio supported on OMAP3? In particular via the TWL4030/TPS659x0 chip? Is anyone working on this? This is supported in the ASoC subsystem - see sound/soc/omap for the OMAP specific stuff and sound/soc/codecs/twl4030.c for the TWL4030 specifics. Thanks. How is this normally configured - ALSA or OSS? What tools have been used (simple busybox system, not Android)? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS2 questions
Tomi Valkeinen wrote:
Hi,
ext Gary Thomas wrote:
Tomi,
I've been following your DSS2 work, with reasonable success.
However, when I tried to pull from your repo today, I got
a ton of merge errors. I cloned your tree a [little] while
back (it seems it was 2009-06-16, but where did the time go?)
Here's what I did:
git clone http://www.bat.org/~tomba/git/linux-omap-dss.git
HEAD=5bd374f9b199d46ae434489d56615b240de5a6d7
git checkout -b my_branch origin/master
...
When I went to pull into my_branch, I got the merge errors.
Any clues what I did wrong? How could/should I have managed
this better?
The problem is that I have rebased my tree so that I end up with a clean
set of patches that can be posted to mailing lists. And rebasing means
changing history, which means that you cannot merge it normally.
Perhaps I should keep the master branch as it is, and do rebasing on a
separate branch. I don't know, I'm no git-master ;).
If you have no changes of your own in the branch, you can do
git reset --hard origin/master
which will reset that branch to the exact version that is in origin/master.
I'll give this a try - I still have the old tree I was working from.
n.b. you earlier told me that git was better than sliced
bread; I'm still waiting to be shown the light :-)
You'll see it when you understand how git works ;)
Second question; I've set up my system much the same as the
boards you are working on, with an LCD and TV outputs. I'm
a bit confused as to how I configure the overlays and managers
to be able to send YUV data directly through to either the
LCD or TV. Can you explain this?
You need to change the framebuffer to YUV color mode. And YUV only works
on video overlays, so you need to setup video overlay to be shown on the
LCD or TV.
If you have fb1 as a video overlay, you can do for example:
fbset -fb /dev/fb1 -nonstd 1
which sets fb1 to YUV422 mode. 8 would be YUY422. Those numbers come
from omapfb.h, enum omapfb_color_format.
Check also Documentation/arm/OMAP/DSS, if you haven't already done so.
Still a bit fuzzy on this. I'm sure that document helps, if
one already knows how all the overlays and managers and ...
are wired together. I'm new at this game :-)
I tried to set my TV to be video/uyv422 via the attached script.
I was trying to leave fb0 alone (running on the LCD) and use fb1
to display the YUV422 data. Alas, 'fbset' gives me Bad video mode?
Any pointers?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
#! /bin/sh
ovl0=/sys/devices/platform/omapdss/overlay0
ovl1=/sys/devices/platform/omapdss/overlay1
ovl2=/sys/devices/platform/omapdss/overlay2
mgr0=/sys/devices/platform/omapdss/manager0
mgr1=/sys/devices/platform/omapdss/manager1
lcd=/sys/devices/platform/omapdss/display0
tv=/sys/devices/platform/omapdss/display1
fb0=/sys/class/graphics/fb0
fb1=/sys/class/graphics/fb1
fb2=/sys/class/graphics/fb2
MODE=${MODE:-ntsc}
echo 0 $tv/enabled
echo ${MODE} $tv/timings
w=`cat $tv/timings | cut -d , -f 2 | cut -d / -f 1`
h=`cat $tv/timings | cut -d , -f 3 | cut -d / -f 1`
echo ... Setting ${MODE} mode, Width = ${w}, Height = ${h}
echo 0 $ovl2/enabled
echo 2 $fb1/overlays
echo $w,$h $ovl2/output_size
echo tv $ovl2/manager
echo 1 $ovl2/enabled
echo 1 $tv/enabled
fbset -fb /dev/fb1 -nonstd 1
Re: DSS2 questions
Tomi Valkeinen wrote: Hi, ext Gary Thomas wrote: Second question; I've set up my system much the same as the boards you are working on, with an LCD and TV outputs. I'm a bit confused as to how I configure the overlays and managers to be able to send YUV data directly through to either the LCD or TV. Can you explain this? You need to change the framebuffer to YUV color mode. And YUV only works on video overlays, so you need to setup video overlay to be shown on the LCD or TV. If you have fb1 as a video overlay, you can do for example: fbset -fb /dev/fb1 -nonstd 1 which sets fb1 to YUV422 mode. 8 would be YUY422. Those numbers come from omapfb.h, enum omapfb_color_format. Check also Documentation/arm/OMAP/DSS, if you haven't already done so. Still a bit fuzzy on this. I'm sure that document helps, if one already knows how all the overlays and managers and ... are wired together. I'm new at this game :-) I tried to set my TV to be video/uyv422 via the attached script. I was trying to leave fb0 alone (running on the LCD) and use fb1 to display the YUV422 data. Alas, 'fbset' gives me Bad video mode? Any pointers? You need to allocate memory for the framebuffer. Try adding for example this: mem=$((w*h*4)) echo $mem $fb1/size Also, you are trying to connect video2 overlay to fb1, but by default DSS connects video2 to fb2. So if you really want to do that, you first need to detach video1 from fb1, video2 from fb2, and then attach video2 to fb1. I suggest you use fb2 which is already attached to video2. That helped, thanks. 'fbset' no longer complains and I now have a lovely green screen on my TV. Now, to figure out how to send some YUV422 data to it. I have Vaibhav's V4L2 support in my tree - will this work with your DSS2 devices? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: ISP buffer issue
Gary Thomas wrote: I'm having trouble with the OMAP3 camera (ISP) support when I have a large sensor. I'm working with a 3M CCD sensor which has a native resolution of 2048x1536. The problem is when I run V4L2 code which tries to allocate map buffers for input streaming. If the frame is much bigger than PAL size (720x576) the system hangs. I traced this into the ISP layer and found that when the buffer being allocated is over 1MB, this happens: isp_tmp_buf_alloc: allocating 1531904 bytes which eventually fails in iommu_vmalloc() Looking at the code, there seems to be some magic here - the buffer allocation falls over if the request is large. I'm working from this code: http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git starting from commit (ti_display head on 2009-07-23) 6810d6d683e768c3bc6b5647c214804045665e22 Hiroshi - I CC'd you directly as this code seems to be yours. Could you comment on my problem? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
ISP buffer issue
I'm having trouble with the OMAP3 camera (ISP) support when I have a large sensor. I'm working with a 3M CCD sensor which has a native resolution of 2048x1536. The problem is when I run V4L2 code which tries to allocate map buffers for input streaming. If the frame is much bigger than PAL size (720x576) the system hangs. I traced this into the ISP layer and found that when the buffer being allocated is over 1MB, this happens: isp_tmp_buf_alloc: allocating 1531904 bytes which eventually fails in iommu_vmalloc() Looking at the code, there seems to be some magic here - the buffer allocation falls over if the request is large. I'm working from this code: http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git starting from commit (ti_display head on 2009-07-23) 6810d6d683e768c3bc6b5647c214804045665e22 Ideas? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
OMAP camera with BT-656 sensor
Sergio, I'm trying to use your tree with a BT-656 style sensor(*). I've managed to get this [more or less] working when I use the official TI PSP tree + OMAP3 patches, but I'm not getting very far with your code. I just updated my copy from your tree, but I don't see any real changes since June 18 when I first started looking at this. I've made a number of changes, inspired by the PSP code to get the BT-656 handling enabled in the CCDC. I do see that the PSP codebase seems older than yours? but is more complete in other respects. Can you enlighten me as to the heritage of these different trees? The problem I have at the moment is that sensor data is getting into the CCDC module, but since the previewer/resizer modules are not used, nothing is ever delivered to my user code. Bottom line, I'm confused as to how I should go about getting my driver/system working. Do I use your work, or just stick with the PSP base (why?)?? Thanks (*) I cloned: git://dev.omapzoom.org/pub/scm/saaguirre/linux-omap-camera.git -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP camera with BT-656 sensor
Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Monday, July 27, 2009 2:11 PM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-omap@vger.kernel.org Subject: OMAP camera with BT-656 sensor ... snip Bottom line, I'm confused as to how I should go about getting my driver/system working. Do I use your work, or just stick with the PSP base (why?)?? What I do feel is that the PSP base will fulfill better your immediate needs, but in the future, as I'm getting aware of Vaibhav changes, I'll be interested in making them part of my tree aswell, so Vaibhav could avoid rebasing the BT646 support internally everytime... Is there a GIT tree for this? A [hopefully] minor complication is that I'm using Tomi's DSS2 tree for the base of my port. How can I move/merge the PSP based support into it? Can I just pick up the whole drivers/media subtree and put in in place of what I have? Thanks for your help - this myriad of trees and very disparate support levels is really confusing to those of us on the outside... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Problems configuring OMAP35x ISP driver
Eino-Ville Talvala wrote: Zach, We've gotten a Aptina MT9P031 driver working with the latest ISP patchset, both with YUV and RAW data. I don't know what the problem might be with YUYV data - we get useful YUYV data without any changes to the ISP defaults. However, to request RAW data, that simply uses the CCDC and bypasses all the processing in the ISP, request the pixelformat of V4L2_PIX_FMT_SGRBG10. This will give you two bytes per pixel, at least in our case (although we have a 12-bit sensor cut down to 10 bits), so be prepared to throw out every other byte. Hope this helps, Eino-Ville (Eddy) Talvala Computer Graphics Lab Stanford University I've been working on this same issue, using a Micron MT9T001 sensor, without much success. Could you share your tree and/or patches (against what?)?? This would be most helpful. Thanks On 7/14/2009 9:49 AM, Zach LeRoy wrote: Hello Sergio, I spoke with you earlier about using the ISP and omap34xxcam drivers with a micron mt9d111 SOC sensor. I have since been able to take pictures, but the sensor data is not making it through the ISP data-path correctly. I know the problem is in the ISP data-path because I am configuring the sensor the exact same way as I have been on my working PXA system. I am expecting 4:2:2 packed YUV data, but all of the U and V data is no more than 2 bits where it should be 8. I know the ISP has a lot of capabilities, but all I want to use it for is grabbing 8-bit data from my sensor and putting it in a buffer untouched using the CCDC interface (and of course clocking and timing). What are the key steps to take to get this type of configuration? Other Questions: Is there any processing done on YUV data in the ISP driver by default that I am missing? Has any one else experienced similar problems while adding new sensor support? Any help here would be greatly appreciated. Thank you, Zach LeRoy -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
v4l2_int_device vs v4l2_subdev?
Still trying to wrap my head around the OMAP/34xx camera support. I need to use the TVP5150 sensor/controller, but the existing driver uses v4l_subdev. The working examples I've found (from Sergio's tree) use sensors like ov3640 with uses v4l2_int_device Are these two totally separate beasts? If I have an infrastructure (I assume) based on v4l2_int_device, how do I use a v4l2_subdev device driver? or need I move one to the other? ... dizzy from traveling down too many twisty little passages :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP34XXCAM: Micron mt9d111 sensor support?
Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Monday, June 22, 2009 1:06 PM To: Aguirre Rodriguez, Sergio Alberto Cc: Zach LeRoy; linux-omap; linux-me...@vger.kernel.org; Sakari Ailus Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support? Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy Sent: Wednesday, June 17, 2009 5:06 PM To: linux-omap; linux-me...@vger.kernel.org Subject: OMAP34XXCAM: Micron mt9d111 sensor support? I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? Hi Gary, I'm currently on the process to rebase and verify all this code on 3430SDP, Zoom1 and soon Zoom2. Here you can find my progress: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Check devel branch, which contains all latest Sakari's tree patches (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM tree, plus the patches, which are still in works, to make the above mentioned platforms to work. I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right now... My gitorious tree will eventually disappear, as I can work better with this new one. I'll consolidate some patches when this sensor code is ready, and will CC you if interested. Thanks. I've already checked out this tree and at least it builds for the Zoom (I have one here). Is this in a state where I can test it for you? What do you use to capture video from the sensor? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP34XXCAM: Micron mt9d111 sensor support?
Aguirre Rodriguez, Sergio Alberto wrote: From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto From: Gary Thomas [mailto:g...@mlbassoc.com] Aguirre Rodriguez, Sergio Alberto wrote: From: Gary Thomas [mailto:g...@mlbassoc.com] Aguirre Rodriguez, Sergio Alberto wrote: From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S- video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? Hi Gary, I'm currently on the process to rebase and verify all this code on 3430SDP, Zoom1 and soon Zoom2. Here you can find my progress: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Check devel branch, which contains all latest Sakari's tree patches (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM tree, plus the patches, which are still in works, to make the above mentioned platforms to work. I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right now... My gitorious tree will eventually disappear, as I can work better with this new one. I'll consolidate some patches when this sensor code is ready, and will CC you if interested. Thanks. I've already checked out this tree and at least it builds for the Zoom (I have one here). Is this in a state where I can test it for you? What do you use to capture video from the sensor? I normally use a small test binary I wrote which saves the captured frames to memory, so later I can see them with either IrfanView (when capturing RAW images) or PYUV for seeing the YUV422 images. You should be able to use any standard V4l2 capturing application anyways. Btw, any contribution would be completely welcome. Either on Testing or on development. :) Thanks for your interest in helping. I've built for the Zoom, now I just need to figure out how to capture the data. I'll let you know if I have any questions or problems. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP34XXCAM: Micron mt9d111 sensor support?
Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy Sent: Wednesday, June 17, 2009 5:06 PM To: linux-omap; linux-me...@vger.kernel.org Subject: OMAP34XXCAM: Micron mt9d111 sensor support? I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video in) Sadly, the tree above (omap3-linux-camera-driver) won't build for the Zoom/LDP: CC arch/arm/mach-omap2/board-ldp-camera.o /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:59: error: implicit declaration of function 'PAGE_ALIGN' /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:59: error: initializer element is not constant /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:59: error: (near initialization for 'ov3640_hwc.capture_mem') /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c: In function 'ov3640_sensor_set_prv_data': /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:89: error: 'hwc' undeclared (first use in this function) /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:89: error: (Each undeclared identifier is reported only once /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c:89: error: for each function it appears in.) Looking at the code, it seems that some pieces are missing - merge problem maybe? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS2 TV settings
halli manjunatha wrote: Hi Thomas, [not 100% related] The documentation says that TI is working on the V4L2 support. Do you know the status of this? where I might find it? I cannot help you with this. There have been mails about it on linux-omap and v4l2 lists, so you could search those archives. There is a public repository representing the V4L2 driver on the Tomi's DSS patches. Here is the link to that. http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/ti_display Thanks for the pointer. Which board(s) has this been tested with (so I can look at the configs)? What are you using to test it with? I noticed that your tree is 2.6.30-rc7, Tomi's is -rc8. There are quite a few differences ( 1MB patch file). How can I reconcile what you've changed with my working tree (which is based on Tomi's 2.6.30-rc8 tree)? Thanks for any help On Thu, Jun 11, 2009 at 11:38 AM, Tomi Valkeinentomi.valkei...@nokia.com wrote: Hi, On Wed, 2009-06-10 at 19:17 +0200, ext Gary Thomas wrote: Tomi, I'm running your latest DSS2 tree and have some questions about the TV settings. The timings, as published, don't work all that well on our TV sets. When I display a frame buffer to the TV (using the recipe from the Documentation directory), some of the actual frame buffer does not show on the screen. In particular, if I have tux from the default system console framebuffer showing, the top of his head is chopped off, as is a fair amount of his left side. Further tests show that some amount of the frame buffer is not present on all margins. Is this to be expected? Can the timings be adjusted so that the whole frame buffer shows? That is to be expected. I'm not an expert on analog TVs, but I think analog TVs always have non-visible areas. Some TVs show more of the total frame, and some show less. You need to adjust the overlay position and size so that it's fully visible on the TV. I guess there are some sane defaults that are more or less ok for every TV out there, and omapfb could use those defaults, but I haven't really had time to study the TV out. [not 100% related] The documentation says that TI is working on the V4L2 support. Do you know the status of this? where I might find it? I cannot help you with this. There have been mails about it on linux-omap and v4l2 lists, so you could search those archives. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: MUSB Host problems
Pandita, Vikram wrote: -Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Tuesday, June 09, 2009 1:28 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org Subject: Re: MUSB Host problems Pandita, Vikram wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Tuesday, June 09, 2009 12:46 PM To: linux-omap@vger.kernel.org Subject: MUSB Host problems I'm trying to get MUSB Host working on my 3530 platform (very Based on your description, its not MUSB but the USBHOST EHCI block that you want to get working. Sorry, mistaken terminology. Yes, I'm trying to get the host ECHI working. similar to the Beagle). When I startup, I get this message: Clock usbhost_48m_fck didn't enable in 10 tries This is bad Why? What does it mean? How do I fix it? The ehci driver on linux-omap works for Beagleboard and sdp. so this may not be a fatal problem What does this mean? How do I fix it? Currently, the USB subsystem finds the various hubs (ports 0-2). The OTG port (0) works great. When I plug in a device to USB-1, Is this a full speed device? it sees it, but immediately gives up :-( ehci-omap ehci-omap.0: GetStatus port 1 status 001803 POWER sig=j CSC CONNECT hub 1-0:1.0: port 1: status 0501 change 0001 hub 1-0:1.0: state 7 ports 3 chg 0002 evt hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s ehci-omap ehci-omap.0: port 1 full speed -- companion Looks like your device is getting recognized as a full speed. So EHCI cannot handle it. Odd, this is a high speed device (USB 2.0). I also tried a 2.0 hub, same result. What could confuse it like this? Is it PHY mode or TLL mode? If its PHY: then the transceiver used definitely matters. SDP has ISP1504 and Beagle board has SMSC phy The 60Mhz clock is fed from omap into the Transceiver (Input clocking mode). Only few phy's in market support this. You need to have OHCI driver built in which is not present in linux-omap code base. Do, how does one use an arbitrary device on the EHCI port? Must I use a 2.0 hub? ehci-omap ehci-omap.0: GetStatus port 1 status 003801 POWER OWNER sig=j CONNECT hub 1-0:1.0: port 1 not reset yet, waiting 50ms ehci-omap ehci-omap.0: GetStatus port 1 status 003002 POWER OWNER sig=se0 CSC hub 1-0:1.0: unable to enumerate USB device on port 1 hub 1-0:1.0: state 7 ports 3 chg evt 0002 hub 1-0:1.0: hub_suspend Then it's dead. Any ideas? Note: this is unproven hardware, I'm mostly looking for ideas on how to troubleshoot the problems. Have one side working: Say have EHCI working on SDP/Beagle and then connect your device to it. As I said, unproven hardware. It turns out the PHY was [hardware strapping] set in the wrong mode. Fixing this and all seems to work. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
DSS2 TV settings
Tomi, I'm running your latest DSS2 tree and have some questions about the TV settings. The timings, as published, don't work all that well on our TV sets. When I display a frame buffer to the TV (using the recipe from the Documentation directory), some of the actual frame buffer does not show on the screen. In particular, if I have tux from the default system console framebuffer showing, the top of his head is chopped off, as is a fair amount of his left side. Further tests show that some amount of the frame buffer is not present on all margins. Is this to be expected? Can the timings be adjusted so that the whole frame buffer shows? [not 100% related] The documentation says that TI is working on the V4L2 support. Do you know the status of this? where I might find it? Thanks for your comments -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
MUSB Host problems
I'm trying to get MUSB Host working on my 3530 platform (very similar to the Beagle). When I startup, I get this message: Clock usbhost_48m_fck didn't enable in 10 tries What does this mean? How do I fix it? Currently, the USB subsystem finds the various hubs (ports 0-2). The OTG port (0) works great. When I plug in a device to USB-1, it sees it, but immediately gives up :-( ehci-omap ehci-omap.0: GetStatus port 1 status 001803 POWER sig=j CSC CONNECT hub 1-0:1.0: port 1: status 0501 change 0001 hub 1-0:1.0: state 7 ports 3 chg 0002 evt hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s ehci-omap ehci-omap.0: port 1 full speed -- companion ehci-omap ehci-omap.0: GetStatus port 1 status 003801 POWER OWNER sig=j CONNECT hub 1-0:1.0: port 1 not reset yet, waiting 50ms ehci-omap ehci-omap.0: GetStatus port 1 status 003002 POWER OWNER sig=se0 CSC hub 1-0:1.0: unable to enumerate USB device on port 1 hub 1-0:1.0: state 7 ports 3 chg evt 0002 hub 1-0:1.0: hub_suspend Then it's dead. Any ideas? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: MUSB Host problems
Pandita, Vikram wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Tuesday, June 09, 2009 12:46 PM To: linux-omap@vger.kernel.org Subject: MUSB Host problems I'm trying to get MUSB Host working on my 3530 platform (very Based on your description, its not MUSB but the USBHOST EHCI block that you want to get working. Sorry, mistaken terminology. Yes, I'm trying to get the host ECHI working. similar to the Beagle). When I startup, I get this message: Clock usbhost_48m_fck didn't enable in 10 tries This is bad Why? What does it mean? How do I fix it? What does this mean? How do I fix it? Currently, the USB subsystem finds the various hubs (ports 0-2). The OTG port (0) works great. When I plug in a device to USB-1, Is this a full speed device? it sees it, but immediately gives up :-( ehci-omap ehci-omap.0: GetStatus port 1 status 001803 POWER sig=j CSC CONNECT hub 1-0:1.0: port 1: status 0501 change 0001 hub 1-0:1.0: state 7 ports 3 chg 0002 evt hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s ehci-omap ehci-omap.0: port 1 full speed -- companion Looks like your device is getting recognized as a full speed. So EHCI cannot handle it. Odd, this is a high speed device (USB 2.0). I also tried a 2.0 hub, same result. What could confuse it like this? You need to have OHCI driver built in which is not present in linux-omap code base. Do, how does one use an arbitrary device on the EHCI port? Must I use a 2.0 hub? ehci-omap ehci-omap.0: GetStatus port 1 status 003801 POWER OWNER sig=j CONNECT hub 1-0:1.0: port 1 not reset yet, waiting 50ms ehci-omap ehci-omap.0: GetStatus port 1 status 003002 POWER OWNER sig=se0 CSC hub 1-0:1.0: unable to enumerate USB device on port 1 hub 1-0:1.0: state 7 ports 3 chg evt 0002 hub 1-0:1.0: hub_suspend Then it's dead. Any ideas? Note: this is unproven hardware, I'm mostly looking for ideas on how to troubleshoot the problems. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS porting problems
Tomi Valkeinen wrote: On Thu, 2009-06-04 at 23:22 +0200, ext Gary Thomas wrote: I'm porting my platform (3530, very similar to LDP) to your tree. http://www.bat.org/~tomba/git/linux-omap-dss.git Since you have complete support for the 3430SDP, I started with that board file. I've added my own display (larger Hitachi screen that is 800x600). I've run into a few problems: * All output to the main frame buffer (/dev/fb0) seems to go to the very last line of the display. Difficult to say anything about this. The problem could be in the board file configuration, or in the panel driver. So the question remains - how do I debug this? I have a straight forward LCD panel, much like what's on LDP or Beagle (the two I know about), just a different model with larger size. I cloned the panel description from the sharp_ls and changed the dimensions. * The documentation (Documentation/arm/OMAP/DSS) does not seem to match what's in sysfs. In particular, there are no horizontal or vertical fields in the displayN tree. This makes the examples of how to clone, etc, not work. Thanks, I pushed a fix for the documentation. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
DSS porting problems
I'm porting my platform (3530, very similar to LDP) to your tree. http://www.bat.org/~tomba/git/linux-omap-dss.git Since you have complete support for the 3430SDP, I started with that board file. I've added my own display (larger Hitachi screen that is 800x600). I've run into a few problems: * All output to the main frame buffer (/dev/fb0) seems to go to the very last line of the display. * The documentation (Documentation/arm/OMAP/DSS) does not seem to match what's in sysfs. In particular, there are no horizontal or vertical fields in the displayN tree. This makes the examples of how to clone, etc, not work. Any ideas what I should look at? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS2: How to test TV and LCD output simulatenously
Venkatesh, Subbu wrote: Hi, I have DSS2 ported on LDP board, I could manage to get output display on TV and LCD interface individually, also tested some of the features like Rotation and Mirroring, they worked with out any problem. What does DSS2 ported on LDP board mean? What source tree/branch did you use? Now I am trying to get output both on TV and LCD simultaneously, I was not successful with my approach that I tried, like 1. Boot the kernel with the default LCD display 2. Then I enabled ntsc timings for TV, as PAL do not work on it. #echo ntsc /sys/devices/platform/omapdss/display1/timings 3. Enabled TV # echo 1 /sys/devices/platform/omapdss/display1/enable and did the common fb test But it did not seem to work. Its nice if someone has different working approach or can suggest me where I am going wrong in the above steps. Is this stuff documented somewhere? Like the difference between DSS1 and DSS2? How the various layers and overlays are supposed to work? What about the camera interface? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS2: How to test TV and LCD output simulatenously
Venkatesh, Subbu wrote: Hi Gary, LDP is a development board, I have to work on LDP panel driver and BSP code to support new DSS2, It is ported on linux-omap tree. I am still working on testing the features. For camera I might move into V4l2, but I cannot confirm this, I am still working on testing the Framebuffer features. How much of this can you share? I'd like to try this on my LDP (Zoom1) and then get it ported to my own hardware (very similar to Zoom1) Thanks From: Gary Thomas [g...@mlbassoc.com] Sent: Tuesday, June 02, 2009 6:52 AM To: Venkatesh, Subbu Cc: linux-omap@vger.kernel.org; Shah, Hardik; tomi.valkei...@nokia.com Subject: Re: DSS2: How to test TV and LCD output simulatenously Venkatesh, Subbu wrote: Hi, I have DSS2 ported on LDP board, I could manage to get output display on TV and LCD interface individually, also tested some of the features like Rotation and Mirroring, they worked with out any problem. What does DSS2 ported on LDP board mean? What source tree/branch did you use? Now I am trying to get output both on TV and LCD simultaneously, I was not successful with my approach that I tried, like 1. Boot the kernel with the default LCD display 2. Then I enabled ntsc timings for TV, as PAL do not work on it. #echo ntsc /sys/devices/platform/omapdss/display1/timings 3. Enabled TV # echo 1 /sys/devices/platform/omapdss/display1/enable and did the common fb test But it did not seem to work. Its nice if someone has different working approach or can suggest me where I am going wrong in the above steps. Is this stuff documented somewhere? Like the difference between DSS1 and DSS2? How the various layers and overlays are supposed to work? What about the camera interface? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS2: How to test TV and LCD output simulatenously
Venkatesh, Subbu wrote: Hello Gary, I have already emailed the patch, here is the link.. http://patchwork.kernel.org/patch/24196/ Thanks, I'll give it a try. From: Gary Thomas [g...@mlbassoc.com] Sent: Tuesday, June 02, 2009 10:38 AM To: Venkatesh, Subbu Cc: linux-omap@vger.kernel.org; Shah, Hardik; tomi.valkei...@nokia.com Subject: Re: DSS2: How to test TV and LCD output simulatenously Venkatesh, Subbu wrote: Hi Gary, LDP is a development board, I have to work on LDP panel driver and BSP code to support new DSS2, It is ported on linux-omap tree. I am still working on testing the features. For camera I might move into V4l2, but I cannot confirm this, I am still working on testing the Framebuffer features. How much of this can you share? I'd like to try this on my LDP (Zoom1) and then get it ported to my own hardware (very similar to Zoom1) Thanks From: Gary Thomas [g...@mlbassoc.com] Sent: Tuesday, June 02, 2009 6:52 AM To: Venkatesh, Subbu Cc: linux-omap@vger.kernel.org; Shah, Hardik; tomi.valkei...@nokia.com Subject: Re: DSS2: How to test TV and LCD output simulatenously Venkatesh, Subbu wrote: Hi, I have DSS2 ported on LDP board, I could manage to get output display on TV and LCD interface individually, also tested some of the features like Rotation and Mirroring, they worked with out any problem. What does DSS2 ported on LDP board mean? What source tree/branch did you use? Now I am trying to get output both on TV and LCD simultaneously, I was not successful with my approach that I tried, like 1. Boot the kernel with the default LCD display 2. Then I enabled ntsc timings for TV, as PAL do not work on it. #echo ntsc /sys/devices/platform/omapdss/display1/timings 3. Enabled TV # echo 1 /sys/devices/platform/omapdss/display1/enable and did the common fb test But it did not seem to work. Its nice if someone has different working approach or can suggest me where I am going wrong in the above steps. Is this stuff documented somewhere? Like the difference between DSS1 and DSS2? How the various layers and overlays are supposed to work? What about the camera interface? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS2: How to test TV and LCD output simulatenously
Gary Thomas wrote: Venkatesh, Subbu wrote: Hello Gary, I have already emailed the patch, here is the link.. http://patchwork.kernel.org/patch/24196/ Thanks, I'll give it a try. I applied this patch to Tomi's tree (cloned today), but no joy: http://www.bat.org/~tomba/git/linux-omap-dss.git commit 72f7d3309a25dd9f39c292aa15e41a719a734867 CC arch/arm/mach-omap2/board-ldp.o /local/linux-omap-dss/arch/arm/mach-omap2/board-ldp.c:317: warning: 'struct omap_display' declared inside parameter list /local/linux-omap-dss/arch/arm/mach-omap2/board-ldp.c:317: warning: its scope is only this definition or declaration, which is probably not what you want /local/linux-omap-dss/arch/arm/mach-omap2/board-ldp.c:332: warning: 'struct omap_display' declared inside parameter list /local/linux-omap-dss/arch/arm/mach-omap2/board-ldp.c:342: error: variable 'omap_ldp_display_data_tv' has initializer but incomplete type How do I get a working tree with this patch applied? From: Gary Thomas [g...@mlbassoc.com] Sent: Tuesday, June 02, 2009 10:38 AM To: Venkatesh, Subbu Cc: linux-omap@vger.kernel.org; Shah, Hardik; tomi.valkei...@nokia.com Subject: Re: DSS2: How to test TV and LCD output simulatenously Venkatesh, Subbu wrote: Hi Gary, LDP is a development board, I have to work on LDP panel driver and BSP code to support new DSS2, It is ported on linux-omap tree. I am still working on testing the features. For camera I might move into V4l2, but I cannot confirm this, I am still working on testing the Framebuffer features. How much of this can you share? I'd like to try this on my LDP (Zoom1) and then get it ported to my own hardware (very similar to Zoom1) Thanks From: Gary Thomas [g...@mlbassoc.com] Sent: Tuesday, June 02, 2009 6:52 AM To: Venkatesh, Subbu Cc: linux-omap@vger.kernel.org; Shah, Hardik; tomi.valkei...@nokia.com Subject: Re: DSS2: How to test TV and LCD output simulatenously Venkatesh, Subbu wrote: Hi, I have DSS2 ported on LDP board, I could manage to get output display on TV and LCD interface individually, also tested some of the features like Rotation and Mirroring, they worked with out any problem. What does DSS2 ported on LDP board mean? What source tree/branch did you use? Now I am trying to get output both on TV and LCD simultaneously, I was not successful with my approach that I tried, like 1. Boot the kernel with the default LCD display 2. Then I enabled ntsc timings for TV, as PAL do not work on it. #echo ntsc /sys/devices/platform/omapdss/display1/timings 3. Enabled TV # echo 1 /sys/devices/platform/omapdss/display1/enable and did the common fb test But it did not seem to work. Its nice if someone has different working approach or can suggest me where I am going wrong in the above steps. Is this stuff documented somewhere? Like the difference between DSS1 and DSS2? How the various layers and overlays are supposed to work? What about the camera interface? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: DSS2: How to test TV and LCD output simulatenously
Venkatesh, Subbu wrote: Hi Gary, I just got to know Tomi's tree underwent lots of changes after mailing this patch, since Tomi has no target to commit, so I will update my tree and resend the patch, let me know. Yes, that would be appreciated. I had a look at the commits in Tomi's tree since May 14 (latest date which your patch _might_ be OK) and they are significant. Looking forward to your updated patch. Thanks From: Gary Thomas [g...@mlbassoc.com] Sent: Tuesday, June 02, 2009 2:02 PM To: Venkatesh, Subbu Cc: linux-omap@vger.kernel.org; Shah, Hardik; tomi.valkei...@nokia.com Subject: Re: DSS2: How to test TV and LCD output simulatenously Gary Thomas wrote: Venkatesh, Subbu wrote: Hello Gary, I have already emailed the patch, here is the link.. http://patchwork.kernel.org/patch/24196/ Thanks, I'll give it a try. I applied this patch to Tomi's tree (cloned today), but no joy: http://www.bat.org/~tomba/git/linux-omap-dss.git commit 72f7d3309a25dd9f39c292aa15e41a719a734867 CC arch/arm/mach-omap2/board-ldp.o /local/linux-omap-dss/arch/arm/mach-omap2/board-ldp.c:317: warning: 'struct omap_display' declared inside parameter list /local/linux-omap-dss/arch/arm/mach-omap2/board-ldp.c:317: warning: its scope is only this definition or declaration, which is probably not what you want /local/linux-omap-dss/arch/arm/mach-omap2/board-ldp.c:332: warning: 'struct omap_display' declared inside parameter list /local/linux-omap-dss/arch/arm/mach-omap2/board-ldp.c:342: error: variable 'omap_ldp_display_data_tv' has initializer but incomplete type How do I get a working tree with this patch applied? From: Gary Thomas [g...@mlbassoc.com] Sent: Tuesday, June 02, 2009 10:38 AM To: Venkatesh, Subbu Cc: linux-omap@vger.kernel.org; Shah, Hardik; tomi.valkei...@nokia.com Subject: Re: DSS2: How to test TV and LCD output simulatenously Venkatesh, Subbu wrote: Hi Gary, LDP is a development board, I have to work on LDP panel driver and BSP code to support new DSS2, It is ported on linux-omap tree. I am still working on testing the features. For camera I might move into V4l2, but I cannot confirm this, I am still working on testing the Framebuffer features. How much of this can you share? I'd like to try this on my LDP (Zoom1) and then get it ported to my own hardware (very similar to Zoom1) Thanks From: Gary Thomas [g...@mlbassoc.com] Sent: Tuesday, June 02, 2009 6:52 AM To: Venkatesh, Subbu Cc: linux-omap@vger.kernel.org; Shah, Hardik; tomi.valkei...@nokia.com Subject: Re: DSS2: How to test TV and LCD output simulatenously Venkatesh, Subbu wrote: Hi, I have DSS2 ported on LDP board, I could manage to get output display on TV and LCD interface individually, also tested some of the features like Rotation and Mirroring, they worked with out any problem. What does DSS2 ported on LDP board mean? What source tree/branch did you use? Now I am trying to get output both on TV and LCD simultaneously, I was not successful with my approach that I tried, like 1. Boot the kernel with the default LCD display 2. Then I enabled ntsc timings for TV, as PAL do not work on it. #echo ntsc /sys/devices/platform/omapdss/display1/timings 3. Enabled TV # echo 1 /sys/devices/platform/omapdss/display1/enable and did the common fb test But it did not seem to work. Its nice if someone has different working approach or can suggest me where I am going wrong in the above steps. Is this stuff documented somewhere? Like the difference between DSS1 and DSS2? How the various layers and overlays are supposed to work? What about the camera interface? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP3530 USB host problems
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 08:41:58PM +0100, ext Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:35:29PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:05:49PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
you have OMAP_EHCI_TLL_MODE set, you should probably use
OMAP_EHCI_PHY_MODE instead.
You can fix it via make menuconfig
I already have that; this code is still being used.
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_OMAP_EHCI_PHY_MODE=y
This is not used in the function above at all.
hmm.. true, just checked the function.
Weird, TRM says when that bit is 1, we cannot access ST_USBTLL, we
should access it when it's 0, try the following:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b3266c..122e95b 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -250,7 +250,7 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
/* Wait for TLL to be Active */
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
-(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
+(0 OMAP3430ES2_ST_USBTLL_SHIFT)))
cpu_relax();
/* perform TLL soft reset, and wait until reset is complete */
and tell us if it worked
Sadly, I've already tried this and things just continue to fall apart.
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd8062010
Internal error: : 1008 [#1]
Modules linked in:
CPU: 0Not tainted (2.6.27-omap1-svn4799-dirty14 #60)
PC is at ehci_hcd_omap_drv_probe+0x370/0x5e4
LR is at release_console_sem+0x1a8/0x1d8
Hence, my desired to figure out the TLL timeout...
keep TLL as is, the problem now seems to be a clock that should be on
and is off. Try to figure (with printk() for example) at which line the
code stops, put printk() before and after register read/write operations
during probe and omap_start_ehc(), let's see where does it dies.
any news ??
Not really; I'd like to figure out *why* this part of the USB
device isn't working, not just find a way around it...
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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: OMAP3530 USB host problems
Felipe Balbi wrote:
On Mon, Feb 23, 2009 at 02:08:12PM +0100, ext Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 08:41:58PM +0100, ext Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:35:29PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:05:49PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
you have OMAP_EHCI_TLL_MODE set, you should probably use
OMAP_EHCI_PHY_MODE instead.
You can fix it via make menuconfig
I already have that; this code is still being used.
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_OMAP_EHCI_PHY_MODE=y
This is not used in the function above at all.
hmm.. true, just checked the function.
Weird, TRM says when that bit is 1, we cannot access ST_USBTLL, we
should access it when it's 0, try the following:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b3266c..122e95b 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -250,7 +250,7 @@ static int omap_start_ehc(struct platform_device
*dev, struct usb_hcd *hcd)
/* Wait for TLL to be Active */
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
-(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
+(0 OMAP3430ES2_ST_USBTLL_SHIFT)))
cpu_relax();
/* perform TLL soft reset, and wait until reset is complete */
and tell us if it worked
Sadly, I've already tried this and things just continue to fall apart.
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd8062010
Internal error: : 1008 [#1]
Modules linked in:
CPU: 0Not tainted (2.6.27-omap1-svn4799-dirty14 #60)
PC is at ehci_hcd_omap_drv_probe+0x370/0x5e4
LR is at release_console_sem+0x1a8/0x1d8
Hence, my desired to figure out the TLL timeout...
keep TLL as is, the problem now seems to be a clock that should be on
and is off. Try to figure (with printk() for example) at which line the
code stops, put printk() before and after register read/write operations
during probe and omap_start_ehc(), let's see where does it dies.
any news ??
Not really; I'd like to figure out *why* this part of the USB
device isn't working, not just find a way around it...
It's not a way around it. That bit is wrong, one problem is fixed now
but we came to another issue which is a non-linefetch, which makes me
wonder that's a clock issue.
You should just try to fetch me for information and I might be able to
help you more.
It turns out that the various USB clocks were not enabled (this is prototype
hardware, only roughly equivalent to the OMAP3EVM and I started with a
kernel snapshot more than a month ago, so much may have changed in the
meantime). I can now get through this part of the USB host initialization
code (still doesn't work, but I think I can figure it out).
Thanks for the pointers
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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
OMAP3530 USB host problems
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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: OMAP3530 USB host problems
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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: OMAP3530 USB host problems
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
you have OMAP_EHCI_TLL_MODE set, you should probably use
OMAP_EHCI_PHY_MODE instead.
You can fix it via make menuconfig
I already have that; this code is still being used.
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_OMAP_EHCI_PHY_MODE=y
This is not used in the function above at all.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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: OMAP [TV] video
Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Tuesday, February 10, 2009 9:35 PM To: Linux OMAP Subject: OMAP [TV] video I'm trying to get TV [S-Video] working on my 3530 board. The settings in the current kernel don't seem to work very well on my TV (U.S. NTSC, standard). Comparing the video encoder setup with the suggested values in the manual, I find many differences, mostly with respect to the framing (signal shaping). Questions: * Are the settings in the kernel tree known to work [as is]? * Why the divergence from the recommended values? Any ideas or helpful pointers would be graciously accepted [Hiremath, Vaibhav] Can you provide some more details like, Which kernel version are you using? I started with the official OMAP tree (git://git.omapzoom.org/repo/omapkernel.git) If there is a better starting point, I'd certainly like to know. Trying to find the correct tree to use is challenging. Are you using DSS2 for TV out? Not sure exactly what that means. Again, trying to follow this development is not straight forward - it seems that those who know the answers assume that everyone does, so why bother explaining anything? (Maybe that's a bit cynical, but my experience so far) Which board you are using, (must be EVM)? It's a new board under development, more or less like the beagle. Again, I'd appreciate any help or pointers. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
OMAP I2C question
Why is I2C_FUNC_SMBUS_QUICK functionality missing in i2c-omap.c? This prevents using drivers which use the generic i2c_probe() method of finding devices. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP I2C question
Note: these questions should go to the mailing list, not me. I'm not an expert here, just trying to get it working as well... Alejandro Blanca G. wrote: Sorry, forgot to add that we are using the I2C tools on a Beagle, with the latest kernel (2.6.29-rc4-omap1). Regards, Alex B. On Wed, Feb 11, 2009 at 11:36 AM, Alejandro Blanca G. alex.bla...@gmail.com wrote: Hi Gary. Would this prevent the I2C tools (http://www.lm-sensors.org/wiki/I2CTools) from working? In the latest kernels we've built, we have been unable to use i2cdetect to verify the presence of I2C devices. The error we get is: Error: Can't use SMBus Quick Write command on this bus (ISA bus?). From the description you provide, it seems related. Best regards, Alex B. On Wed, Feb 11, 2009 at 10:58 AM, Gary Thomas g...@mlbassoc.com wrote: Why is I2C_FUNC_SMBUS_QUICK functionality missing in i2c-omap.c? This prevents using drivers which use the generic i2c_probe() method of finding devices. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
OMAP [TV] video
I'm trying to get TV [S-Video] working on my 3530 board. The settings in the current kernel don't seem to work very well on my TV (U.S. NTSC, standard). Comparing the video encoder setup with the suggested values in the manual, I find many differences, mostly with respect to the framing (signal shaping). Questions: * Are the settings in the kernel tree known to work [as is]? * Why the divergence from the recommended values? Any ideas or helpful pointers would be graciously accepted Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
OMAP TV video
Note: if this is the wrong list, or if there's a better place to ask these questions, please redirect me. I have an OMAP/Zoom1 (3430 LDP). I'm trying to use the S-Video output, without much success. Today, I grabbed the latest tree (as least from what I can gather from various web pages) from git://git.omapzoom.org/repo/omapkernel.git When I try to use the TV, the kernel crashes immediately: Unhandled fault: external abort on non-linefetch (0x1008) at 0xd8050440 Internal error: : 1008 [#1] Modules linked in: CPU: 0Not tainted (2.6.27.10-omap1-00181-gc9fd795 #1) PC is at omap2_disp_enable_output_dev+0x30/0x44 LR is at write_layer_out+0x118/0x220 pc : [c0053a84]lr : [c018f3d4]psr: 6013 sp : c7963ec8 ip : c7963ed8 fp : c7963ed4 r10: c7963f70 r9 : c7940e78 r8 : c039c8f0 r7 : r6 : 0003 r5 : c78626f8 r4 : c03c3c44 r3 : r2 : d805 r1 : 0003 r0 : 0005 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 00c5387f Table: 87320018 DAC: 0015 Process echo (pid: 723, stack limit = 0xc79622e0) kernel version: Linux version 2.6.27.10-omap1-00181-gc9fd795 config: omap_ldp_defconfig Notes: * An older kernel (circa 2008-12-01) does not crash. The TV output is not correct, but at least it doesn't crash. * How can I turn off the double printk()? All kernel messages get duplicated and it makes it terribly hard to use. e.g. 5Looking up port of RPC 13/2 on 192.168.1.100 Looking up port of RPC 13/2 on 192.168.1.100 5Looking up port of RPC 15/1 on 192.168.1.100 Looking up port of RPC 15/1 on 192.168.1.100 VFS: Mounted root (nfs filesystem). VFS: Mounted root (nfs filesystem). Other kernels (PowerPC, etc) don't suffer from this. * This kernel version is very unstable - it simply quits after just a few moments of running. I didn't see this with the older kernel. Thanks for any ideas/pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP TV video
Imre Deak wrote: On Wed, Feb 04, 2009 at 03:57:37PM +0100, ext Gary Thomas wrote: Note: if this is the wrong list, or if there's a better place to ask these questions, please redirect me. I have an OMAP/Zoom1 (3430 LDP). I'm trying to use the S-Video output, without much success. Today, I grabbed the latest tree (as least from what I can gather from various web pages) from git://git.omapzoom.org/repo/omapkernel.git When I try to use the TV, the kernel crashes immediately: Unhandled fault: external abort on non-linefetch (0x1008) at 0xd8050440 I'm guessing that the external abort is caused by the DSS interface clock being disabled. How can I fix it? Am I missing some setup? How am I supposed to use the S-Video (TV) interface? Currently, I'm executing this (which used to work): echo tv /sys/class/display_control/omap_disp_control/graphics -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: OMAP TV video
Gary Thomas wrote: Imre Deak wrote: On Wed, Feb 04, 2009 at 03:57:37PM +0100, ext Gary Thomas wrote: Note: if this is the wrong list, or if there's a better place to ask these questions, please redirect me. I have an OMAP/Zoom1 (3430 LDP). I'm trying to use the S-Video output, without much success. Today, I grabbed the latest tree (as least from what I can gather from various web pages) from git://git.omapzoom.org/repo/omapkernel.git When I try to use the TV, the kernel crashes immediately: Unhandled fault: external abort on non-linefetch (0x1008) at 0xd8050440 I'm guessing that the external abort is caused by the DSS interface clock being disabled. How can I fix it? Am I missing some setup? How am I supposed to use the S-Video (TV) interface? Currently, I'm executing this (which used to work): echo tv /sys/class/display_control/omap_disp_control/graphics Interestingly, this sort of worked (no kernel crash) when I disabled Power Management. Sadly, it quit/vanished after some scant few seconds... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
