scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL

PATCH In review Stanley Chu 5 participants 15 messages Dec 22, 2020 – Dec 28, 2020

Subsystems (2)

SCSI Arm MediaTek

lore

Share & tools

lore

Stanley Chu

author

2020-12-22 07:30 UTC #0 lore raw

PATCH 1/1 scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL

Flush during hibern8 is sufficient on MediaTek platforms, thus enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL to skip enabling fWriteBoosterBufferFlush during WriteBooster initialization.

Signed-off-by Stanley Chu <[email protected]>

---
 drivers/scsi/ufs/ufs-mediatek.c | 1 +
 1 file changed, 1 insertion(+)

drivers/scsi/ufs/ufs-mediatek.c +1 -0

index 80618af7c872..c55202b92a43 100644
@@ -661,6 +661,7 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 
 	/* Enable WriteBooster */
 	hba->caps |= UFSHCD_CAP_WB_EN;
+	hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL;
 	hba->vps->wb_flush_threshold = UFS_WB_BUF_REMAIN_PERCENT(80);
 
 	if (host->caps & UFS_MTK_CAP_DISABLE_AH8)

Signature · 1 line

2.18.0

Can Guo

2020-12-22 11:34 UTC #1 lore raw

Quoted 14 lines · Stanley Chu

Flush during hibern8 is sufficient on MediaTek platforms, thus enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL to skip enabling fWriteBoosterBufferFlush during WriteBooster initialization.
Signed-off-by Stanley Chu <[email protected]>
---
 drivers/scsi/ufs/ufs-mediatek.c | 1 +
 1 file changed, 1 insertion(+)
drivers/scsi/ufs/ufs-mediatek.c +0 -0
index 80618af7c872..c55202b92a43 100644

drivers/scsi/ufs/ufs-mediatek.c static int ufs_mtk_init(struct ufs_hba *hba) · line 667

Quoted 7 lines

drivers/scsi/ufs/ufs-mediatek.c +1 -0

@@ -661,6 +661,7 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 
 	/* Enable WriteBooster */
 	hba->caps |= UFSHCD_CAP_WB_EN;
+	hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL;
 	hba->vps->wb_flush_threshold = UFS_WB_BUF_REMAIN_PERCENT(80);
 
 	if (host->caps & UFS_MTK_CAP_DISABLE_AH8)

I guess we need it too...

Change LGTM.

Regards,

Can Guo.

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Stanley Chu

author

2020-12-23 04:20 UTC #2 lore raw

Hi Can,

Quoted 17 lines · Can Guo

Quoted 16 lines · Stanley Chu
Flush during hibern8 is sufficient on MediaTek platforms, thus enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL to skip enabling fWriteBoosterBufferFlush during WriteBooster initialization.
Signed-off-by Stanley Chu <[email protected]>
---
 drivers/scsi/ufs/ufs-mediatek.c | 1 +
 1 file changed, 1 insertion(+)
drivers/scsi/ufs/ufs-mediatek.c +0 -0
index 80618af7c872..c55202b92a43 100644
@@ -661,6 +661,7 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 

Quoted 8 lines

drivers/scsi/ufs/ufs-mediatek.c static int ufs_mtk_init(struct ufs_hba *hba) · line 667
Quoted 6 lines
drivers/scsi/ufs/ufs-mediatek.c +1 -0
 	/* Enable WriteBooster */
 	hba->caps |= UFSHCD_CAP_WB_EN;
+	hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL;
 	hba->vps->wb_flush_threshold = UFS_WB_BUF_REMAIN_PERCENT(80);
 
 	if (host->caps & UFS_MTK_CAP_DISABLE_AH8)
I guess we need it too...

AHHA, if you decide to add this in your platform too later, maybe we could change the way it does: Keep manual flush disabled by default and remove this quirk.

Thanks,
Stanley Chu

Quoted 6 lines

Change LGTM.
Regards,
Can Guo.

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Can Guo

2020-12-23 04:41 UTC #3 lore raw

Quoted 25 lines · Stanley Chu

