On 08/04/14 17:59, Frank Rowand wrote:

Stephen,

I made some changes to drivers/tty/serial/msm_serial.c to allow kgdb
to work with the dragon board (which has a qcom,msm-uartdm-v1.4 serial
port).

I will reply to this email with the patches.

With these fixes, kgdb properly communicates with the dragon board, but
following the continue command, the serial driver does not get any stale
(UART_IMR_RXSTALE) interrupts until 48 characters have been read, which
triggers a high water interrupt.  After the high water interrupt has been
processed, the driver resumes properly getting stale interrupts.

I am hoping you can help me figure out how to get the stale interrupt to
occur for the first character after gdb continues, instead of having to
first get a high water interrupt.

Patch 2 adds a framework to fix up the state of the driver and/or hardware
after gdb continues.  Patch 3 is a series of experiments trying to fix
things up for msm_serial.  I don't have complete documentation and
understanding of the hardware, so some of the experiments might be less
than intelligent.

Can you give me some suggestions of What should I be doing in the fix up
function?

Hmm... I've never gotten the serial console to come back after
continuing because I only have one serial port and I use it for the
console so switching it into kgdb makes me lose the console. How do you
work around this? Use adb shell?

I think the big problem is

    msm_write(port, UARTDM_DMEN_RX_SC_ENABLE, UARTDM_DMEN)

in msm_poll_init() which forces the uart into single character mode.
That causes all sorts of problems but is required to make the get_char
stuff work cleanly. I really wanted the msm_poll_get_char_dm_1p3() to
work for the 1.4 version of the hardware but I guess they made the
hardware different again for some unknown reason so it doesn't work. I
never got around to figuring it out or talking to the hardware people.
It took a while to develop the 1p3 version of the get_char code because
of the "fifo" centric design.

Do you know if that 1p3 version of the code works for you on 1.3
hardware? Just curious if that actually has the same bugs or not. I
probably won't have much time to look at this anytime soon, but I'll try
and send an email off to the hardware designers to figure out a way to
avoid switching the mode.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation