Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-11-08 Thread Abhishek Sahu

On 2018-11-04 21:26, Boris Brezillon wrote:

Hi Abhishek,

On Fri, 20 Jul 2018 15:03:48 +0200
Boris Brezillon  wrote:


On Fri, 20 Jul 2018 17:46:38 +0530
Abhishek Sahu  wrote:

> Hi Boris,
>
> On 2018-07-19 03:13, Boris Brezillon wrote:
> > On Wed, 18 Jul 2018 23:23:50 +0200
> > Miquel Raynal  wrote:
> >
> >> Boris,
> >>
> >> Can you please check the change in qcom_nandc_write_oob() is
> >> valid? I think it is but as this is a bit of a hack I prefer double
> >> checking.
> >
> > Indeed, it's hack-ish.
> >
> >>
> >> Thanks,
> >> Miquèl
> >>
> >>
> >> Abhishek Sahu  wrote on Fri,  6 Jul 2018
> >> 13:21:56 +0530:
> >>
> >> > The NAND base layer calls write_oob() by setting bytes at
> >> > chip->badblockpos with value non 0xFF for updating bad block status.
> >> > The QCOM NAND controller skips the bad block bytes while doing normal
> >> > write with ECC enabled. When initial support for this driver was
> >> > added, the driver specific function was added temporarily for
> >> > block_markbad() with assumption to change for raw read in NAND base
> >> > layer. Moving to raw read for block_markbad() seems to take more time
> >> > so this patch removes driver specific block_markbad() function by
> >> > using following HACK in write_oob() function.
> >> >
> >> > Check for BBM bytes in OOB and accordingly do raw write for updating
> >> > BBM bytes in NAND flash or normal write for updating available OOB
> >> > bytes.
> >
> > Why don't we change that instead of patching the qcom driver to guess
> > when the core tries to mark a block bad? If you're afraid of breaking
> > existing drivers that might rely on the "write/read BBM in non-raw
> > mode" solution (I'm sure some drivers are), you can always add a new
> > flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
> > accessors when this flag is set.
> >
>
>   We started with that Only
>
>   http://patchwork.ozlabs.org/patch/508565/
>
>   and since we didn't conclude, we went for driver
>   specific bad block check and mark bad block functions.
>
>   Now, we wanted to get rid of driver specific functions
>
>   1. For bad block check, we found the way to get the BBM bytes
>  with ECC read. Controller updates BBM in separate register
>  which we can read and update the same in OOB. Patch #1 of
>  series does the same.
>
>   2. For bad block mark, there is no way to update in ECC mode
>  that's why we went for HACK to get rid of driver specific
>  function.
>
>   If adding flag is fine now then this HACK won't be required.

Yep. I'm fine with that. Can you rebase the patch you pointed out on 
top

of nand/next and move the flag to chip->options instead of
chip->bbt_options + prefix it with NAND_ instead of NAND_BBT_?


I'm currently trying to get rid of chip->block_bad() (now placed in
chip->legacy.block_bad()), and I wanted to know if you were still
planning to submit the changes we discussed in this thread. If you
don't have time, please let me know and I'll try to do it.



 Sorry Boris, I couldn't work on these patches.

 Currently, I am working on non open source projects so
 I can't submit any patches in open source till this project
 completion due to legal guidelines.

 If this is urgent then you can try. I will help in
 QCOM related stuffs and testing.

 Thanks,
 Abhishek



Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-11-08 Thread Abhishek Sahu

On 2018-11-04 21:26, Boris Brezillon wrote:

Hi Abhishek,

On Fri, 20 Jul 2018 15:03:48 +0200
Boris Brezillon  wrote:


On Fri, 20 Jul 2018 17:46:38 +0530
Abhishek Sahu  wrote:

> Hi Boris,
>
> On 2018-07-19 03:13, Boris Brezillon wrote:
> > On Wed, 18 Jul 2018 23:23:50 +0200
> > Miquel Raynal  wrote:
> >
> >> Boris,
> >>
> >> Can you please check the change in qcom_nandc_write_oob() is
> >> valid? I think it is but as this is a bit of a hack I prefer double
> >> checking.
> >
> > Indeed, it's hack-ish.
> >
> >>
> >> Thanks,
> >> Miquèl
> >>
> >>
> >> Abhishek Sahu  wrote on Fri,  6 Jul 2018
> >> 13:21:56 +0530:
> >>
> >> > The NAND base layer calls write_oob() by setting bytes at
> >> > chip->badblockpos with value non 0xFF for updating bad block status.
> >> > The QCOM NAND controller skips the bad block bytes while doing normal
> >> > write with ECC enabled. When initial support for this driver was
> >> > added, the driver specific function was added temporarily for
> >> > block_markbad() with assumption to change for raw read in NAND base
> >> > layer. Moving to raw read for block_markbad() seems to take more time
> >> > so this patch removes driver specific block_markbad() function by
> >> > using following HACK in write_oob() function.
> >> >
> >> > Check for BBM bytes in OOB and accordingly do raw write for updating
> >> > BBM bytes in NAND flash or normal write for updating available OOB
> >> > bytes.
> >
> > Why don't we change that instead of patching the qcom driver to guess
> > when the core tries to mark a block bad? If you're afraid of breaking
> > existing drivers that might rely on the "write/read BBM in non-raw
> > mode" solution (I'm sure some drivers are), you can always add a new
> > flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
> > accessors when this flag is set.
> >
>
>   We started with that Only
>
>   http://patchwork.ozlabs.org/patch/508565/
>
>   and since we didn't conclude, we went for driver
>   specific bad block check and mark bad block functions.
>
>   Now, we wanted to get rid of driver specific functions
>
>   1. For bad block check, we found the way to get the BBM bytes
>  with ECC read. Controller updates BBM in separate register
>  which we can read and update the same in OOB. Patch #1 of
>  series does the same.
>
>   2. For bad block mark, there is no way to update in ECC mode
>  that's why we went for HACK to get rid of driver specific
>  function.
>
>   If adding flag is fine now then this HACK won't be required.

Yep. I'm fine with that. Can you rebase the patch you pointed out on 
top

of nand/next and move the flag to chip->options instead of
chip->bbt_options + prefix it with NAND_ instead of NAND_BBT_?


I'm currently trying to get rid of chip->block_bad() (now placed in
chip->legacy.block_bad()), and I wanted to know if you were still
planning to submit the changes we discussed in this thread. If you
don't have time, please let me know and I'll try to do it.



 Sorry Boris, I couldn't work on these patches.

 Currently, I am working on non open source projects so
 I can't submit any patches in open source till this project
 completion due to legal guidelines.

 If this is urgent then you can try. I will help in
 QCOM related stuffs and testing.

 Thanks,
 Abhishek



Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-11-04 Thread Boris Brezillon
Hi Abhishek,

