On 08/04/14 19:09, Frank Rowand wrote: > 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 Cool. Thanks for the pointer. > >> 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. > > I tried it and it doesn't work either. Typing lots of characters finally unjams it like you see on 1.4 hardware. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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
