Hi Adam,
On Mon, 8 Oct 2018 11:13:40 -0500 Adam Ford aford173@gmail.com wrote:
On Wed, Oct 3, 2018 at 8:41 AM Adam Ford aford173@gmail.com wrote:
On Wed, Oct 3, 2018 at 8:35 AM Miquel Raynal miquel.raynal@bootlin.com wrote:
Hi Adam,
> > I can use the nand read/write functions and mtdparts lists the > partitions, so I know nand works. My defconfig > lists the partitions, so if we're not supposed to use mtdparts, where > I do store the partition information?
You are not supposed to use the mtdpart _command_, but the mtdparts _variable_ must be used in order to declare the partitions.
OK. If I can get MTD working, I'll work to remove the other commands like NAND and MTDPARTS
As of today, the process of migration is not entirely finished to DM and you might still need to issue *first* a "nand probe" to register the device operations.
Mmmh there is no nand probe actually, for raw nands like the one you have it should work out of the box.
i haven't actually insterted debug code yet, but I started a quick code review. There is a function called 'mtd_probe_uclass_mtd_devs' which states it will probe with DM compliant drivers. I am thinking the nand and/or GPMC drivers are not yet DM compliant yet. The DM tree doesn't list any of the MTD parts.
Is it save to assume it just wont' work until the drives are DM compliant, or is this driver designed to play with the lower-level drivers as-is?
The whole point of this rework was to allow both old (non-DM compliant) and new (DM compliant) drivers to be exposed the same way to the upper layers. If it doesn't work for regular NAND drivers it's a bug, and we should fix it.
Regards,
Boris