On 07/09/2012 11:48 AM, Chris Ball wrote: > Hi, > > On Sun, Jul 08 2012, Jaehoon Chung wrote: >>> I think MMC_CAP2_BKOPS should be removed. If the card BKOPs were already >>> enabled, the host must support BKOPs. Therefore, in mmc_start_bkops we >>> should check only if card->ext_csd.bkops_en is set. >> >> If bkops bit is set, it means that use the bkops by default. >> If somebody didn't want to use the bkops, then just didn't set the MMC_CAP2_BKOPS. >> And eMMC card's BKOPS bit should not be set, >> then we can set the BKOPS support with switch command. >> For this, MMC_CAP2_INIT_BKOPS is added. >> In my case, didn't set the bkops enable bit at first time. >> So need to set bkops enable bit with switch command. >> >> As Maya's mentioned, if we use the bkops by default, we can remove the MMC_CAP2_BKOPS2. > > I'm not sure I understand. If someone has advertised MMC_CAP2_BKOPS on > their host, why do we also need to check for MMC_CAP2_INIT_BKOPS before > we enable it in the ext_csd? Actually, it didn't need to check the MMC_CAP2_INIT_BKOPS. Because, if MMC_CAP2_BKOPS is set, it means we want to use the bkops. Then we could enable in ext_csd by default. In the initial version, didn't add the MMC_CAP2_INIT_BKOPS. But some people asked me that card didn't set bkops enable bit in ext_csd why set enable bkops by default? Also others suggested the bkops enable bit should be set at user space. I think host didn't consider whether enable bkops or not. But some people want to enable bkops bit, some people didn't want to enable bkops bit by default. So i added the MMC_CAP2_INIT_BKOPS. If you can decide, i will confirm yours. Best Regards, Jaehoon Chung > > Why shouldn't we just use one (MMC_CAP2_BKOPS) capability to mean > "enable bkops if supported, by writing 1 (if it wasn't already set) > to ext_csd[163] to tell the card that we're going to be using bkops"? > Are there any disadvantages to doing this? > > Thanks, > > - Chris. -- 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