Hi Can,
Quoted 22 lines · Can Guo
Quoted 21 lines · Stanley Chu
Flush during hibern8 is sufficient on MediaTek platforms, thus enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL to skip enabling fWriteBoosterBufferFlush during WriteBooster initialization.
Signed-off-by Stanley Chu <[email protected]>
---
 drivers/scsi/ufs/ufs-mediatek.c | 1 +
 1 file changed, 1 insertion(+)
drivers/scsi/ufs/ufs-mediatek.c +1 -0
index 80618af7c872..c55202b92a43 100644
@@ -661,6 +661,7 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 
 	/* Enable WriteBooster */
 	hba->caps |= UFSHCD_CAP_WB_EN;
+	hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL;
 	hba->vps->wb_flush_threshold = UFS_WB_BUF_REMAIN_PERCENT(80);
 

Quoted 8 lines

Quoted 3 lines
drivers/scsi/ufs/ufs-mediatek.c static int ufs_mtk_init(struct ufs_hba *hba) · line 667
Quoted 1 line
drivers/scsi/ufs/ufs-mediatek.c +0 -0
 	if (host->caps & UFS_MTK_CAP_DISABLE_AH8)
I guess we need it too...
AHHA, if you decide to add this in your platform too later, maybe we could change the way it does: Keep manual flush disabled by default and remove this quirk.

Yeah... I will get back with an answer later.

Thanks,

Can Guo.

Quoted 8 lines

Thanks,
Stanley Chu
Quoted 6 lines
Change LGTM.
Regards,
Can Guo.

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Avri Altman

2020-12-23 07:47 UTC #4 lore raw

Quoted 23 lines · Stanley Chu

Quoted 6 lines
Hi Can,
Quoted 3 lines · Can Guo
Quoted 2 lines · Stanley Chu
Flush during hibern8 is sufficient on MediaTek platforms, thus enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL to skip
enabling
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
fWriteBoosterBufferFlush during WriteBooster initialization.
Signed-off-by Stanley Chu <[email protected]>
---
 drivers/scsi/ufs/ufs-mediatek.c | 1 +
 1 file changed, 1 insertion(+)
drivers/scsi/ufs/ufs-mediatek.c +0 -0
index 80618af7c872..c55202b92a43 100644
@@ -661,6 +661,7 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 

Quoted 13 lines

Quoted 4 lines
Quoted 4 lines
drivers/scsi/ufs/ufs-mediatek.c static int ufs_mtk_init(struct ufs_hba *hba)
Quoted 4 lines
drivers/scsi/ufs/ufs-mediatek.c +1 -0
   /* Enable WriteBooster */
   hba->caps |= UFSHCD_CAP_WB_EN;
+  hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL;
   hba->vps->wb_flush_threshold =
UFS_WB_BUF_REMAIN_PERCENT(80);
Quoted 8 lines
Quoted 4 lines
drivers/scsi/ufs/ufs-mediatek.c static int ufs_mtk_init(struct ufs_hba *hba) · line 667
Quoted 2 lines
drivers/scsi/ufs/ufs-mediatek.c +0 -0
   if (host->caps & UFS_MTK_CAP_DISABLE_AH8)
I guess we need it too...
AHHA, if you decide to add this in your platform too later, maybe we could change the way it does: Keep manual flush disabled by default and remove this quirk.

Ack on that.
I never understood why it was needed in the first place. Maybe just remove it, and allow to perform explicit flush from sysfs.

Thanks,
Avri

Quoted 3 lines

Quoted 1 line
Yeah... I will get back with an answer later.

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Bean Huo

2020-12-23 08:35 UTC #5 lore raw

Quoted 10 lines · Avri Altman

Quoted 3 lines
Quoted 3 lines
could change the way it does: Keep manual flush disabled by default and
remove this quirk.
Ack on that.
I never understood why it was needed in the first place. Maybe just remove it, and allow to perform explicit flush from sysfs.
Thanks,
Avr

Avri
I agree with you.
I don't understand why setting that at the begginnning, also assign this feature the contrller to make desicion.

