Re: [RFC PATCH 3/6] mtd: spi-nor: core: run calibration when initialization is done

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux