lkml.org 
[lkml]   [2020]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v1 1/3] scsi: ufs: add write booster feature support
    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
    >

    \
     
     \ /
      Last update: 2020-06-23 06:35    [W:2.216 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site