> -----Original Message----- > From: Vimal Singh [mailto:vimal.newwork@xxxxxxxxx] > Sent: Saturday, May 29, 2010 12:20 AM > To: Ghorai, Sukumar > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v4 1/3] omap3 gpmc: functionality enhancement > > On Fri, May 28, 2010 at 11:50 PM, Ghorai, Sukumar <s-ghorai@xxxxxx> wrote: > > > > > >> -----Original Message----- > >> From: Vimal Singh [mailto:vimal.newwork@xxxxxxxxx] > >> Sent: Friday, May 28, 2010 9:14 PM > >> To: Ghorai, Sukumar > >> Cc: linux-omap@xxxxxxxxxxxxxxx > >> Subject: Re: [PATCH v4 1/3] omap3 gpmc: functionality enhancement > >> > >> On Fri, May 28, 2010 at 12:03 PM, Ghorai, Sukumar <s-ghorai@xxxxxx> > wrote: > >> > > >> >> -----Original Message----- > >> >> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > >> >> owner@xxxxxxxxxxxxxxx] On Behalf Of Vimal Singh > >> >> Sent: Thursday, May 27, 2010 11:56 PM > >> >> To: Ghorai, Sukumar > >> >> Cc: linux-omap@xxxxxxxxxxxxxxx > >> >> Subject: Re: [PATCH v4 1/3] omap3 gpmc: functionality enhancement > >> >> > >> >> On Thu, May 27, 2010 at 6:54 PM, Sukumar Ghorai <s-ghorai@xxxxxx> > >> wrote: > >> >> [...] > >> >> > -static unsigned gpmc_cs_map; > >> >> > +static unsigned int gpmc_cs_map; /* flag for cs > which > >> are > >> >> initialized */ > >> >> > >> >> Tab should be after 'int', not before. > >> >> > >> >> [...] > >> >> > @@ -456,13 +565,22 @@ EXPORT_SYMBOL(gpmc_prefetch_enable); > >> >> > /** > >> >> > * gpmc_prefetch_reset - disables and stops the prefetch engine > >> >> > */ > >> >> > -void gpmc_prefetch_reset(void) > >> >> > +int gpmc_prefetch_reset(int cs) > >> >> > { > >> >> > + u32 config1; > >> >> > + > >> >> > + /* check if the same module/cs is trying to reset */ > >> >> > + config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1); > >> >> > + if (((config1 >> CS_NUM_SHIFT) & 0x7) != cs) > >> >> > + return -EINVAL; > >> >> > + > >> >> > >> >> You really do not need this. > >> >> Prefetch has just one instance at a time and 'reset' will be call > only > >> >> when driver has got access to prefetch (for either read or write > >> >> access), from the driver. > >> > [Ghorai] Agree. And.. NAND may not be good example. But if tomorrow > i/o > >> operation need to cancel for some other type of device and for big size > of > >> IO on progress. So is not this API required that case? > >> > > >> > >> First of all, this prefetch engine is dedicated for only NAND. > > [Ghorai] ok. Does not this below response is contradicting previous > statement? > >> Then, if user wants to 'cancel', say a big write operation; since > >> there is no 'cancel' command provided by chip (nand), FS has to handle > >> it. And, I guess, best way will be to complete current chunck of > >> request (in this case writing of current page or sub-page) and then > >> cancel any further pending transfer. > >> And in that case again, prefetch 'reset' will get called for > >> completion of current page/sub-page operation. > > > > [Ghorai] > > 1. In this case why we checks - prefetch engine busy or not, if we are > waiting to complete one request to be completed before another? As we > reset the prefetch-engine at the end of the io? > > > Since there could be other request (for read/write) from another > driver instance (in case we have more than one NAND chip on board). > > > 2. The only possible scenario is - when two driver(say for two separate > nand chip) trying to access the prefetch-engine. In that case who > accessing the prefetch engine he should only reset the engine. And to > avoid confusion and mistake of the user of this API, it has been added > 'cs' number as a function parameter for reset and the same is used to > check before reset. > > > > In this scenario, when second driver instance fails to get prefetch, > it completes the request by cpu transfer method. And there is no > chance for prefetch reset to get called from this driver instance. > Note that we are not calling reset explicitly, but a driver (instance) > resets the prefetch only if it gets first. [Ghorai] I says.. And to avoid confusion and mistake of the user of this API, it has been added 'cs' number as a function parameter for reset and the same is used to check before reset. What's wrong? > > -- > Regards, > Vimal Singh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