On Fri, 20 Jul 2018 15:03:48 +0200
Boris Brezillon  wrote:

> On Fri, 20 Jul 2018 17:46:38 +0530
> Abhishek Sahu  wrote:
> 
> > Hi Boris,
> > 
> > On 2018-07-19 03:13, Boris Brezillon wrote:  
> > > On Wed, 18 Jul 2018 23:23:50 +0200
> > > Miquel Raynal  wrote:
> > > 
> > >> Boris,
> > >> 
> > >> Can you please check the change in qcom_nandc_write_oob() is
> > >> valid? I think it is but as this is a bit of a hack I prefer double 
> > >> checking.
> > > 
> > > Indeed, it's hack-ish.
> > > 
> > >> 
> > >> Thanks,
> > >> Miquèl
> > >> 
> > >> 
> > >> Abhishek Sahu  wrote on Fri,  6 Jul 2018
> > >> 13:21:56 +0530:
> > >> 
> > >> > The NAND base layer calls write_oob() by setting bytes at
> > >> > chip->badblockpos with value non 0xFF for updating bad block status.
> > >> > The QCOM NAND controller skips the bad block bytes while doing normal
> > >> > write with ECC enabled. When initial support for this driver was
> > >> > added, the driver specific function was added temporarily for
> > >> > block_markbad() with assumption to change for raw read in NAND base
> > >> > layer. Moving to raw read for block_markbad() seems to take more time
> > >> > so this patch removes driver specific block_markbad() function by
> > >> > using following HACK in write_oob() function.
> > >> >
> > >> > Check for BBM bytes in OOB and accordingly do raw write for updating
> > >> > BBM bytes in NAND flash or normal write for updating available OOB
> > >> > bytes.
> > > 
> > > Why don't we change that instead of patching the qcom driver to guess
> > > when the core tries to mark a block bad? If you're afraid of breaking
> > > existing drivers that might rely on the "write/read BBM in non-raw
> > > mode" solution (I'm sure some drivers are), you can always add a new
> > > flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
> > > accessors when this flag is set.
> > > 
> > 
> >   We started with that Only
> > 
> >   http://patchwork.ozlabs.org/patch/508565/
> > 
> >   and since we didn't conclude, we went for driver
> >   specific bad block check and mark bad block functions.
> > 
> >   Now, we wanted to get rid of driver specific functions
> > 
> >   1. For bad block check, we found the way to get the BBM bytes
> >  with ECC read. Controller updates BBM in separate register
> >  which we can read and update the same in OOB. Patch #1 of
> >  series does the same.
> > 
> >   2. For bad block mark, there is no way to update in ECC mode
> >  that's why we went for HACK to get rid of driver specific
> >  function.
> > 
> >   If adding flag is fine now then this HACK won't be required.  
> 
> Yep. I'm fine with that. Can you rebase the patch you pointed out on top
> of nand/next and move the flag to chip->options instead of
> chip->bbt_options + prefix it with NAND_ instead of NAND_BBT_?

I'm currently trying to get rid of chip->block_bad() (now placed in
chip->legacy.block_bad()), and I wanted to know if you were still
planning to submit the changes we discussed in this thread. If you
don't have time, please let me know and I'll try to do it.

Thanks,

Boris


Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-11-04 Thread Boris Brezillon
Hi Abhishek,

On Fri, 20 Jul 2018 15:03:48 +0200
Boris Brezillon  wrote:

> On Fri, 20 Jul 2018 17:46:38 +0530
> Abhishek Sahu  wrote:
> 
> > Hi Boris,
> > 
> > On 2018-07-19 03:13, Boris Brezillon wrote:  
> > > On Wed, 18 Jul 2018 23:23:50 +0200
> > > Miquel Raynal  wrote:
> > > 
> > >> Boris,
> > >> 
> > >> Can you please check the change in qcom_nandc_write_oob() is
> > >> valid? I think it is but as this is a bit of a hack I prefer double 
> > >> checking.
> > > 
> > > Indeed, it's hack-ish.
> > > 
> > >> 
> > >> Thanks,
> > >> Miquèl
> > >> 
> > >> 
> > >> Abhishek Sahu  wrote on Fri,  6 Jul 2018
> > >> 13:21:56 +0530:
> > >> 
> > >> > The NAND base layer calls write_oob() by setting bytes at
> > >> > chip->badblockpos with value non 0xFF for updating bad block status.
> > >> > The QCOM NAND controller skips the bad block bytes while doing normal
> > >> > write with ECC enabled. When initial support for this driver was
> > >> > added, the driver specific function was added temporarily for
> > >> > block_markbad() with assumption to change for raw read in NAND base
> > >> > layer. Moving to raw read for block_markbad() seems to take more time
> > >> > so this patch removes driver specific block_markbad() function by
> > >> > using following HACK in write_oob() function.
> > >> >
> > >> > Check for BBM bytes in OOB and accordingly do raw write for updating
> > >> > BBM bytes in NAND flash or normal write for updating available OOB
> > >> > bytes.
> > > 
> > > Why don't we change that instead of patching the qcom driver to guess
> > > when the core tries to mark a block bad? If you're afraid of breaking
> > > existing drivers that might rely on the "write/read BBM in non-raw
> > > mode" solution (I'm sure some drivers are), you can always add a new
> > > flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
> > > accessors when this flag is set.
> > > 
> > 
> >   We started with that Only
> > 
> >   http://patchwork.ozlabs.org/patch/508565/
> > 
> >   and since we didn't conclude, we went for driver
> >   specific bad block check and mark bad block functions.
> > 
> >   Now, we wanted to get rid of driver specific functions
> > 
> >   1. For bad block check, we found the way to get the BBM bytes
> >  with ECC read. Controller updates BBM in separate register
> >  which we can read and update the same in OOB. Patch #1 of
> >  series does the same.
> > 
> >   2. For bad block mark, there is no way to update in ECC mode
> >  that's why we went for HACK to get rid of driver specific
> >  function.
> > 
> >   If adding flag is fine now then this HACK won't be required.  
> 
> Yep. I'm fine with that. Can you rebase the patch you pointed out on top
> of nand/next and move the flag to chip->options instead of
> chip->bbt_options + prefix it with NAND_ instead of NAND_BBT_?

