Re: Enabling MMC BKOPs in kernel based on host caps

[Ravikumar <a0131654@ti.com>]

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.
>> 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.
>>
>> I would like to ask for expert opinion on ‘why is it a bad idea to 
>> enable bkops in kernel?’
>
> 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.
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@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
Thanks for your response.

Regards,
RK