TSIF Start up procedure (dm6467)

Brandy Jabkiewicz

Other Parts Discussed in Thread: TMS320DM6467T, CDCE949

hello,

I am begining to think that my tsif problems maybe in the start up procedure. What I mean is, does the TSIF module expect a certian order of events in order to properly receive data?

In our set up, we have the clock running all the time and use the enable and start of packet pins to control whether or not the module should collect data. However, as mentioned in our other post - the reception will only occur if we attach a scope probe to the clock pin (http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/101024/355201.aspx#355201).

We originally thought that the probe was adding capacitance and perhaps "cleaning up the signal" allowing for reception. But another thought has now occured that maybe the probe is interrupting the clock signal and giving the module the proper start up sequence?

Is there any advice on this? Does the clock need to be disabled/enabled with the enable and start of packet pins? Is there documentation to describe this - in Section 2.1 of http://focus.ti.com/lit/ug/sprueq2e/sprueq2e.pdf it describes the transmission sequence but I didn't see a reception sequence.

Thanks for the advice!

Brandy

over 14 years ago

0 Brandy Jabkiewicz over 14 years ago

Mastermind 6325 points

Hello again,

We made some more progress today. The behavior that we see now is this:

After we run the program to receive data over TSIF (in bypass mode @256 bytes), it will work the first time. We receive correct data (a counting pattern). Then we turn off the clock and data lines on the simulator and run the program a second time. We expect that the program will just wait for input at TSIF_WAIT_FOR_RX_COMPLETE command becuase there is no activity on the lines, but instead it gets the Rx ISRs still! I checked and after every execution, I am disabling the ISRs but it seems like the ISRs are being buffered some how and when the interrupts are re-enabled in the next program execution, it handles them. In this situation though, the data received is not correct.

Now, I am not sure if this should be moved to the embedded forum or not. My theory on the problem seems to be related to the hardware module - is the module stuck waiting for clock cycles to continue becuase we discontinue the clock and data at a random time for instance (and not at the end of a packet?)? Or perhaps as in my first theory, do we need to turn the clock off in between packets? If so, for how long?

Thanks
Brandy

Here is a sample of

PS: our output from the second run of the program, it is a bit hard to read becuase of the kernel prints mixing in with the standard prints. It is only a portion, there are hundreds of the "## PID7 Interrupt" comments. Then the program starts to run. (sets up driver parameters, then waits for RX_Complete, receives data, and copies it to buffer.) the code is based on saTsifLoopback.c with most of the transmit side commented out. However the variable names from the log can be found in that file still. The drivers are from the LSP 1.30 and we ported them (hopefully) to SDK3.10.x.x. The phrase "Inside Release of tsif_control" is a kernel print that proves we are calling the disable interupts function.

## PID7 Interrupt
## PID7 Interrupt
## PID7 Interrupt
## PID7 Interrupt
## PID7 Interrupt
## PID7 Interrupt
## PID7 Interrupt
## PID7 Interrupt
MUX: Setting register PTSOMUX_PARALLEL
PINMUX0 (0x00000000) = 0x05aa0001 -> 0x05aa0001
MUX: Setting register PTSIMUX_PARALLEL
PINMUX0 (0x00000000) = 0x05aa0001 -> 0x05aa0001
RX: Entering Loop @ rx_buf: 0x403d6000 read_offset: 0x0 read_data_buf: 0x495a8
RX: Waiting for Rx complete.
RX: Received data @ rx_buf: 0x403d6000 read_offset: 0x0 read_data_buf: 0x495a8
RX: Received and copied 5632 data bytes to buffer: 2568us
RX: cpu is loaded 0%
RX: Waiting for Rx complete.
RX: Received data @ rx_buf: 0x403d7600 read_offset: 0x1600 read_data_buf: 0x495a8
RX: Received and copied 5632 data bytes to buffer: 1601us
RX: cpu is loaded 0%
RX: Waiting for Rx complete.
RX: Received data @ rx_buf: 0x403d8c00 read_offset: 0x2c00 read_data_buf: 0x495a8
RX: Received and copied 5632 data bytes to buffer: 1613us
RX: cpu is loaded 0%
RX: Waiting for Rx complete.
RX: Received data @ rx_buf: 0x403d6000 read_offset: 0x4200 read_data_buf: 0x495a8
RX: Received and copied 5632 data bytes to buffer: 11731us
RX: cpu is loaded 50%
RX: Waiting for Rx complete.
RX: Received data @ rx_buf: 0x403d7600 read_offset: 0x5800 read_data_buInside Release of tsif_control
f: 0x495a8
RX: Received and copied 5632 data bytes to buffer: 1626us
RX: cpu is loaded 0%
RXInside Release of tsif_control
: Exit thread
TX: Stop.
RX: Stop.
closing files.

0 Brandy Jabkiewicz over 14 years ago in reply to Brandy Jabkiewicz

Mastermind 6325 points

Hello,

Is there any advice from the experts on this? Is there a proper way to start and stop transmissions such that I can execute a program without it getting stuck servicing empty ISRs? I mean, what is happening when the driver does not receive a complete packet or a complete ring? How do I reset the module back to zero?

I guess this should be moved to linux, if someone could please move it for me.

Here is the basic flow of the program:

Open receive drivers (rxcontrol, rxfilter7)

TSIF_REQ_RX_BUF

TSIF_QUERY_RX_BUF

mmap(rx_addr)

rx_cfg.if_mode = TSIF_IF_PARALLEL_SYNC;
rx_cfg.stream_mode = TSIF_STREAM_NON_TS;
rx_cfg.pkt_size = TSIF_256_BYTES_PER_PKT;
rx_cfg.ats_mode = TSIF_RX_ATS_THROUGH; //orginial 0;
rx_cfg.filter_mode = TSIF_PID_FILTER_BYPASS;

TSIF_SET_RX_CONFIG

TSIF_GET_RX_CONFIG

rx_ring_buf_cfg.pstart = (char*)rx_addr; // address from mmap (addresses device memory)
rx_ring_buf_cfg.buf_size = RING_SIZE; // 22*3

TSIF_RX_RING_BUF_CONFIG

TSIF_START_RX

Do (TSIF_WAIT_FOR_RX_COMPLETE)

{ if (TSIF_WAIT_FOR_RX_COMPLETE) then (Copy Data) } while (!exit_signal);

TSIF_STOP_RX

close(tsif_rx_fd);
close(tsif_rx_ctl_fd);

0 Brandy Jabkiewicz over 14 years ago in reply to Brandy Jabkiewicz

Mastermind 6325 points

Also, other things I have noticed:

1. It behaves much more civilally if I do not use the printk in the driver ISR

2. The IRQ is linked in the init function and freed in the exit function. Could this be why it seems like the ISRs are "buffered"? I mean, I don't unload the modules between program executions. I thought the release function was masking the ISR off.

Thanks again,

Brandy

0 Brandy Jabkiewicz over 14 years ago in reply to Brandy Jabkiewicz

Mastermind 6325 points

Hello again,

When my system is receiving these "extra interupts", it seems that the pointed are not being moved. Here is my log:

TSIF_RX_RING_BUF_CONFIG:
        Start Address. 0x83f60000
        End Address. 0x83f64200
        Subtraction Ptr. 0x1600
        Read ptr. 0x83f62c00
        Write ptr. 0x83e98000
Wait for completion interruptible:
        Start Address. 0x83f60000
        End Address. 0x83f64200
        Subtraction Ptr. 0x1600
        Read ptr. 0x83f62c00
        Write ptr. 0x83f60000
Wait for completion interruptible:
        Start Address. 0x83f60000
        End Address. 0x83f64200
        Subtraction Ptr. 0x1600
        Read ptr. 0x83f62c00
        Write ptr. 0x83f60000
Wait for completion interruptible:
        Start Address. 0x83f60000
        End Address. 0x83f64200
        Subtraction Ptr. 0x1600
        Read ptr. 0x83f62c00
        Write ptr. 0x83f60000
Wait for completion interruptible:
        Start Address. 0x83f60000
        End Address. 0x83f64200
        Subtraction Ptr. 0x1600
        Read ptr. 0x83f62c00
        Write ptr. 0x83f60000
Wait for completion interruptible:
        Start Address. 0x83f60000
        End Address. 0x83f64200
        Subtraction Ptr. 0x1600
        Read ptr. 0x83f62c00
        Write ptr. 0x83f60000
RX: Stop. tsif_stop_rx after disable:

        Start Address. 0x83f60000
        End Address. 0x83f64200
        Subtraction Ptr. 0x1600
        Read ptr. 0x83f62c00
        Write ptr. 0x83f60000
Inside Release of tsif_control

In a working run, the pointer increment in a logical manner as described in the buffer management section.

Also, what does this mean from section 4.29 in SPRUEQ2E, "if write address reaches this address, further write access is stalled until the ring buffer pointer address is updated with reactivation of this channel." Every execution of my program includes a start and a stop, so I don't think this could be the problem.

To re-interate, the program works fine the first time. Then I close that executable and stop the data being sent (but leave the clock), then I get into this situation where the pointers don't move but it appears to get interrupts. But I never turned the data back on!!! Help please!!!!

0 Brandy Jabkiewicz over 14 years ago in reply to Brandy Jabkiewicz

Mastermind 6325 points

Hello for today,

With more expirmenting, I get more nervous that something is quite wrong. Before I was trying small amounts of data You see, now - if I try to receive at lot of data at 60 mhz, the first program execution again runs fine. However, if I allow some time between executions, say 5 minutes, the second execution will not get any isrs! I can't "clear out the buffered" as I described above and the only way to fix it is to reboot the part. This is worse than before.

I really fear that the driver is not shutting down properly between programs, please advise quickly. I did not change the open and release functions of the driver during my port. The main change was just in the init/exit to create the dev files.

I hope I have given you enough information the past few days, I would hate to have missed a simple point and then a response is delayed again.

Thanks!

Brandy

0 Sudhakar Rajashekhara over 14 years ago in reply to Brandy Jabkiewicz

TI__Expert 5170 points

Hi Brandy,

AFAIK TSIF peripheral is not having a reset bit. So the only way the module can be shut down is by disabling the clocks. I am not sure whether disabling the clocks will result in resetting the registers.

Regards, Sudhakar

0 Brandy Jabkiewicz over 14 years ago in reply to Sudhakar Rajashekhara

Mastermind 6325 points

Hi Sudhakar,

I am not clear, what is AFAIK? which clocks are you talking about? The clock in, the parent clock? I thought the driver was controlling the clock with open/closes. Anyhow, I am only on the reception side, which does not have clock control. How does this explain why I can get ISRs when there is no data coming in? there is no enable line and I can still get ISRs? Or on the other hand, after receiving a lot of data, the ISRs just stop. How can I use this feature in production if I cannot even understand why it stops working?

And speaking clocks, I posted this before but no one seemed to answer. Which parent clock is the TSIF supposed to have? I had to create the TSIF clocks in dm6f46x.c and I just guessed that the parent clock was the same as the VPIF module becuase they are similar. Please tell me if this is correct:

dm646x.c:

static struct clk tsif0_clk = {
.name = "tsif0",
.parent = &ref_clk,
.lpsc = DM646X_LPSC_TSIF0,
.flags = ALWAYS_ENABLED,
};

static struct clk tsif1_clk = {
.name = "tsif1",
.parent = &ref_clk,
.lpsc = DM646X_LPSC_TSIF1,
.flags = ALWAYS_ENABLED,
};

struct davinci_clk dm646x_clks[] = {
CLK(NULL, "ref", &ref_clk),
CLK(NULL, "aux", &aux_clkin),
CLK(NULL, "pll1", &pll1_clk),
CLK(NULL, "pll1_sysclk", &pll1_sysclk1),
CLK(NULL, "pll1_sysclk", &pll1_sysclk2),
CLK(NULL, "pll1_sysclk", &pll1_sysclk3),
CLK(NULL, "pll1_sysclk", &pll1_sysclk4),
CLK(NULL, "pll1_sysclk", &pll1_sysclk5),
CLK(NULL, "pll1_sysclk", &pll1_sysclk6),
CLK(NULL, "pll1_sysclk", &pll1_sysclk8),
CLK(NULL, "pll1_sysclk", &pll1_sysclk9),
CLK(NULL, "pll1_sysclk", &pll1_sysclkbp),
CLK(NULL, "pll1_aux", &pll1_aux_clk),
CLK(NULL, "pll2", &pll2_clk),
CLK(NULL, "pll2_sysclk1", &pll2_sysclk1),
CLK(NULL, "dsp", &dsp_clk),
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "edma_cc", &edma_cc_clk),
CLK(NULL, "edma_tc0", &edma_tc0_clk),
CLK(NULL, "edma_tc1", &edma_tc1_clk),
CLK(NULL, "edma_tc2", &edma_tc2_clk),
CLK(NULL, "edma_tc3", &edma_tc3_clk),
CLK(NULL, "uart0", &uart0_clk),
CLK(NULL, "uart1", &uart1_clk),
CLK(NULL, "uart2", &uart2_clk),
CLK("i2c_davinci.1", NULL, &i2c_clk),
CLK(NULL, "gpio", &gpio_clk),
CLK("davinci-mcasp.0", NULL, &mcasp0_clk),
CLK("davinci-mcasp.1", NULL, &mcasp1_clk),
CLK(NULL, "aemif", &aemif_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
CLK("spi_davinci.0", NULL, &spi0_clk),
CLK(NULL, "pwm0", &pwm0_clk),
CLK(NULL, "pwm1", &pwm1_clk),
CLK(NULL, "timer0", &timer0_clk),
CLK(NULL, "timer1", &timer1_clk),
CLK(NULL, "pci", &pci_clk),
CLK("watchdog", NULL, &timer2_clk),
CLK("palm_bk3710", NULL, &ide_clk),
CLK(NULL, "vpif0", &vpif0_clk),
CLK(NULL, "vpif1", &vpif1_clk),
CLK(NULL, "tsif0", &tsif0_clk),
CLK(NULL, "tsif1", &tsif1_clk),
CLK(NULL, "usb", &usb_clk),
CLK(NULL, NULL, NULL),
};

Please be clear on the expected behavoir of this module, I have given you a ton of information on what I am seeing, now I need an explanation and solution.

0 Sudhakar Rajashekhara over 14 years ago in reply to Brandy Jabkiewicz

TI__Expert 5170 points

Hi Brandy,

The clock information you have added are proper.

It's really difficult to understand why are you receiving interrupts even when there is no data coming in. Can you explain the setup you are using here? How are you feeding and stopping the data to TSIF?

Regards, Sudhakar

0 Brandy Jabkiewicz over 14 years ago in reply to Sudhakar Rajashekhara

Mastermind 6325 points

I agree, I don't understand it either.

Setup:

- A dm6764t EVM is connected to an FPGA development board. This connection is made using the TSIF pins on the DC-2 connector. The wires are 30 gauge

- FPGA is programed to give a 60mHz clock on TSIF ClkIn aka the PTSI pin. FPGA also creates 8 data bits, an enable signal and a start of packet signal.

- The signals from the FPGA behave as such: The enable pin goes high for the entire length of the packet (size set to 256 bytes), and the start of packet is just a short "blip" at the beginning of each packet. The delays are according to the timing in section 7.12.4 in tms320dm6467t.pdf.

- The FPGA has user buttons that allow the user to start the clock, then start the data with some delay. It also allows for the user to turn off the data and leave the clock running.

- the saLoopback.c application was adjusted to be only receiving data. Also, immediately after the memcpy in the rx thread, I also memset the shared memory to 0xffs so that I can see clearly that I receiving data properly. See below for an example.

Questions:

- We could not find a description of the time needed between packets. Is there a delay necessary, right now it is just a very few clock cycles.

- You did not tell me what was meant by AFAIK.

- Which clocks am I supposed to reset?

- If the clock is running but there is no data and the enable signal is low, we still get interrupts from the dma and the data being copied over is the data that I initialized the shared buffer too (that is all 0xffs). This is a problem for the real world running situation. We do not plan to send data all the time.

- How exactly does the enable pin effect the ISR? Should we leave the enable pin in between packets? Could this be causing a set up delay in the module? The behavior I am seeing is that sometimes I will get a ring and it will have one or two packets that we did not received, but the write pointer was moved a head (as if the pointer kept moving but the dma did not copy the packet to SDRAM.)

Here is an example of two ring buffers. This first 256 bytes * 22 packets is supposed to be a small header with all zeros. The ring is supposed to be a counting pattern (we haven't fixed the endian problem yet, so it is counting correctly except when tehre is 0xffs).

0004200: 0100 0001 2c21 1203 0000 00ab 0000 0000 ....,!..........
0004210: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0004220: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0004230: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0004240: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0004250: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0004260: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0004270: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0004280: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0004290: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00042a0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00042b0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00042c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00042d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00042e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00042f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0004300: 0302 0100 0706 0504 0b0a 0908 0f0e 0d0c ................
0004310: 1312 1110 1716 1514 1b1a 1918 1f1e 1d1c ................
0004320: 2322 2120 2726 2524 2b2a 2928 2f2e 2d2c #"! '&%$+*)(/.-,
0004330: 3332 3130 3736 3534 3b3a 3938 3f3e 3d3c 32107654;:98?>=<
0004340: ffff ffff ffff ffff ffff ffff ffff ffff ................
0004350: ffff ffff ffff ffff ffff ffff ffff ffff ................
0004360: 6362 6160 6766 6564 6b6a 6968 6f6e 6d6c cba`gfedkjihonml
0004370: 7372 7170 7776 7574 7b7a 7978 7f7e 7d7c srqpwvut{zyx.~}|
0004380: ffff ffff ffff ffff ffff ffff ffff ffff ................
0004390: ffff ffff ffff ffff ffff ffff ffff ffff ................
00043a0: a3a2 a1a0 a7a6 a5a4 abaa a9a8 afae adac ................
00043b0: b3b2 b1b0 b7b6 b5b4 bbba b9b8 bfbe bdbc ................
00043c0: c3c2 c1c0 c7c6 c5c4 cbca c9c8 cfce cdcc ................
00043d0: d3d2 d1d0 d7d6 d5d4 dbda d9d8 dfde dddc ................
00043e0: e3e2 e1e0 e7e6 e5e4 ebea e9e8 efee edec ................
00043f0: f3f2 f1f0 f7f6 f5f4 fbfa f9f8 fffe fdfc ................

Thanks as usual!

0 Brandy Jabkiewicz over 14 years ago in reply to Brandy Jabkiewicz

Mastermind 6325 points

Also, I forgot to mention I solved the ISRs mysteriously stopping problem. The ISR needs to be setup as non-interruptible. This means, when the request_irq function is called it should have the flag IRQF_DISABLED. Another solution that also worked was to short the ISR call back so it only had the if-statement I was looking for in it.

To be safe - I implemented both solutions :)

0 Brandy Jabkiewicz over 14 years ago in reply to Brandy Jabkiewicz

Mastermind 6325 points

Also, please clarify what this means, it seems to contradict itself:

From: SPRUEQ2E

In synchronous format, all initiated data is detected by the receiver. Therefore, the host device and the DM646x DMSoC are regarded as synchronous to each other. All signals are generated by a data initiator with a packet start pulse and an enable signal. The enable signal is inactive during data transfer of a packet. In addition, the enable signal sometimes stays active during consecutive packets.

I am so confused. I am trying to figure about these spuriuos interrupts and what the enable pin should be doing. We have it high with start of packet signal and it remains high until end of packet. Maybe this is not right....

0 Nageswari Srinivasan over 14 years ago in reply to Brandy Jabkiewicz

TI__Expert 5660 points

Brandy,

In SPRUQ2E, section 2.1 talks about clock control for TSIF reception.

TSIF module requires around 3 to 4 clock cycles to latch all its register configurations correctly once it is turned on. Till then, it will not receive the packets correctly.

Can you make sure this is followed when you switch on/off the simulator and change any configurations?

Also, no register configurations can be changed on the fly and requires the TSIF MODULE to be stopped before changing any configurations.

Regarding spurious interrupts...

Interrupts occur for every 1/3rd of the buffer. (i.e when WP-RP = Subtraction Pointer (1/3rd of the buffer)).

I have some questions based on your setup....

1.Are you timing the simulator on/off with known number of packets or is it a random off. If it is a random off, you will get interrupts once it is turned on again.

2. Can you start/end your sim on/off with a known pattern so that you can confirm its reception every time you on/off.

3. For the TSIF hardware to sense the start of the packet, it needs both PKT_START and ENABLE singals to be high. Later enable signal is a don't care till the next packet start. So it can be held high continously with only pkt_start indicating the next packet. In your mail, you have mentioned that it remains high till the end of packet. Does it go high again for the next packet?

In short, clocks have to be enabled. ENABLE signal has to be high with a valid pkt_start for the TSIF module to start receiving the packets..

Hope this helps.....

Regards,

Nageswari

0 Brandy Jabkiewicz over 14 years ago in reply to Nageswari Srinivasan

Mastermind 6325 points

Hi Nageswari,

1. The simulator sends full data packets and turns off when I press a button. I can either turn off the clock, the data or both. But it will always complete its packet (256 bytes) before stopping.

What behavior do you mean by random off? Do you mean if it ends in the middle of a packet or in the middle of a ring? Also, you mean I will get interrupts once I re-run the application even though there is no data or enable signal (but there is a clock signal)? Can you explain what exactly is happening inside the module to cause this behavior? Once the modules starts, is it counting clock signals in order to move the write pointer? As I showed in the data log on March 31st, why is there 32 byte chunks of data missing?

how many clock cycles should be in between packets? How long does packet start need to be?

2. Yes, I think we are doing that. We send 256 bytes of "header data". This is a counter in the first few bytes and then all zeros. The we send a "counting packet", each byte of the 256 bytes increments by one (this is seen in the log). To ensure, we clear the shared ring buffer (rx_addr) to 0xffs. This is how we can see that sometimes we miss data.

3. I see about enable. We have the enable high for the entire 256 bytes, then it goes low until the next packet. The next packet is only 4 clock cycles later. Should we leave it high?

So let's get back to question 1. Really, what is the expected data stream for the module to be able to receive data properly. When is the clock and data signals supposed to be to be in sync with the application? What has to happen in between application runs? Why do we get interrupts when the enable line is low? Please explain what you can.

And questions still unanswered from other posts:

- We could not find a description of the time needed between packets. Is there a delay necessary, right now it is just a very few clock cycles.

- How long does the start packet enable need to be? Right now it is set to 1 byte length.

- Sudhakar said I was suppose to reset clocks, which clocks am I supposed to reset?

Thanks for the attention. If I could just understand how TI expects this driver to be used, then I hope I could make it work for our case.

0 jaydubya over 14 years ago in reply to Brandy Jabkiewicz

Intellectual 350 points

One thing I was wondering about is the clock setup. In the driver guide, they mention that there is support for certain clock frequencies when in parallel synchronous mode. This can be verified by looking at the set_tsif_clk() function in tsif_control.c. I don’t know if this is because those frequencies are what have been tested by TI, or if there is a limitation that has not been mentioned in any of the documentation. static int __init tsif_data_init(void) { … set_tsif_clk(TSIF_16_875_MHZ_SERIAL_PARALLEL); davinci_cfg_reg(DM646X_PTSOMUX_PARALLEL); davinci_cfg_reg(DM646X_PTSIMUX_PARALLEL); … } If someone from TI would shed some light on this, that would be nice.

0 Brandy Jabkiewicz over 14 years ago in reply to jaydubya

Mastermind 6325 points

hello, After much study, I can say that those frequencies in the driver pertain to the fact that TI is driving the TSIF TX module with an external I2C clock device. Therefore the driver is setup to use that external clock. So, if you are using the same clock for transmission, then it is a limitation. If you are doing receive only on the module, then this clock setup does not do much as the receive clock is driver by the transmitting source not the davinci. If someone at TI could confirm this, that would be nice. Brandy

0 Nageswari Srinivasan over 14 years ago in reply to Brandy Jabkiewicz

TI__Expert 5660 points

Brandy, You are correct. There is a CDCE949 clock generator that can generate various clocks depending on the configuration and this is controlled thru' I2C. TSIF transmit clock source currently chosen to be external and I2C writes that happen in the driver to enable various clock sources. As you mentioned, these are do not care for receive as clock comes from initiator. If you want to change the clock source to internal, you need to change the driver to reconfigure the clock source TSIF_CTL register... Currently only TSIF_COUNTER clock is assumed internal and TSSO_CLOCK is assumed external and driven from CDEC949 in the EVM. Regards, nageswari

0 Brandy Jabkiewicz over 14 years ago in reply to Nageswari Srinivasan

Mastermind 6325 points

Thanks Nageswari! Do you have more advice regarding my other open questions? Brandy

0 Nageswari Srinivasan over 14 years ago in reply to Brandy Jabkiewicz

TI__Expert 5660 points

Brandy,

Please my responses in "Bold Italic" in-lined below....

Hope this helps...

1. The simulator sends full data packets and turns off when I press a button. I can either turn off the clock, the data or both. But it will always complete its packet (256 bytes) before stopping.

1. 32 bytes missing could be a cache issue. Which is the exact LSP version you are using for TSIF. I assume you are using the driver in mmap mode where in you need to check whether your driver code (tsif_data.c) has vma->vm_page_prot is calling pgprot_noncached before calling remap_pfn_range in mmap function.... If this is not there, you need a patch and I can send you that...

how many clock cycles should be in between packets? How long does packet start need to be?

Packet start needs to be one byte length. There is no need for any gap in packets as long as packet start is available for every chosen packet start. (once in 256 bytes in your case)

3. I see about enable. We have the enable high for the entire 256 bytes, then it goes low until the next packet. The next packet is only 4 clock cycles later. Should we leave it high?

You can leave it high or low. You need to ensure that enable is high when packer_start is high....

And questions still unanswered from other posts:

- We could not find a description of the time needed between packets. Is there a delay necessary, right now it is just a very few clock cycles.

There is no delay needed as long as enable and packet start signal are properly places. (At the start of packet)

- How long does the start packet enable need to be? Right now it is set to 1 byte length.

1 byte lenght is sufficient.

- Sudhakar said I was suppose to reset clocks, which clocks am I supposed to reset?

Sudhakar meant resetting TSIF using LPSC

- I still need interpretation on this line in the spec, 4.29 in SPRUEQ2E, "if write address reaches this address, further write access is stalled until the ring buffer pointer address is updated with reactivation of this channel." How do I reactivate the channel? How do I know when it stalled? What kind of error recovery should I implement to prevent this?
This condition does not occur in the driver as we update RP in the driver ISR (happens every time when SP=RP-WP) irrespective of application read it or not.. If app does not read the data fast enough, data gets over written. This is done in order to avoid stalling of hardware....

0 Brandy Jabkiewicz over 14 years ago in reply to Nageswari Srinivasan

Mastermind 6325 points

Hi Nageswari,

You write at all times of the day! Thank you very much for the response.

Yesterday I found a newer version of the driver from LSP 2.00.00.00.140. I still had to make some changes for it to work with Arago, but it seems to work a bit better than 1.30.xx. The main improvement is that I can now rmmod whereas before I could not.

Also, I added the patch you gave Sheetal. this was for the freeing of the buffers. I do not think I have the mmap patch.

int tsif_data_mmap(struct file *filp, struct vm_area_struct *vma)
{
if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
vma->vm_end - vma->vm_start, vma->vm_page_prot))
return -EAGAIN;

return 0;
}

Please, where can I find a list of all the patches or perhaps you can send me the most recent drivers?

Also, is okay, the way were are discontinuing data on a packet boundary? Is that what you mean by "random off"?

Brandy

0 jaydubya over 14 years ago in reply to Brandy Jabkiewicz

Intellectual 350 points

Hi Nagaswari,

I suggested this fix to Brandy offline.

int tsif_data_mmap(struct file *filp, struct vm_area_struct *vma)
{

vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);

      if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
            vma->vm_end - vma->vm_start, vma->vm_page_prot))
            return -EAGAIN;

return 0;
}

Can you make sure that this is the way you intended to call pgprot_noncached()? She appears to be having some success with it.

Thanks,

John

0 jaydubya over 14 years ago in reply to jaydubya

Intellectual 350 points

Also, can you comment on if this needs to be emulated in the tsif_control driver as well? I didn't see a need to mmap to that driver.

0 Nageswari Srinivasan over 14 years ago in reply to jaydubya

TI__Expert 5660 points

Jaydubya,

Yes. The patch you gave is the correct one.

TSIF driver is divided into two parts. data part (tsif_data.c) and control part (tsif_control.c)

Control part takes care of all general configurations of TSIF0 and TSIF1 and so no need of mmap there.

Data part takes care of all PID filter configurations and buffer management of PID filters. Since TSIF hardware puts the data directly to the memory, and considering the large amount of data to be dealt with, mmap is supported for all PID filters to enable effiecient buffer/memory management. Also, the ring buffer has to be managed efficiently between hardware and software.

You can refer to the below presentation on the TSIF buffer management

http://processors.wiki.ti.com/index.php/DM6467_PSP_WebEx_Presentations (look for TSIF_DRIVER presentation)

Regards,

Nageswari

0 Nageswari Srinivasan over 14 years ago in reply to Brandy Jabkiewicz

TI__Expert 5660 points

Brandy,

These were the only two fixes that were made on top of TSIF driver.

Can you go thru' the presentation that I have sent in my previous reply to Jaydubya...

That can give you an idea of how buffers are managed and whether there is any ramdom off in your application.

Another way to check why the interrupts are not comign is to print the buffer address of PID7 (RP/WP/SP).

If you can send me a dump of registers when you restart your application, I can have a look....

Regards,

Nageswari

0 Brandy Jabkiewicz over 14 years ago in reply to Nageswari Srinivasan

Mastermind 6325 points

Hello,

Here are some more updates to the code that have helped make the driver better.

1. The interrupts with no data on the line were caused actually by the wait_for_completion_interruptible function. This function counts the interrupts that were received and then will also return to the application as long as application requests to wait_for_completion_interruptible was less that the actual amount of interrupts. So since the wait_for_completion_interruptible was only initialized when the modules are loaded (not when they are opened) if any interrupts occured between application runs, the function was still counting them. I guess this is not a super clear explanation but you trust me when I say update you open function tsif_data.c to this and the problem will go away.

int tsif_data_open(struct inode *inode, struct file *file)
{
unsigned int index, i , j;
struct tsif_data_dev *tsif_dev;

index = iminor(inode) / tsif_data_minor_count;
tsif_dev = tsif_data_dev_get_by_major(index);

tsif_int_status = 0;

silly_counter = 0;

/* Enable the interrupt to arm */
outl((inl(tsif_dev->base + CTRL1) | 0x8000),
tsif_dev->base + CTRL1);

for (i = 0; i < tsif_device_count; i++)
{
  for (j = 0; j < tsif_data_minor_count; j++)
  {
   init_completion(&tsif_data_dev_array[i]->rx_complete[j]);
   tsif_data_dev_array[i]->rx_complete[j].done = 0;
  }
}
return 0;
}

2. The freeing of the pages also needs to have munmap function call in the application. And the munmap needs to be before the FREE_BUF functions.

For example:

munmap(rx_addr, MMAP_LEN);
ret = ioctl (tsif_rx_ctl_fd, TSIF_FREE_RX_BUF, MMAP_LEN);
if (ret != 0) printf ("TSIF_FREE_RX_BUF IOCTL Failed\n");

if you did not get this patch, see this post: http://e2e.ti.com/support/embedded/f/354/p/96407/363137.aspx?PageIndex=2

3. Lastly, it was found that the Endian Ctl bit is a "don't care" when in Non-TS mode. Just an interesting point to note.

0 Brandy Jabkiewicz over 14 years ago in reply to Brandy Jabkiewicz

Mastermind 6325 points

Hi Nageswari,

I noticed a problem with the free pages patch.

Brandy Jabkiewicz said:

munmap(rx_addr, MMAP_LEN);
ret = ioctl (tsif_rx_ctl_fd, TSIF_FREE_RX_BUF, MMAP_LEN);
if (ret != 0) printf ("TSIF_FREE_RX_BUF IOCTL Failed\n");

I was using the wrong fd. It should have been the tsif_data.c descriptor - tsif_rx_fd. The control descriptor was doing nothing because it could not find the ioctl. But with the data descriptor it completely crashes my system! It such a horrific crash that my display history will not let me see the entire message but it is clearly saying that it is freeing an invalid address. Like the virtual address is wrong or something.

Here is the output right before the crash:

root@dm6467t-evm:/binaries# ./logos_TsifTestApp.x470MV 10
tsif_request_rx_buffer rx_offset: 3258974208
tsif_request_rx_buffer rx_offset: 2185232384 PAGE_SIZE 4096
tsif_query_rx_buffer rx_offset: 2185232384
Enabling ISRs
INTEN: 0x8000
INTEN_SET: 0x8000
WRB_CH_CTRL: 0x10000000
Started TSIF.
entering loop.
RX: pread_write: 0x824a8c00, pstart: 0x82400000, pcurrent: 0x8240e500 isr_counter: 0
RX: user_buf_loc: -1015946772
App_counter:10 isr_counter:11 WAIT_COMPLETE_retval: 0
Num Bytes:3456000
RX: pread_write: 0x82454600, pstart: 0x82400000, pcurrent: 0x824af500 isr_counter: 11
RX: pread_write: 0x82454600, pstart: 0x82400000, pcurrent: 0x824afd00 isr_counter: 11
RX: pread_write: 0x82454600, pstart: 0x82400000, pcurrent: 0x824b0400 isr_counter: 11
RX: pread_write: 0x82454600, pstart: 0x82400000, pcurrent: 0x824b0b00 isr_counter: 11
RX: pread_write: 0x82454600, pstart: 0x82400000, pcurrent: 0x824b1300 isr_counter: 11
RX: Stopping TSIF RX.
writing file.
Press any key to write data to file:

Please help me solve this.

0 Nageswari Srinivasan over 14 years ago in reply to Brandy Jabkiewicz

TI__Expert 5660 points

Brandy,

The parameters to the IOCTL is not correct.

You need to pass the address of mmap_len variable and not the actual value...

/***********************************************/

ret = ioctl (tsif_rx_fd, TSIF_FREE_RX_BUF, &mmap_len);

if (ret != 0)

printf ("TSIF_FREE_RX_BUF IOCTL Failed\n");

/*****************************************/

Regards,

Nageswari

Brandy Jabkiewicz said:

Hi Nageswari,

I noticed a problem with the free pages patch.

munmap(rx_addr, MMAP_LEN);
ret = ioctl (tsif_rx_ctl_fd, TSIF_FREE_RX_BUF, MMAP_LEN);
if (ret != 0) printf ("TSIF_FREE_RX_BUF IOCTL Failed\n");

Here is the output right before the crash:

Please help me solve this.

[/quote]

Processors

Processors forum

TSIF Start up procedure (dm6467)