I'm currently trying to get rid of chip->block_bad() (now placed in
chip->legacy.block_bad()), and I wanted to know if you were still
planning to submit the changes we discussed in this thread. If you
don't have time, please let me know and I'll try to do it.

Thanks,

Boris


Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-07-20 Thread Boris Brezillon
On Fri, 20 Jul 2018 17:46:38 +0530
Abhishek Sahu  wrote:

> Hi Boris,
> 
> On 2018-07-19 03:13, Boris Brezillon wrote:
> > On Wed, 18 Jul 2018 23:23:50 +0200
> > Miquel Raynal  wrote:
> >   
> >> Boris,
> >> 
> >> Can you please check the change in qcom_nandc_write_oob() is
> >> valid? I think it is but as this is a bit of a hack I prefer double 
> >> checking.  
> > 
> > Indeed, it's hack-ish.
> >   
> >> 
> >> Thanks,
> >> Miquèl
> >> 
> >> 
> >> Abhishek Sahu  wrote on Fri,  6 Jul 2018
> >> 13:21:56 +0530:
> >>   
> >> > The NAND base layer calls write_oob() by setting bytes at
> >> > chip->badblockpos with value non 0xFF for updating bad block status.
> >> > The QCOM NAND controller skips the bad block bytes while doing normal
> >> > write with ECC enabled. When initial support for this driver was
> >> > added, the driver specific function was added temporarily for
> >> > block_markbad() with assumption to change for raw read in NAND base
> >> > layer. Moving to raw read for block_markbad() seems to take more time
> >> > so this patch removes driver specific block_markbad() function by
> >> > using following HACK in write_oob() function.
> >> >
> >> > Check for BBM bytes in OOB and accordingly do raw write for updating
> >> > BBM bytes in NAND flash or normal write for updating available OOB
> >> > bytes.  
> > 
> > Why don't we change that instead of patching the qcom driver to guess
> > when the core tries to mark a block bad? If you're afraid of breaking
> > existing drivers that might rely on the "write/read BBM in non-raw
> > mode" solution (I'm sure some drivers are), you can always add a new
> > flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
> > accessors when this flag is set.
> >   
> 
>   We started with that Only
> 
>   http://patchwork.ozlabs.org/patch/508565/
> 
>   and since we didn't conclude, we went for driver
>   specific bad block check and mark bad block functions.
> 
>   Now, we wanted to get rid of driver specific functions
> 
>   1. For bad block check, we found the way to get the BBM bytes
>  with ECC read. Controller updates BBM in separate register
>  which we can read and update the same in OOB. Patch #1 of
>  series does the same.
> 
>   2. For bad block mark, there is no way to update in ECC mode
>  that's why we went for HACK to get rid of driver specific
>  function.
> 
>   If adding flag is fine now then this HACK won't be required.

Yep. I'm fine with that. Can you rebase the patch you pointed out on top
of nand/next and move the flag to chip->options instead of
chip->bbt_options + prefix it with NAND_ instead of NAND_BBT_?


>   Moving to RAW mode for every one still looks risky.

I agree.


Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-07-20 Thread Boris Brezillon
On Fri, 20 Jul 2018 17:46:38 +0530
Abhishek Sahu  wrote:

> Hi Boris,
> 
> On 2018-07-19 03:13, Boris Brezillon wrote:
> > On Wed, 18 Jul 2018 23:23:50 +0200
> > Miquel Raynal  wrote:
> >   
> >> Boris,
> >> 
> >> Can you please check the change in qcom_nandc_write_oob() is
> >> valid? I think it is but as this is a bit of a hack I prefer double 
> >> checking.  
> > 
> > Indeed, it's hack-ish.
> >   
> >> 
> >> Thanks,
> >> Miquèl
> >> 
> >> 
> >> Abhishek Sahu  wrote on Fri,  6 Jul 2018
> >> 13:21:56 +0530:
> >>   
> >> > The NAND base layer calls write_oob() by setting bytes at
> >> > chip->badblockpos with value non 0xFF for updating bad block status.
> >> > The QCOM NAND controller skips the bad block bytes while doing normal
> >> > write with ECC enabled. When initial support for this driver was
> >> > added, the driver specific function was added temporarily for
> >> > block_markbad() with assumption to change for raw read in NAND base
> >> > layer. Moving to raw read for block_markbad() seems to take more time
> >> > so this patch removes driver specific block_markbad() function by
> >> > using following HACK in write_oob() function.
> >> >
> >> > Check for BBM bytes in OOB and accordingly do raw write for updating
> >> > BBM bytes in NAND flash or normal write for updating available OOB
> >> > bytes.  
> > 
> > Why don't we change that instead of patching the qcom driver to guess
> > when the core tries to mark a block bad? If you're afraid of breaking
> > existing drivers that might rely on the "write/read BBM in non-raw
> > mode" solution (I'm sure some drivers are), you can always add a new
> > flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
> > accessors when this flag is set.
> >   
> 
>   We started with that Only
> 
>   http://patchwork.ozlabs.org/patch/508565/
> 
>   and since we didn't conclude, we went for driver
>   specific bad block check and mark bad block functions.
> 
>   Now, we wanted to get rid of driver specific functions
> 
>   1. For bad block check, we found the way to get the BBM bytes
>  with ECC read. Controller updates BBM in separate register
>  which we can read and update the same in OOB. Patch #1 of
>  series does the same.
> 
>   2. For bad block mark, there is no way to update in ECC mode
>  that's why we went for HACK to get rid of driver specific
>  function.
> 
>   If adding flag is fine now then this HACK won't be required.

Yep. I'm fine with that. Can you rebase the patch you pointed out on top
of nand/next and move the flag to chip->options instead of
chip->bbt_options + prefix it with NAND_ instead of NAND_BBT_?


>   Moving to RAW mode for every one still looks risky.

I agree.


Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-07-20 Thread Abhishek Sahu

Hi Boris,

On 2018-07-19 03:13, Boris Brezillon wrote:

On Wed, 18 Jul 2018 23:23:50 +0200
Miquel Raynal  wrote:


Boris,

Can you please check the change in qcom_nandc_write_oob() is
valid? I think it is but as this is a bit of a hack I prefer double 
checking.


Indeed, it's hack-ish.



Thanks,
Miquèl


Abhishek Sahu  wrote on Fri,  6 Jul 2018
13:21:56 +0530:

