lkml.org 
[lkml]   [2015]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] lightnvm: calculate device values correctly
From
OK, I see. Thanks for the explanation.

2015-11-23 2:34 GMT+08:00 Matias <mb@lightnvm.io>:
> On 11/22/2015 02:51 PM, Wenwei Tao wrote:
>>
>> In the original calculation, the relationships among
>> block, plane and lun was confusing, refine it on the
>> basis of Open-channelSSDInterfaceSpecification.
>>
>> Signed-off-by: Wenwei Tao <ww.tao0320@gmail.com>
>> ---
>> drivers/lightnvm/core.c | 9 ++++-----
>> 1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
>> index f659e60..1864b94 100644
>> --- a/drivers/lightnvm/core.c
>> +++ b/drivers/lightnvm/core.c
>> @@ -174,8 +174,8 @@ static int nvm_core_init(struct nvm_dev *dev)
>> dev->nr_chnls = grp->num_ch;
>> dev->luns_per_chnl = grp->num_lun;
>> dev->pgs_per_blk = grp->num_pg;
>> - dev->blks_per_lun = grp->num_blk;
>> dev->nr_planes = grp->num_pln;
>> + dev->blks_per_lun = grp->num_blk * grp->num_pln;
>> dev->sec_size = grp->csecs;
>> dev->oob_size = grp->sos;
>> dev->sec_per_pg = grp->fpg_sz / grp->csecs;
>> @@ -191,13 +191,12 @@ static int nvm_core_init(struct nvm_dev *dev)
>> dev->plane_mode = NVM_PLANE_QUAD;
>>
>> /* calculated values */
>> - dev->sec_per_pl = dev->sec_per_pg * dev->nr_planes;
>> - dev->sec_per_blk = dev->sec_per_pl * dev->pgs_per_blk;
>> + dev->sec_per_blk = dev->sec_per_pg * dev->pgs_per_blk;
>> + dev->sec_per_pl = dev->sec_per_blk * grp->num_blk;
>> dev->sec_per_lun = dev->sec_per_blk * dev->blks_per_lun;
>> dev->nr_luns = dev->luns_per_chnl * dev->nr_chnls;
>>
>> - dev->total_blocks = dev->nr_planes *
>> - dev->blks_per_lun *
>> + dev->total_blocks = dev->blks_per_lun *
>> dev->luns_per_chnl *
>> dev->nr_chnls;
>> dev->total_pages = dev->total_blocks * dev->pgs_per_blk;
>>
>
> The reason I had it as before, was because I wanted to drive the device in
> either single/double/quad read/write/erase plane mode. That way we could get
> away with only managing 1/4 or 1/2 of the block metadata.
>
> What is your use case? It could make sense, but it will require a little
> more work to build up the framework for having the various modes. i.e.
> detect supported plane mode, make a explicit decision about which plane mode
> to always use (or dynamically) and afterwards allocate the appropriate data
> structures.


\
 
 \ /
  Last update: 2015-11-23 03:41    [W:0.088 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site