Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
In-Reply-To: <CAF6AEGuG3XAqN_sedxk9GRm_9yK+a4OH56CZPmbHx+SW-FNVPQ@mail.gmail.com>
References: <cover.1586374414.git.asutoshd@codeaurora.org> <3c186284280c37c76cf77bf482dde725359b8a8a.1586382357.git.asutoshd@codeaurora.org>
 <CAF6AEGvgmfYoybv4XMVVH85fGMr-eDfpzxdzkFWCx-2N5PEw2w@mail.gmail.com>
 <SN6PR04MB46402FD7981F9FCA2111AB37FC960@SN6PR04MB4640.namprd04.prod.outlook.com>
 <20200621075539.GK128451@builder.lan> <CAF6AEGuG3XAqN_sedxk9GRm_9yK+a4OH56CZPmbHx+SW-FNVPQ@mail.gmail.com>
From:   Kyuho Choi <chlrbgh0@gmail.com>
Date:   Tue, 23 Jun 2020 13:34:28 +0900
Message-ID: <CAP2JTQJ735yQYSeHgDPqnT0mRUTt1uKVAHacOHmSj3WK48PUog@mail.gmail.com>
Subject: Re: [PATCH v1 1/3] scsi: ufs: add write booster feature support
To:     Rob Clark <robdclark@gmail.com>
Cc:     Bjorn Andersson <bjorn.andersson@linaro.org>,
        Avri Altman <Avri.Altman@wdc.com>,
        Asutosh Das <asutoshd@codeaurora.org>,
        "cang@codeaurora.org" <cang@codeaurora.org>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        Subhash Jadavani <subhashj@codeaurora.org>,
        Alim Akhtar <alim.akhtar@samsung.com>,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        Bean Huo <beanhuo@micron.com>,
        Stanley Chu <stanley.chu@mediatek.com>,
        Tomas Winkler <tomas.winkler@intel.com>,
        Colin Ian King <colin.king@canonical.com>,
        Bart Van Assche <bvanassche@acm.org>,
        open list <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Rob,

On 6/22/20, Rob Clark <robdclark@gmail.com> wrote:
> On Sun, Jun 21, 2020 at 12:58 AM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
>>
>> On Sun 21 Jun 00:40 PDT 2020, Avri Altman wrote:
>>
>> >
>> > >
>> > > On Wed, Apr 8, 2020 at 3:00 PM Asutosh Das <asutoshd@codeaurora.org>
>> > > wrote:
>> > > >
>> > > > The write performance of TLC NAND is considerably
>> > > > lower than SLC NAND. Using SLC NAND as a WriteBooster
>> > > > Buffer enables the write request to be processed with
>> > > > lower latency and improves the overall write performance.
>> > > >
>> > > > Adds support for shared-buffer mode WriteBooster.
>> > > >
>> > > > WriteBooster enable: SW enables it when clocks are
>> > > > scaled up, thus it's enabled only in high load conditions.
>> > > >
>> > > > WriteBooster disable: SW will disable the feature,
>> > > > when clocks are scaled down. Thus writes would go as normal
>> > > > writes.
>> > >
>> > > btw, in v5.8-rc1 (plus handful of remaining patches for lenovo c630
>> > > laptop (sdm850)), I'm seeing a lot of:
>> > >
>> > >   ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query
>> > > for
>> > > idn 14 failed, err = 253
>> > >   ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag: Sending flag query
>> > > for
>> > > idn 14 failed, err = 253
>> > >   ufshcd-qcom 1d84000.ufshc: ufshcd_query_flag_retry: query
>> > > attribute,
>> > > opcode 6, idn 14, failed with error 253 after 3 retires
>> > >   ufshcd-qcom 1d84000.ufshc: ufshcd_wb_ctrl write booster enable
>> > > failed 253
>> > >
>> > > and at least subjectively, compiling mesa seems slower, which seems
>> > > like it might be related?
>> > This looks like a device issue to be taken with the flash vendor:
>>
>> There's no way for a end-user to file a bug report with the flash vendor
>> on a device bought from an OEM and even if they would accept the bug
>> report they wouldn't re-provision the flash in an shipped device.
>>
>> So you will have to work around this in the driver.
>
> oh, ugg.. well I think these msgs from dmesg identify the part if we
> end up needing to use a denylist:
>
> scsi 0:0:0:49488: Well-known LUN    SKhynix  H28S8Q302CMR     A102 PQ: 0
> ANSI: 6
> scsi 0:0:0:49476: Well-known LUN    SKhynix  H28S8Q302CMR     A102 PQ: 0
> ANSI: 6
> scsi 0:0:0:49456: Well-known LUN    SKhynix  H28S8Q302CMR     A102 PQ: 0
> ANSI: 6
> scsi 0:0:0:0: Direct-Access     SKhynix  H28S8Q302CMR     A102 PQ: 0 ANSI:
> 6
> scsi 0:0:0:1: Direct-Access     SKhynix  H28S8Q302CMR     A102 PQ: 0 ANSI:
> 6
> sd 0:0:0:0: [sda] 29765632 4096-byte logical blocks: (122 GB/114 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 32 00 10
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports
> DPO and FUA
> sd 0:0:0:0: [sda] Optimal transfer size 786432 bytes
> scsi 0:0:0:2: Direct-Access     SKhynix  H28S8Q302CMR     A102 PQ: 0 ANSI:
> 6
> scsi 0:0:0:3: Direct-Access     SKhynix  H28S8Q302CMR     A102 PQ: 0 ANSI:
> 6
>

AFAIK, this device are ufs 2.1. It's not support writebooster.

I'd check latest linux scsi branch and ufshcd_wb_config function's
called without device capability check.

ufshcd_wb_config
 -> ufshcd_is_wb_allowed
     -> only check about hba caps with writebooster

Asutosh's first patch already check about device's capability in here.

IMO, it would be need to fixing in ufshcd_probe_hba or ufshcd_wb_config.

>
> (otoh I guess the driver could just notice that writeboost keeps
> failing and stop trying to use it)
>
> BR,
> -R
>
>
>> Regards,
>> Bjorn
>>
>> > The device reports that it supports wd, but returns inalid idn for flag
>> > 0xe...
>> >
>> > Thanks,
>> > Avri
>