linux-kernel - Re: [PATCH v2] ARM: PL011: Add support for Rx DMA buffer polling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Jan 2013 11:57:35 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Chanho Min <chanho.min@....com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alan Cox <alan@...ux.intel.com>, linux-kernel@...r.kernel.org,
	Pawel Moll <pawel.moll@....com>, linux-serial@...r.kernel.org,
	Chanho Min <chanho0207@...il.com>
Subject: Re: [PATCH v2] ARM: PL011: Add support for Rx DMA buffer polling

On Tue, Jan 29, 2013 at 3:41 AM, Chanho Min <chanho.min@....com> wrote:
> On Mon, Jan 28, 2013 at 5:28 PM, Linus Walleij <linus.walleij@...aro.org> wrote:
>> On Mon, Jan 28, 2013 at 9:15 AM, Chanho Min <chanho.min@....com> wrote:
>>> [Russell]
>>>>Well, I thought I had explained that I'd prefer to see the poll rate
>>>>adjusted with the baud rate, but maybe I wasn't explicit enough.
>>>>Instead, what we seem to have ended up with are two new entries in
>>>>platform data (which we're trying to get away from with DT):
>>>>
>>>>+       unsigned int dma_rx_poll_rate;
>>>>+       unsigned int dma_rx_poll_timeout;
>
>>>>Should we scale the polling interval according to baud
>>>>rate?
>>>
>>> It is also our concern, I will suggest the proper way.
>
> It was thought a way to reduce unnecessary cpu usage,
> but, now we add dma_rx_poll_timeout to stop polling during idle.

During idle I guess any system want to set the UART into
IRQ mode? So it will wake up on some event on the
UART, whatever it may be.

Then it can use DMA polling post-wakeup?

> I thought it is preferred  the poll rate is decided by it's user than
> auto scale.

What do you mean by "user" here? Userspace? Or
"platform data parameter"?

I can se three usecases:

- Console or serial TTY
- Modem (as in 33k8 modem, needing RTS/CTS HW handshaking)
- Peripheral (like high-speed bluetooth chips) needing low-latency

The kernel already knows if the port is a console or TTY.

What you need to know is if it is one of the other two usecases.

> because The required response to tty can be differ from platform to platform.
> Some platform need fast response even if more cpu usage is needed,
> but other platform will be enough to handle  with slow response.

Not platform I think. Per usecase.

Are you not actually thinking about things like the above?
These are usecase requirements, not platform requirements.

For example I thing it is magnitude better idea to encode
something like an enum for these usecases that some
bool is_platform_foo_bt_uart or whatever the alternative
would be.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/