Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

The 1 does indicate which bus. It tells i2cdump to open "/dev/i2c-1" instead of "/dev/i2c-2". It is used to append a number to "/dev/i2c-" in the program when opening the device node.

The I2C bus number that is assigned in the kernel, unfortunately, appears to be 1 based. You can see this, if you are interested, by looking at the "id" field assigned of the da8xx_i2c_device1 and da8xx_i2c_device0 structures in devices-da8xx.c of the kernel. That's how TI implemented it.

So the bus ID for I2C0 is "i2c_davinci.1" and gets mapped to /dev/i2c-1 by udev when creating the device nodes. I2C1 would appear as /dev/i2c-2 if it were instantiated in the kernel, which by default is not as the pins are used for other functions (UART 2 pins instead).

It's confusing, but I think you should be able to press on at this point?

-Mike

Sorry, did not manage to dig that out of the kernel. What I could use now as a sanity test is an i2cdump address of some chip on the Industrial I/O board, just to check that I can get the standard configuration with the standard kernel to work. We will have to go step by step from there at our end.

Unfortunately, the Rev-B industrial I/O boards do not have anything hooked to the I2C0 port outside of the SOM.

Rev-C boards moved the I2C interface from the DVI controller chip to I2C0 away from the FPGA I/O pins.

I think if you enable the audio, and add the codec to the I2C port, it should come up...

I backed up and repeated my steps today.
1) Stock kernel on the rev B card: i2cdump -y 1 0x51 works.
Presumably this is the kernel from the "release 2010.05"
However that kernel did not have the
>Look for the text "SYSTEM_RESET"
mentioned by Mike above.
2) Grabbed "the tarball on the BSP wiki page" mentioned by Thomas above (release_2010-10-12.tar.bz2)
Booted the kernel out of the "images" directory of that tarball.
i2cdump -y 1 0x51 gives the followin messages
i2c_davinci i2c_davinci.1: controller timeout
i2c_davinci i2c_davinci.1: initiating bus recovery
2b) built the kernel from the source out of that tarball
used strcitly the "environment-setup", "make ... mityomapl138_defconfig", "make ... uImage"
Booting that kernel gives the same behavior as the one out of the images directory.

So what I think I'm seeing is the "stock" version of your 2010-10-12 kernel has a problem with the i2c bus on the rev B board.

Hi Dennis,

I tried the same steps as you listed above on a revision A board as well as a C board and don't see this behavior. You are doing this on an unmodified rev-B board?

I will see if I can grab another revision B and repeat the test. There are really no differences between A and B, as far as the I2C interface goes. Normally, the message above indicates that the I2C data bus may be getting shorted or being held off by a device, perhaps stuck in reset?

When you run this test and it fails, can you repost the "find" command above (if the results are not consistent with the initial request)?

-Mike

I'm realizing I'm not clear on the hardware. Is it the card that is "Rev B" or the board the card is seated on? Is it the card that contains address 0x51 or the board the card is seated on? I do have two different cards, they have different pinouts for the jtag connectors and I have two different boards, the I-I/O and the one we are trying to prototype. I always use the new of the cards because the older seems to get a corrupted jffs2 on a regular basis. The problem is with the 2010-10-12 kernel and our prototype board.
The 2010.05 kernel does find the i2c and allow the i2cdump, the 2010-10-12 does not. I ran the find on the failing configuration and
a number of the 0048 subdirectories are missing. I've attached the front of the dmesg for the failing configuration. The Peripheral
Config Block does get found, but the i2c times out.

Linux version 2.6.34-rc1 (mikew@mitydsp) (gcc version 4.3.3 (GCC) ) #1 PREEMPT Tue Oct 12 20:09:23 EDT 2010
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: MityDSP-L138
Peripheral Config Block Found
Enet_Config = 2
EMAC = 00:50:C2:BF:83:28
PHYMask = 0x8
LCD Configured : COM57H5M06XRC
UART[0] = 0, 0, 0, 115200
UART[1] = 1, 1, 0, 115200
UART[2] = 0, 0, 0, 115200
SPI[0] = 0, 0, 00, 0, 0
SPI[1] = 1, 1, 01, 0, 30000000
Memory policy: ECC disabled, Data cache writethrough
On node 0 totalpages: 24576
free_area_init_node: node 0, pgdat c040c56c, node_mem_map c043a000
  DMA zone: 192 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 24384 pages, LIFO batch:3
DaVinci da850/omap-l138 variant 0x0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 24384
Kernel command line: mem=96M console=ttyS1,115200n8 mtdparts=nand:128M(rootfs),-(userfs) root=/dev/mtdblock0 rw rootfstype=jffs2
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 96MB = 96MB total
Memory: 93108k/93108k available, 5196k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xff000000 - 0xffe00000   (  14 MB)
    vmalloc : 0xc6800000 - 0xfea00000   ( 898 MB)
    lowmem  : 0xc0000000 - 0xc6000000   (  96 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc0028000   ( 128 kB)
      .text : 0xc0028000 - 0xc03c3000   (3692 kB)
      .data : 0xc03de000 - 0xc040cf40   ( 188 kB)
Experimental preemptable hierarchical RCU implementation.
NR_IRQS:245
Console: colour dummy device 80x30
Calibrating delay loop... 149.50 BogoMIPS (lpj=747520)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
DaVinci: 144 gpio irqs
regulator: core version 0.5
NET: Registered protocol family 16
mityomapl138_init...
mityomapl138_init: unknown LCD type : COM57H5M06XRC
bio: create slab <bio-0> at 0
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c_davinci i2c_davinci.1: controller timed out
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
tps65023 1-0048: Read from reg 0x3 failed
set_machine_constraints: failed to enable VDCDC1

I'm trying to dig through the two kernels to see what the difference is w.r.t the i2c bus. It looks like the 2010.05 kernel did not try to activate the i2c lines going for the SOC, while the 2010-10-12 does try to activate those lines. Am I reading the code correctly on this? If so, something we are doing on our version of the board is causing the time-outs when those lines are activated.

I'm not sure if that's true. The I2C lines are required in order to manage the on-board power controller needed for core voltage adjustments. I will check today.

Would it be possible for you to provide (offline, via email or some other mechanism) a copy of your schematic?

-Mike

I've been playing with the kernel trying to narrow down the problem. With the new kernel I can get i2cdump -y 1 0x51 to work by modifying mityomapl138_mcasp_pins back to the value of the 2010.05 kernel. I don't understand why this changes that behavior yet. Values from board-mityomapl138.c are

static __init int mityomapl138_setup_mcasp(void) {
int ret;

/* TODO - read from peripheral config block */
        mityomapl138_mcasp_pins[7+0] = DA850_AXR_13;  // change

Hi Dennis,

I am looping back on this issue. We've have seen the I2C timeout issue now, but it was when we tried to use the i2c port immediately after boot up (e.g., early in an init.d script). The time out was occurring because udev had not settled and installed the device node in the /dev yet. If we waited a couple of seconds, and then ran the script, there were no issues. Are you trying to run an i2c command immediately on boot up? Or is this problem happening several seconds after you log in, etc?

-Mike

Mike,

We found out that our Touch screen controller (TSC2004IRTJT) was at the same address as the power manager. One the reset was removed the touch screen controller would lock the bus up when it got accessed with an single byte access since the TSC2004IRTJT is expecting a double byte access. We modified the address on the controller to be different and this seemed to solve the problem. Now it only locks the I2C bus when a single byte access is done to the TSC2004IRTJT (Now address 0x4A in the I2C bus)

John

Mike,

As John pointed out our problem was with the hardware. My problem was insufficient understanding of what I2C things were on the daughter card and which were on the custom board. However, you comment is extremely useful, as (once we got things working) I was planning to run an i2c script as part of the boot sequence. Since I've been warned I'll have the boot sequence background the script and have the script sleep a few seconds before it runs it's i2c commands. Thanks for the help.

Dennis