Michal Simek wrote:
Peter Korsgaard wrote:
"Michal" == Michal Simek <monstr@xxxxxxxxx> writes:
Hi,
>> But I still don't understand why you would want to burn CPU spinning
>> when you know the UART will be busy for a while. Leaving it alone
>> until it generates the TX fifo empty interrupt seems more logical to
>> me.
Michal> I didn't know when tx fifo was full and then empty interrupt is
Michal> generated. I have added some debug things to driver and I am
going to
Michal> look into.
Michal> I just changed return value and I have got correct output and
Michal> then I sent this email to check if is correct or not.
According to the spec, you should get an interrupt when RX !empty or TX
empty.
We wouldn't ever be able to send more bytes than fits in the TX fifo if
it didn't.
Yes, I know.
I looked at that loop and I think that we should reread actual status
before ulite_transmit because status reg can be changed when
ulite_receive is executed. What do you think? (BTW: status reading can
be moved directly to ulite_receive/transmit functions)
do {
int stat = ioread32be(port->membase + ULITE_STATUS);
busy = ulite_receive(port, stat);
stat = ioread32be(port->membase + ULITE_STATUS); // check status
again
busy |= ulite_transmit(port, stat);
n++;
} while (busy);
I did some investigating and I found:
1. xmit circ buffer contains what needs to be printed but it is not
printed.
Here is circ_buf structure, pointer to buffer and head/tail
struct circ_buf {
char *buf;
int head;
int tail;
};
Part of the broken log. ( There should be in Welcome to and log)
adding dns 172.16.0.5
>
> >> Yeah, that loop should probably be time based (and perhaps
calculated
> >> from baud rate).
>
> Michal> It is hard to say if you can find out any accurate number of
loops
> Michal> which is baud rate dependent.
>
> Not loops, microseconds (or rather jiffies).
>
adding dns 172.16.10.1
Starting portmap:
Starting uWeb server:
Welc
mdm login:
Here is the circ buffer:
(NOTE: mdm login is coming from getty and it is at the beginning)
5ed72000: 0d0d0a6d 646d206c 6f67696e 3a20200d ...mdm login: .
5ed72010: 0a4d6f75 6e74696e 67207661 723a200d .Mounting var: .
5ed72020: 0a506f70 756c6174 696e6720 2f766172 .Populating /var
5ed72030: 3a200d0a 52756e6e 696e6720 6c6f6361 : ..Running loca
5ed72040: 6c207374 61727420 73637269 7074732e l start scripts.
...
5ed721b0: 646e7320 3137322e 31362e30 2e350d0a dns 172.16.0.5..
5ed721c0: 61646469 6e672064 6e732031 37322e31 adding dns 172.1
5ed721d0: 362e3130 2e310d0a 53746172 74696e67 6.10.1..Starting
5ed721e0: 20706f72 746d6170 3a0d0a53 74617274 portmap:..Start
5ed721f0: 696e6720 75576562 20736572 7665723a ing uWeb server:
5ed72200: 0d0a0d0a 57656c63 6f6d6520 746f0d0a ....Welcome to..
5ed72210: 205f5f5f 5f5f2020 20202020 205f2020 _____ _
5ed72220: 20202020 20202020 205f2020 20202020 _
5ed72230: 5f0d0a7c 205f5f5f 205c2020 2020207c _..| ___ \ |
5ed72240: 207c2020 20202020 2020207c 207c2020 | | |
5ed72250: 2020285f 290d0a7c 207c5f2f 202f205f (_)..| |_/ / _
5ed72260: 5f5f207c 207c5f20 20205f5f 205f207c __ | |_ __ _ |
5ed72270: 207c2020 2020205f 20205f20 5f5f2020 | _ _ __
5ed72280: 205f2020 205f205f 5f20205f 5f0d0a7c _ _ __ __..|
5ed72290: 20205f5f 2f202f20 5f205c7c 205f5f7c __/ / _ \| __|
5ed722a0: 202f205f 60207c7c 207c2020 20207c20 / _` || | |
5ed722b0: 7c7c2027 5f205c20 7c207c20 7c207c5c || '_ \ | | | |\
5ed722c0: 205c2f20 2f0d0a7c 207c2020 207c2020 \/ /..| | |
5ed722d0: 5f5f2f7c 207c5f20 7c20285f 7c207c7c __/| |_ | (_| ||
5ed722e0: 207c5f5f 5f5f7c20 7c7c207c 207c207c |____| || | | |
5ed722f0: 7c207c5f 7c207c20 3e20203c 0d0a5c5f | |_| | > <..\_
5ed72300: 7c202020 205c5f5f 5f7c205c 5f5f7c20 | \___| \__|
5ed72310: 5c5f5f2c 5f7c5c5f 5f5f5f5f 2f7c5f7c \__,_|\_____/|_|
5ed72320: 7c5f7c20 7c5f7c20 5c5f5f2c 5f7c2f5f |_| |_| \__,_|/_
5ed72330: 2f5c5f5c 0d0a0d0a 6f6e206d 646d0d0a /\_\....on mdm..
5ed72340: 0d0a0000 00000000 00000000 00000000 ................
I look at head and tail values and they are OK "c" (in Welc) is called.
Exact values are: head:0x342, tail:208.(You can check that it is correct
range in circ buffer)
Let me describe what driver did:
1. Before fault happen:
ISR is called, status is 0x18 (interrupt enabled, tx fifo full) just to
ulite_transmit and detect TXFULL and return to ISR. Head and tail are
correct
2. Broken part
ISR is called, status is 0x14 (interrupt enabled, tx fifo empty), jump
to ulite_transmit. Here I am printing (head and tail values are zero).
Xmit buffer address is the same. Then uart_circ_empty(xmit) detects that
head and tail are the same which means nothing to print.
My question: Is there any part of the code which can change xmit head
and tail values?
I will try to setup watchpoints on that addresses to see which part of
the code is breaking that addresses.
uart_circ_clear reset circ head/tail values from uart_flush_buffer.
crisv10.c and 68360serial.c implement wait_until_sent function which is
probably what I need to implement.
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
