On Tue, Jun 28, 2011 at 09:22:20AM +0300, saeed bishara wrote: > On Mon, Jun 27, 2011 at 2:02 PM, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: > > On Mon, Jun 27, 2011 at 01:34:48PM +0300, saeed bishara wrote: > >> Russell, > >> I'm curious about the correctness of this patch for systems with > >> outer cache. shouldn't the dsb be issued before the outer cache > >> maintenance? > > > > Maybe we should do two passes over SG lists then - one for the inner and > > another for the outer cache? > > > > In effect we could do three passes: > > > > 1. Calculate the total size of the SG list to determine whether full > > cache flush is more efficient. > > 2. Flush inner cache > > Then dsb() > > 3. Flush outer cache > > Another dsb() > > > looking at l2x0 cache, it seems to me that it would be possible to do > asynchronous l2 cache maintenance for > range operations, so maybe that can be utilized in order to > parallelism between inner cache and outer cache maintenance, > so the flow can be: > 2. Flush sg buffer from inner cache > 3. dsb() > 4. start Flush outer cache for that buffer > 5. Flush next sg buffer from inner cache > 6. dsb > 7. goto 4. > 8. when no more buffers left, wait for outer cache operations I'm not sure how practical that is given the architecture of the L2x0 controllers - where we need to wait for the previous operation to complete by reading the operation specific register and then issue a sync. Having looked at this again, I think trying to do any optimization of this code will be fraught, because of the dmabounce stuff getting in the way. If only dmabounce didn't exist... if only crap hardware didn't exist... dmabounce really needs to die. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
