[RFC PATCH 3/6] mtd: spi-nor: core: run calibration when initialization is done
Pratyush Yadav
p.yadav at ti.com
Mon Jun 27 03:35:54 PDT 2022
On 27/06/22 11:43AM, Cédric Le Goater wrote:
> On 6/27/22 11:14, Pratyush Yadav wrote:
> > On 18/05/22 10:51AM, Cédric Le Goater wrote:
[...]
>
> > > > This series does that by looking at the MTD
> > > > partitions. For that to happen, we need to create those partitions
> > > > first, which happens after mtd_device_register().
> > >
> > > hmm, that might work for some boards. This is not at all the case for
> > > the BMC boards. Vendors can put any kind of flash model and/or layout
> > > and the driver needs to be more generic.
> >
> > Yes, vendors can choose any layout, but one partition on that layout
> > would be your calibration pattern. I think you can use a different
> > compatible for that partition.
>
> OK. and that it would become more generic then.
>
> > I have not thought this through yet though.
>
> If a partition is required, that's a dependency on mtdpart.
>
> It could be done from spi_nor_probe() after mtd_device_register() with
> some spimem handler using the 'struct mtd_partition' for the {size,offset}
> parameters.
Hmm, yes but I've got this feedback from multiple people that we should
not do the calibration after mtd_device_register() since at that point
the device is usable from userspace. Maybe we can come up with an API
from MTD parsers that can just return us a list of partitions but not
actually register them?
>
> > >
> > > > But I am planning to use device tree to get that information now so this
> > > > should no longer be needed and we can do calibration before registering
> > > > the device with MTD.
> > >
> > > Perfect, we can move the calibration hook in spi_nor_create_read_dirmap()
> > > then, or in devm_spi_mem_dirmap_create(), which would make more sense IMHO.
> >
> > Sorry, I still don't get why you want to tie dirmap and calibration
> > together. Just let them be independent and let flash drivers take care
> > of when to call what. SPI MEM should not care.
>
> I know you would prefer a specific handler and that can still be done.
>
> Thanks,
>
> C.
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
More information about the linux-arm-kernel
mailing list