On 8/4/2014 6:33 PM, Stephen Boyd wrote: > 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 use kdmx2 to share the host serial port between gdb for kgdb and minicom for the console input and output. I had to update kdmx2 to work in my environment. You can download it from: http://elinux.org/images/a/a7/Kdmx-2.00_v140730a.tar.gz Whenever that link is updated, the new link can be found at: http://elinux.org/Kgdb > > 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. Yep, most of my fixes deal with the fact that in single character mode echo fifo word only contains a single character of data. All of that works now. So my only problem is not getting a stale interrupt until after I've gotten a high water interrupt. > 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. > I don't have any 1.3 hardware on my desk. I'll have to see if I can find some when I get a chance. I did try telling the driver that I was using 1.3 hardware even though it is 1.4; I had to make some changes to msm_poll_get_char_dm_1p3() to make it kind of sort of work, but not well. Instead of spending more time on that I just went back to making the single character mode work. -Frank -- 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