Bean

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Avri Altman

Reviewed-by

2020-12-28 13:00 UTC #6 lore raw

In reply to Avri Altman

Quoted 5 lines

Quoted 5 lines · Stanley Chu
Quoted 2 lines
Hi Can,

Quoted 8 lines

Quoted 8 lines
Quoted 4 lines · Can Guo
Quoted 3 lines · Stanley Chu
Quoted 2 lines
Flush during hibern8 is sufficient on MediaTek platforms, thus enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL to skip
enabling
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
fWriteBoosterBufferFlush during WriteBooster initialization.
Signed-off-by Stanley Chu <[email protected]>

Reviewed-by Avri Altman <[email protected]>

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Can Guo

2020-12-24 02:21 UTC #7 lore raw

In reply to Can Guo

Quoted 30 lines · Can Guo

Quoted 29 lines · Stanley Chu
Hi Can,
Quoted 25 lines · Can Guo
Quoted 15 lines · Stanley Chu
Flush during hibern8 is sufficient on MediaTek platforms, thus enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL to skip enabling fWriteBoosterBufferFlush during WriteBooster initialization.
Signed-off-by Stanley Chu <[email protected]>
---
 drivers/scsi/ufs/ufs-mediatek.c | 1 +
 1 file changed, 1 insertion(+)
drivers/scsi/ufs/ufs-mediatek.c +0 -0
index 80618af7c872..c55202b92a43 100644
drivers/scsi/ufs/ufs-mediatek.c static int ufs_mtk_init(struct ufs_hba *hba) · line 667
Quoted 7 lines
drivers/scsi/ufs/ufs-mediatek.c +1 -0
@@ -661,6 +661,7 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 
 	/* Enable WriteBooster */
 	hba->caps |= UFSHCD_CAP_WB_EN;
+	hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL;
 	hba->vps->wb_flush_threshold = UFS_WB_BUF_REMAIN_PERCENT(80);
 
 	if (host->caps & UFS_MTK_CAP_DISABLE_AH8)
I guess we need it too...

Quoted 6 lines

Quoted 4 lines
AHHA, if you decide to add this in your platform too later, maybe we could change the way it does: Keep manual flush disabled by default and remove this quirk.
Yeah... I will get back with an answer later.

Hi Stanley,

Do you see any substantial benefit of having fWriteBoosterBufferFlushEn disabled?

Thanks,
Can Guo.

Quoted 13 lines

Thanks,
Can Guo.
Quoted 8 lines
Thanks,
Stanley Chu
Quoted 6 lines
Change LGTM.
Regards,
Can Guo.

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Stanley Chu

author

2020-12-24 07:52 UTC #8 lore raw

Hi Can,

Quoted 37 lines · Can Guo

Quoted 36 lines · Can Guo
Quoted 34 lines · Stanley Chu
Hi Can,
Quoted 17 lines · Can Guo
Quoted 16 lines · Stanley Chu
Flush during hibern8 is sufficient on MediaTek platforms, thus enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL to skip enabling fWriteBoosterBufferFlush during WriteBooster initialization.
Signed-off-by Stanley Chu <[email protected]>
---
 drivers/scsi/ufs/ufs-mediatek.c | 1 +
 1 file changed, 1 insertion(+)
drivers/scsi/ufs/ufs-mediatek.c +0 -0
index 80618af7c872..c55202b92a43 100644
@@ -661,6 +661,7 @@ static int ufs_mtk_init(struct ufs_hba *hba)
 
Quoted 8 lines
drivers/scsi/ufs/ufs-mediatek.c static int ufs_mtk_init(struct ufs_hba *hba) · line 667
Quoted 6 lines
drivers/scsi/ufs/ufs-mediatek.c +1 -0
 	/* Enable WriteBooster */
 	hba->caps |= UFSHCD_CAP_WB_EN;
+	hba->quirks |= UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL;
 	hba->vps->wb_flush_threshold = UFS_WB_BUF_REMAIN_PERCENT(80);
 
 	if (host->caps & UFS_MTK_CAP_DISABLE_AH8)
