From: Dean_Jenkins@mentor•com (Dean Jenkins)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 1/5] serial: imx: remove unneeded imx_transmit_buffer() from imx_start_tx()
Date: Mon, 12 May 2014 09:03:21 +0100 [thread overview]
Message-ID: <53708049.8060108@mentor.com> (raw)
In-Reply-To: <53706FD8.6090201@freescale.com>
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 at mentor.com ??:
>>>>>> 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
next prev parent reply other threads:[~2014-05-12 8:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 15:19 [PATCH 0/5] serial: imx: fixes dean_jenkins at mentor.com
2014-05-09 15:19 ` [PATCH 1/5] serial: imx: remove unneeded imx_transmit_buffer() from imx_start_tx() dean_jenkins at mentor.com
2014-05-12 3:40 ` Huang Shijie
2014-05-12 5:45 ` Dirk Behme
2014-05-12 6:30 ` Huang Shijie
2014-05-12 6:40 ` Dirk Behme
2014-05-12 6:53 ` Huang Shijie
2014-05-12 8:03 ` Dean Jenkins [this message]
2014-05-12 8:17 ` Huang Shijie
2014-05-09 15:19 ` [PATCH 2/5] serial: imx: remove uart_write_wakeup() from imx_transmit_buffer() dean_jenkins at mentor.com
2014-05-09 15:19 ` [PATCH 3/5] serial: imx: avoid spinlock recursion deadlock dean_jenkins at mentor.com
2014-05-12 3:12 ` Huang Shijie
2014-05-14 16:24 ` Dean Jenkins
2014-05-09 15:19 ` [PATCH 4/5] serial: imx: move imx_transmit_buffer() into imx_txint() dean_jenkins at mentor.com
2014-05-09 15:19 ` [PATCH 5/5] serial: imx: clean up imx_poll_get_char() dean_jenkins at mentor.com
2014-05-28 19:34 ` [PATCH 0/5] serial: imx: fixes Greg KH
2014-05-29 4:58 ` Dirk Behme
2014-05-29 4:14 ` Huang Shijie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53708049.8060108@mentor.com \
--to=dean_jenkins@mentor$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox