[u-boot][PATCH 04/14] mtd: rawnand: omap_gpmc: Optimize NAND reads

[Roger Quadros]

Hi Michael,

On 17/10/2022 09:39, Michael Nazzareno Trimarchi wrote:
> Hi Roger
> 
> On Sat, Oct 15, 2022 at 3:29 PM Roger Quadros <rogerq at kernel.org> wrote:
>>
>> Hi Michael,
>>
>> On 15/10/2022 10:24, Michael Nazzareno Trimarchi wrote:
>>> Hi
>>>
>>> On Tue, Oct 11, 2022 at 1:50 PM Roger Quadros <rogerq at kernel.org> wrote:
>>>>
>>>> Rename omap_nand_read() to omap_nand_read_buf() to reflect
>>>> actual behaviour.
>>>>
>>>> Use FIFO read address instead of raw read address for reads.
>>>>
>>>> The GPMC automatically converts 32-bit/16-bit reads to NAND
>>>> device specific reads (8/16 bit). Use the largest possible
>>>> read granularity size for more efficient reads.
>>>>
>>>> Signed-off-by: Roger Quadros <rogerq at kernel.org>
>>>> ---
>>>>  drivers/mtd/nand/raw/omap_gpmc.c | 49 ++++++++++++++++++--------------
>>>>  1 file changed, 28 insertions(+), 21 deletions(-)
>>>>
>>>> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
>>>> index d62c3e6fce..b36fe762b3 100644
>>>> --- a/drivers/mtd/nand/raw/omap_gpmc.c
>>>> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
>>>> @@ -55,6 +55,7 @@ struct omap_nand_info {
>>>>         enum omap_ecc ecc_scheme;
>>>>         uint8_t cs;
>>>>         uint8_t ws;             /* wait status pin (0,1) */
>>>> +       void __iomem *fifo;
>>>>  };
>>>>
>>>>  /* We are wasting a bit of memory but al least we are safe */
>>>> @@ -350,6 +351,20 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const uint8_t *dat,
>>>>         return 0;
>>>>  }
>>>>
>>>> +static inline void omap_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
>>>> +{
>>>> +       struct nand_chip *chip = mtd_to_nand(mtd);
>>>> +       struct omap_nand_info *info = nand_get_controller_data(chip);
>>>> +       u32 alignment = ((uintptr_t)buf | len) & 3;
>>>> +
>>>> +       if (alignment & 1)
>>>> +               readsb(info->fifo, buf, len);
>>>> +       else if (alignment & 3)
>>>> +               readsw(info->fifo, buf, len >> 1);
>>>> +       else
>>>> +               readsl(info->fifo, buf, len >> 2);
>>>> +}
>>>> +
> 
> Can you optimize more I think here.You can consider the disaligment
> portion and then read at max len. You read more
> than the actual lens but I think it should not be a big problem. In

This will overrun the passed buffer and we don't want to take that risk?

> case of SPL you can use byte read and then can reduce
> the code size here

Apart from some legacy chips SPL size is not a huge problem. So
unless we are sure that we can actually run this driver in SPL
there is no point in doing any SPL optimizations now.

> 
> Michael

cheers,
-roger