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. -- 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