I guess we need it too...
AHHA, if you decide to add this in your platform too later, maybe we could change the way it does: Keep manual flush disabled by default and
remove this quirk.

Quoted 6 lines

Quoted 1 line
Yeah... I will get back with an answer later.
Hi Stanley,
Do you see any substantial benefit of having fWriteBoosterBufferFlushEn disabled?

1. The definition of fWriteBoosterBufferFlushEn is that host allows device to do flush in anytime after fWriteBoosterBufferFlushEn is set as on. This is not what we want.

Just Like BKOP, We do not want flush happening beyond host's expected timing that device performance may be "randomly" dropped.

2. Another related concern is that currently fWriteBoosterBufferFlushEn may keep on while device is not in Active Power Mode during suspend period. I am not sure if such configuration would confuse the device.

Thanks,
Stanley Chu

Quoted 17 lines

Thanks,
Can Guo.
Quoted 13 lines
Thanks,
Can Guo.
Quoted 8 lines
Thanks,
Stanley Chu
Quoted 6 lines
Change LGTM.
Regards,
Can Guo.

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Avri Altman

2020-12-24 11:03 UTC #9 lore raw

Hi,
Just to clarify things:

Quoted 9 lines

Quoted 2 lines
Do you see any substantial benefit of having fWriteBoosterBufferFlushEn disabled?
1. The definition of fWriteBoosterBufferFlushEn is that host allows device to do flush in anytime after fWriteBoosterBufferFlushEn is set as on. This is not what we want.
Just Like BKOP, We do not want flush happening beyond host's expected timing that device performance may be "randomly" dropped.

Explicit flush takes place only when the device is idle:
if fWriteBoosterBufferFlushEn is set, the device is idle, and before h8 received. If a request arrives, the flush operation should be halted.
So no performance degradation is expected.

Quoted 4 lines

2. Another related concern is that currently fWriteBoosterBufferFlushEn may keep on while device is not in Active Power Mode during suspend period. I am not sure if such configuration would confuse the device.

The spec says: " While the flushing operation is in progress, the device is in Active power mode"

Quoted 21 lines

Thanks,
Stanley Chu
Quoted 17 lines
Thanks,
Can Guo.
Quoted 13 lines
Thanks,
Can Guo.
Quoted 8 lines
Thanks,
Stanley Chu
Quoted 6 lines
Change LGTM.
Regards,
Can Guo.

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Bean Huo

2020-12-24 12:02 UTC #10 lore raw

Quoted 13 lines · Avri Altman

Quoted 4 lines
Quoted 3 lines
Do you see any substantial benefit of having
fWriteBoosterBufferFlushEn
disabled?
Quoted 8 lines
1. The definition of fWriteBoosterBufferFlushEn is that host allows device to do flush in anytime after fWriteBoosterBufferFlushEn is set as
on. This is not what we want.
Just Like BKOP, We do not want flush happening beyond host's expected
timing that device performance may be "randomly" dropped.

Quoted 5 lines

Explicit flush takes place only when the device is idle:
if fWriteBoosterBufferFlushEn is set, the device is idle, and before h8 received.
If a request arrives, the flush operation should be halted. So no performance degradation is expected.

Hi Stanley

Avri's comment is correct, fWriteBoosterBufferFlushEn==1, device will flush only when it is in idle, once there is new incoming request, the flush will be suspended. You should be very careful when you want to skip this stetting of this flag.

Bean

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Stanley Chu

author

2020-12-24 13:48 UTC #11 lore raw

Hi Avri, Bean,

Quoted 20 lines · Bean Huo

Quoted 13 lines · Avri Altman
Quoted 4 lines
Quoted 3 lines
Do you see any substantial benefit of having
fWriteBoosterBufferFlushEn
disabled?
Quoted 8 lines
1. The definition of fWriteBoosterBufferFlushEn is that host allows device to do flush in anytime after fWriteBoosterBufferFlushEn is set as
on. This is not what we want.
Just Like BKOP, We do not want flush happening beyond host's expected
timing that device performance may be "randomly" dropped.
Quoted 5 lines
Explicit flush takes place only when the device is idle:
if fWriteBoosterBufferFlushEn is set, the device is idle, and before h8 received.
If a request arrives, the flush operation should be halted. So no performance degradation is expected.