> The NAND base layer calls write_oob() by setting bytes at
> chip->badblockpos with value non 0xFF for updating bad block status.
> The QCOM NAND controller skips the bad block bytes while doing normal
> write with ECC enabled. When initial support for this driver was
> added, the driver specific function was added temporarily for
> block_markbad() with assumption to change for raw read in NAND base
> layer. Moving to raw read for block_markbad() seems to take more time
> so this patch removes driver specific block_markbad() function by
> using following HACK in write_oob() function.
>
> Check for BBM bytes in OOB and accordingly do raw write for updating
> BBM bytes in NAND flash or normal write for updating available OOB
> bytes.


Why don't we change that instead of patching the qcom driver to guess
when the core tries to mark a block bad? If you're afraid of breaking
existing drivers that might rely on the "write/read BBM in non-raw
mode" solution (I'm sure some drivers are), you can always add a new
flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
accessors when this flag is set.



 We started with that Only

 http://patchwork.ozlabs.org/patch/508565/

 and since we didn't conclude, we went for driver
 specific bad block check and mark bad block functions.

 Now, we wanted to get rid of driver specific functions

 1. For bad block check, we found the way to get the BBM bytes
with ECC read. Controller updates BBM in separate register
which we can read and update the same in OOB. Patch #1 of
series does the same.

 2. For bad block mark, there is no way to update in ECC mode
that's why we went for HACK to get rid of driver specific
function.

 If adding flag is fine now then this HACK won't be required.
 Moving to RAW mode for every one still looks risky.

 Thanks,
 Abhishek




Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-07-20 Thread Abhishek Sahu

Hi Boris,

On 2018-07-19 03:13, Boris Brezillon wrote:

On Wed, 18 Jul 2018 23:23:50 +0200
Miquel Raynal  wrote:


Boris,

Can you please check the change in qcom_nandc_write_oob() is
valid? I think it is but as this is a bit of a hack I prefer double 
checking.


Indeed, it's hack-ish.



Thanks,
Miquèl


Abhishek Sahu  wrote on Fri,  6 Jul 2018
13:21:56 +0530:

> The NAND base layer calls write_oob() by setting bytes at
> chip->badblockpos with value non 0xFF for updating bad block status.
> The QCOM NAND controller skips the bad block bytes while doing normal
> write with ECC enabled. When initial support for this driver was
> added, the driver specific function was added temporarily for
> block_markbad() with assumption to change for raw read in NAND base
> layer. Moving to raw read for block_markbad() seems to take more time
> so this patch removes driver specific block_markbad() function by
> using following HACK in write_oob() function.
>
> Check for BBM bytes in OOB and accordingly do raw write for updating
> BBM bytes in NAND flash or normal write for updating available OOB
> bytes.


Why don't we change that instead of patching the qcom driver to guess
when the core tries to mark a block bad? If you're afraid of breaking
existing drivers that might rely on the "write/read BBM in non-raw
mode" solution (I'm sure some drivers are), you can always add a new
flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
accessors when this flag is set.



 We started with that Only

 http://patchwork.ozlabs.org/patch/508565/

 and since we didn't conclude, we went for driver
 specific bad block check and mark bad block functions.

 Now, we wanted to get rid of driver specific functions

 1. For bad block check, we found the way to get the BBM bytes
with ECC read. Controller updates BBM in separate register
which we can read and update the same in OOB. Patch #1 of
series does the same.

 2. For bad block mark, there is no way to update in ECC mode
that's why we went for HACK to get rid of driver specific
function.

 If adding flag is fine now then this HACK won't be required.
 Moving to RAW mode for every one still looks risky.

 Thanks,
 Abhishek




Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-07-18 Thread Boris Brezillon
On Wed, 18 Jul 2018 23:23:50 +0200
Miquel Raynal  wrote:

> Boris,
> 
> Can you please check the change in qcom_nandc_write_oob() is
> valid? I think it is but as this is a bit of a hack I prefer double checking.

Indeed, it's hack-ish.

> 
> Thanks,
> Miquèl
> 
> 
> Abhishek Sahu  wrote on Fri,  6 Jul 2018
> 13:21:56 +0530:
> 
> > The NAND base layer calls write_oob() by setting bytes at
> > chip->badblockpos with value non 0xFF for updating bad block status.
> > The QCOM NAND controller skips the bad block bytes while doing normal
> > write with ECC enabled. When initial support for this driver was
> > added, the driver specific function was added temporarily for
> > block_markbad() with assumption to change for raw read in NAND base
> > layer. Moving to raw read for block_markbad() seems to take more time
> > so this patch removes driver specific block_markbad() function by
> > using following HACK in write_oob() function.
> > 
> > Check for BBM bytes in OOB and accordingly do raw write for updating
> > BBM bytes in NAND flash or normal write for updating available OOB
> > bytes.

Why don't we change that instead of patching the qcom driver to guess
when the core tries to mark a block bad? If you're afraid of breaking
existing drivers that might rely on the "write/read BBM in non-raw
mode" solution (I'm sure some drivers are), you can always add a new
flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
accessors when this flag is set.

> > 
> > Signed-off-by: Abhishek Sahu 
> > ---
> >  drivers/mtd/nand/raw/qcom_nandc.c | 103 
> > +++---
> >  1 file changed, 40 insertions(+), 63 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/raw/qcom_nandc.c 
> > b/drivers/mtd/nand/raw/qcom_nandc.c
> > index ea253ac..df12cf3 100644
> > --- a/drivers/mtd/nand/raw/qcom_nandc.c
> > +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> > @@ -2138,28 +2138,57 @@ static int qcom_nandc_write_oob(struct mtd_info 
> > *mtd, struct nand_chip *chip,
> > struct qcom_nand_host *host = to_qcom_nand_host(chip);
> > struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
> > struct nand_ecc_ctrl *ecc = >ecc;
> > -   u8 *oob = chip->oob_poi;
> > -   int data_size, oob_size;
> > +   u8 *oob = chip->oob_poi, bbm_byte;
> > +   int data_size, oob_size, bbm_offset, write_size;
> > int ret;
> >  
> > -   host->use_ecc = true;
> > clear_bam_transaction(nandc);
> >  
> > -   /* calculate the data and oob size for the last codeword/step */
> > -   data_size = ecc->size - ((ecc->steps - 1) << 2);
> > -   oob_size = mtd->oobavail;
> > +   /*
> > +* The NAND base layer calls ecc->write_oob() by setting bytes at
> > +* chip->badblockpos (chip->badblockpos will be 0 for QCOM NAND
> > +* controller layout) in OOB buffer with value other that 0xFF
> > +* for updating bad block status. QCOM NAND controller skips
> > +* BBM bytes while writing with ECC, so following HACK has been
> > +* added in this function for using generic block_markbad() function.
> > +*
> > +* Check for BBM bytes in OOB and accordingly do raw write for
> > +* updating BBM bytes in NAND flash or normal write with ECC for
> > +* updating available OOB bytes.
> > +*/
> > +   bbm_byte = oob[0];
> > +   if (chip->options & NAND_BUSWIDTH_16)
> > +   bbm_byte &= oob[1];
> >  
> > -   memset(nandc->data_buffer, 0xff, host->cw_data);
> > -   /* override new oob content to last codeword */
> > -   mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size, oob,
> > -   0, mtd->oobavail);
> > +   /* Write BBM bytes by doing raw write. */
> > +   if (bbm_byte != 0xff) {
> > +   host->use_ecc = false;
> > +   memset(nandc->data_buffer, 0xff, host->cw_size);
> > +   /* Determine the BBM bytes position and update the same */
> > +   bbm_offset = mtd->writesize - host->cw_size * (ecc->steps - 1);
> > +   memcpy(nandc->data_buffer + bbm_offset, oob, host->bbm_size);
> > +   write_size = host->cw_size;
> > +   /* Write OOB bytes by doing normal write with ECC */
> > +   } else {
> > +   host->use_ecc = true;
> > +   /* calculate the data and oob size for the last codeword/step */
> > +   data_size = ecc->size - ((ecc->steps - 1) << 2);
> > +   oob_size = mtd->oobavail;
> > +
> > +   memset(nandc->data_buffer, 0xff, host->cw_data);
> > +   /* override new oob content to last codeword */
> > +   mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size,
> > +   oob, 0, mtd->oobavail);
> > +
> > +   write_size = data_size + oob_size;
> > +   }
> >  
> > set_address(host, host->cw_size * (ecc->steps - 1), page);
> > update_rw_regs(host, 1, false);
> >  
> > config_nand_page_write(nandc);
> > write_data_dma(nandc, FLASH_BUF_ACC,
> > -  nandc->data_buffer, 

Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-07-18 Thread Boris Brezillon
On Wed, 18 Jul 2018 23:23:50 +0200
Miquel Raynal  wrote:

> Boris,
> 
> Can you please check the change in qcom_nandc_write_oob() is
> valid? I think it is but as this is a bit of a hack I prefer double checking.

Indeed, it's hack-ish.

> 
> Thanks,
> Miquèl
> 
> 
> Abhishek Sahu  wrote on Fri,  6 Jul 2018
> 13:21:56 +0530:
> 
> > The NAND base layer calls write_oob() by setting bytes at
> > chip->badblockpos with value non 0xFF for updating bad block status.
> > The QCOM NAND controller skips the bad block bytes while doing normal
> > write with ECC enabled. When initial support for this driver was
> > added, the driver specific function was added temporarily for
> > block_markbad() with assumption to change for raw read in NAND base
> > layer. Moving to raw read for block_markbad() seems to take more time
> > so this patch removes driver specific block_markbad() function by
> > using following HACK in write_oob() function.
> > 
> > Check for BBM bytes in OOB and accordingly do raw write for updating
> > BBM bytes in NAND flash or normal write for updating available OOB
> > bytes.

Why don't we change that instead of patching the qcom driver to guess
when the core tries to mark a block bad? If you're afraid of breaking
existing drivers that might rely on the "write/read BBM in non-raw
mode" solution (I'm sure some drivers are), you can always add a new
flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
accessors when this flag is set.

> > 
> > Signed-off-by: Abhishek Sahu 
> > ---
> >  drivers/mtd/nand/raw/qcom_nandc.c | 103 
> > +++---
> >  1 file changed, 40 insertions(+), 63 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/raw/qcom_nandc.c 
> > b/drivers/mtd/nand/raw/qcom_nandc.c
> > index ea253ac..df12cf3 100644
> > --- a/drivers/mtd/nand/raw/qcom_nandc.c
> > +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> > @@ -2138,28 +2138,57 @@ static int qcom_nandc_write_oob(struct mtd_info 
> > *mtd, struct nand_chip *chip,
> > struct qcom_nand_host *host = to_qcom_nand_host(chip);
> > struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
> > struct nand_ecc_ctrl *ecc = >ecc;
> > -   u8 *oob = chip->oob_poi;
> > -   int data_size, oob_size;
> > +   u8 *oob = chip->oob_poi, bbm_byte;
> > +   int data_size, oob_size, bbm_offset, write_size;
> > int ret;
> >  
> > -   host->use_ecc = true;
> > clear_bam_transaction(nandc);
> >  
> > -   /* calculate the data and oob size for the last codeword/step */
> > -   data_size = ecc->size - ((ecc->steps - 1) << 2);
> > -   oob_size = mtd->oobavail;
> > +   /*
> > +* The NAND base layer calls ecc->write_oob() by setting bytes at
> > +* chip->badblockpos (chip->badblockpos will be 0 for QCOM NAND
> > +* controller layout) in OOB buffer with value other that 0xFF
> > +* for updating bad block status. QCOM NAND controller skips
> > +* BBM bytes while writing with ECC, so following HACK has been
> > +* added in this function for using generic block_markbad() function.
> > +*
> > +* Check for BBM bytes in OOB and accordingly do raw write for
> > +* updating BBM bytes in NAND flash or normal write with ECC for
> > +* updating available OOB bytes.
> > +*/
> > +   bbm_byte = oob[0];
> > +   if (chip->options & NAND_BUSWIDTH_16)
> > +   bbm_byte &= oob[1];
> >  
> > -   memset(nandc->data_buffer, 0xff, host->cw_data);
> > -   /* override new oob content to last codeword */
> > -   mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size, oob,
> > -   0, mtd->oobavail);
> > +   /* Write BBM bytes by doing raw write. */
> > +   if (bbm_byte != 0xff) {
> > +   host->use_ecc = false;
> > +   memset(nandc->data_buffer, 0xff, host->cw_size);
> > +   /* Determine the BBM bytes position and update the same */
> > +   bbm_offset = mtd->writesize - host->cw_size * (ecc->steps - 1);
> > +   memcpy(nandc->data_buffer + bbm_offset, oob, host->bbm_size);
> > +   write_size = host->cw_size;
> > +   /* Write OOB bytes by doing normal write with ECC */
> > +   } else {
> > +   host->use_ecc = true;
> > +   /* calculate the data and oob size for the last codeword/step */
> > +   data_size = ecc->size - ((ecc->steps - 1) << 2);
> > +   oob_size = mtd->oobavail;
> > +
> > +   memset(nandc->data_buffer, 0xff, host->cw_data);
> > +   /* override new oob content to last codeword */
> > +   mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size,
> > +   oob, 0, mtd->oobavail);
> > +
> > +   write_size = data_size + oob_size;
> > +   }
> >  
> > set_address(host, host->cw_size * (ecc->steps - 1), page);
> > update_rw_regs(host, 1, false);
> >  
> > config_nand_page_write(nandc);
> > write_data_dma(nandc, FLASH_BUF_ACC,
> > -  nandc->data_buffer, 

Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-07-18 Thread Miquel Raynal
Boris,

Can you please check the change in qcom_nandc_write_oob() is
valid? I think it is but as this is a bit of a hack I prefer double checking.

Thanks,
Miquèl


Abhishek Sahu  wrote on Fri,  6 Jul 2018
13:21:56 +0530:

> The NAND base layer calls write_oob() by setting bytes at
> chip->badblockpos with value non 0xFF for updating bad block status.
> The QCOM NAND controller skips the bad block bytes while doing normal
> write with ECC enabled. When initial support for this driver was
> added, the driver specific function was added temporarily for
> block_markbad() with assumption to change for raw read in NAND base
> layer. Moving to raw read for block_markbad() seems to take more time
> so this patch removes driver specific block_markbad() function by
> using following HACK in write_oob() function.
> 
> Check for BBM bytes in OOB and accordingly do raw write for updating
> BBM bytes in NAND flash or normal write for updating available OOB
> bytes.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/mtd/nand/raw/qcom_nandc.c | 103 
> +++---
>  1 file changed, 40 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c 
> b/drivers/mtd/nand/raw/qcom_nandc.c
> index ea253ac..df12cf3 100644
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> @@ -2138,28 +2138,57 @@ static int qcom_nandc_write_oob(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   struct qcom_nand_host *host = to_qcom_nand_host(chip);
>   struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
>   struct nand_ecc_ctrl *ecc = >ecc;
> - u8 *oob = chip->oob_poi;
> - int data_size, oob_size;
> + u8 *oob = chip->oob_poi, bbm_byte;
> + int data_size, oob_size, bbm_offset, write_size;
>   int ret;
>  
> - host->use_ecc = true;
>   clear_bam_transaction(nandc);
>  
> - /* calculate the data and oob size for the last codeword/step */
> - data_size = ecc->size - ((ecc->steps - 1) << 2);
> - oob_size = mtd->oobavail;
> + /*
> +  * The NAND base layer calls ecc->write_oob() by setting bytes at
> +  * chip->badblockpos (chip->badblockpos will be 0 for QCOM NAND
> +  * controller layout) in OOB buffer with value other that 0xFF
> +  * for updating bad block status. QCOM NAND controller skips
> +  * BBM bytes while writing with ECC, so following HACK has been
> +  * added in this function for using generic block_markbad() function.
> +  *
> +  * Check for BBM bytes in OOB and accordingly do raw write for
> +  * updating BBM bytes in NAND flash or normal write with ECC for
> +  * updating available OOB bytes.
> +  */
> + bbm_byte = oob[0];
> + if (chip->options & NAND_BUSWIDTH_16)
> + bbm_byte &= oob[1];
>  
> - memset(nandc->data_buffer, 0xff, host->cw_data);
> - /* override new oob content to last codeword */
> - mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size, oob,
> - 0, mtd->oobavail);
> + /* Write BBM bytes by doing raw write. */
> + if (bbm_byte != 0xff) {
> + host->use_ecc = false;
> + memset(nandc->data_buffer, 0xff, host->cw_size);
> + /* Determine the BBM bytes position and update the same */
> + bbm_offset = mtd->writesize - host->cw_size * (ecc->steps - 1);
> + memcpy(nandc->data_buffer + bbm_offset, oob, host->bbm_size);
> + write_size = host->cw_size;
> + /* Write OOB bytes by doing normal write with ECC */
> + } else {
> + host->use_ecc = true;
> + /* calculate the data and oob size for the last codeword/step */
> + data_size = ecc->size - ((ecc->steps - 1) << 2);
> + oob_size = mtd->oobavail;
> +
> + memset(nandc->data_buffer, 0xff, host->cw_data);
> + /* override new oob content to last codeword */
> + mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size,
> + oob, 0, mtd->oobavail);
> +
> + write_size = data_size + oob_size;
> + }
>  
>   set_address(host, host->cw_size * (ecc->steps - 1), page);
>   update_rw_regs(host, 1, false);
>  
>   config_nand_page_write(nandc);
>   write_data_dma(nandc, FLASH_BUF_ACC,
> -nandc->data_buffer, data_size + oob_size, 0);
> +nandc->data_buffer, write_size, 0);
>   config_nand_cw_write(nandc);
>  
>   ret = submit_descs(nandc);
> @@ -2174,48 +2203,6 @@ static int qcom_nandc_write_oob(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   return nand_prog_page_end_op(chip);
>  }
>  
> -static int qcom_nandc_block_markbad(struct mtd_info *mtd, loff_t ofs)
> -{
> - struct nand_chip *chip = mtd_to_nand(mtd);
> - struct qcom_nand_host *host = to_qcom_nand_host(chip);
> - struct qcom_nand_controller *nandc = 

Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-07-18 Thread Miquel Raynal
Boris,

Can you please check the change in qcom_nandc_write_oob() is
valid? I think it is but as this is a bit of a hack I prefer double checking.

Thanks,
Miquèl


Abhishek Sahu  wrote on Fri,  6 Jul 2018
13:21:56 +0530:

> The NAND base layer calls write_oob() by setting bytes at
> chip->badblockpos with value non 0xFF for updating bad block status.
> The QCOM NAND controller skips the bad block bytes while doing normal
> write with ECC enabled. When initial support for this driver was
> added, the driver specific function was added temporarily for
> block_markbad() with assumption to change for raw read in NAND base
> layer. Moving to raw read for block_markbad() seems to take more time
> so this patch removes driver specific block_markbad() function by
> using following HACK in write_oob() function.
> 
> Check for BBM bytes in OOB and accordingly do raw write for updating
> BBM bytes in NAND flash or normal write for updating available OOB
> bytes.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/mtd/nand/raw/qcom_nandc.c | 103 
> +++---
>  1 file changed, 40 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c 
> b/drivers/mtd/nand/raw/qcom_nandc.c
> index ea253ac..df12cf3 100644
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> @@ -2138,28 +2138,57 @@ static int qcom_nandc_write_oob(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   struct qcom_nand_host *host = to_qcom_nand_host(chip);
>   struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
>   struct nand_ecc_ctrl *ecc = >ecc;
> - u8 *oob = chip->oob_poi;
> - int data_size, oob_size;
> + u8 *oob = chip->oob_poi, bbm_byte;
> + int data_size, oob_size, bbm_offset, write_size;
>   int ret;
>  
> - host->use_ecc = true;
>   clear_bam_transaction(nandc);
>  
> - /* calculate the data and oob size for the last codeword/step */
> - data_size = ecc->size - ((ecc->steps - 1) << 2);
> - oob_size = mtd->oobavail;
> + /*
> +  * The NAND base layer calls ecc->write_oob() by setting bytes at
> +  * chip->badblockpos (chip->badblockpos will be 0 for QCOM NAND
> +  * controller layout) in OOB buffer with value other that 0xFF
> +  * for updating bad block status. QCOM NAND controller skips
> +  * BBM bytes while writing with ECC, so following HACK has been
> +  * added in this function for using generic block_markbad() function.
> +  *
> +  * Check for BBM bytes in OOB and accordingly do raw write for
> +  * updating BBM bytes in NAND flash or normal write with ECC for
> +  * updating available OOB bytes.
> +  */
> + bbm_byte = oob[0];
> + if (chip->options & NAND_BUSWIDTH_16)
> + bbm_byte &= oob[1];
>  
> - memset(nandc->data_buffer, 0xff, host->cw_data);
> - /* override new oob content to last codeword */
> - mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size, oob,
> - 0, mtd->oobavail);
> + /* Write BBM bytes by doing raw write. */
> + if (bbm_byte != 0xff) {
> + host->use_ecc = false;
> + memset(nandc->data_buffer, 0xff, host->cw_size);
> + /* Determine the BBM bytes position and update the same */
> + bbm_offset = mtd->writesize - host->cw_size * (ecc->steps - 1);
> + memcpy(nandc->data_buffer + bbm_offset, oob, host->bbm_size);
> + write_size = host->cw_size;
> + /* Write OOB bytes by doing normal write with ECC */
> + } else {
> + host->use_ecc = true;
> + /* calculate the data and oob size for the last codeword/step */
> + data_size = ecc->size - ((ecc->steps - 1) << 2);
> + oob_size = mtd->oobavail;
> +
> + memset(nandc->data_buffer, 0xff, host->cw_data);
> + /* override new oob content to last codeword */
> + mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size,
> + oob, 0, mtd->oobavail);
> +
> + write_size = data_size + oob_size;
> + }
>  
>   set_address(host, host->cw_size * (ecc->steps - 1), page);
>   update_rw_regs(host, 1, false);
>  
>   config_nand_page_write(nandc);
>   write_data_dma(nandc, FLASH_BUF_ACC,
> -nandc->data_buffer, data_size + oob_size, 0);
> +nandc->data_buffer, write_size, 0);
>   config_nand_cw_write(nandc);
>  
>   ret = submit_descs(nandc);
> @@ -2174,48 +2203,6 @@ static int qcom_nandc_write_oob(struct mtd_info *mtd, 
> struct nand_chip *chip,
>   return nand_prog_page_end_op(chip);
>  }
>  
> -static int qcom_nandc_block_markbad(struct mtd_info *mtd, loff_t ofs)
> -{
> - struct nand_chip *chip = mtd_to_nand(mtd);
> - struct qcom_nand_host *host = to_qcom_nand_host(chip);
> - struct qcom_nand_controller *nandc = 

[PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-07-06 Thread Abhishek Sahu
The NAND base layer calls write_oob() by setting bytes at
chip->badblockpos with value non 0xFF for updating bad block status.
The QCOM NAND controller skips the bad block bytes while doing normal
write with ECC enabled. When initial support for this driver was
added, the driver specific function was added temporarily for
block_markbad() with assumption to change for raw read in NAND base
layer. Moving to raw read for block_markbad() seems to take more time
so this patch removes driver specific block_markbad() function by
using following HACK in write_oob() function.

Check for BBM bytes in OOB and accordingly do raw write for updating
BBM bytes in NAND flash or normal write for updating available OOB
bytes.

Signed-off-by: Abhishek Sahu 
---
 drivers/mtd/nand/raw/qcom_nandc.c | 103 +++---
 1 file changed, 40 insertions(+), 63 deletions(-)

diff --git a/drivers/mtd/nand/raw/qcom_nandc.c 
b/drivers/mtd/nand/raw/qcom_nandc.c
index ea253ac..df12cf3 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -2138,28 +2138,57 @@ static int qcom_nandc_write_oob(struct mtd_info *mtd, 
struct nand_chip *chip,
struct qcom_nand_host *host = to_qcom_nand_host(chip);
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
struct nand_ecc_ctrl *ecc = >ecc;
-   u8 *oob = chip->oob_poi;
-   int data_size, oob_size;
+   u8 *oob = chip->oob_poi, bbm_byte;
+   int data_size, oob_size, bbm_offset, write_size;
int ret;
 
-   host->use_ecc = true;
clear_bam_transaction(nandc);
 
-   /* calculate the data and oob size for the last codeword/step */
-   data_size = ecc->size - ((ecc->steps - 1) << 2);
-   oob_size = mtd->oobavail;
+   /*
+* The NAND base layer calls ecc->write_oob() by setting bytes at
+* chip->badblockpos (chip->badblockpos will be 0 for QCOM NAND
+* controller layout) in OOB buffer with value other that 0xFF
+* for updating bad block status. QCOM NAND controller skips
+* BBM bytes while writing with ECC, so following HACK has been
+* added in this function for using generic block_markbad() function.
+*
+* Check for BBM bytes in OOB and accordingly do raw write for
+* updating BBM bytes in NAND flash or normal write with ECC for
+* updating available OOB bytes.
+*/
+   bbm_byte = oob[0];
+   if (chip->options & NAND_BUSWIDTH_16)
+   bbm_byte &= oob[1];
 
-   memset(nandc->data_buffer, 0xff, host->cw_data);
-   /* override new oob content to last codeword */
-   mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size, oob,
-   0, mtd->oobavail);
+   /* Write BBM bytes by doing raw write. */
+   if (bbm_byte != 0xff) {
+   host->use_ecc = false;
+   memset(nandc->data_buffer, 0xff, host->cw_size);
+   /* Determine the BBM bytes position and update the same */
+   bbm_offset = mtd->writesize - host->cw_size * (ecc->steps - 1);
+   memcpy(nandc->data_buffer + bbm_offset, oob, host->bbm_size);
+   write_size = host->cw_size;
+   /* Write OOB bytes by doing normal write with ECC */
+   } else {
+   host->use_ecc = true;
+   /* calculate the data and oob size for the last codeword/step */
+   data_size = ecc->size - ((ecc->steps - 1) << 2);
+   oob_size = mtd->oobavail;
+
+   memset(nandc->data_buffer, 0xff, host->cw_data);
+   /* override new oob content to last codeword */
+   mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size,
+   oob, 0, mtd->oobavail);
+
+   write_size = data_size + oob_size;
+   }
 
set_address(host, host->cw_size * (ecc->steps - 1), page);
update_rw_regs(host, 1, false);
 
config_nand_page_write(nandc);
write_data_dma(nandc, FLASH_BUF_ACC,
-  nandc->data_buffer, data_size + oob_size, 0);
+  nandc->data_buffer, write_size, 0);
config_nand_cw_write(nandc);
 
