On Tue, Jan 29, 2013 at 3:41 AM, Chanho Min <chanho.min@xxxxxxx> wrote: > On Mon, Jan 28, 2013 at 5:28 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> On Mon, Jan 28, 2013 at 9:15 AM, Chanho Min <chanho.min@xxxxxxx> 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-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