Quoted 6 lines

Hi Stanley
Avri's comment is correct, fWriteBoosterBufferFlushEn==1, device will flush only when it is in idle, once there is new incoming request, the flush will be suspended. You should be very careful when you want to skip this stetting of this flag.

Very appreciate your the clarification.

However similar to "Background Operations Termination Latency", while the next request comes, device may need some time to suspend on-going flush operations. This delay may "randomly" degrade the performance right?

Since the configuration, i.e., enable fWriteBoosterBufferFlushDuringHibernate only with fWriteBoosterBufferFlushEn disabled, has been applied in many of our mass-produced products these yeas, we would like to keep it unless the new setting has obvious benefits.

Thanks,
Stanley Chu

Quoted 3 lines

Bean

Asutosh Das (asd)

2020-12-28 01:33 UTC #12 lore raw

Quoted 30 lines · Stanley Chu

Hi Avri, Bean,
Quoted 20 lines · Bean Huo
Quoted 13 lines · Avri Altman
Quoted 4 lines
Quoted 3 lines
Do you see any substantial benefit of having
fWriteBoosterBufferFlushEn
disabled?
Quoted 8 lines
1. The definition of fWriteBoosterBufferFlushEn is that host allows device to do flush in anytime after fWriteBoosterBufferFlushEn is set as
on. This is not what we want.
Just Like BKOP, We do not want flush happening beyond host's expected
timing that device performance may be "randomly" dropped.
Quoted 5 lines
Explicit flush takes place only when the device is idle:
if fWriteBoosterBufferFlushEn is set, the device is idle, and before h8 received.
If a request arrives, the flush operation should be halted. So no performance degradation is expected.
Quoted 6 lines
Hi Stanley
Avri's comment is correct, fWriteBoosterBufferFlushEn==1, device will flush only when it is in idle, once there is new incoming request, the flush will be suspended. You should be very careful when you want to skip this stetting of this flag.

Quoted 7 lines

Very appreciate your the clarification.
However similar to "Background Operations Termination Latency", while the next request comes, device may need some time to suspend on-going flush operations. This delay may "randomly" degrade the performance right?

Have you actually seen this happening? I've not come across any random performance degradation concerns, hence asking.

From what I've observed is the handling of WB buffer flush depends on how flash vendors implement it. Some vendors that I've seen just create a separate WB buffer in an instant. I don't know the intricacies of their implementation, but I guess the new WB buffer handles the requests while the previous one is being flushed. Anyway, for Qualcomm platforms we plan to have fWriteBoosterBufferFlushEn=1 by default.

Quoted 13 lines

Since the configuration, i.e., enable fWriteBoosterBufferFlushDuringHibernate only with fWriteBoosterBufferFlushEn disabled, has been applied in many of our mass-produced products these yeas, we would like to keep it unless the new setting has obvious benefits.
Thanks,
Stanley Chu
Quoted 3 lines
Bean

Signature · 7 lines

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Stanley Chu

author

2020-12-28 02:01 UTC #13 lore raw

Hi Asutosh,

Quoted 42 lines · Asutosh Das (asd)

