Messages in this thread | | | Subject | Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader. | From | Maxim Levitsky <> | Date | Wed, 04 Aug 2010 22:31:44 +0300 |
| |
On Wed, 2010-08-04 at 19:48 +0300, Maxim Levitsky wrote: > On Wed, 2010-08-04 at 00:57 -0700, Alex Dubov wrote: > > I see two immediate problems with this patch: > > > > 1. On cosmetic level, custom debug macros should not be employed. Device > > core already have this functionality (dynamic debug levels and such). Please, > > use dev_dbg and friends for print-outs. > This allows much easier control for debug. > Single module parameter is enough to adjust it. > This helps me help users. > (Eg, kernel compilation is out of question) > > > > > > 2. On a structural level, I'd rather prefer host drivers to not start their > > own threads. If you look at both current host implementations, they operate > > in callback fashion. Apart from saving some resources, this reduces the > > amount of problems encountered during suspend/resume and shutdown. > This isn't possible. > Hardware doesn't support interrupts on memstick bus changes, it only > supports DMA done from/to internal FIFO, and DMA it only possible for > 512 byte TPCs. >
Another question.
I see that current code ignores MEMSTICK_CAP_AUTO_GET_INT Instread mspro_blk.c enables this capability for parallel mode, assuming that hw supports it. Its true in my case, but might not be true in other cases. I think I should fix that, right?
Also I see that you bath TPC_READ_LONG_DATA/TPC_READ_LONG_DATA Does that mean that every HW sector is larger that 512? If so, you are doing copy on write, right? I have small caching in my sm_ftl of last sector. It helps performance a lot.
Also I want to clarify that the only kind of interrupts supported by hw (besides usual card detection interrupt), is DMA done interrupt. Thats why I have to use thread. Doing polling in r592_submit_req (which runs in atomic context is just cruel). Besides, under moderate IO load, the IO thread doesn't sleep, thus there is no overhead of wake/sleep.
Best regards, Maxim Levitsky
| |