Re: [PATCH 1/5] serial: imx: remove unneeded imx_transmit_buffer() from imx_start_tx()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/05/14 07:53, Huang Shijie wrote:
于 2014年05月12日 14:40, Dirk Behme 写道:
On 12.05.2014 08:30, Huang Shijie wrote:
于 2014年05月12日 13:45, Dirk Behme 写道:
On 12.05.2014 05:40, Huang Shijie wrote:
于 2014年05月09日 23:19, dean_jenkins@xxxxxxxxxx 写道:
Use imx_start_tx() just to enable the TX interrupt. It's the job of the
TX interrupt ISR to fill the transmit buffer, then. If the transmit
buffer
  From the Documentation/serial/driver, we can see:
    -----------------------------------------
     start_tx(port)
      Start transmitting characters.
     -----------------------------------------

It tells us we can transmit data in the imx_start_tx.

Well, it depends how you read 'Start transmitting', no?

It doesn't have to mean 'actually transmit data'. It talks about 'start'. And this could also mean 'start the transmission (by enabling the interrupt)'.

Ok :)
I do not object this patch.

My opinion is : If the third patch is redundant, could this patch still needed?


But this patch moves it to the interrupt handler,

It doesn't 'move' any code to the interrupt handler. The code in the interrupt handler is already there.

i knew it.

this patch makes the
interrupt handler do more jobs.

... to get the locking in the correct order.

again, the third patch can be ignored.
The locking is correct for the imx.c.

Well, the locking might now be OK but due to an existing issue the TX will be woken up excessively with no new characters to transmit so there will be excessive context switching with the new work queue that results in no useful work done. There is an API issue in HCI LDISC because TTY_DO_WRITE_WAKEUP is set BEFORE checking whether any characters remain pending to be sent. This means most of the time hci_uart_tx_wakeup() is unnecessarily called will no chance of seeing any remain pending characters to be process. This weakness contributed to triggering lockup issue.

In my opinion, TTY_DO_WRITE_WAKEUP should only be set when the UART character circular holding buffer becomes full which for BCSP traffic is unlikely I think (4kB buffer versus traffic < 1kB BCSP frames in length). The current API needs fixing so that TTY_DO_WRITE_WAKEUP is set after filling up the holding buffer but BEFORE enabling the TX interrupts. I think TTY_DO_WRITE_WAKEUP needs to be set in a callback function called from the bound layer below HCI LDISC.

Best regards,
Dean

--
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




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux