On 25/03/19 10:54 PM, Joakim Tjernlund wrote: > On Mon, 2019-03-25 at 22:36 +0530, Vignesh Raghavendra wrote: >> >> On 25/03/19 7:21 PM, Joakim Tjernlund wrote: >>> On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: >>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >>>> >>>> >>>> Hi, >>>> >>>> On 21/03/19 11:41 PM, Joakim Tjernlund wrote: >>>>> On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >>>>>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >>>>>> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >>>>>> can be use as is. But these devices do not support DQ polling method of >>>>>> determining chip ready/good status. These flashes provide Status >>>>>> Register whose bits can be polled to know status of flash operation. >>>>>> >>>>>> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >>>>>> Extended Query version 1.5. Bit 0 of "Software Features supported" field >>>>>> of CFI Primary Vendor-Specific Extended Query table indicates >>>>>> presence/absence of status register and Bit 1 indicates whether or not >>>>>> DQ polling is supported. Using these bits, its possible to determine >>>>>> whether flash supports DQ polling or need to use Status Register. >>>>>> >>>>>> Add support for polling status register to know device ready/status of >>>>>> erase/write operations when DQ polling is not supported. >>>>> >>>>> Isn't this new Status scheme just a copy of Intels(cmdset_0001)? >>>> >>>> Yes, but with one difference: At the end of program/erase operation, >>>> device directly enters status register mode and starts reflecting >>>> status register content at any address. >>>> The device remains in the read status register state until another >>>> command is written to the device. Therefore there is notion of device is >>>> in "status register read mode" (FL_STATUS) state >>> >>> That seems to vary and long time ago RMK added this: >>> /* If the flash has finished erasing, then 'erase suspend' >>> * appears to make some (28F320) flash devices switch to >>> * 'read' mode. Make sure that we switch to 'read status' >>> * mode so we get the right data. --rmk >>> */ >>> map_write(map, CMD(0x70), chip->in_progress_block_addr); >>> >> >> This behavior is expected with cmdset_0001. Because "The device remains >> in the read status register state until another command is written", >> therefore "erase suspend' command after erase completion will switch >> device to read mode. And therefore read status is safe thing to do for >> cmdset_0001. >> >> But in case of cmdset_0002 erase completion will not put device to read >> status mode and therefore no special status tracking is required. >> >>>> But in case of cfi_cmdset_0002, once program/erase operation is >>>> complete, device returns to previous address space overlay from which >>>> operation was started from (mostly read mode) >>> >>> I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. >> >> Even if we issue Read Status command to enter read status mode, any >> single subsequent read will put device back to read mode. So, sending >> explicit Status CMD is of not much use. >> >> As long as cmdset_0002 driver ensures sending Read Status cmd and next >> single read can be done in one go (ie. mutex held), I don't see any >> trouble here. This is already take care off. > > Ouch, a non sticky Status sounds borken. Are you sure that nothing can change the > chip between you issue the Status CMD and read out of status bits? > Like if an erase/suspend/resume completes just after Status CMD but before Status readout? > Yes, I did some tests(with HyperFlash) and erase/program completion/suspend in b/w issue of Status CMD but before status readout does not result in exiting status read address space overlay. So we are safe here with non sticky Status. -- Regards Vignesh
