-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Balaji Rao wrote: > Hi, > > As Mark had pointed out, I have changed the pcf50633 regulator driver to > use the new regulator API. > > But I haven't been able to convert existing users of pcf50633_voltage_set > to use the regulator API. The ordering of initialization seems to cause > problems when the regulator appears after the device does. I > get a "can't get regulator xxxx" message, followed by a OOPS. > > What can be done here ?
andy-tracking changes about device tree reordering will fix this. I will shortly move that patchset into stable-tracking. It's worth looking at mach-gta02.c on that branch http://git.openmoko.org/?p=kernel.git;a=blob;f=arch/arm/mach-s3c2440/mach-gta02.c;h=eb940e3d19bc5e4f2c79d02097fd9208333ededf;hb=andy-tracking#l1574 you can see that we now only create a lot of devices as children of the PMU only at the end of PMU probe. This resolves all of these races. > This change in API also removed the flexibility of defining constraints > and consumer-supply relationships at different places. For the glamo-mci > device, which uses needs a regulator, the platform_device is > available in glamo-core.c. Hence this does not allow us to define the > corresponding regulator_init_data in mach-gta02.c. The only solution I > see is to move the glamo-mci platform device into mach-gta02.c. Mark, > can you please suggest me something ? Currently we solve this problem by piggybacking engine-specific platform data into struct glamofb_platform_data. You will see there MCI-specific entries like .glamo_set_mci_power callback. For now I would just piggyback on that and the regulator init data there, glamo mci driver knows how to get at it in probe(). - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjyPhMACgkQOjLpvpq7dMqN7QCgkLO2C7rAXToxTDaGiH0xzu/0 PtgAmgPLyrSXsBghmAgBO/huP26dcKsk =KJsw -----END PGP SIGNATURE-----
