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 <rog...@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 <rog...@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 <rog...@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