Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1470715
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 0/3] UART slave device bus |
| Date | 2016-08-26 15:20 +0200 |
| Message-ID | <sapd7-7yi-7@gated-at.bofh.it> (permalink) |
| References | <s7k9X-TX-3@gated-at.bofh.it> <s7sKd-6Ri-19@gated-at.bofh.it> <s7voL-ho-51@gated-at.bofh.it> <s7H6x-7vO-29@gated-at.bofh.it> <sa60O-3vb-15@gated-at.bofh.it> |
| Organization | Intel Corporation |
> Either we'd have to call tty_port->rx a character at a time or > implement some temporary buffer. I don't think we want to call things > like BT receive code a byte at a time. This needs to be a layer > higher. flush_to_ldisc either needs to be duplicated to handle > tty_port->rx or generalized to call either tty_port->rx or ldisc > receive_buf. I'm not sure what to do about ldisc ref counting in the > latter case. You already have the buffer What I was trying to suggest was that instead of chars->buffer flush workqueue loop pushing data into the ldisc You can also do chars->buffer flush workqueue ->rx() [where flush_to_ldisc is just one implementation of ->rx] For byte by byte ports it really makes no difference (except you would be able to do processing without an ldisc), but for DMA devices it would give us a faster path for processing since the DMA completion event can simply fire a buffer a characters directly at the protocol handler where there are not latency concerns (ie it starts the new DMA and directly involves ->rx()) Alan
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-25 18:50 +0200 Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-26 15:20 +0200
csiph-web