2008-09-16 08:35:19 ppi with 2FSYNC doesn't work.. on my bf537
tom R (FRANCE)
Message: 62248
Hi,
I am working on uClinux-dist-2008R1-RC8 (bf537E). I wan't to read data from a counter. It's working with one or no
frame sync, but it doesn't when I choose 2 FSy. I use the bfin-ppi.c driver. This is what i can see:
my config:
ppi_Slave_Table_2D_2Sy[] = {
{ CMD_PPI_PORT_DIRECTION, CFG_PPI_PORT_DIR_RX },
{ CMD_PPI_PACKING, CFG_PPI_PACK_DISABLE },
{ CMD_PPI_SKIPPING, CFG_PPI_SKIP_DISABLE },
{ CMD_PPI_SKIP_ODDEVEN, CFG_PPI_SKIP_ODD },
{ CMD_PPI_DATALEN, CFG_PPI_DATALEN_16 },
{ CMD_PPI_CLK_EDGE, CFG_PPI_CLK_EDGE_RISE },
{ CMD_PPI_TRIG_EDGE, CFG_PPI_TRIG_EDGE_FALL },
{ CMD_PPI_XFR_TYPE, CFG_PPI_XFR_TYPE_NON646 },
{ CMD_PPI_PORT_CFG, CFG_PPI_PORT_CFG_XSYNC23 },
{ CMD_PPI_SET_DIMS, CFG_PPI_DIMS_2D },
{ CMD_PPI_DELAY, 0 },
{ 0, 0 }
};
typedef struct {
unsigned long id;
unsigned short size;
UINT16 data[LINELEN*NUMLINES];
} Datagram;
In the slave fonction:
Datagram* msg;
Buffer_Size = bufX*bufY;
slave_2Dconfig_2Sy ( ppiFD, bufX, bufY ); // fonction with ioctl() inside
bytes_read = read (ppiFD,(char*)msg->data, Buffer_Size*2 );
On the blackfin:
root:/var> ppitest slave 2 2 0 10 11 16384 1
ppi_open:
bufX 16384, bufY: 1 buffer_size: 16384, nb_bytes: 32768
slave_2Dconfig_2Sy
******************
BUFFER 1:
opened: 1.
portenable: 0.
nonblock: 0.
irqnum: 23.
pixel size: 7.
line length: 16384.
num lines: 1.
Ctrl reg: 0xb8ac.
Status reg: 0x0000.
Status count: 0x0000.
Status frame: 0x0000.
Status delay: 0x0000.
Timer Enable: 0x0000.
ppi_read(0x004C000A, 32768)
PPI read -- 2D data xcount = linelen = 16384, ycount = numlines = 1 stepsize = 2
dma_config = 0x00B6
PPI wait_event_interruptible
-----------------------------------------------------------------------------------------------------
When a falling edge comes on the FSy2, nothing happens :S .
I need your help plz.
TranslateQuoteReplyEditDelete
2008-09-16 08:51:11 Re: ppi with 2FSYNC doesn't work.. on my bf537
tom R (FRANCE)
Message: 62250
There is something I don't understand in the bfin-ppi driver:
#ifdef CONFIG_BF537
port_cfg = (pdev->ppi_control & CFG_PPI_PORT_CFG_NOSYNC) >> 2;
switch (port_cfg) {
case CFG_PPI_PORT_CFG_XSYNC23: // << the program don't exec. this :(, but have to. (see my config)
// disable timer1 for FS2
regdata = get_gptimer_config(FS2_TIMER_ID),
regdata &= ~TIMER_OUT_DIS;
set_gptimer_config(FS2_TIMER_ID, regdata);
// fall through to get FS1 timers
case CFG_PPI_PORT_CFG_SYNC1: // just that
// disable timer0 outputs for FS1
regdata = get_gptimer_config(TIMER0_id),
regdata &= ~TIMER_OUT_DIS;
set_gptimer_config(TIMER0_id, regdata);
break;
default:
break;
}
#endif
TranslateQuoteReplyEditDelete
2008-09-17 09:54:01 Re: ppi with 2FSYNC doesn't work.. on my bf537
tom R (FRANCE)
Message: 62311
I saw that CFG_PPI_PORT_CFG_NOSYNC is always egal to 3 (0b0011). As the result is divided by 4 (>> 2),
port_cfg will always be 0. So I've removed the switch code, but it makes nothing... I also suppose that the code
was correct. I am going the clean all drivers and apps that are not usefull for ppi. Maybe sould I have a look on
port_mux.
TranslateQuoteReplyEditDelete
2008-09-29 04:10:36 Re: ppi with 2FSYNC doesn't work.. on my bf537
Ian Jeffray (UNITED KINGDOM)
Message: 62883
If FS2 is seemingly not operating as you intended...
ADI have recently confirmed to us that FS2 input is broken. [PPI doesn't care about FS2 except on the first transition of FS1] This has caused us major problems. They have not yet assigned this an anomoly number, but confirmed that it is indeed not operating as intended. BF537, BF527, BF561. There are no plans to correct this in newer silicon. Seems like a truly horrendous bug to us.
QuoteReplyEditDelete
2008-09-29 11:25:27 Re: ppi with 2FSYNC doesn't work.. on my bf537
Frank Van Hooft (CANADA)
Message: 62896
I agree with Ian; we've been tripping over this as well. The hardware bugs in the PPI interface are a big big problem - we were wondering for a while if it would force us away from the blackfin processor, and it very nearly did. Thankfully for us, at the hardware level we have a little bit of control over the incoming PPI data - we're able to stop & start the data using a GPIO pin. So what we do is:
- stop the incoming data
- set up the PPI port
- start the incoming data
- stop the incoming data once a frame's worth has been received
This seems to result in the PPI port capturing a frame of incoming data pretty reliably, using FS1 & FS2. However if you don't have any way to control the incoming PPI data at all, you've got a much more difficult problem on your hands.