[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Sync Serial 1
Oke, I've comment out the initialize_port(1) and now
The kernel doesn't complain. So that's fixed, thanx a lot.
BUT. I still get no data from the sync-serial port.
We are using the port in the SLAVE input mode based on a
External clock generated by the firmware.
Are there some special settings I have to do before reading from the
or must the external clock meet some special requirements ? (e.g. a
prescale factor of the
I've copy-pasted the code of a small test program below.
+++++++++++++++++++++ START CODE SNAP ++++++++++++++++++++++
int main(int argc, char * argv)
int ser = open(SYNC_DEV, O_RDONLY | O_SYNC);
unsigned char buf[BUFSIZE];
if ( ser == -1 )
cerr << "ERROR: failed to open serial port" << endl;
if ( ioctl(ser, SSP_MODE, SLAVE_INPUT ) )
cerr << "failed to set slave input mode" << endl;
if ( ioctl(ser, SSP_FRAME_SYNC, NORMAL_SYNC |
CLOCK_GATED ) )
cerr << "failed to set frame sync" << endl;
if ( ioctl(ser, SSP_IPOLARITY, STATUS_NORMAL))
cerr << "failed to set ipolarity" << endl;
cerr << "start reading from port" << endl;
rd = read(ser, buf, BUFSIZE);
cerr << "done reading from port" << endl;
+++++++++++++++++++++ END CODE SNAP ++++++++++++++++++++++++
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Mikael Starvik
> Sent: 14 May 2004 09:41
> To: Peter van Duijn; dev-etrax
> Subject: RE: Sync Serial 1
> >There is indeed a kernel panic at the bottom of the capture file
> >"Kernel panic: Can't allocate sync serial port 3 IRQ", this
> is due to
> >the cause of me using the ETRAX_FAST_TIMER feature of the
> >The kernel is at this moment compiling with the fast timer
> disabled and
> >sync serial dma enabled.
> This means that IRQ 20 or 21 already has been claimed by someone.
> The fast timer doesn't use these interrupts and can be
> enabled at the same time as the sync serial port. The serial
> driver only
> claims these interrupts if SERIAL_PORT3 is enabled which it
> isn't in your kernel config.
> >The SSBV_ECPMODE driver is ower internal parport driver based on (I
> >think) your ecp_skeleton, which uses parport 0.
> Aha! When I look in the ecp_skeleton I see that it initalizes
> both port even if you just use one of them. This will claim
> your interrupt. Comment out the line "initialize_port(1);" or
> put a CONFIG around it.