Messages in this thread | | | Date | Thu, 31 Dec 2009 01:33:29 -0800 | From | Dmitry Torokhov <> | Subject | Re: [PATCH] [0/6] kfifo fixes/improvements |
| |
On Thu, Dec 31, 2009 at 09:59:51AM +0100, Stefani Seibold wrote: > Am Mittwoch, den 30.12.2009, 23:35 -0800 schrieb Dmitry Torokhov: > > > > I have a use case in linux/drivers/media/video/cx23885/cx23888-ir.c > > > right now. > > > > > > I have a hardware fifo that can hold up to 8 values, 17 bits each - and > > > the high bit of the value is a flag indicating if more data is in the > > > hardware fifo. > > > > > > The hardware fifo watermark for generating an interrupt is 4 or more > > > values in the hardware fifo. > > > > > > I use a kfifo that needs to be protected with a spinlock. > > > > > > It in much better in the IRQ context to drain the hardware fifo and then > > > put records in the kfifo all at once (or at least in groups of 8 or less > > > but usually greater than 1). > > > > Hmm, so there you have a local buffer that you fill by reading from the > > device word by word, then you copy that data over into fifo and then you > > upper layer again fetches that fifo as byte stream... > > > > I'd probably simply move the processing that you are doing in > > cx23888_ir_rx_read() into cx23888_ir_irq_handler() (since it is very > > simple) and then used kfifo in simple byte mode (since that is what > > upper layer seem to expect). > > > > Why using byte mode? He can use any type he like, the new macro based > implementation is record based! And a record can be a byte or any other > data type. Why do you discuss about code you didn't understand and want > not try? Why to discuss and waste time about less than 400 bytes of > library code? Terminate this useless discussion. >
Yes, indeed.
-- Dmitry
| |