Quoted 30 lines · Stanley Chu
Hi Avri, Bean,
Quoted 20 lines · Bean Huo
Quoted 13 lines · Avri Altman
Quoted 4 lines
Quoted 3 lines
Do you see any substantial benefit of having
fWriteBoosterBufferFlushEn
disabled?
Quoted 8 lines
1. The definition of fWriteBoosterBufferFlushEn is that host allows device to do flush in anytime after fWriteBoosterBufferFlushEn is set as
on. This is not what we want.
Just Like BKOP, We do not want flush happening beyond host's expected
timing that device performance may be "randomly" dropped.
Quoted 5 lines
Explicit flush takes place only when the device is idle:
if fWriteBoosterBufferFlushEn is set, the device is idle, and before h8 received.
If a request arrives, the flush operation should be halted. So no performance degradation is expected.
Quoted 6 lines
Hi Stanley
Avri's comment is correct, fWriteBoosterBufferFlushEn==1, device will flush only when it is in idle, once there is new incoming request, the flush will be suspended. You should be very careful when you want to skip this stetting of this flag.
Quoted 7 lines
Very appreciate your the clarification.
However similar to "Background Operations Termination Latency", while the next request comes, device may need some time to suspend on-going flush operations. This delay may "randomly" degrade the performance right?
Have you actually seen this happening? I've not come across any random performance degradation concerns, hence asking.

Quoted 7 lines

From what I've observed is the handling of WB buffer flush depends on
how flash vendors implement it. Some vendors that I've seen just create a separate WB buffer in an instant. I don't know the intricacies of their implementation, but I guess the new WB buffer handles the requests while the previous one is being flushed.
Anyway, for Qualcomm platforms we plan to have fWriteBoosterBufferFlushEn=1 by default.

Thanks for above information and discussion : )

Actually we've not come across any random performance degradation due to fWriteBoosterBufferFlushEn=1 as well. Since the implementation of fWriteBoosterBufferFlushEn may differ by different vendors, we would like to keep current configuration used in our mass-produced products first.

But this is an interesting topic for possible termination latency of WriteBooster flush. Maybe we could discuss with vendors to explicitly define the required latency in UFS specification, just like "Background Operations Termination Latency"? Then host can choose the best configuration according to the definition provided by the device.

Thanks.
Stanley Chu

Quoted 16 lines

Quoted 14 lines
Since the configuration, i.e., enable fWriteBoosterBufferFlushDuringHibernate only with fWriteBoosterBufferFlushEn disabled, has been applied in many of our mass-produced products these yeas, we would like to keep it unless the new setting has obvious benefits.
Thanks,
Stanley Chu
Quoted 3 lines
Bean

Can Guo

2020-12-28 01:34 UTC #14 lore raw

In reply to Stanley Chu

Quoted 30 lines · Stanley Chu

Hi Avri, Bean,
Quoted 20 lines · Bean Huo
Quoted 13 lines · Avri Altman
Quoted 4 lines
Quoted 3 lines
Do you see any substantial benefit of having
fWriteBoosterBufferFlushEn
disabled?
Quoted 8 lines
1. The definition of fWriteBoosterBufferFlushEn is that host allows device to do flush in anytime after fWriteBoosterBufferFlushEn is set as
on. This is not what we want.
Just Like BKOP, We do not want flush happening beyond host's expected
timing that device performance may be "randomly" dropped.
Quoted 5 lines
Explicit flush takes place only when the device is idle:
if fWriteBoosterBufferFlushEn is set, the device is idle, and before h8 received.
If a request arrives, the flush operation should be halted. So no performance degradation is expected.
Quoted 6 lines
Hi Stanley
Avri's comment is correct, fWriteBoosterBufferFlushEn==1, device will flush only when it is in idle, once there is new incoming request, the flush will be suspended. You should be very careful when you want to skip this stetting of this flag.

Quoted 6 lines

Very appreciate your the clarification.
However similar to "Background Operations Termination Latency", while the next request comes, device may need some time to suspend on-going flush operations. This delay may "randomly" degrade the performance right?

That can be case by case (or vendor by vendor), but generally I agree with you on this.

Quoted 6 lines

Since the configuration, i.e., enable fWriteBoosterBufferFlushDuringHibernate only with fWriteBoosterBufferFlushEn disabled, has been applied in many of our mass-produced products these yeas, we would like to keep it unless the new setting has obvious benefits.

Thanks for sharing the info. I will leave the decision to Asutosh on this.

Thanks,
Can Guo.

Quoted 7 lines

Thanks,
Stanley Chu
Quoted 3 lines
Bean

_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek