On 05/10/16 14:55, Ravikumar wrote: > Hi Shawn, > > > On Wednesday 05 October 2016 03:07 PM, Shawn Lin wrote: >> Hi Ravikumar, >> >> + Alex, >> >> 在 2016/10/3 18:43, Ravikumar Kattekola 写道: >>> Hi all, >>> I’ve seen an eMMC failure due to pending background operations on a >>> certain OMAP device since bkops enable bit was not set. It is not clear what you are talking about. BKOPS_EN is one-time-programmable so you can just set when the device is provisioned. However BKOPS_EN does not really enable background operations. It is an indication from the host to the card about whether the card may delay maintenance operations. The definition is: "This field allows the host to indicate to the device if it is expected to periodically manually start background operations by writing to the BKOPS_START field." Currently the kernel does not do periodic background operations, so having the kernel set BKOPS_EN would not make sense - even if it wasn't one-time-programmable. >>> Further investigation showed me that someone already posted patch to >>> enable Background operations in kernel based on a host capability check >>> (Caps2 & BK_OPS_EN) >>> but was turned down quoting that it should be enabled from user space >>> using mmc-utils. >>> >>> Enabling this would add one additional check for exception event in the >>> response R1 or R1B (only on hosts that explicitly set BK_OPS_EN in caps2). >>> But not enabling this could lead to a system failure especially when the >>> Filesystem is on eMMC and the card stops responding due to pending >>> critical bkops. Yes the kernel only does urgent background operations if BKOPS_EN is set. You seem to be suggesting that the cards are violating the specification by delaying maintenance operations even though they are not allowed to because BKOPS_EN is not set. Is that the case? >>> >>> I would like to ask for expert opinion on ‘why is it a bad idea to enable >>> bkops in kernel?’ It is one-time-programmable so the kernel should not have to program it, because it should have already been programmed when the device was provisioned. >> >> Some discussion about the similar topic could be found here: >> https://patchwork.kernel.org/patch/9157121/ >> >> >>> It’s a one time programmable bit but if it helps in keeping system >>> functional why not do it? >> >> Actually BKOPS_EN is not OTP bit.. Quoted from Ulf "I don't have any >> issue to allow all non-OTP registers bits to be written." So I guess >> you could do this, although it needs more discussion there. > In the spec for 4.5, jesd84_B45 it does say not whether the ENABLE bit is OTP. That is not entirely accurate. Table 75 clearly lists it as R/W meaning one-time-programmable and readable. > But in 5.1 spec, jesd84-b51, it says MANUAL_EN is R/W which means OTP and > readable. > As I read form mmc-utils -help > " mmc bkops enable <device> > Enable the eMMC BKOPS feature on <device>. > NOTE! This is a one-time programmable (unreversible) change " >> >> But it's persistent EXT_CSD register and we get used to control it from >> userspace, which is the policy we have been sticking to when writing to >> persistent EXT_CSD registers. I guess that is nothing about "right and >> wrong", just a rule for us in case someone wants to set the persistent >> bit in kernel but setting other persistent bits from user-space, which >> is prone to mess up the mmc core. Or, someone will sent mail to the list >> asking "why is it a good idea to enable bkops in kernel" ? :) > So there's no functional problem/reason that stops us from enabling BKOPS > (Manual) in > kernel except for consistency with other persistent registers. > Since not enabling BKOPS could lead to a functional failure / non-responsive > system > at a later point of time I guess this could be exempted. > what do you think? > > As user I would choose functional safety and reliability over performance. > Hence it would make sense to have the bkops (at least manual) be enabled by > default, > especially in Automotive applications. > >> >>> I haven’t measured the performance impact but I don’t see a reason for >>> major drop because the frequency of critical bkops events would be less. >>> >>> Regards, >>> RK >>> -- >>> 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 >>> >> >> > Thanks for your response. > > Regards, > RK > > -- > 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 > -- 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
