Watchdog dump
I got a watchdog dump and it said cut here so I did and I am pasting to get help eth0: link down Sending DHCP requests .. eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1 .. [ cut here ] WARNING: at net/sched/sch_generic.c:246 dev_watchdog+0x18c/0x29c() NETDEV WATCHDOG: eth0 (dm9000): transmit queue 0 timed out Modules linked in: Backtrace: [] (dump_backtrace+0x0/0x114) from [] (dump_stack+0x18/0x1c) r7:c03b3e10 r6:c0256344 r5:c038ad99 r4:00f6 [] (dump_stack+0x0/0x1c) from [] (warn_slowpath_common+0x50) [] (warn_slowpath_common+0x0/0x68) from [] (warn_slowpath_f) r7:0024 r6:c04043a0 r5:c48d7400 r4: [] (warn_slowpath_fmt+0x0/0x38) from [] (dev_watchdog+0x18c) r3:c48d7400 r2:c038adb1 [] (dev_watchdog+0x0/0x29c) from [] (run_timer_softirq+0x1b) [] (run_timer_softirq+0x0/0x280) from [] (__do_softirq+0x98) [] (__do_softirq+0x0/0x12c) from [] (irq_exit+0x50/0xa4) [] (irq_exit+0x0/0xa4) from [] (_text+0x74/0x8c) [] (_text+0x0/0x8c) from [] (__irq_svc+0x4c/0x90) Exception stack(0xc03b3f50 to 0xc03b3f98) 3f40: 0005317f 0005217f 6013 3f60: c03b2000 c03de420 c0023e14 c03b6358 80022334 41069265 80022300 c03b3fa4 3f80: 60d3 c03b3f98 c002a9b0 c002a9bc 6013 r5:fec48000 r4: [] (default_idle+0x0/0x38) from [] (cpu_idle+0x78/0xe4) [] (cpu_idle+0x0/0xe4) from [] (rest_init+0x70/0x84) r5:c03de420 r4:c03f2af8 [] (rest_init+0x0/0x84) from [] (start_kernel+0x268/0x2c0) [] (start_kernel+0x0/0x2c0) from [<80008034>] (0x80008034) r5:c03de4c4 r4:00053175 ---[ end trace 5b6c3710ca2a460a ]--- ., OK IP-Config: Got DHCP answer from 192.168.2.1, my address is 192.168.2.155 IP-Config: Complete: device=eth0, addr=192.168.2.155, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.155, domain=, nis-domain=(none), bootserver=192.168.2.1, rootserver=192.168.2.1, rootpath= kjournald starting. Commit interval 5 seconds The kernel continued to boot and all is well but just curious if there is something that I can do to "pet the dog" or whatever to prevent this from outputting. Thanks in Advance John Sarman -- 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: Oops on shutdown?
On Thu, Aug 20, 2009 at 11:34 AM, Steve Sakoman wrote: > I've been doing a bit of testing on 2.6.31-rc5 on Overo with good > results overall. Related to the Gumstix Overo How is the USB working on this version. I am still stuck using the 2.6.20-rc8, with patches for the hwmod and mmc updates. This is the last version I can successfully use the USB host. > > The only major issue I see at the moment is an oops on shutdown/restart. > > Is anyone else seeing this? > > Rebooting... Internal error: Oops - undefined instruction: 0 [#1] > Modules linked in: ipv6 udf libertas_sdio libertas lib80211 sg sr_mod > cdrom uvcvideo videodev v4l1_compat ads7846 > CPU: 0 Not tainted (2.6.31-rc5-omap1 #1) > PC is at 0xcf8ab014 > LR is at usb_hcd_platform_shutdown+0x20/0x28 > pc : [] lr : [] psr: a013 > sp : cb307e60 ip : 0001 fp : 0001 > r10: r9 : cb306000 r8 : c00eefc4 > r7 : 006c r6 : fee1dead r5 : c0635258 r4 : c05bcae8 > r3 : cf8aae88 r2 : cf802c20 r1 : c05bcdc0 r0 : cf8a4b60 > Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 10c5387d Table: 8a31c019 DAC: 0015 > Process reboot (pid: 10985, stack limit = 0xcb3062f0) > Stack: (0xcb307e60 to 0xcb308000) > 7e60: c0635258 c02dcbc8 c00eefc4 c02d874c 28121969 c0121840 > 7e80: 400d8000 c012188c 01234567 c01219a0 cf8652c0 cb2eff40 400d8000 > 7ea0: ca31c000 0200 cfbd5680 c01684ac 00b2 cf8bc168 > 7ec0: cb307f10 00d8 0360 ca31d000 00d0 c0639124 > 7ee0: 400d8000 cf8652c0 ca14dca0 c03a6110 0200 400d8000 cf8652c0 c00f457c > 7f00: ca14dca0 ca14dd40 ca990848 cf67b418 00200200 00100100 cf401398 > 7f20: cf67b418 00200200 00100100 cf67b418 cf80a620 c0189480 cf67b418 cf67b418 > 7f40: c05cacd4 c0189be0 ca990848 0021 caba28a0 c017b630 > 7f60: 0003 caba28a0 caba28a0 cb0bbe40 > 7f80: 0006 c01784d4 0003 cb0bbe40 caba28a0 0001 0004 > 7fa0: 0058 c00eee40 0001 fee1dead 28121969 01234567 006c > 7fc0: 0001 0004 0058 0001 0001 0001 > 7fe0: 400e0880 bedd1cb0 9210 400e0898 6010 fee1dead > Code: cf8a3000 0158 cf8ab158 004e () > ---[ end trace 59776612ba8fbf0c ]--- > Segmentation fault > -- > 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
Re: TI OMAP 3503 GPIO signal I/O standard for interfacing with FPGA
On Fri, Aug 14, 2009 at 3:14 PM, Philip Balister wrote: > John Sarman wrote: >> >> On Thu, Aug 13, 2009 at 9:29 AM, Elvis Dowson wrote: >>> >>> Hi John, >>> >>> On Aug 13, 2009, at 5:14 PM, John Sarman wrote: >>> >>>> >>>> >>>> General Purpose Memory Controller (GPMC) >>>> >>>> * 16-bit Wide Multiplexed Address/Data Bus >>>> * Up to 8 Chip Select Pins With 128M-Byte Address Space per Chip Select >>>> Pin >>>> * Glueless Interface to NOR Flash, NAND Flash (With ECC Hamming >>>> Code Calculation), SRAM and Pseudo-SRAM >>>> * Flexible Asynchronous Protocol Control for Interface to Custom >>>> Logic (FPGA, CPLD, ASICs, etc.) >>>> * Nonmultiplexed Address/Data Mode (Limited 2K-Byte Address Space) >>>> >>> >>> Thanks for the info, I've read that section on the GPMC. I'm going to >>> attempt this in stages. First I'll implement a simple protocol between >>> the >>> OMAP and the FPGA, e.g. use GPIOs to signal read and write operations, >>> and >>> the serial UART0 to transfer data to a memory location for the FPGA to >>> process and return the result. >>> >>> Since the TI OMAP uses 1.8v signalling, I can directly interface it with >>> the >>> Virtex-5 and get a simple prototype up and running. >>> >>> After that, create a TI OMAP GPMC to PLB v4.6 Bus Bridge, to make the >>> GPMC >>> requests appear in the FPGA PLB bus, so that it can access the FPGA >>> devices >>> and peripherals connected to the PLB bus. I'm using the gumstix Overo for >>> these tests, and the GPMC signals are not available on the Palo43 or >>> summit >>> expansion boards. It is available on the Overo J4/J6 connector though, >>> but >>> that needs a custom board to bring those signals out. >>> >>> Do you know if any other TI OMAP 35xx development board exposes the GPMC >>> connectors? I just want to finish the software/firmware part before >>> starting >>> work on a custom expansion board. >> >> >> I had to build a custom board for my project, I would recommend taking >> that approach if possible. > > Gumstix Overo? Yeah using the Overo. I whipped up a board with 4 port USB Host, 1 OTG, the smsc911x ethernet controller. and msp430 to control some peripherials, 3rd MMC, etc, etc. My favorite part was the 70 Watt dual power supply (5V,3.3V). The gumstix uses about 1-2 watts so a little overkill on the supply, but it can cook right through a pencil lead :) Gumstix site has excellent docs to be able to build an expansion board. Makes more sense with these fine pitch connectors to build a proper test board rather than try to bread board up two demo boards. John > > Philip > -- 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: TI OMAP 3503 GPIO signal I/O standard for interfacing with FPGA
On Thu, Aug 13, 2009 at 9:29 AM, Elvis Dowson wrote: > Hi John, > > On Aug 13, 2009, at 5:14 PM, John Sarman wrote: > >> >> >> >> General Purpose Memory Controller (GPMC) >> >> * 16-bit Wide Multiplexed Address/Data Bus >> * Up to 8 Chip Select Pins With 128M-Byte Address Space per Chip Select >> Pin >> * Glueless Interface to NOR Flash, NAND Flash (With ECC Hamming >> Code Calculation), SRAM and Pseudo-SRAM >> * Flexible Asynchronous Protocol Control for Interface to Custom >> Logic (FPGA, CPLD, ASICs, etc.) >> * Nonmultiplexed Address/Data Mode (Limited 2K-Byte Address Space) >> > > Thanks for the info, I've read that section on the GPMC. I'm going to > attempt this in stages. First I'll implement a simple protocol between the > OMAP and the FPGA, e.g. use GPIOs to signal read and write operations, and > the serial UART0 to transfer data to a memory location for the FPGA to > process and return the result. > > Since the TI OMAP uses 1.8v signalling, I can directly interface it with the > Virtex-5 and get a simple prototype up and running. > > After that, create a TI OMAP GPMC to PLB v4.6 Bus Bridge, to make the GPMC > requests appear in the FPGA PLB bus, so that it can access the FPGA devices > and peripherals connected to the PLB bus. I'm using the gumstix Overo for > these tests, and the GPMC signals are not available on the Palo43 or summit > expansion boards. It is available on the Overo J4/J6 connector though, but > that needs a custom board to bring those signals out. > > Do you know if any other TI OMAP 35xx development board exposes the GPMC > connectors? I just want to finish the software/firmware part before starting > work on a custom expansion board. I had to build a custom board for my project, I would recommend taking that approach if possible. > > Best regards, > > Elvis > > -- 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: TI OMAP 3503 GPIO signal I/O standard for interfacing with FPGA
On Wed, Aug 12, 2009 at 10:13 AM, Elvis Dowson wrote: > Hi John, > > On Aug 12, 2009, at 4:54 PM, John Sarman wrote: > >> Use LVCMOS at 1.8V if you can not use 1.8 V (get another FPGA, just >> kidding) then you will need a buffer (level translator) between them. > > Thanks for the info. I think I have support for LVCMOS at 1.8v on the > Virtex-5. :-) > > BTW, what about the GPMC controller, does same signal I/O standard apply? LVCMOS Single ended standard IO for low power low voltage. LVTTL Single ended standard IO for compatiblity with older technologies, can sink souce more current and have higher voltage tolerances. HSTL differential pair, no good for GPMC SSTL SSTL_18 Series Stub Terminated, used with DDR II memory; requires Vddq = 1.8v, Vt = 0.5 x Vddq. Worth doing research to see if this would make sense for the GPMC. GTL is a backplane Ghz IO only swings to 1.2V PCI for interfacing with the PCI bus, so again probably not. I would look into SSTL if you are going to interface the FPGA with the OMAP as if the FPGA appears as a memory device. Not 100% sure though. General Purpose Memory Controller (GPMC) * 16-bit Wide Multiplexed Address/Data Bus * Up to 8 Chip Select Pins With 128M-Byte Address Space per Chip Select Pin * Glueless Interface to NOR Flash, NAND Flash (With ECC Hamming Code Calculation), SRAM and Pseudo-SRAM * Flexible Asynchronous Protocol Control for Interface to Custom Logic (FPGA, CPLD, ASICs, etc.) * Nonmultiplexed Address/Data Mode (Limited 2K-Byte Address Space) John > > Best regards, > > Elvis > > -- 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: TI OMAP 3503 GPIO signal I/O standard for interfacing with FPGA
On Tue, Aug 11, 2009 at 3:12 PM, Elvis Dowson wrote: > Hi, > If I have to interface the TI OMAP 3503 GPIO signals to an FPGA > (Xilinx Virtex-5), which I/O standard should I use. Use LVCMOS at 1.8V if you can not use 1.8 V (get another FPGA, just kidding) then you will need a buffer (level translator) between them. I had great success with http://focus.ti.com/docs/prod/folders/print/txs0108e.html (TXS0108) 8-channel push-pull/ open drain level transceiver. John Sarman > > The options available to me for single ended I/O on the FPGA are : LVCMOS, > LVTTL, HSTL, SSTL, GTL, PCI > > Best regards, > > Elvis > -- > 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
MMC3 Overo
On Wed, Aug 5, 2009 at 2:35 PM, Kevin Hilman wrote: > Steve Sakoman wrote: >> >> On Wed, Aug 5, 2009 at 10:58 AM, Kevin >> Hilman wrote: >>> >>> Steve Sakoman wrote: And up to now in each case I shrug and say "no time to do that now, I'll just leave kernel pinmuxing turned off and do it in u-boot" >>> >>> I agree there are lots of shortcomings in the current mux code and we've >>> been hitting them regularily lately. >>> >>> That being said, for mux settings that done one-time only at boot, what >>> are >>> the problems you're running into? >> >> It's been a few months since I last encountered this, so the exact >> details are a bit fuzzy. >> >> I seem to recall that there were some basic issues with enabling >> kernel pinmuxing in that some of the setup that was done for all >> machines was just wrong for my particular machine. IIRC, it was due >> to assumptions about which pad was used for a particular function (for >> those functions which can be steered to multiple GPIO pads). >> >> So I faced having to undo that change in my board file as well as any >> issues that may have arisen from glitches on the GPIO pins during the >> process. And since there were several of these I gave up and turned >> off kernel pinmuxing. >> >> I'd be happy if we cleaned up the "one size fits all" pinmuxing to >> just that subset that truly does fit all boards, and leave the rest to >> the board files. I'd also be content to have it all done in the board >> file for each machine. > > Indeed, any assumptions about common muxing that are not indeed common are > bugs and should be fixed. > > The "right" solution is to have everything in the kernel, and split across > SoC "common" init and board specific init. Of course u-boot > will still have to do some early muxing, but it should be redone in > the kernel so it's trivial to change bootloaders. > > So the real missing piece is someone to step up and rework the mux code. > The bigger problem is that the vast majority of folks don't care about the > common case and only care about getting thing working for a specific > platform. > > Kevin > I like the idea of having the board file configure the mux. First of all lets address the shortcomings of mux.h. The Pin values are labeled as so: * NOTE: Please use the following naming style for new pin entries. * For example, W8_1610_MMC2_DAT0, where: * - W8 = ball * - 1610 = 1510 or 1610, none if common for both 1510 and 1610 * - MMC2_DAT0 = function But lets take the 3530 as an example. The 3530 has three separate packages. CBB, CBC, and CUS. Now lets look at MMC3_clk (the root of my original problem that started this thread) CBB CBC CUS mmc3_clk AB1 / AF10 R9 / AB2 AC1 So to properly add these to mux.h we need to add 5 entries for mmc3_clk AB1_35XXCBB_MMC3_CLK AF10_35XXCBB_MMC3_CLK R9_35XXCBC_MMC3_CLK AB2_35XXCBC_MMC3_CLK AC1_35XXCUS_MMC3_CLK We would then have to update mux.c making sure the position matches and add the proper settings. So this is obviously a maintenance nightmare. Another option is to add a CONFIG_35XX_CBB or CBC or CUS when selecting a board example in menuconfig selecting MACH_OVERO would select CONFIG_35XX_CBB. Then in a new mux_35xx.h located in the mach_omap2 folder have #ifdef CONFIG_35XX_CBB //all muxable balls #define N4 0x078 #define AB1 0x164 etc . #endif where we just use the Ball name defined as its offset in the 35xx case then we create a file say board_overo_mux.c in it we call configure_pin(AB1, MODE3, INPUT | PU | PE); for every ball that is muxable. voila, we have a predefined limit of pins so once mux_35xx.h is fully defined, and the driver code is in place then the only thing that a developer would need to do to leverage the mux is edit his board file. Im sure I have glossed ove many details but this is a general outline. -- 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: Fwd: MMC3 Overo
On Wed, Aug 5, 2009 at 12:25 PM, Kevin Hilman wrote: > John Sarman writes: > >> -- Forwarded message -- >> From: John Sarman >> Date: Wed, Aug 5, 2009 at 12:01 PM >> Subject: Re: MMC3 Overo >> To: Grazvydas Ignotas >> >> >> On Wed, Aug 5, 2009 at 4:32 AM, Grazvydas Ignotas wrote: >>>> >>>> MUX_VAL(CP(ETK_CLK_ES2), (IDIS | PTU | EN | M2)) /*MMC3_CLK*/\ >>> >>> You must have input enable on CLK line for MMC3 or it won't work for >>> some reason (MMC 1 and 2 doesn't need that). Without this part of the >>> host controller hardware doesn't get the clock I guess, or something >>> like that. You won't believe how much time we've wasted on this! >>> >> MUX_VAL(CP(ETK_CLK_ES2), (IEN | PTU | EN | M2)) /*MMC3_CLK*/\ >> >> Works Beautifully, Thank you so much. I have also burnt too much >> midnight oil on this problem. >> So looks like Overo MMC3 works like a champ! > > Might I suggest a kernel patch for this rather than fixing u-boot so that > all the midnight oil you've burnt does not have to be duplicated by others. Well I dont know how to answer that. Because the Mux architecture is slightly on the scary side. I personally have had success with it, but everytime you need to add a new pin functionality you have to update mux.h. I finally decided to just focus on having the MUX correct at boot up via u-boot. I could just add the code to update the mux without using the mux architecture. I would appreciate some opinions on this. > > Thanks, > > Kevin > -- 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
Fwd: MMC3 Overo
-- Forwarded message -- From: John Sarman Date: Wed, Aug 5, 2009 at 12:01 PM Subject: Re: MMC3 Overo To: Grazvydas Ignotas On Wed, Aug 5, 2009 at 4:32 AM, Grazvydas Ignotas wrote: >> >> MUX_VAL(CP(ETK_CLK_ES2), (IDIS | PTU | EN | M2)) /*MMC3_CLK*/\ > > You must have input enable on CLK line for MMC3 or it won't work for > some reason (MMC 1 and 2 doesn't need that). Without this part of the > host controller hardware doesn't get the clock I guess, or something > like that. You won't believe how much time we've wasted on this! > MUX_VAL(CP(ETK_CLK_ES2), (IEN | PTU | EN | M2)) /*MMC3_CLK*/\ Works Beautifully, Thank you so much. I have also burnt too much midnight oil on this problem. So looks like Overo MMC3 works like a champ! John Sarman -- 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: MMC3 Overo
On Sun, Aug 2, 2009 at 9:20 PM, Paul Walmsley wrote:
> Hello John,
>
> you are using the PM branch, correct?
>
> On Thu, 30 Jul 2009, John Sarman wrote:
>
>> On Thu, Jul 30, 2009 at 11:49 AM, John Sarman wrote:
>> > I am trying to use mmc3 on the Overo Gumstix board with no luck. I
>> > have patched the kernel with the latest changes and have yet to see a
>> > clk pulse, both before and after the patches.
>> After adding some debugging printks, I have determined the mmc3 fails
>> getting IRQ
>> mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
>> REQUEST IRQ = 83 HOST = -812068416
>> mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
>> REQUEST IRQ = 86 HOST = -812067392
>> mmci-omap-hs mmci-omap-hs.2: Failed to get debounce clock
>> REQUEST IRQ = 83 HOST = -812066368
>> mmci-omap-hs mmci-omap-hs.2: Unable to grab HSMMC IRQ
>> mmci-omap-hs mmci-omap-hs.2: Probe Failed
>> mmci-omap-hs: probe of mmci-omap-hs.2 failed with error -16
>>
>> For some reason mmc1 and mmc3 ask for the same interrupt 83 ???
>>
>> Why would this be assigned the same value?
>
> Developer error. Does this patch fix it for you?
That fixed it. However I still am not having success. I have
tracked down my problem to the omap_hsmmc interrupt. When the code
initializes with CMD8 the interrupt is triggered with a timeout. I
have probed the SD 2G card on the CMD line and Clock line and I see
the 400Khz clock and transitions on the CMD line. I am not 100% sure
it is not hardware but I seems to work all the way down the circuit up
to the SD card socket. Tried several cards with same results. Have
not captured the CMD stream and parsed it though. (Still looking for
a datasheet to explain the signals of SD). I read in the TRM and it
states the timeout is triggered when a command is sent and 64 clocks
occur without a response.
Still going strong on it, but I would appreciate any tips.
John
>
>
> - Paul
>
>
> From baca68c40ec3b391cdbfc0fb20ac5092b4ab7025 Mon Sep 17 00:00:00 2001
> From: Paul Walmsley
> Date: Mon, 3 Aug 2009 04:18:45 +0300
> Subject: [PATCH] OMAP3 hwmod: fix MMC3 IRQ
>
> The MMC3 IRQ is incorrect in mach-omap2/omap_hwmod_34xx.h, which causes
> MMC3 init to fail.
>
> Signed-off-by: Paul Walmsley
> ---
> arch/arm/mach-omap2/omap_hwmod_34xx.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> index 29a2d60..56215bd 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> +++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> @@ -470,7 +470,7 @@ static struct omap_hwmod omap34xx_mmc2_hwmod = {
> static struct mmc_dev_attr mmc3_dev_attr;
>
> static u8 mmc3_mpu_irqs[] = {
> - INT_24XX_MMC_IRQ,
> + INT_34XX_MMC3_IRQ,
> };
>
> static struct omap_hwmod_dma_info mmc3_sdma_chs[] = {
> --
> 1.6.3.GIT
>
--
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
Fwd: MMC3 Overo
On Mon, Aug 3, 2009 at 6:37 AM, Elvis Dowson wrote: > Hi John, > What does MMC3 on the Overo connect to? MMC3 connects to one of the 70 pin bottom connectors. The datasheet states that MMC3 has no PBIAS circuit so you have to interface it with 1.8V logic. I used a TXS0108 from TI as a level translator. Datasheet states "The TXS0108E device is a semi-buffered auto-direction-sensing voltage translator design is optimized for translation applications (e.g. MMC Card Interfaces) that require the system to start out in a low-speed open-drain mode and then switch to a higher speed push-pull mode." So no need for transceiver control with this IC. > > I am trying to get pm working on the overo, and I have a recipe for the > overo for v.2.6.29 (which still has some issues with mmc1) and I have > v2.6.31 latest kernel update recipe for overo that has both DSS2 and PM > integrated. Have you tested the USB host with 2.6.31 recipe yet? Definitely would like the recipe for the v2.6.31. I have tested DSS2 on 2.6.30-rc8 and either I have a user error(most likely) or it wasn't working. I attempted to backport PM but as my main concern was for MMC. I stopped after realizing it wasn't absolutely necessary to get the new mmc patches to compile. > > I can share it with you if you like. > > Best regards, > > Elvis > > John Sarman -- 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: MMC3 Overo
Paul,
On Sun, Aug 2, 2009 at 9:20 PM, Paul Walmsley wrote:
> Hello John,
>
> you are using the PM branch, correct?
Unfortunately I am not using the pm patch, because I am stuck at
2.6.30-rc8. This is because it is the last place I have usb host
working. I backported the necessary changes and pm wasn't an absolute
necessity, basically equivalent to not compiling in PM. I basically
used nearly every related patch after 6-6-09 - the 32 mmc patches.
>
> On Thu, 30 Jul 2009, John Sarman wrote:
>
>> On Thu, Jul 30, 2009 at 11:49 AM, John Sarman wrote:
>> > I am trying to use mmc3 on the Overo Gumstix board with no luck. I
>> > have patched the kernel with the latest changes and have yet to see a
>> > clk pulse, both before and after the patches.
>> After adding some debugging printks, I have determined the mmc3 fails
>> getting IRQ
>> mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
>> REQUEST IRQ = 83 HOST = -812068416
>> mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
>> REQUEST IRQ = 86 HOST = -812067392
>> mmci-omap-hs mmci-omap-hs.2: Failed to get debounce clock
>> REQUEST IRQ = 83 HOST = -812066368
>> mmci-omap-hs mmci-omap-hs.2: Unable to grab HSMMC IRQ
>> mmci-omap-hs mmci-omap-hs.2: Probe Failed
>> mmci-omap-hs: probe of mmci-omap-hs.2 failed with error -16
>>
>> For some reason mmc1 and mmc3 ask for the same interrupt 83 ???
>>
>> Why would this be assigned the same value?
>
> Developer error. Does this patch fix it for you?
>
>
> - Paul
>
>
> From baca68c40ec3b391cdbfc0fb20ac5092b4ab7025 Mon Sep 17 00:00:00 2001
> From: Paul Walmsley
> Date: Mon, 3 Aug 2009 04:18:45 +0300
> Subject: [PATCH] OMAP3 hwmod: fix MMC3 IRQ
>
> The MMC3 IRQ is incorrect in mach-omap2/omap_hwmod_34xx.h, which causes
> MMC3 init to fail.
>
> Signed-off-by: Paul Walmsley
> ---
> arch/arm/mach-omap2/omap_hwmod_34xx.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> index 29a2d60..56215bd 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> +++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> @@ -470,7 +470,7 @@ static struct omap_hwmod omap34xx_mmc2_hwmod = {
> static struct mmc_dev_attr mmc3_dev_attr;
>
> static u8 mmc3_mpu_irqs[] = {
> - INT_24XX_MMC_IRQ,
> + INT_34XX_MMC3_IRQ,
> };
>
> static struct omap_hwmod_dma_info mmc3_sdma_chs[] = {
> --
> 1.6.3.GIT
>
Thanks for the patch, I will apply that and keep on testing.
John Sarman
--
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: MMC3 Overo
On Thu, Jul 30, 2009 at 11:49 AM, John Sarman wrote:
> I am trying to use mmc3 on the Overo Gumstix board with no luck. I
> have patched the kernel with the latest changes and have yet to see a
> clk pulse, both before and after the patches.
After adding some debugging printks, I have determined the mmc3 fails
getting IRQ
mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
REQUEST IRQ = 83 HOST = -812068416
mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
REQUEST IRQ = 86 HOST = -812067392
mmci-omap-hs mmci-omap-hs.2: Failed to get debounce clock
REQUEST IRQ = 83 HOST = -812066368
mmci-omap-hs mmci-omap-hs.2: Unable to grab HSMMC IRQ
mmci-omap-hs mmci-omap-hs.2: Probe Failed
mmci-omap-hs: probe of mmci-omap-hs.2 failed with error -16
For some reason mmc1 and mmc3 ask for the same interrupt 83 ???
Why would this be assigned the same value?
> So far I have reconfigured the pins with uboot to GPIO and tested each
> pin to verify that the signals are connected properly. That test
> passed.
> Then I reconfigured them back to MODE 2(mmc modes) for each pin. I am
> confident that the level transceiver(TXS0108ERGYR) is operating
> properly. This transceiver is automatic so no external controls are
> necessary.
>
>
>
> MUX_VAL(CP(ETK_CLK_ES2), (IDIS | PTU | EN | M2)) /*MMC3_CLK*/\
> MUX_VAL(CP(ETK_CTL_ES2), (IEN | PTU | EN | M2)) /*MMC3_CMD*/\
> MUX_VAL(CP(ETK_D3_ES2), (IEN | PTU | EN | M2)) /*MMC3_DAT3*/\
> MUX_VAL(CP(ETK_D4_ES2), (IEN | PTU | EN | M2)) /*MMC3_DAT0*/\
> MUX_VAL(CP(ETK_D5_ES2), (IEN | PTU | EN | M2)) /*MMC3_DAT1*/\
> MUX_VAL(CP(ETK_D6_ES2), (IEN | PTU | EN | M2)) /*MMC3_DAT2*/\
>
>
>
> // I Switched mmc 2 and 3 in a feeble attempt. Also I removed 2 in an
> earlier attempt and the kernel would not boot ???
> // Also I have tested working gpio connected to CD and WP but not
> attempting to tackle that yet.
> static struct twl4030_hsmmc_info mmc[] = {
> {
> .mmc = 1,
> .wires = 4,
> .gpio_cd = -EINVAL,
> .gpio_wp = -EINVAL,
> },
> {
> .mmc = 3,
> .wires = 4,
> .gpio_cd = -EINVAL,
> .gpio_wp = -EINVAL,
> },
> {
> .mmc = 2,
> .wires = 4,
> .gpio_cd = -EINVAL,
> .gpio_wp = -EINVAL,
> .transceiver = true,
> .ocr_mask = 0x0010, /* 3.3V */
> },
> {} /* Terminator */
> };
>
>
>
>
> static int overo_twl_gpio_setup(struct device *dev,
> unsigned gpio, unsigned ngpio)
> {
> twl4030_mmc_init(mmc); <-- mmc params passed to init
>
> overo_vmmc1_supply.dev = mmc[0].dev;
>
> return 0;
> }
> static struct twl4030_gpio_platform_data overo_gpio_data = {
> .gpio_base = OMAP_MAX_GPIO_LINES,
> .irq_base = TWL4030_GPIO_IRQ_BASE,
> .irq_end = TWL4030_GPIO_IRQ_END,
> .setup = overo_twl_gpio_setup,
> <- setup passed into the twl4030 gpio platform data
> };
>
> static struct twl4030_platform_data overo_twldata = {
> .irq_base = TWL4030_IRQ_BASE,
> .irq_end = TWL4030_IRQ_END,
> .gpio = &overo_gpio_data,
> <--- gpio data passed into twl4030 plat data
> .usb = &overo_usb_data,
> .power = GENERIC3430_T2SCRIPTS_DATA,
> .vmmc1 = &overo_vmmc1,
> };
>
> static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
> {
> I2C_BOARD_INFO("tps65950", 0x48),
> .flags = I2C_CLIENT_WAKE,
> .irq = INT_34XX_SYS_NIRQ,
> .platform_data = &overo_twldata,
> },
> };
>
> static int __init overo_i2c_init(void)
> {
> omap_register_i2c_bus(1, 2600, overo_i2c_boardinfo,
> ARRAY_SIZE(overo_i2c_boardinfo));
> /* i2c2 pins are used for gpio */
> omap_register_i2c_bus(3, 400, NULL, 0);
> return 0;
> }
>
> // i2c_init called first in init.
> static void __init overo_init(void)
> {
> overo_i2c_init();
> .
>
>
>
> So the way I see it working is i2c is initialized, which sets up the
> twl4030. When the twl4030 configures gpio it initializes the mmc.
> mmc0 comes up fine (I have a root File System), but I never get a clk
> on mmc3.
>
> Any help would be greatly appreciated.
>
> Thanks
> John Sarman
>
--
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
MMC3 Overo
I am trying to use mmc3 on the Overo Gumstix board with no luck. I
have patched the kernel with the latest changes and have yet to see a
clk pulse, both before and after the patches.
So far I have reconfigured the pins with uboot to GPIO and tested each
pin to verify that the signals are connected properly. That test
passed.
Then I reconfigured them back to MODE 2(mmc modes) for each pin. I am
confident that the level transceiver(TXS0108ERGYR) is operating
properly. This transceiver is automatic so no external controls are
necessary.
MUX_VAL(CP(ETK_CLK_ES2), (IDIS | PTU | EN | M2)) /*MMC3_CLK*/\
MUX_VAL(CP(ETK_CTL_ES2), (IEN | PTU | EN | M2)) /*MMC3_CMD*/\
MUX_VAL(CP(ETK_D3_ES2),(IEN | PTU | EN | M2)) /*MMC3_DAT3*/\
MUX_VAL(CP(ETK_D4_ES2),(IEN | PTU | EN | M2)) /*MMC3_DAT0*/\
MUX_VAL(CP(ETK_D5_ES2),(IEN | PTU | EN | M2)) /*MMC3_DAT1*/\
MUX_VAL(CP(ETK_D6_ES2),(IEN | PTU | EN | M2)) /*MMC3_DAT2*/\
// I Switched mmc 2 and 3 in a feeble attempt. Also I removed 2 in an
earlier attempt and the kernel would not boot ???
// Also I have tested working gpio connected to CD and WP but not
attempting to tackle that yet.
static struct twl4030_hsmmc_info mmc[] = {
{
.mmc= 1,
.wires = 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
},
{
.mmc= 3,
.wires = 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
},
{
.mmc= 2,
.wires = 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.transceiver= true,
.ocr_mask = 0x0010, /* 3.3V */
},
{} /* Terminator */
};
static int overo_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
twl4030_mmc_init(mmc);<-- mmc paramspassed to init
overo_vmmc1_supply.dev = mmc[0].dev;
return 0;
}
static struct twl4030_gpio_platform_data overo_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
.setup = overo_twl_gpio_setup,
<-setup passed into the twl4030 gpio platform data
};
static struct twl4030_platform_data overo_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
.gpio = &overo_gpio_data,
<--- gpio data passed into twl4030 plat data
.usb= &overo_usb_data,
.power = GENERIC3430_T2SCRIPTS_DATA,
.vmmc1 = &overo_vmmc1,
};
static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("tps65950", 0x48),
.flags = I2C_CLIENT_WAKE,
.irq = INT_34XX_SYS_NIRQ,
.platform_data = &overo_twldata,
},
};
static int __init overo_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, overo_i2c_boardinfo,
ARRAY_SIZE(overo_i2c_boardinfo));
/* i2c2 pins are used for gpio */
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
}
// i2c_init called first in init.
static void __init overo_init(void)
{
overo_i2c_init();
.
So the way I see it working is i2c is initialized, which sets up the
twl4030. When the twl4030 configures gpio it initializes the mmc.
mmc0 comes up fine (I have a root File System), but I never get a clk
on mmc3.
Any help would be greatly appreciated.
Thanks
John Sarman
--
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
Eddy and anyone who may be able to help, I am currently working on an Omnivision OV5620 and have used the ov3640 driver as a starting point. I have the June 18( latest ? ) code from the gitorious git repo. I have thouroughly tested my i2c driver setup using a 500 Mhz oscilloscope and have configured the sensor to 640 x 480. The only mode this supports is RAW V4L2_PIX_FMT_SGRBG10 and I have that as the only available format. So far so good. Sensor powers, configures etc, etc. However when I run the sensor I get ISPCTRL: HS_VS_IRQ <6>ISPCTRL: OVF_IRQ <6>ISPCTRL: To test this I used the example code provided with v4l2 documentation. I have attached a complete log with all my added printk's set up as a poor mans stacktrace. Stuck trying to determine where to go from here, I feel like I am so close to getting an image. Thanks, John Sarman v4l2_open omap34xx: Opening device isp_get ISPCTRL: isp_get: old 0 isp_enable_clocks isp_restore_ctx isp_restore_context isp_restore_context iommu_restore_ctx ISPHIST: Restoring context isp_restore_context ISPH3A: Restoring context isp_restore_context isp_restore_context ISPRESZ: Restoring context isp_restore_context ISPCTRL: isp_get: new 1 omap34xxcam_slave_power_set OV5620: ioctl_s_power isp_set_xclk isp_reg_and_or ISPCTRL: isp_set_xclk(): cam_xclka set to 2400 Hz BOARD_OVERO_CAMERA: Switching Power to 1 OV5620: POWER ON isp_configure_interface isp_buf_init OV5620: Sensor Detected, calling configure ov5620:configure omap34xxcam_slave_power_set OV5620: ioctl_s_power BOARD_OVERO_CAMERA: Switching Power to 2 OV5620: POWER STANDBY isp_set_xclk isp_reg_and_or ISPCTRL: isp_set_xclk(): cam_xclka set to 0 Hz OV5620: ioctl_g_fmt_cap omap34xxcam_s_pix_parm omap34xxcam_try_pix_parm omap34xxcam_try_pix_parm fps = 1 OV5620: ioctl_enum_fmt_cap OV5620: ioctl_enum_fmt_cap index 0 type 1 video4linux video0: trying fmt 30314142 (0) OV5620: ioctl_enum_framesizes isp_try_fmt_cap isp_try_pipeline video4linux video0: this w 640 h 480 fmt 30314142-> w 640h 480 fmt 30314142wanted w 640h 480fmt 30314142 video4linux video0: renegotiate: w 640 h 480 w 1073741823h 1073741823 OV5620: ioctl_enum_frameintervals video4linux video0: fps 60 the demoninator is 0 video4linux video0: best_pix_in: w 640 h 480 fmt 30314142ival 1/60 OV5620: ioctl_enum_frameintervals video4linux video0: fps 30 video4linux video0: closer fps: fps 29 fps 59 video4linux video0: best_pix_in: w 640 h 480 fmt 30314142ival 1/30 OV5620: ioctl_enum_frameintervals video4linux video0: fps 7 video4linux video0: closer fps: fps 6fps 29 video4linux video0: best_pix_in: w 640 h 480 fmt 30314142ival 2/15 OV5620: ioctl_enum_frameintervals OV5620: ioctl_enum_framesizes isp_try_fmt_cap isp_try_pipeline video4linux video0: this w 1280 h 960 fmt 30314142-> w 1280 h 960 fmt 30314142wanted w 640h 480fmt 30314142 video4linux video0: size diff bigger: w 1280h 960 w 640 h 480 OV5620: ioctl_enum_framesizes OV5620: ioctl_enum_fmt_cap OV5620: ioctl_enum_fmt_cap index 1 type 1 video4linux video0: w 640, h 480, fmt 30314142 -> w 640, h 480 video4linux video0: Wanted w 640, h 480, fmt 30314142 omap34xxcam_s_pix_parm 1 0 isp_s_fmt_cap isp_s_pipeline isp_release_resources isp_try_pipeline isp_reg_or isp_reg_or isp_reg_and_or isp_reg_and_or isp_reg_and isp_print_status ISPCTRL: ###ISP_CTRL=0x29c140 ISPCTRL: ###ISP_TCTRL_CTRL=0x0 ISPCTRL: ###ISP_SYSCONFIG=0x2000 ISPCTRL: ###ISP_SYSSTATUS=0x1 ISPCTRL: ###ISP_IRQ0ENABLE=0x0 ISPCTRL: ###ISP_IRQ0STATUS=0x8000 isp_reg_and isp_reg_and isp_reg_and omap34xxcam_s_pix_parm 2 0 OV5620: ioctl_g_fmt_cap OV5620: ioctl_s_fmt_cap OV5620: ioctl_try_fmt_cap OV5620: ioctl_try_fmt_cap WIDTH = 640 OV5620: ioctl_try_fmt_cap HEIGHT = 480 omap34xxcam_s_pix_parm 3 0 OV5620: ioctl_s_parm OV5620 desired_fps = 7 omap34xxcam_s_pix_parm 4 0 omap34xx: Opened device video_do_ioctl omap34xxcam_vidioc_querycap video_do_ioctl omap34xxcam_cropcap OV5620: ioctl_g_fmt_cap video_do_ioctl omap34xxcam_vidioc_s_crop isp_s_crop video_do_ioctl omap34xxcam_vidioc_s_fmt_vid_cap omap34xxcam_s_pix_parm omap34xxcam_try_pix_parm omap34xxcam_try_pix_parm fps = 1 OV5620: ioctl_enum_fmt_cap OV5620: ioctl_enum_fmt_cap index 0 type 1 video4linux video0: trying fmt 30314142 (0) OV5620: ioctl_enum_framesizes isp_try_fmt_cap isp_try_pipeline video4linux video0: this w 640 h 480 fmt 30314142-> w 640h 480 fmt 56595559wanted w 640h 480fmt 56595559 video4linux video0: renegotiate: w 640 h 480 w 1073741823h 1073741823 OV5620: ioctl_enum_frameintervals video4linux video0: fps 60 the demoninator is 0 video4linux video0: best_pix_in: w 640 h 480 fmt 30314142ival 1/60 OV5620: ioctl_enum_frameintervals video4linux video0: fps 30 video4linux video0: closer fps: fps 29 fps 59 video4linux video0: best_pix_in: w 640 h 480 fmt 30314142ival 1/30 OV5620: ioctl_enum_frameinterv