ret = submit_descs(nandc);
@@ -2174,48 +2203,6 @@ static int qcom_nandc_write_oob(struct mtd_info *mtd, 
struct nand_chip *chip,
return nand_prog_page_end_op(chip);
 }
 
-static int qcom_nandc_block_markbad(struct mtd_info *mtd, loff_t ofs)
-{
-   struct nand_chip *chip = mtd_to_nand(mtd);
-   struct qcom_nand_host *host = to_qcom_nand_host(chip);
-   struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
-   struct nand_ecc_ctrl *ecc = >ecc;
-   int page, ret;
-
-   clear_read_regs(nandc);
-   clear_bam_transaction(nandc);
-
-   /*
-* to mark the BBM as bad, we flash the entire last codeword with 0s.
-* we don't care about the rest of the 

[PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function

2018-07-06 Thread Abhishek Sahu
The NAND base layer calls write_oob() by setting bytes at
chip->badblockpos with value non 0xFF for updating bad block status.
The QCOM NAND controller skips the bad block bytes while doing normal
write with ECC enabled. When initial support for this driver was
added, the driver specific function was added temporarily for
block_markbad() with assumption to change for raw read in NAND base
layer. Moving to raw read for block_markbad() seems to take more time
so this patch removes driver specific block_markbad() function by
using following HACK in write_oob() function.

Check for BBM bytes in OOB and accordingly do raw write for updating
BBM bytes in NAND flash or normal write for updating available OOB
bytes.

Signed-off-by: Abhishek Sahu 
---
 drivers/mtd/nand/raw/qcom_nandc.c | 103 +++---
 1 file changed, 40 insertions(+), 63 deletions(-)

diff --git a/drivers/mtd/nand/raw/qcom_nandc.c 
b/drivers/mtd/nand/raw/qcom_nandc.c
index ea253ac..df12cf3 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -2138,28 +2138,57 @@ static int qcom_nandc_write_oob(struct mtd_info *mtd, 
struct nand_chip *chip,
struct qcom_nand_host *host = to_qcom_nand_host(chip);
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
struct nand_ecc_ctrl *ecc = >ecc;
-   u8 *oob = chip->oob_poi;
-   int data_size, oob_size;
+   u8 *oob = chip->oob_poi, bbm_byte;
+   int data_size, oob_size, bbm_offset, write_size;
int ret;
 
-   host->use_ecc = true;
clear_bam_transaction(nandc);
 
-   /* calculate the data and oob size for the last codeword/step */
-   data_size = ecc->size - ((ecc->steps - 1) << 2);
-   oob_size = mtd->oobavail;
+   /*
+* The NAND base layer calls ecc->write_oob() by setting bytes at
+* chip->badblockpos (chip->badblockpos will be 0 for QCOM NAND
+* controller layout) in OOB buffer with value other that 0xFF
+* for updating bad block status. QCOM NAND controller skips
+* BBM bytes while writing with ECC, so following HACK has been
+* added in this function for using generic block_markbad() function.
+*
+* Check for BBM bytes in OOB and accordingly do raw write for
+* updating BBM bytes in NAND flash or normal write with ECC for
+* updating available OOB bytes.
+*/
+   bbm_byte = oob[0];
+   if (chip->options & NAND_BUSWIDTH_16)
+   bbm_byte &= oob[1];
 
-   memset(nandc->data_buffer, 0xff, host->cw_data);
-   /* override new oob content to last codeword */
-   mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size, oob,
-   0, mtd->oobavail);
+   /* Write BBM bytes by doing raw write. */
+   if (bbm_byte != 0xff) {
+   host->use_ecc = false;
+   memset(nandc->data_buffer, 0xff, host->cw_size);
+   /* Determine the BBM bytes position and update the same */
+   bbm_offset = mtd->writesize - host->cw_size * (ecc->steps - 1);
+   memcpy(nandc->data_buffer + bbm_offset, oob, host->bbm_size);
+   write_size = host->cw_size;
+   /* Write OOB bytes by doing normal write with ECC */
+   } else {
+   host->use_ecc = true;
+   /* calculate the data and oob size for the last codeword/step */
+   data_size = ecc->size - ((ecc->steps - 1) << 2);
+   oob_size = mtd->oobavail;
+
+   memset(nandc->data_buffer, 0xff, host->cw_data);
+   /* override new oob content to last codeword */
+   mtd_ooblayout_get_databytes(mtd, nandc->data_buffer + data_size,
+   oob, 0, mtd->oobavail);
+
+   write_size = data_size + oob_size;
+   }
 
set_address(host, host->cw_size * (ecc->steps - 1), page);
update_rw_regs(host, 1, false);
 
config_nand_page_write(nandc);
write_data_dma(nandc, FLASH_BUF_ACC,
-  nandc->data_buffer, data_size + oob_size, 0);
+  nandc->data_buffer, write_size, 0);
config_nand_cw_write(nandc);
 
ret = submit_descs(nandc);
@@ -2174,48 +2203,6 @@ static int qcom_nandc_write_oob(struct mtd_info *mtd, 
struct nand_chip *chip,
return nand_prog_page_end_op(chip);
 }
 
-static int qcom_nandc_block_markbad(struct mtd_info *mtd, loff_t ofs)
-{
-   struct nand_chip *chip = mtd_to_nand(mtd);
-   struct qcom_nand_host *host = to_qcom_nand_host(chip);
-   struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
-   struct nand_ecc_ctrl *ecc = >ecc;
-   int page, ret;
-
-   clear_read_regs(nandc);
-   clear_bam_transaction(nandc);
-
-   /*
-* to mark the BBM as bad, we flash the entire last codeword with 0s.
-* we don't care about the rest of the